Re: Global bar to display global information

[Jérémy Compostella]

Drew Adams <drew.adams <at> oracle.com> writes:
> 
> > If [reusing the minibuffer area] is not possible or convenient,
> > a dedicated line on each frame looks like the next choice.
> > If it is on each frame then the feature doesn't really factor out the
> global info.  Since you use only one frame, "on each frame" just hides
> the general-case duplication from you.


> > (If the global info line is displayed on just one frame, what
> > happens when the user creates a new frame on a remote display?)
> 
> Dunno.  (But why would you want this info on *each* remote frame?)
> 
> So make it one frame per display (remotes + local), instead of just
> one frame overall.  Or I suppose users could configure some option to
> specify just which frames to use...  (Hello, Martin )
> 
> Essentially, what's requested is some stable place to post (and leave
> posted) a bit of general info - info that is not specific to any
> buffer or window or frame...
> 
> What you feel about windows should also hold for frames: get rid of
> the duplication.  That you use only one frame does not mean that that
> need goes away for others who might like the feature.
> 
> It makes most sense not to duplicate that info anywhere, with the
> possible exception I guess that it could be available (once) on each
> display (e.g. each remote display, plus local).
> 
> That means not on every frame and not on every window.  It means
> either giving it its own, dedicated frame (frames, if we include
> remote) or posting it in some existing frame (e.g. standalone
> minibuffer frame).
> 
> And the info need not be limited to a single line.  Especially if it
> is in a dedicated frame, it could use any number of lines.
> 
> This could be done easily now, just by using a dedicated frame.
> Instead of posting your global info to the mode line, just display it
> in a buffer that uses a special frame (which is dedicated).
> 
> Yes, that's different from (somehow) gathering up some common, global
> stuff from existing mode lines and displaying it elsewhere.  But how
> to identify such factorable info in existing mode lines?
> 
> Anyway, it sounds like the main case (OP) was user code that displays
> such stuff in the mode line.  If that hurts then don't do it -
> instead, put it in a special-display buffer in its own frame.
> 
> For my part, I still think it could be useful to (be able to) add the
> info to a standalone minibuffer frame.  One difference from having a
> separate frame for it is that that would save the real estate of an
> extra frame title and border.

What I imagine is more like a mode-line bar with the current
configuration associated to current Emacs server.

The user could enable this global bar and modify a simple
global-line-format (like the mode-line-format) to add whatever
information he wants.

I'm currently using Emacs 23. And I really think it looks inconsistent
about some features. What does the display-time feature means ? I think
it does not make any sense to have the date and time displayed on each
window. As most user, I activate this feature to be able to have the
date and time visible even when my underlined desktop environment is
hidden or disabled. I just want to be able to see the date and time at
the same place every time I need.

As another example, I developed a personal activity manager (looks like
the usual multi-desktop feature except that each desktop is named and
changes between desktop is managed through a stack). And I want to
display the current activity name. I do it modifying the
mode-line-format but this information is redundant over the all the
window on the same frame. This information should be factored by
frame. Like the date and time it does not make any sense for me to have
this information displayed on each frame.

Currently my mode-line is very long in some mode and some information
should not be on this mode-line (date/time, jabber notification, current
activity, ...). I think the configuration (global-line-format) should be
associated to each Emacs server but displaying this bar should be a frame
dependant user choice.