emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!


From: Lennart Borgman
Subject: Re: Blunderbuss ".dir-locals.el" raises everything in its path!!
Date: Thu, 16 Jul 2009 23:29:22 +0200

On Thu, Jul 16, 2009 at 11:19 PM, Drew Adams<address@hidden> wrote:
>> `display-warning' is too intrusive because it changes the current
>> window configuration.  I'd rather display a tail of the *Messages*
>> buffer in the echo area.
>
> Quelle horreur.
>
> Nothing wrong with something that shows the *Messages* tail somewhere. But,
> please, not in the echo area.
>
> If you want, add a mode/option that displays the end of *Messages* (keeps it 
> on
> top) and scrolls it automatically, so it always shows the tail. But show that
> separately from the echo area.
>
> (I just keep *Messages* visible when I want that - it does exactly that, but I
> can imagine a mode that does a bit more than that.)

A simple idea that (maybe) does not give more complexity, but merges
messages/warnings/errors/tracebacks:

- Show it all in the message buffer.
- Color those differently there.
- Get rid of the warnings buffer. Instead, if it is desired to do so,
open the message buffer like the warnings buffer is opened today. At
least that is not more intrusive than today...
- Errors are more severe than warnigns so do at least that much for
errors too. (But a lot of code in Emacs gives errors instead of using
catch/throw as they should. Also a catch label to just jump out of a
command without having to add a label internally would be very good...
- hope that is not more complexity...)

I think this would be a good start toward making the complexity in
this area less than today because with such a structure we could
invent common ways to make a certain message more visible.

There are complexities like that an important message might be hidden
by a later less important message (a rather common problem) but with a
structure like the one above we can try to handle it in a general way
that both programmers and users understand, recognizes and remember.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]