emacs-devel
[Top][All Lists]
Advanced

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

Re: Avoiding moving point into minibuffer prompt area


From: Lennart Borgman
Subject: Re: Avoiding moving point into minibuffer prompt area
Date: Fri, 19 Aug 2005 00:46:11 +0200
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Richard M. Stallman wrote:

2) Do not show the message "Prompt is read-only" when Inviolable is on. It is just disturbing and unexpected in my opinion. It is simply the usual behavior for most applications that you are not able to delete the prompt.

The command delete-backward-char is going to fail because the text is
read-only.  What exactly do you suggest that it do?
I would just like the point to stop where it is then.

This is how it normally works in other programs. I guess the problem we have with this here comes from the nature and history of Emacs. In a buffer with an input widget (like Custom buffers sometimes have) a message seems useful. In that case the boundary between the field and the area outside is a more hard to grasp in the beginning since you might expect Emacs to behave like other applications for such a page. The message is also shown in a not disturbing place - in the message area. Many applications use an area at the bottom for messages so it is not unexpected.

In a Custom buffer colors are also used to mark the input fields. This is rather easily recognized by most users I believe since this too is common. It can be shown more clearly than now, an inset frame has been standard long, but for the moment I think it is as good as it can be. (Maybe the colors could be different though. Gray most often is a symbol for text that can not be changed. In the Custom buffers this has been reversed. I would have choosen white for the editable fields and another color for the rest, probably not all gray. Preferable would in my opinion be the color the user have selected for the menubar, ie a system color.)

In the minibuffer there is by default (emacs -Q) no color that tells where the prompt ends. A colored background to the prompt could in my opinion be useful and I would suggest that it is on by default. In the minibuffer too the color symbols other states than in most other applications. Normally a message area is in the same color as the menubar. Input fields are most often white. Using the color symbolic that comes with the OS would to me make most sense. In this case that would mean that the prompt area would be in the color of the menu bar and the input area would be white. When there is no input area active the whole minibuffer window would have the color of the menubar.

Using a message for such a common case in the minibuffer is just disturbing and more so since it prints the message over the prompt (as I explained in an earlier message).

Such things would of course be customizeable. I do not know if the system colors currently can be used on different platforms. On text only systems I guess something similar could be done.

All my points above (in this long message, sorry) are geared towards making things less surprising for a beginner. I myself must have very good reasons to use any application that does not follow OS guidelines. I do use Gimp for example but I am highly irritated by its "creative" ways of doing very common things sometimes. (Even though I think very much very good work has been done to create the program itself.) I often even do not know if the strange GUI behaviour I see is by intention or if it is a bug.




reply via email to

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