Re: customizing minibuffer and the message bar, ie mode-line

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> While I rather agree with the above (especially that
> "professional" was not defined here, and it seems
> not necessarily to be an objective quality - for
> instance, it might mean a completely different thing
> for various, well, professions, like writer vs.
> programmer), one must admit that there is a lot of
> information in the mode-line (even with only the
> default settings), which may be distracting.

Yes. Especially if you have a big font like me there
is far too much information to fit (my terminal is 85
chars wide).

[Mode line code last in the post, for the impatient.]

> (Personally, I did it with the (in a sense) opposite
> goal in mind: so that I can cramp /even more/ info
> in the mode-line, e.g. Org-mode's currently clocked
> task, which-function mode and a bunch of minor modes
> I use every day.)

My take is you should have everything you need, and
nothing you do not need. So it is never a matter of
having "less" or "more", it is always to have exactly
what you need, and always so.

This cannot be planned on the drawing table but must
be worked out day in, day out. As in, whenever I find
I hit a command frequently to get a piece of
information, I think - can I put that information
somewhere so I don't have to hit the command each time
to get it? But sometimes there is just no room.

There are clever schemes to solve such issues, as
always. For example, I have CAPS bring up the
*Buffer List*. In the buffer list, I don't need
anything "buffery" information in the mode bar as
I see in the main buffer it is a buffer list, and
I don't need anything else. So then I can use the mode
bar for that mode and put common data I frequently
need. That way I only have to hit CAPS to get it, then
M-TAB to get back (note the positions of those
keys on the keyboard). [If I did it today I would put
CAPS in the *Buffer List* to get to the previous
buffer, i.e., to get back. Now that lists non-file
buffers as well, which is practical,
so it isn't worth the effort to reprogram my hands
which takes considerably longer than reprogramming the
keys, for sure.]

Indeed, such solutions are like the familiar pile of
firewood by the outhouse. Instead of saying "let's
move the firewood and be done with it", every time you
go to the outhouse, you bring back a log under each
arms. Multiple purpose walking - even (and especially)
in the Emacs wellingtons!

Now, this is how I set up the mode line to be reactive
on specific modes. The best way would probably be to
not have to do that: instead all modes would have
a format variable string, e.g. the Gnus
`gnus-group-mode-line-format', the ERC
`erc-mode-line-format', and so on. (Hey - what
a social guy!)

For context, is the file URL:

    http://user.it.uu.se/~embe8573/conf/emacs-init/mode-line.el

With the most relevant (indispensible) code:

    (setq-default mode-line-format
       `(" "
         (:eval (if (not (or buffer-read-only
                             (member major-mode '(erc-mode
                                                  inferior-emacs-lisp-mode
                                                  message-mode) )))
                    mode-line-modified) )
         " "
         (:eval
          (if (eq major-mode 'w3m-mode) w3m-current-title
            (if dired-directory dired-directory
              (if (eq major-mode 'message-mode) (buffer-name)
                (if buffer-file-name
                    (abbreviate-file-name buffer-file-name)
                  mode-line-buffer-identification )))))
         " "
         (show-modes mode-line-modes)
         (line-number-mode "[%l] ")
         (column-number-mode "{%c} ")
         ))

-- 
underground experts united
http://user.it.uu.se/~embe8573