[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: [OT] fixing emacs
From: |
Tom Lord |
Subject: |
[Gnu-arch-users] Re: [OT] fixing emacs |
Date: |
Wed, 3 Sep 2003 10:54:25 -0700 (PDT) |
> 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_.
- [Gnu-arch-users] Re: [OT] fixing emacs, Stephen J. Turnbull, 2003/09/01
- [Gnu-arch-users] Re: [OT] fixing emacs, Tom Lord, 2003/09/01
- [Gnu-arch-users] Re: [OT] fixing emacs, Stephen J. Turnbull, 2003/09/01
- [Gnu-arch-users] Re: [OT] fixing emacs, Tom Lord, 2003/09/01
- [Gnu-arch-users] Re: [OT] fixing emacs, Stephen J. Turnbull, 2003/09/02
- [Gnu-arch-users] Re: [OT] fixing emacs, Tom Lord, 2003/09/02
- [Gnu-arch-users] Re: [OT] fixing emacs, Stephen J. Turnbull, 2003/09/02
- [Gnu-arch-users] Re: [OT] fixing emacs, Tom Lord, 2003/09/02
- [Gnu-arch-users] Re: [OT] fixing emacs, Stephen J. Turnbull, 2003/09/03
- [Gnu-arch-users] Re: [OT] fixing emacs,
Tom Lord <=
- [Gnu-arch-users] Re: [OT] fixing emacs, Stephen J. Turnbull, 2003/09/03