Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman <lennart.borgman.073@student.lu.se>]

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.