🚀 go-pugleaf

IMHO, one should be able to attach keymaps to each 'field' of the
modeline.  For example, one might have the following bindings:

%* (read-only): toggle-read-only

%b (buffer-name): pop up a muffer menu

display-time-string: pop up a menu of time related op's (e.g. edit-timers)

major/minor mode: pop up a mode selection menu

%p (percentage): scroll to reflect inc/dec'ing the digit clicked on

%l: (line number): goto-line

%n (narrow): widen

%[ (recursive-edit): jump to debugger at that level (if appropriate)

%S: (screen): pop up a screen menu

%s: (process-status): pop up a menu of process operations

One of the nice benefits of this scheme is that the modeline is often
much closer to the pointer than the menubar so that it is quicker to
do certain mouse op's from the modeline (e.g. buffer selection).

But of course the biggest benefit is the WYSIWYG style editing: any
element of editor state that is displayed graphically may be modified
via clicking on it. This is a tremendous help for novices.

Implementing this would probably require new support from the code
that displays the mode-line, in particular display_mode_element would
need to save the 'hpos' for each element so that it could be accessed
later from elisp code.

It is a kludge the way the mode-line is currently hardwired into the
display engine. Instead, the mode-line should just be a normal window
and the 'display_mode_line' functionality should be lifted up to elisp
level, perhaps by introducing a means for having lines in buffers that
are constructed dynamically from modeline elements (e.g. one could
introduce a special type of extent for this purpose).  In particular,
this would allow multi-line modelines and would be a step in the
direction of allowing full elisp control of the display--which is
crucial if one wants to build other apps on top of emacs.

Perhaps Chuck can tell us if any of this proposal has already been
anticipated in the xemacs 19.12 display engine.