12

The echo area is empty most of the time, which makes me think that I could use it to display some information. For example, org-clock displays the current task, the remaining time and the total elapsed time on the modeline. This information is not really readable there (the modeline can be rather short), is repeated on each modeline (because it applies to the whole emacs session), and is not that useful that I'm willing to sacrifice some precious modeline space for it. On the other hand, it could appear in the echo area when there is nothing else to display here.

Is there a canonical way of achieving this? I have thought of hacking an insert function in minibuffer-inactive-mode-hook (but it doesn't work reliably, for example the message disappears as soon as the echo area is used again), or spamming non-logged messages (but this will be mess with other uses of the echo area and the minibuffer).

A poor-man version of this would use idle timers, but the echo area can be empty without emacs being idle (for example when inputting some text).

Community
  • 1
T. Verron
  • 4,283
  • 2
  • 24
  • 56
  • 2
    The echo area displayed is the content of *Echo Area 0* or *Echo Area 1* and these are "normal" buffers. It should be posible to patch Emacs so as to provide maybe a hook run whenever these buffers are "flushed" (or are displayed and empty), so that this functionality can be implemented efficiently and reliably. – Stefan Feb 26 '15 at 16:05
  • It is not exactly what you have in mind but Bastien Guerry did some interesting stuff to save screen estate especially with displaying the mode line in the frame title: http://bzg.fr/emacs-strip-tease.html – Dieter.Wilhelm Aug 28 '15 at 21:47

4 Answers4

5

A comment on this question mentions that a package named symon makes use of such a feature.

It is achieved by spamming non-logged messages when the minibuffer is inactive, and by stopping the redisplay everytime a command is issued. The boilerplate for that is rather short, and after a few minutes of usage, I couldn't notice any problems with that: messages and minibuffer usage still take priority over the messages.

The key components are:

  • a display function, run on an idle timer (calls message with message-log-max set to nil, so that the displayed string does not get in the *Messages* buffer)
  • a redisplay function, run on a timer
  • a function to stop the display, run in pre-command-hook

The only issue is that the display is stopped whenever a command is being run, which includes when typing.

For those interested, I have extracted the relevant code into a boilerplate package available on github.

Community
  • 1
T. Verron
  • 4,283
  • 2
  • 24
  • 56
1

The answer, IMO, is no. The echo area is for ephemeral messages. And lots of things explicitly erase anything that might have been echoed there. So realizing what you request in any reasonable way is problematic, IMO.

In sum, use an alternative. Here are some:

  1. Use some other buffer (e.g. a small frame or window that you keep open for this purpose). Simple to do, you can move it around, edit it, erase it, or do whatever else you like with it.

  2. Use part or all of the mode line (which you have already considered, apparently).

  3. Use a header line.

  4. Use a frame title.

If it were I, I would probably opt for #1. (But I don't really want/need such a full-time display of status info. I would more likely define a command that shows me the info (even a history/log) on demand.)

Updated after your comments:

You already said, in your question, "the message disappears as soon as the echo area is used again". So it sounded like using such an ephemeral space as the echo area would not fit your needs. Your comment replies seem to contradict this.

If you really want to use the echo area, then use minibuffer-inactive-mode-hook, as you mentioned, or use a timer to call message or to insert the time message in the echo area in some other way. However, you have already noted the problems with that. Those problems (overwriting, erasure) follow from the (intended) ephemeral nature of the echo area.

In sum, you want to use an area intended for ephemeral messages, but you don't want your messages to disappear as soon as that area is used again.

(BTW - wrt your mention that the mode-line info is repeated in every mode line: That need not be the case. You can make the mode line be specific for a particular buffer etc. IOW, you can choose one mode line to always (or periodically) show your clock or whatever.)

Drew
  • 77,472
  • 10
  • 114
  • 243
  • Thank you for your suggestions! First, though, I don't quite understand, why is that problematic? I'd like things that would go to the echo area atm to override any other use of the echo area, so erasing it is OK. And the extra information should only be displayed when the echo area is empty, so there is nothing to erase. Doesn't that sound like a reasonable specification? About #1, the problem is that I don't want to waste screen space. The echo area is always there, even when it is empty. I listed some problems with #2, and #3 and #4 share a lot of these issues. – T. Verron Jan 20 '15 at 16:33
  • About why I want full-time display of the info, take for example the org-clock example from the question: I want the timer ticking down to remind me of what I should be doing, and that I am supposed to be doing that right now, as often as possible. – T. Verron Jan 20 '15 at 16:35
  • "the message disappears as soon as the echo area is used again" Ok that was unclear. What I meant was that if I use minibuffer-inactive-mode-hook and exit the minibuffer, the message shows. Then if some other command prints something to the echo area, this new message is added, and the ephemeral message does not come back (because the minibuffer didn't get involved this time). – T. Verron Jan 21 '15 at 10:03
  • About the modeline, the main problem is the small available space there (I frequently have a lot of windows, split horizontally, so very short modelines). – T. Verron Jan 21 '15 at 10:07
  • Again - "In sum, you want to use an area intended for ephemeral messages, but you don't want your messages to disappear as soon as that area is used again." Use a timer with message or post-command-hook, if you like. But the essential problem of disappearing/overwriting will rear its head sometimes, because you are trying to use a temporary display area for something that you do not want to be temporary. – Drew Jan 21 '15 at 14:59
  • Maybe temporary was not the correct word then. How about permanent, but with lowest priority? – T. Verron Jan 21 '15 at 15:01
1

Surprisingly, when it's not echoing anything, the echo area displays the buffer *Minibuf-0* (note that the buffer name starts with a space).

To see this in action, evaluate

(with-current-buffer " *Minibuf-0*" (insert "Hello World!"))

and then just go about using Emacs for a while.

So you can put information there and it will display whenever the last command (including cursor movements, window switches, and so on) hasn't updated the echo area. So that gets you a maybe-good-enough-for-your-purposes minimal solution.

The only caveat is that when code explicitly echoes nothing, for example with (message nil), which lots of code does at various times to ensure the echo area is clear, that does not switch back to minibuffer zero - instead it erases and displays one of the two echo area buffers, so you'll still get a blank echo area any time that happens. I haven't figured out how to work around that, but there might be a way that's still simpler than the other solutions.

mtraceur
  • 346
  • 2
  • 13
0

I think the best solution so far is https://github.com/QiangF/emacs-mini-modeline

There could be a better solution as stefan pointed out: "It should be posible to patch Emacs so as to provide maybe a hook run whenever these buffers are "flushed" (or are displayed and empty), so that this functionality can be implemented efficiently and reliably. "

godblessfq
  • 1,217
  • 9
  • 22