Global bar to display global information

Global bar to display global information

[Jérémy Compostella]

All,

As many user, I use Emacs as my full desktop environment on several
system (mainly GNU/Linux and Windows at work).  To be as independent as
possible, I use the mode-line to show information like current date and
time, jabber notifications, unread mail number, ... and I start Emacs in
full-screen.

The problem is since I use several windows (in Emacs term), these
information are duplicated and are not always visible. Indeed, the
mode-line bar is split in the middle of the information it displays.

I think it could be really great if Emacs would provide a global bar
based on the same mechanisms as the mode line but dedicated to this
kind of global information.

What is your opinion ? Is this subject already discussed before ?

Thanks,

Jérémy

RE: Global bar to display global information

[Drew Adams]

> I use the mode-line to show information like current date and
> time, jabber notifications, unread mail number, ... and I 
> start Emacs in full-screen.
> 
> The problem is since I use several windows (in Emacs term), these
> information are duplicated and are not always visible. Indeed, the
> mode-line bar is split in the middle of the information it displays.
> 
> I think it could be really great if Emacs would provide a global bar
> based on the same mechanisms as the mode line but dedicated to this
> kind of global information.  What is your opinion ? Is this subject
> already discussed before?

+1

I sort of recall this having been suggested before; dunno...

Personally, I think it would be a good (optional) behavior to provide,
especially for the case where a user has a standalone minibuffer frame.

Using a standalone minibuffer frame already removes the duplication of multiple
minibuffer/echo area lines.  That, and having a single, stable place to look for
messages and input text, is the raison d'etre of a standalone minibuffer.

This proposed feature is along the same lines.  But this would not have as its
goal to eliminate mode lines from individual windows.  It would instead just
free up some of that individual-window mode line space that might be used for
global info (not specific to the given buffer/window).

Re: Global bar to display global information

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

> +1

+1

[snip]

> This proposed feature is along the same lines.  But this would not
> have as its goal to eliminate mode lines from individual windows.  It
> would instead just free up some of that individual-window mode line
> space that might be used for global info (not specific to the given
> buffer/window).

I'll appreacite such feature.

Most of the time the minibuffer is an idle blank line at the bottom of
the frame. Using it for displaying some global info sounds quite
convenient. It could display the global info even while asking for
input, overwritting the area used by the info as necessary.

RE: Global bar to display global information

[Drew Adams]

> > This proposed feature is along the same lines.  But this would not
> > have as its goal to eliminate mode lines from individual 
> > windows.  It would instead just free up some of that
> > individual-window mode line space that might be used for global
> > info (not specific to the given buffer/window).
> 
> I'll appreacite such feature.
> 
> Most of the time the minibuffer is an idle blank line at the bottom of
> the frame. Using it for displaying some global info sounds quite
> convenient. It could display the global info even while asking for
> input, overwritting the area used by the info as necessary.

Ouch!  That's not what I meant at all.  I would not want to see such info
displayed in the minibuffer/echo area itself (too complex, confusing,
distracting, messy, noisy).  

And we already have ways of posting text to the echo area (same space as
minibuffer) when the minibuffer is inactive: `message'.  That messages get
replaced by later messages and by minibuffer input is just a further
demonstration that using the minibuffer/echo area for this global info would be
a bad idea.

All I really meant was an analogy: In the same way that a standalone minibuffer
frame lets you factor out the multiple minibuffers into a single one, so some
kind of global mode line would let you factor out the common/global info from
the multiple mode lines into a single one.  Somewhere.

The feature needs to be optional in any case (obviously).  It could also be a
user choice where to put this global/common mode line.  Choices might be:

a. In a standalone minibuffer frame (if it exists), in its own dedicated space
within that frame (e.g. 1 line, 2 lines? extendable?), perhaps above the
minibuffer/echo area.

b. Standalone, in its own frame.

c. As a separate line in some existing frame (but in only one).  We'd need some
way to let users (and Lisp code) choose which frame.

d. ? ...

(As a user, I would choose (a).)

However, for (c), there would be the annoyance of not necessarily seeing the
info whenever the frame in question is somewhat occluded by another frame.

That could happen in (a) or (b) also, but there the frame could presumably be
positioned so that it is generally visible.  That's anyway what users (e.g. I)
do now for a minibuffer frame.  (Mine's across the bottom of the screen, and I
generally fit other frames, by default, so they don't overlap it.)

Another possibility here (for (a) & (b)) would be to provide an `always-on-top'
frame parameter that would cause its frame to never be occluded by other (Emacs)
frames (except possibly by another frame that also has non-nil `always-on-top').

Re: Global bar to display global information

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

>> Most of the time the minibuffer is an idle blank line at the bottom of
>> the frame. Using it for displaying some global info sounds quite
>> convenient. It could display the global info even while asking for
>> input, overwritting the area used by the info as necessary.
>
> Ouch!  That's not what I meant at all.

I know. It was an alternative idea.

> I would not want to see such info displayed in the minibuffer/echo
> area itself (too complex, confusing, distracting, messy, noisy).
>
> And we already have ways of posting text to the echo area (same space
> as minibuffer) when the minibuffer is inactive: `message'.  That
> messages get replaced by later messages and by minibuffer input is
> just a further demonstration that using the minibuffer/echo area for
> this global info would be a bad idea.

`message' is used for ephemeral info, very ephemeral (just a keypress
makes it go away). I was thinking about something stable that is hidden
(totally or partially) while the minibuffer/echo area is used for its
current purpose. But your comment about `message' makes me think that
*maybe* it would be confusing/distracting/etc when something is posted
to the echo area with `message' to be quickly replaced by the global
info. It may create a blinking effect.

I don't like standalone frames for things like the minibuffer or our
hypothetical global info display. I work on just one frame and reusing
the minibuffer area looks like a good idea, if it could be implemented
on a sane way. If that is not possible or convenient, a dedicated line
on each frame looks like the next choice.

(If the global info line is displayed on just one frame, what happens
when the user creates a new frame on a remote display?)

[snip]

Re: Global bar to display global information

[Stefan Monnier]

> And we already have ways of posting text to the echo area (same space
> as minibuffer) when the minibuffer is inactive: `message'.
> That messages get replaced by later messages and by minibuffer input
> is just a further demonstration that using the minibuffer/echo area
> for this global info would be a bad idea.

I tend to agree, tho it is also true that the echo area tends to be
empty most of the time, so it is tempting to try and use it to display
"permanent global non-urgent" info.  I probably wouldn't want that by
default, but it would be good for Emacs to make such a thing possible/easy.

Emacs-24 has introduced the minibuffer-inactive-mode which lets you
setup key-bindings for this "empty" inactive thingy, but it has lots
of quirks (e.g. mouse event bindings seem to work well, but key event
bindings only work for minibuffer-only frames).

The inactive/empty echo area is actually displaying a buffer (the buffer
named " *Minibuf-0*", IIUC), so technically it shouldn't be too
difficult to create a package that inserts useful stuff in that buffer
so they get displayed in the echo area when nothing else is shown there.

> a. In a standalone minibuffer frame (if it exists), in its own
> dedicated space within that frame (e.g. 1 line, 2 lines? extendable?),
> perhaps above the minibuffer/echo area.

Shouldn't be too hard: create a normal (i.e. with minibuffer, and not
minibuffer-only) frame of the appropriate size, make it display
a special buffer whose mode-line-format is set to nil and whose content
shows whatever you want to see there.

> b. Standalone, in its own frame.

Same thing, but without the minibuffer.

Overall, it sounds like it shouldn't be too hard to make up a little
package that fills a buffer with useful global info
(time/battery/mail/younameit) and then lets you choose where you want to
display it (separate frame, inactive minibuffer, ...).


        Stefan

RE: Global bar to display global information

[Drew Adams]

> 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.

Re: Global bar to display global information

[joakim]

Óscar Fuentes <ofv@wanadoo.es> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> +1
>
> +1
>
> [snip]
>
>> This proposed feature is along the same lines.  But this would not
>> have as its goal to eliminate mode lines from individual windows.  It
>> would instead just free up some of that individual-window mode line
>> space that might be used for global info (not specific to the given
>> buffer/window).
>
> I'll appreacite such feature.
>
> Most of the time the minibuffer is an idle blank line at the bottom of
> the frame. Using it for displaying some global info sounds quite
> convenient. It could display the global info even while asking for
> input, overwritting the area used by the info as necessary.
>

I think it is possible to do such things with Martins new window code.


-- 
Joakim Verona

Re: Global bar to display global information

[chad]

Perhaps a header-line is what you want?

	C-h v header-line-format RET

*Chad

On Aug 16, 2011, at 7:33 AM, Jérémy Compostella wrote:

> All,
> 
> As many user, I use Emacs as my full desktop environment on several
> system (mainly GNU/Linux and Windows at work).  To be as independent as
> possible, I use the mode-line to show information like current date and
> time, jabber notifications, unread mail number, ... and I start Emacs in
> full-screen.
> 
> The problem is since I use several windows (in Emacs term), these
> information are duplicated and are not always visible. Indeed, the
> mode-line bar is split in the middle of the information it displays.
> 
> I think it could be really great if Emacs would provide a global bar
> based on the same mechanisms as the mode line but dedicated to this
> kind of global information.
> 
> What is your opinion ? Is this subject already discussed before ?
> 
> Thanks,
> 
> Jérémy
> 
> 
> 

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.

Re: Global bar to display global information

[chad]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]


On Aug 16, 2011, at 12:23 PM, Jérémy Compostella wrote:
> 
> I'm currently using Emacs 23. And I really think it looks inconsistent
> about some features. What does the display-time feature means ?
> […] I just want to be able to see the date and time at
> the same place every time I need.

For the vast majority of users, emacs is not their operating system, and 
such non-editing facilities don't need to be provided by their editor.  For 
those who do use emacs as (a larger part of) their operating system, 
they typically want very specific things, and know how to assemble those
things from the (many) parts emacs provides.  For example, Ted Zlanatov
was pushing forward an effort in this area:

	http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html

For some(including you), the header-line provides an easy way to meet
your goals, but others, like Drew Adams, live in a very multi-frame world,
and need different tools.

There is interest in this area, especially if you're willing to work on the
leading edge.  Perhaps you should try either header-line-format or Ted's
`Emacs as a Desktop Environment' idea and report back your experience
with either/both.

Hope that helps,
*Chad


[-- Attachment #2: Type: text/html, Size: 1951 bytes --]

Re: Global bar to display global information

[chad]

On Aug 16, 2011, at 12:46 PM, chad wrote:

>> 
>>   For example, Ted Zlanatov was pushing forward an effort in this area:

That should have been `Ted Zlatanov'.  My apologies.

*Chad

Re: Global bar to display global information

[Thien-Thi Nguyen]

() "Drew Adams" <drew.adams@oracle.com>
() Tue, 16 Aug 2011 10:42:41 -0700

   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...

Perhaps ‘message’ could be extended to recognize a distinguished text property
and arrange for that text to be placed in a *State of the Emacs* buffer
(perhaps indexed/formatted/prettified in some way by that property's value),
in addition to being added to *Messages*.  Something like:

  (defun message/stateful (category fmt &rest args)
    (message "%s" (propertize (apply 'format fmt args)
                              'message/stateful
                              category)))
  
  (defun note-stateful (category text)
    (with-current-buffer "*State of the Emacs*"
      (goto-char (GOOD-PLACE-FOR category text))
      (apply 'delete-region (REGION-OF-OLD category))
      (insert (APPROPRIATELY-DECORATED category text))))

where ‘note-stateful’ is called by ‘Fmessage’.

Re: Global bar to display global information

[Jérémy Compostella]

chad <yandros <at> MIT.EDU> writes:

> 
> 
> 
> On Aug 16, 2011, at 12:23 PM, Jérémy Compostella wrote:
> 
> I'm currently using Emacs 23. And I really think it looks inconsistentabout
some features. What does the display-time feature means ?
> […] I just want to be able to see the date and time atthe same place every
time I need.
> 
> 
> For the vast majority of users, emacs is not their operating system, and 
> such non-editing facilities don't need to be provided by their editor.  For 
> those who do use emacs as (a larger part of) their operating system, 
> they typically want very specific things, and know how to assemble those
> things from the (many) parts emacs provides.  For example, Ted Zlanatov
> was pushing forward an effort in this area:
> 
> 	http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html
> 
> For some(including you), the header-line provides an easy way to meet
> your goals, but others, like Drew Adams, live in a very multi-frame world,
> and need different tools.
I really do understand that we have different usage of Emacs. However, the
feature I describe could be enable or not without any sides effects.

> There is interest in this area, especially if you're willing to work on the
> leading edge.  Perhaps you should try either header-line-format or Ted's
> `Emacs as a Desktop Environment' idea and report back your experience
> with either/both.
As long as I know, header-line-format is buffer related and not frame related.
Am I wrong ?
What is this Ted's `Emacs as a Desktop Environment' you are talking about ?

> Hope that helps,
> *Chad

Re: Global bar to display global information

[chad]

On Aug 16, 2011, at 1:54 PM, Jérémy Compostella wrote:

> As long as I know, header-line-format is buffer related and not frame related.
> Am I wrong ?

It is buffer- and not frame-associated, yes.  I was suggesting that you consider
building a way to have only the topmost window in a given frame display the
header-line.  This might be tricky in general, but since you're using a
desktop system of your own creation, it seems likely to be easier for you.

For emacs in general, there is a lot of currently on-going work/discussion 
around frame and window parameters, so it's probably a bit too early to 
try to figure out such a mechanism for emacs24, but that's just an artifact 
of development right now.

> What is this Ted's `Emacs as a Desktop Environment' you are talking about ?

Some developers are pursing the idea of moving all of the `important' parts 
of the desktop environment inside emacs, or at least inside emacs' easy 
reach.  This includes `desktop widgets' and an associated `dock', that would
be in specialized frames/windows. It's closer to Thien-Thi Nguyen's idea
of a `special messages buffer' than your `global mode-line', but it could easily
serve both purposes, and other more gui-based uses as well. You can read
the discussion (from emacs-devel archives) starting here:

>> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html


*Chad

Re: Global bar to display global information

[Jérémy Compostella]

chad <yandros <at> MIT.EDU> writes:

> On Aug 16, 2011, at 1:54 PM, Jérémy Compostella wrote:
> 
> > As long as I know, header-line-format is buffer related and not
> > frame related.  Am I wrong ?
> [...]
> 
> For emacs in general, there is a lot of currently on-going
> work/discussion around frame and window parameters, so it's probably a
> bit too early to try to figure out such a mechanism for emacs24, but
> that's just an artifact of development right now.
OK I see your point. It seems to be a viable workaround except that :
how can I disable the mode-line for this topmost window ?

> > What is this Ted's `Emacs as a Desktop Environment' you are talking about ?
> 
> [...]
> >> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html
I'm reading this thread right now.

Re: Global bar to display global information

[Nicolas Martyanoff]

chad <yandros@MIT.EDU> writes:

> On Aug 16, 2011, at 1:54 PM, Jérémy Compostella wrote:
>
>> As long as I know, header-line-format is buffer related and not frame
>> related.  Am I wrong ?
>
> It is buffer- and not frame-associated, yes.  I was suggesting that
> you consider building a way to have only the topmost window in a given
> frame display the header-line.  This might be tricky in general, but
> since you're using a desktop system of your own creation, it seems
> likely to be easier for you.
But if you're using elscreen, the header-line is already used to display
the list of screens, right ?

>> What is this Ted's `Emacs as a Desktop Environment' you are talking
>> about ?
>
> Some developers are pursing the idea of moving all of the `important'
> parts of the desktop environment inside emacs, or at least inside
> emacs' easy reach.  This includes `desktop widgets' and an associated
> `dock', that would be in specialized frames/windows. It's closer to
> Thien-Thi Nguyen's idea of a `special messages buffer' than your
> `global mode-line', but it could easily serve both purposes, and other
> more gui-based uses as well. You can read the discussion (from
> emacs-devel archives) starting here:
>
>>> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html
While this project is really interesting, it seems an order of magnitude
more complex than adding an optional per-frame status window.

I have no idea about the complexity about adding this feature; there's
already a mini-buffer window which behaves in some aspects like a status
bar (split-independant width, fixed position, no mode line), so I
believe it would be possible to add a status bar just under (or above)
the minibuffer without modifying a ton of code.

Would someone know if it's possible to do it in emacs lisp, without
modifying the C code ? It would make developement much easier.

-- 
Nicolas Martyanoff
   http://codemore.org
   khaelin@gmail.com

Re: Global bar to display global information

[martin rudalics]

 > I have no idea about the complexity about adding this feature; there's
 > already a mini-buffer window which behaves in some aspects like a status
 > bar (split-independant width, fixed position, no mode line), so I
 > believe it would be possible to add a status bar just under (or above)
 > the minibuffer without modifying a ton of code.
 >
 > Would someone know if it's possible to do it in emacs lisp, without
 > modifying the C code ? It would make developement much easier.

With current trunk you can try (experimentally)

(display-buffer
  (get-buffer-create "foo")
  '((use-side-window bottom 0) (pop-up-window-set-height . 1)))

How you update the contents of foo is obviously entirely left to you.

martin

Re: Global bar to display global information

[Juri Linkov]

> With current trunk you can try (experimentally)
>
> (display-buffer
>  (get-buffer-create "foo")
>  '((use-side-window bottom 0) (pop-up-window-set-height . 1)))

I tried this code and get funny results: typing `C-x C-b' displays
the *Buffer List* buffer in that small 1-line window :)

So this window should be marked as dedicated.  A more compact specification
to do that could look like:

  (display-buffer "*global-mode-line*"
                  '(minibuffer . above) (dedicated . t) (height . 1))

Re: Global bar to display global information

[martin rudalics]

 > I tried this code and get funny results: typing `C-x C-b' displays
 > the *Buffer List* buffer in that small 1-line window :)
 >
 > So this window should be marked as dedicated.  A more compact specification
 > to do that could look like:
 >
 >   (display-buffer "*global-mode-line*"
 >                   '(minibuffer . above) (dedicated . t) (height . 1))

Frames don't necessarily have a minibuffer.  So currently this would be
done as

(display-buffer
  (get-buffer-create "*global-mode-line*")
  '((use-side-window bottom 0) (dedicate . t) (pop-up-window-set-height . 1)))

martin

Re: Global bar to display global information

[Nicolas Martyanoff]

martin rudalics <rudalics@gmx.at> writes:

>> I have no idea about the complexity about adding this feature; there's
>> already a mini-buffer window which behaves in some aspects like a status
>> bar (split-independant width, fixed position, no mode line), so I
>> believe it would be possible to add a status bar just under (or above)
>> the minibuffer without modifying a ton of code.
>>
>> Would someone know if it's possible to do it in emacs lisp, without
>> modifying the C code ? It would make developement much easier.
>
> With current trunk you can try (experimentally)
>
> (display-buffer
>  (get-buffer-create "foo")
>  '((use-side-window bottom 0) (pop-up-window-set-height . 1)))
>
> How you update the contents of foo is obviously entirely left to you.

I played a bit using your code and got encouraging results; I'll see
what I can do in the next days, and post on emacs-devel if I make
something useful.

Thank you for helping!

Regards,

-- 
Nicolas Martyanoff
   http://codemore.org
   khaelin@gmail.com

Re: Global bar to display global information

[Jérémy Compostella]

martin rudalics <rudalics <at> gmx.at> writes:

> 
>  > I tried this code and get funny results: typing `C-x C-b' displays
>  > the *Buffer List* buffer in that small 1-line window :)
>  >
>  > So this window should be marked as dedicated.  A more compact specification
>  > to do that could look like:
>  >
>  >   (display-buffer "*global-mode-line*"
>  >                   '(minibuffer . above) (dedicated . t) (height . 1))
> 
> Frames don't necessarily have a minibuffer.  So currently this would be
> done as
> 
> (display-buffer
>   (get-buffer-create "*global-mode-line*")
>   '((use-side-window bottom 0) (dedicate . t) (pop-up-window-set-height . 1)))
> 
I don't have a good Internet connexion on my vacation site so I can't get the
emacs repository and I can't test it right now. Could you explain what is the
result ?

Anyway, I was thinking that we could maybe use the echo area to provide globals
information like date/time or unread mail count. These information should not
appear in the *Messages* buffer of course. What is your opinion ?
 

Re: Global bar to display global information

[Stefan Monnier]

> Anyway, I was thinking that we could maybe use the echo area to
> provide globals information like date/time or unread mail count.

And I already explained how to do that in my earlier email in
this thread.


        Stefan

Re: Global bar to display global information

[Jérémy Compostella]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> 
> > Anyway, I was thinking that we could maybe use the echo area to
> > provide globals information like date/time or unread mail count.
> 
> And I already explained how to do that in my earlier email in
> this thread.
Yes. But first I wasn't really agree with this solution. Indeed I was more
thinking about a dedicated/specialized new bar and I confess I was a little bit
too rigid about others solutions. But one night after,
I think your solution is the best one among all the proposals in this thread to
solve this issue because it also solves the useless echo area issue and as I use
Emacs as my desktop environment I do like optimized space usage (I disable
scrollbar, menubar, window decoration, ...).

However, I don't have a reliable Internet access right now and I have to wait
Saturday to work on this solution. I will work on a package to format text like
you suggested.

Thanks for your help,

Jeremy

Re: Global bar to display global information

[Jérémy Compostella]

> [...]
> The inactive/empty echo area is actually displaying a buffer (the buffer
> named " *Minibuf-0*", IIUC), so technically it shouldn't be too
> difficult to create a package that inserts useful stuff in that buffer
> so they get displayed in the echo area when nothing else is shown there.

I finally downloaded the Emacs git repository and I do notfind any reference
to the *Minibuf-0* buffer you are talking about. Could help me ?

Re: Global bar to display global information

[chad]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]


On Aug 17, 2011, at 1:12 PM, Jérémy Compostella wrote:

> I finally downloaded the Emacs git repository and I do notfind any reference
> to the *Minibuf-0* buffer you are talking about. Could help me ?

FYI, there are a couple emacs git mirrors, but the actual repository is held
in bazaar, not git, and the git mirrors seem to lag anywhere between several hours and several weeks behind the actual development sources.

You can get more info on the development sources by visiting:

	http://savannah.gnu.org/projects/emacs

Hope that helps,
*Chad


[-- Attachment #2: Type: text/html, Size: 984 bytes --]

Re: Global bar to display global information

[Jérémy Compostella]

Nicolas Martyanoff <khaelin@gmail.com> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>>> I have no idea about the complexity about adding this feature; there's
>>> already a mini-buffer window which behaves in some aspects like a status
>>> bar (split-independant width, fixed position, no mode line), so I
>>> believe it would be possible to add a status bar just under (or above)
>>> the minibuffer without modifying a ton of code.
>>>
>>> Would someone know if it's possible to do it in emacs lisp, without
>>> modifying the C code ? It would make developement much easier.
>>
>> With current trunk you can try (experimentally)
>>
>> (display-buffer
>>  (get-buffer-create "foo")
>>  '((use-side-window bottom 0) (pop-up-window-set-height . 1)))
>>
>> How you update the contents of foo is obviously entirely left to you.
>
> I played a bit using your code and got encouraging results; I'll see
> what I can do in the next days, and post on emacs-devel if I make
> something useful.
>
I made some tries on my side. The above three lines of code provides an
interesting result. However, I have one important issue : when using the
minibuffer with more than one line, the "foo" buffer size is increased
and never come back to its original one line size.

Do you get interesting result on your side ?

Jérémy

Re: Global bar to display global information

[Óscar Fuentes]

Jérémy Compostella <jeremy.compostella@gmail.com> writes:

>>> With current trunk you can try (experimentally)
>>>
>>> (display-buffer
>>>  (get-buffer-create "foo")
>>>  '((use-side-window bottom 0) (pop-up-window-set-height . 1)))
>>>
>>> How you update the contents of foo is obviously entirely left to you.
>>
>> I played a bit using your code and got encouraging results; I'll see
>> what I can do in the next days, and post on emacs-devel if I make
>> something useful.
>>
> I made some tries on my side. The above three lines of code provides an
> interesting result. However, I have one important issue : when using the
> minibuffer with more than one line, the "foo" buffer size is increased
> and never come back to its original one line size.
>
> Do you get interesting result on your side ?

My "interesting" result is that eventually the `foo' buffer ends being
displayed on a regular window covering half the screen with its usual
modeline. That window wont go away easily (C-x 1 while the other window
is active has no effect).

I'm using a 1-month old Emacs, so maybe the above is due to bugs already
fixed.

Re: Global bar to display global information

[martin rudalics]

 > I made some tries on my side. The above three lines of code provides an
 > interesting result. However, I have one important issue : when using the
 > minibuffer with more than one line, the "foo" buffer size is increased
 > and never come back to its original one line size.

Basically, this problem can be resolved by making the window
fixed-height which would be needed anyway, for example, when resizing
the frame.

But the behavior you observe might hint at a more fundamental problem
with minibuffer resizing.  Can you produce it with (split-window nil -1)
for example?  Here the window goes back to a height of one when the echo
area is temporarily enlarged and goes back to one line.

martin

Re: Global bar to display global information

[martin rudalics]

 > My "interesting" result is that eventually the `foo' buffer ends being

What does "eventually" mean?

 > displayed on a regular window covering half the screen with its usual
 > modeline. That window wont go away easily (C-x 1 while the other window
 > is active has no effect).

That's part of the idea.  C-x 1 should not delete such windows and
should not make such a window the only one on its frame.

martin

Re: Global bar to display global information

[Óscar Fuentes]

martin rudalics <rudalics@gmx.at> writes:

>> My "interesting" result is that eventually the `foo' buffer ends being
>
> What does "eventually" mean?

This is the exact recipe:

emacs -Q

Start by evaluating this in *scratch*

(display-buffer
 (get-buffer-create "foo")
 '((use-side-window bottom 0) (pop-up-window-set-height . 1)))

Now do a C-h f <some-function-name> INTRO

The frame is splitted into two windows, one for *scratch* and another
for *Help*, "foo" is gone, C-x 1 does not work from *scratch*, C-x 1
from the *Help* buffer reports

byte-code: Cannot make side window the only window

>> displayed on a regular window covering half the screen with its usual
>> modeline. That window wont go away easily (C-x 1 while the other window
>> is active has no effect).
>
> That's part of the idea.  C-x 1 should not delete such windows and
> should not make such a window the only one on its frame.

It seems that Emacs reuses that window for displaying other buffers
(*Help*, in the recipe described above)

Re: Global bar to display global information

[Andreas Röhler]

Am 16.08.2011 16:33, schrieb Jérémy Compostella:
> All,
>
> As many user, I use Emacs as my full desktop environment on several
> system (mainly GNU/Linux and Windows at work).  To be as independent as
> possible, I use the mode-line to show information like current date and
> time, jabber notifications, unread mail number, ... and I start Emacs in
> full-screen.
>
> The problem is since I use several windows (in Emacs term), these
> information are duplicated and are not always visible. Indeed, the
> mode-line bar is split in the middle of the information it displays.
>
> I think it could be really great if Emacs would provide a global bar
> based on the same mechanisms as the mode line but dedicated to this
> kind of global information.
>
> What is your opinion ? Is this subject already discussed before ?
>
> Thanks,
>
> Jérémy
>
>
>
>

Hi,

what about implementing that using speedbar?

Best regards,

Andreas

Re: Global bar to display global information

[martin rudalics]

 > Start by evaluating this in *scratch*
 >
 > (display-buffer
 >  (get-buffer-create "foo")
 >  '((use-side-window bottom 0) (pop-up-window-set-height . 1)))

This gets you two windows, one displaying *scratch* and the other one
displaying foo.

 > Now do a C-h f <some-function-name> INTRO
 >
 > The frame is splitted into two windows, one for *scratch* and another
 > for *Help*, "foo" is gone,

Not really.  The window of foo is reused for *Help*.

 > C-x 1 does not work from *scratch*, C-x 1
 > from the *Help* buffer reports
 >
 > byte-code: Cannot make side window the only window

C-x 0 from *Help* should have worked.  Anyway, this behavior was
reported by Juri Linkov immediately after my initial proposal and the
remedy I suggested was to use

(display-buffer
  (get-buffer-create "*global-mode-line*")
  '((use-side-window bottom 0) (dedicate . t) (pop-up-window-set-height . 1)))

In addition you probably want to do

(setq window-size-fixed 'height)

in *global-mode-line* to assure that the window doesn't get resized.

 >> That's part of the idea.  C-x 1 should not delete such windows and
 >> should not make such a window the only one on its frame.
 >
 > It seems that Emacs reuses that window for displaying other buffers
 > (*Help*, in the recipe described above)

Should not happen any more with present trunk.

martin

Re: Global bar to display global information

[Jérémy Compostella]

Stefan, and others,

I made some tries with the " *Minibuffer-0*" buffer and I got some very
encouraging results. Indeed, I am now able to display information like
date/time, current activity or my jabber status in a fashion I like :) I
have tried this with Emacs 23.2.1 and the Emacs trunk and it works the
same way.

For example, the following line of code will display the date and time
when the echo area is unused:

  (defun display-status ()
    (interactive)
    (with-current-buffer " *Minibuf-0*"
      (delete-region (point-min) (point-max))
      (insert (format-time-string "%Hh%M %d/%m/%Y" (current-time)))
      (put-text-property (point-min) (point-max) 'face 'bold)))
  
  (run-at-time t 60 'display-status)

My implementation do more than that but is not generic enough to be
published now.

Yet, the displayed information is not completely stable. What I mean is
that if I move the cursor in another buffer, the echo area is sometimes
cleared. It's a little bit annoying. How could I fix this without
advising several cursor displacement function ?

Thanks for helping me,

Jérémy
-- 
Sent from my Emacs

Re: Global bar to display global information

[Ted Zlatanov]

On Tue, 16 Aug 2011 12:48:35 -0700 chad <yandros@MIT.EDU> wrote: 

c> On Aug 16, 2011, at 12:46 PM, chad wrote:

>>> 
>>> For example, Ted Zlanatov was pushing forward an effort in this area:

c> That should have been `Ted Zlatanov'.  My apologies.

No problem at all.  I get "Zlantanov" etc. all the time.  My dad has the
bigger problem: first name is Zlatko, same last name.  He goes by Mr. Z :)

Ted

Re: Global bar to display global information

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

On Tue, 16 Aug 2011 13:31:13 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

SM> Overall, it sounds like it shouldn't be too hard to make up a little
SM> package that fills a buffer with useful global info
SM> (time/battery/mail/younameit) and then lets you choose where you want to
SM> display it (separate frame, inactive minibuffer, ...).

Don't forget the progress bar Michael Albinus and I were pushing, to
indicate global "busy" status.  That would fit nicely in such a global
"status bar."  Emacs should really support global progress indicators
and I recall our discussion stalled.

I am attaching an *early not really functional* version of my ideas in
the global information direction, emacs-panel.el.  I didn't get far with
it this summer before other tasks took priority, but intend to keep
working on it.  It is specifically intended to function as an
information panel, which I think is the goal of this thread.  Note that
it has some code to let the window manager treat the popups specially so
they can be docked, which is essential IMHO.

Any improvements, especially such that make it ELPA-ready, most
welcome.  As I said I intend to keep working on it as time allows.

Thanks
Ted


[-- Attachment #2: emacs-panel.el --]
[-- Type: application/emacs-lisp, Size: 9023 bytes --]

Re: Global bar to display global information

[Ted Zlatanov]

On Tue, 16 Aug 2011 15:32:47 -0700 chad <yandros@MIT.EDU> wrote: 

c> On Aug 16, 2011, at 1:54 PM, Jérémy Compostella wrote:

>> What is this Ted's `Emacs as a Desktop Environment' you are talking about ?

c> Some developers are pursing the idea of moving all of the `important' parts 
c> of the desktop environment inside emacs, or at least inside emacs' easy 
c> reach.  This includes `desktop widgets' and an associated `dock', that would
c> be in specialized frames/windows. It's closer to Thien-Thi Nguyen's idea
c> of a `special messages buffer' than your `global mode-line', but it could easily
c> serve both purposes, and other more gui-based uses as well. You can read
c> the discussion (from emacs-devel archives) starting here:

>>> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00746.html

For me it was a reaction to the ridiculous GUIs in Unity and GNOME 3,
and I feel it's important to have a lightweight Emacs-only alternative.
See my post in this thread with my current emacs-panel.el for my current
status; I have much to do and any help is appreciated.  It will be on
ELPA eventually.

emacs-panel.el would definitely be a good place for global information.
In fact one example in the comments shows such a global panel.

Thanks
Ted

Re: Global bar to display global information

[Jérémy Compostella]

[-- Attachment #1.1: Type: text/plain, Size: 1841 bytes --]

2011/8/22 Stefan Monnier <monnier@iro.umontreal.ca>

> > Yet, the displayed information is not completely stable. What I mean is
> > that if I move the cursor in another buffer, the echo area is sometimes
> > cleared. It's a little bit annoying. How could I fix this without
> > advising several cursor displacement function ?
>
> I don't know enough about this code to be able to answer.  You're going
> to have to investigate which code does this "clearing" and what calls
> it, to then be able to figure out what's the best way to address the
> problem (we can change the C code for that in 24.2 if needed).
>
>
Hi,

I finally get time to work again on this global information area. I
think the use of " *Minibuf-0*" proposal is really interesting since the
echo area is most of the time useless and the global information are not
really useful when I'm using the minibuffer. So I tried to figure out
why it didn't work the way you said.

The problem is, considering I had put data in the " *Minibuf-0*", these
data are not displayed in the echo area. However, the " *Minibuf-0*" is
displayed each time I do a switch-to-buffer call. But once I type, the
echo area is cleared.

First, each time I type, the clear_message(1, 0) is called even when the
echo area is already cleared. This call looks useless and is part of the
cause of the behavior described above.

Second, when the echo area is clearing it does not redisplay the
miniwindow. So the " *Minibuf-0*" is not displayed as expected.

I tested this patch with emacs -Q, emacs -Q -nw and with my whole
configuration. Everything works perfectly fine and as
expected. Moreover, I verified that this patch does not generate extras
miniwindow redisplay.

Please merge it or review it,

Best regards,

Jérémy

--
One Emacs to rule them all

[-- Attachment #1.2: Type: text/html, Size: 2371 bytes --]

[-- Attachment #2: 0001-echo-area-Remove-unnecessary-clearing-and-get-defaul.patch --]
[-- Type: text/x-patch, Size: 2884 bytes --]

From 7fb88fc4dbca5cfc1f93494f5fb24efeea796842 Mon Sep 17 00:00:00 2001
From: Jeremy Compostella <jeremy.compostella@gmail.com>
Date: Fri, 30 Dec 2011 14:01:13 +0100
Subject: [PATCH] echo-area: Remove unnecessary clearing and get default minibuffer displayed

Each time we push a keyboard key the clear_message(1, 0) is called
even if the echo-area is already cleared.

When the echo area is cleared, the default minibuffer should be
displayed instead of an empty message.

With this patch, it is possible to display information in the echo
area using the default minibuffer when the echo area is cleared and
the minibuffer is inactive.

Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>
---
 src/keyboard.c |    5 +++--
 src/xdisp.c    |   13 ++++++++++++-
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/keyboard.c b/src/keyboard.c
index 2df1ba7..771ee98 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2982,9 +2982,10 @@ read_char (int commandflag, ptrdiff_t nmaps, Lisp_Object *maps,
       || (!(EQ (Qhelp_echo, XCAR (c)))
 	  && !(EQ (Qswitch_frame, XCAR (c)))))
     {
-      if (!NILP (echo_area_buffer[0]))
+      if (!NILP (echo_area_buffer[0])) {
 	safe_run_hooks (Qecho_area_clear_hook);
-      clear_message (1, 0);
+	clear_message (1, 0);
+      }
     }
 
  reread_for_input_method:
diff --git a/src/xdisp.c b/src/xdisp.c
index 90375ba..77cd80c 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -12666,6 +12666,9 @@ redisplay_internal (void)
      frames.  Zero means, only selected_window is considered.  */
   int consider_all_windows_p;
 
+  /* Non-zero means redisplay has to redisplay the miniwindow */
+  int update_miniwindow_p = 0;
+
   TRACE ((stderr, "redisplay_internal %d\n", redisplaying_p));
 
   /* No redisplay if running in batch mode or frame is not yet fully
@@ -12852,6 +12855,10 @@ redisplay_internal (void)
 	  && !MINI_WINDOW_P (XWINDOW (selected_window))))
     {
       int window_height_changed_p = echo_area_display (0);
+
+      if (message_cleared_p)
+	update_miniwindow_p = 1;
+
       must_finish = 1;
 
       /* If we don't display the current message, don't clear the
@@ -13227,7 +13234,7 @@ redisplay_internal (void)
     }
   else if (FRAME_VISIBLE_P (sf) && !FRAME_OBSCURED_P (sf))
     {
-      Lisp_Object mini_window;
+      Lisp_Object mini_window = FRAME_MINIBUF_WINDOW (sf);
       struct frame *mini_frame;
 
       displayed_buffer = XBUFFER (XWINDOW (selected_window)->buffer);
@@ -13236,6 +13243,10 @@ redisplay_internal (void)
       internal_condition_case_1 (redisplay_window_1, selected_window,
 				 list_of_error,
 				 redisplay_window_error);
+      if (update_miniwindow_p)
+	internal_condition_case_1 (redisplay_window_1, mini_window,
+				   list_of_error,
+				   redisplay_window_error);
 
       /* Compare desired and current matrices, perform output.  */
 
-- 
1.7.2.5

Re: Global bar to display global information

[Jérémy Compostella]

[-- Attachment #1: Type: text/plain, Size: 2950 bytes --]

Stefan, all,

I work with this patch for two days now and it works perfectly fine.
The redisplay works fine without any extras rendering operation
(I instrumented a little bit to check that point).

I will be very grateful if someone could try it, review it and tell me
if something is wrong with it.

With the patch applied and the following :

(with-current-buffer (get-buffer-create " *Minibuf-0*")
  (insert "Information displayed in echo area :)"))

you should see the "Information displayed in echo area :)" instead
of the empty usual message.

I'm currently working on a package which displays some more usefull
information like the date, the battery status, the jabber status, the mail
status and anything you may want in the echo area through the " *Minibuf-0*"
buffer.

Thank you and Happy New Year 2012 !

Jérémy

2011/12/30 Jérémy Compostella <jeremy.compostella@gmail.com>

> 2011/8/22 Stefan Monnier <monnier@iro.umontreal.ca>
>
>> > Yet, the displayed information is not completely stable. What I mean is
>> > that if I move the cursor in another buffer, the echo area is sometimes
>> > cleared. It's a little bit annoying. How could I fix this without
>> > advising several cursor displacement function ?
>>
>> I don't know enough about this code to be able to answer.  You're going
>> to have to investigate which code does this "clearing" and what calls
>> it, to then be able to figure out what's the best way to address the
>> problem (we can change the C code for that in 24.2 if needed).
>>
>>
> Hi,
>
> I finally get time to work again on this global information area. I
> think the use of " *Minibuf-0*" proposal is really interesting since the
> echo area is most of the time useless and the global information are not
> really useful when I'm using the minibuffer. So I tried to figure out
> why it didn't work the way you said.
>
> The problem is, considering I had put data in the " *Minibuf-0*", these
> data are not displayed in the echo area. However, the " *Minibuf-0*" is
> displayed each time I do a switch-to-buffer call. But once I type, the
> echo area is cleared.
>
> First, each time I type, the clear_message(1, 0) is called even when the
> echo area is already cleared. This call looks useless and is part of the
> cause of the behavior described above.
>
> Second, when the echo area is clearing it does not redisplay the
> miniwindow. So the " *Minibuf-0*" is not displayed as expected.
>
> I tested this patch with emacs -Q, emacs -Q -nw and with my whole
> configuration. Everything works perfectly fine and as
> expected. Moreover, I verified that this patch does not generate extras
> miniwindow redisplay.
>
> Please merge it or review it,
>
> Best regards,
>
> Jérémy
>
> --
> One Emacs to rule them all
>



-- 
« Si debugger, c'est supprimer des bugs, alors programmer ne peut être que
les ajouter » - Edsger Dijkstra

[-- Attachment #2: Type: text/html, Size: 3897 bytes --]

Re: Global bar to display global information

[Stefan Monnier]

> I work with this patch for two days now and it works perfectly fine.
> The redisplay works fine without any extras rendering operation
> (I instrumented a little bit to check that point).

Thank you very much for this contribution.  I probably won't have time
to review this before we open up the trunk for non-bugfix patches, but
it looks very promising.


        Stefan

Re: Global bar to display global information

[Stefan Monnier]

OK, I found the patch.  To my eyes, it looks fine, but could someone
more familiar with the redisplay double check that it is doing the
right thing?


        Stefan


>>>>> "Jérémy" == Jérémy Compostella <jeremy.compostella@gmail.com> writes:

> 2011/8/22 Stefan Monnier <monnier@iro.umontreal.ca>
>> > Yet, the displayed information is not completely stable. What I mean is
>> > that if I move the cursor in another buffer, the echo area is sometimes
>> > cleared. It's a little bit annoying. How could I fix this without
>> > advising several cursor displacement function ?
>> 
>> I don't know enough about this code to be able to answer.  You're going
>> to have to investigate which code does this "clearing" and what calls
>> it, to then be able to figure out what's the best way to address the
>> problem (we can change the C code for that in 24.2 if needed).
>> 
>> 
> Hi,

> I finally get time to work again on this global information area. I
> think the use of " *Minibuf-0*" proposal is really interesting since the
> echo area is most of the time useless and the global information are not
> really useful when I'm using the minibuffer. So I tried to figure out
> why it didn't work the way you said.

> The problem is, considering I had put data in the " *Minibuf-0*", these
> data are not displayed in the echo area. However, the " *Minibuf-0*" is
> displayed each time I do a switch-to-buffer call. But once I type, the
> echo area is cleared.

> First, each time I type, the clear_message(1, 0) is called even when the
> echo area is already cleared. This call looks useless and is part of the
> cause of the behavior described above.

> Second, when the echo area is clearing it does not redisplay the
> miniwindow. So the " *Minibuf-0*" is not displayed as expected.

> I tested this patch with emacs -Q, emacs -Q -nw and with my whole
> configuration. Everything works perfectly fine and as
> expected. Moreover, I verified that this patch does not generate extras
> miniwindow redisplay.

> Please merge it or review it,

> Best regards,

> Jérémy

> --
> One Emacs to rule them all
> From 7fb88fc4dbca5cfc1f93494f5fb24efeea796842 Mon Sep 17 00:00:00 2001
> From: Jeremy Compostella <jeremy.compostella@gmail.com>
> Date: Fri, 30 Dec 2011 14:01:13 +0100
> Subject: [PATCH] echo-area: Remove unnecessary clearing and get default minibuffer displayed

> Each time we push a keyboard key the clear_message(1, 0) is called
> even if the echo-area is already cleared.

> When the echo area is cleared, the default minibuffer should be
> displayed instead of an empty message.

> With this patch, it is possible to display information in the echo
> area using the default minibuffer when the echo area is cleared and
> the minibuffer is inactive.

> Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>
> ---
>  src/keyboard.c |    5 +++--
>  src/xdisp.c    |   13 ++++++++++++-
>  2 files changed, 15 insertions(+), 3 deletions(-)

> diff --git a/src/keyboard.c b/src/keyboard.c
> index 2df1ba7..771ee98 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -2982,9 +2982,10 @@ read_char (int commandflag, ptrdiff_t nmaps, Lisp_Object *maps,
>        || (!(EQ (Qhelp_echo, XCAR (c)))
>  	  && !(EQ (Qswitch_frame, XCAR (c)))))
>      {
> -      if (!NILP (echo_area_buffer[0]))
> +      if (!NILP (echo_area_buffer[0])) {
>  	safe_run_hooks (Qecho_area_clear_hook);
> -      clear_message (1, 0);
> +	clear_message (1, 0);
> +      }
>      }
 
>   reread_for_input_method:
> diff --git a/src/xdisp.c b/src/xdisp.c
> index 90375ba..77cd80c 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -12666,6 +12666,9 @@ redisplay_internal (void)
>       frames.  Zero means, only selected_window is considered.  */
>    int consider_all_windows_p;
 
> +  /* Non-zero means redisplay has to redisplay the miniwindow */
> +  int update_miniwindow_p = 0;
> +
>    TRACE ((stderr, "redisplay_internal %d\n", redisplaying_p));
 
>    /* No redisplay if running in batch mode or frame is not yet fully
> @@ -12852,6 +12855,10 @@ redisplay_internal (void)
>  	  && !MINI_WINDOW_P (XWINDOW (selected_window))))
>      {
>        int window_height_changed_p = echo_area_display (0);
> +
> +      if (message_cleared_p)
> +	update_miniwindow_p = 1;
> +
>        must_finish = 1;
 
>        /* If we don't display the current message, don't clear the
> @@ -13227,7 +13234,7 @@ redisplay_internal (void)
>      }
>    else if (FRAME_VISIBLE_P (sf) && !FRAME_OBSCURED_P (sf))
>      {
> -      Lisp_Object mini_window;
> +      Lisp_Object mini_window = FRAME_MINIBUF_WINDOW (sf);
>        struct frame *mini_frame;
 
>        displayed_buffer = XBUFFER (XWINDOW (selected_window)->buffer);
> @@ -13236,6 +13243,10 @@ redisplay_internal (void)
>        internal_condition_case_1 (redisplay_window_1, selected_window,
>  				 list_of_error,
>  				 redisplay_window_error);
> +      if (update_miniwindow_p)
> +	internal_condition_case_1 (redisplay_window_1, mini_window,
> +				   list_of_error,
> +				   redisplay_window_error);
 
>        /* Compare desired and current matrices, perform output.  */
 
> -- 
> 1.7.2.5

Re: Global bar to display global information

[Jérémy Compostella]

All,

I would be very thankful too is someone could look at it. It's a very
simple patch that I use for more than 6 months now and provide me a way
to use the echo area as a global information area.

Thanks a lot,

Jérémy


2012/4/24 Stefan Monnier <monnier@iro.umontreal.ca>:
> OK, I found the patch.  To my eyes, it looks fine, but could someone
> more familiar with the redisplay double check that it is doing the
> right thing?
>
>
>        Stefan
>
>
>>>>>> "Jérémy" == Jérémy Compostella <jeremy.compostella@gmail.com> writes:
>
>> 2011/8/22 Stefan Monnier <monnier@iro.umontreal.ca>
>>> > Yet, the displayed information is not completely stable. What I mean is
>>> > that if I move the cursor in another buffer, the echo area is sometimes
>>> > cleared. It's a little bit annoying. How could I fix this without
>>> > advising several cursor displacement function ?
>>>
>>> I don't know enough about this code to be able to answer.  You're going
>>> to have to investigate which code does this "clearing" and what calls
>>> it, to then be able to figure out what's the best way to address the
>>> problem (we can change the C code for that in 24.2 if needed).
>>>
>>>
>> Hi,
>
>> I finally get time to work again on this global information area. I
>> think the use of " *Minibuf-0*" proposal is really interesting since the
>> echo area is most of the time useless and the global information are not
>> really useful when I'm using the minibuffer. So I tried to figure out
>> why it didn't work the way you said.
>
>> The problem is, considering I had put data in the " *Minibuf-0*", these
>> data are not displayed in the echo area. However, the " *Minibuf-0*" is
>> displayed each time I do a switch-to-buffer call. But once I type, the
>> echo area is cleared.
>
>> First, each time I type, the clear_message(1, 0) is called even when the
>> echo area is already cleared. This call looks useless and is part of the
>> cause of the behavior described above.
>
>> Second, when the echo area is clearing it does not redisplay the
>> miniwindow. So the " *Minibuf-0*" is not displayed as expected.
>
>> I tested this patch with emacs -Q, emacs -Q -nw and with my whole
>> configuration. Everything works perfectly fine and as
>> expected. Moreover, I verified that this patch does not generate extras
>> miniwindow redisplay.
>
>> Please merge it or review it,
>
>> Best regards,
>
>> Jérémy
>
>> --
>> One Emacs to rule them all
>> From 7fb88fc4dbca5cfc1f93494f5fb24efeea796842 Mon Sep 17 00:00:00 2001
>> From: Jeremy Compostella <jeremy.compostella@gmail.com>
>> Date: Fri, 30 Dec 2011 14:01:13 +0100
>> Subject: [PATCH] echo-area: Remove unnecessary clearing and get default minibuffer displayed
>
>> Each time we push a keyboard key the clear_message(1, 0) is called
>> even if the echo-area is already cleared.
>
>> When the echo area is cleared, the default minibuffer should be
>> displayed instead of an empty message.
>
>> With this patch, it is possible to display information in the echo
>> area using the default minibuffer when the echo area is cleared and
>> the minibuffer is inactive.
>
>> Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>
>> ---
>>  src/keyboard.c |    5 +++--
>>  src/xdisp.c    |   13 ++++++++++++-
>>  2 files changed, 15 insertions(+), 3 deletions(-)
>
>> diff --git a/src/keyboard.c b/src/keyboard.c
>> index 2df1ba7..771ee98 100644
>> --- a/src/keyboard.c
>> +++ b/src/keyboard.c
>> @@ -2982,9 +2982,10 @@ read_char (int commandflag, ptrdiff_t nmaps, Lisp_Object *maps,
>>        || (!(EQ (Qhelp_echo, XCAR (c)))
>>         && !(EQ (Qswitch_frame, XCAR (c)))))
>>      {
>> -      if (!NILP (echo_area_buffer[0]))
>> +      if (!NILP (echo_area_buffer[0])) {
>>       safe_run_hooks (Qecho_area_clear_hook);
>> -      clear_message (1, 0);
>> +     clear_message (1, 0);
>> +      }
>>      }
>
>>   reread_for_input_method:
>> diff --git a/src/xdisp.c b/src/xdisp.c
>> index 90375ba..77cd80c 100644
>> --- a/src/xdisp.c
>> +++ b/src/xdisp.c
>> @@ -12666,6 +12666,9 @@ redisplay_internal (void)
>>       frames.  Zero means, only selected_window is considered.  */
>>    int consider_all_windows_p;
>
>> +  /* Non-zero means redisplay has to redisplay the miniwindow */
>> +  int update_miniwindow_p = 0;
>> +
>>    TRACE ((stderr, "redisplay_internal %d\n", redisplaying_p));
>
>>    /* No redisplay if running in batch mode or frame is not yet fully
>> @@ -12852,6 +12855,10 @@ redisplay_internal (void)
>>         && !MINI_WINDOW_P (XWINDOW (selected_window))))
>>      {
>>        int window_height_changed_p = echo_area_display (0);
>> +
>> +      if (message_cleared_p)
>> +     update_miniwindow_p = 1;
>> +
>>        must_finish = 1;
>
>>        /* If we don't display the current message, don't clear the
>> @@ -13227,7 +13234,7 @@ redisplay_internal (void)
>>      }
>>    else if (FRAME_VISIBLE_P (sf) && !FRAME_OBSCURED_P (sf))
>>      {
>> -      Lisp_Object mini_window;
>> +      Lisp_Object mini_window = FRAME_MINIBUF_WINDOW (sf);
>>        struct frame *mini_frame;
>
>>        displayed_buffer = XBUFFER (XWINDOW (selected_window)->buffer);
>> @@ -13236,6 +13243,10 @@ redisplay_internal (void)
>>        internal_condition_case_1 (redisplay_window_1, selected_window,
>>                                list_of_error,
>>                                redisplay_window_error);
>> +      if (update_miniwindow_p)
>> +     internal_condition_case_1 (redisplay_window_1, mini_window,
>> +                                list_of_error,
>> +                                redisplay_window_error);
>
>>        /* Compare desired and current matrices, perform output.  */
>
>> --
>> 1.7.2.5
>
>



-- 
« Si debugger, c'est supprimer des bugs, alors programmer ne peut être
que les ajouter » - Edsger Dijkstra

Re: Global bar to display global information

[Stefan Monnier]

Thank you, Jérémy, I installed your patch in the trunk,


        Stefan


> I finally get time to work again on this global information area. I
> think the use of " *Minibuf-0*" proposal is really interesting since the
> echo area is most of the time useless and the global information are not
> really useful when I'm using the minibuffer. So I tried to figure out
> why it didn't work the way you said.

> The problem is, considering I had put data in the " *Minibuf-0*", these
> data are not displayed in the echo area. However, the " *Minibuf-0*" is
> displayed each time I do a switch-to-buffer call. But once I type, the
> echo area is cleared.

> First, each time I type, the clear_message(1, 0) is called even when the
> echo area is already cleared. This call looks useless and is part of the
> cause of the behavior described above.

> Second, when the echo area is clearing it does not redisplay the
> miniwindow. So the " *Minibuf-0*" is not displayed as expected.

> I tested this patch with emacs -Q, emacs -Q -nw and with my whole
> configuration. Everything works perfectly fine and as
> expected. Moreover, I verified that this patch does not generate extras
> miniwindow redisplay.

> Please merge it or review it,

> Best regards,

> Jérémy

> --
> One Emacs to rule them all