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

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>

    > Right.  XEmacs is a sandbox.  As long as it's a GNU Emacs, it's never
    > going to be the new Emacs.  Just a nice place to play with the
    > occasional nifty sand castle that crumbles when the sun shines on it
    > too long.

That's probably the bottom line.

BTW, why does the xemacs.el version of "help.el" contain the string
"-menu-" but the Emacs 20.3 version does not? [1]


    > changes in one instance of a subwindow glyph are not reflected
    > in another instance of the same subwindow glyph

That's a good snapshot of the essense of the issue.

As far as I can tell, generalized subwindows and glyphs generalize the
idea of frame and window decorations -- formerly limited to just menu
bars and scrollbars. [1]

I'm pushing for a generalization of buffers and (ordinary) Emacs
windows:  a buffer being "a thing Emacs let's you edit" and a window
being "an interactive display of a buffer".

By "(ordinary) Emacs window" I mean such things as:

        *) You can get two copies of it with M-x split-window

        *) It can be the "(selected-window)",  M-x other-window
           can select it

        *) It's looking at a buffer.  You can get a currently
           invisible interface with something like

           M-x switch-to-buffer RET abrowse:address@hidden RET

           Perhaps I can save the state of my arch browser with 
           M-x save-buffer and restart it with that state using
           M-x find-file.

        *) Emacs programs don't change GUI windows by talking
           directly to widgets -- they change the state of a buffer
           and this causes all visible instances of GUI windows on
           that buffer to be updated.  (Exceptions, of course, for
           ephemeral choices such as window size or default colors.)

You don't like the idea of parsing text.    That's fine -- there's
other ways to do it.   However, I think there's some desirable 
properties of that idea to preserve, including:

        (a) you can save/load an interface by writing/reading a file
            with property annotations

        (b) "(point)" is meaningful.    It may be, for some 
            widget types, that you have "sub-point positioning"
            of some sort -- but the key thing is to extend the
            usefulness of lisp programs that manipulate "(point)"
            (such as i-search or ispell-word or various abbrev
            expansion commands or hooks into M-x calc or M-x yank
            or .....).

        (c) other than the lowest-level lisp functions for a new 
            widget type, most lisp programs should be agnostic about
            whether or not they are being called from a text display
            of the buffer or a GUI display of the buffer.   As always,
            they're just editting a buffer -- not a display.

        (d) for the large class of interfaces that have a natural
            representation on a text-only display, the buffer
            representation of the interface should double as such
            a display.


Take it as hypothesis that a design satisfying (a..d) is possible and
come up with your own!


Taking you a little out of context:

       > [hack idea on top of a text/GUI outline widget]

       > But you really, really want to support it, right?  Isn't this kind of
       > "just drop in a widget, _any_ widget" application building what you
       > mean by "expressive power"?  (And even if your opinion of my UI design
       > skills just rode over Yosemite Falls in a canteen full of Charles
       > Gallo, shouldn't this kind of idiocy be trivial to _try and see_?)

No -- I don't care about arbitrary generality.  This is Emacs, not
Java.  I care about the greatest amount of generality that "fits" --
which may very well turn out to be more useful than Java.


-t

[1] about generalized subwindows / glyphs

    The generalized subwindow / glyphs stuff doesn't appear to work as
    i would have expected.  In particular, I would have expected it to
    implement "virtual input devices" which generate ordinary emacs
    events -- not callbacks.  That's how menus and scrollbars worked
    and it's a good design because it fits in with the interact loop
    and help subsystems in natural ways.

    You wonder why people aren't taking that functionality and running
    with it.   Well, in my case, I don't care at all about
    fully-general window decorations (and the dialog stuff doesn't fit
    in well enough with the ordinary minibuffer for me to be excited
    about that -- it looks like a descendent of something that was
    slapped onto lucid in order to "give good demo" and maybe save the
    place: "See, we can do pop-ups!".)

    Sure, emacs could use toolbars as a new kind of frame decoration.

    And I think it could also use a different style of menu -- not
    pull-downs but a compact hypertext of commands divided into
    categories.  

    Beyond that?   Who cares?   I don't _want_ generality there -- I
    want a _small_number_ of useful virtual input devices, driven
    automagically from keymaps and similar structures.   

    Above all, I want _uniformity_ -- so that these extra decorations 
    simply fall out of my major mode definitions without having to do
    much else besides that -- so that users really _get_ the taxonomy
    of frames, windows, and buffers at a visceral level.

    Yes, I understand that for toolbars you're pretty much there
    (although why they don't generate events of types like [toolbar
    save-buffer] I can't figure).  But you got there with about 10x
    more mechanism that you actually needed.  I don't think you need
    first-class glyphs for that purpose _at_all_.