[Gnu-arch-users] Re: [OT] fixing emacs

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>
    > >>>>> "Tom" == Tom Lord <address@hidden> writes:
    > 
    >     Tom> Either you've misunderstood what I've proposed or you have a
    >     Tom> web site problem in the sense that your website gives no
    >     Tom> obvious hint of these capabilities.
    > 
    > Deeper than that, we have a developer discipline problem.  The
    > developer who put this stuff in (before I took over the code base that
    > became 21.4) only wanted to make sure that those features were
    > available so he could produce a reasonable facsimile of Windows
    > facilities for Windows users.  This stuff is basically undocumented,
    > except for a brief mention in the docstring to "make-glyph".  I'm not
    > sure who let this stuff get in to a release-track code base with so
    > little documentation.

A couple of things:

a) I can't even freekin' build out of the box on my box.  This is
   lame.  The particular error message from configure says that it
   can't use certain combinations of options with the particular
   version of GCC that I use (and that I use for good reason).

   Well, fine -- then don't use those options and compile.

   I'm scared to imagine what other kinds of 3rd party packages i'll
   have to install and pass as params to Xemacs configure before
   it can show off.


b) I have the general impression, when you start talking about glyphs,
   that you mean you can put up a text buffer in which there are 
   some embedded widgets.   That isn't what I proposed.

   Rather, I want certain buffers that, when I have a window on those
   buffers, the emacs text redisplay isn't involved at all.   Instead,
   there's a widget-tree in that window -- whose structure is
   (dynamically) determined by the contents of the text buffer.


c) How far are you, really, from being able to mutually merge with
   GNU emacs.   Two forks is cool -- one-way forks is lame.


    > I hope you're not wasting your time.  My point is not that this stuff
    > is wonderful; it's that it is available, could be improved rapidly,
    > but nobody cares enough to (a) improve it (core developers) or (b)
    > request it (3rd party library developers).

I won't let you waste my time.

I'm trying to sketch a practical plan for improving it that is better
than the plans you have advertised (with all due respect).


    > I think a reasonable test of the facility (as _proof of concept_ for
    > usability) is if I can come up with a "native layout"-style file
    > browser with the same functionality as the old-style "specialized
    > general frame" browser we currently have.  Let me know if the
    > implementation of the search dialog in dialog-items.el is
    > _conceptually_ way off what you're talking about.


Well, evidently, it's going to take at least a few days to even
build the damn thing.

-t