Avoiding moving point into minibuffer prompt area

Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

I think it is quite confusing that you can move the point into the 
prompt area in the minibuffer. Why don't we use something like the code 
below to avoid this:

(defun minibuff-post-command()
  (when (active-minibuffer-window)
    (when (< (point) (minibuffer-prompt-end))
      (forward-char (- (minibuffer-prompt-end) (point))))))

(add-hook 'post-command-hook 'minibuff-post-command)

Re: Avoiding moving point into minibuffer prompt area

[Luc Teirlinck]

Lennart Borgman wrote:

   I think it is quite confusing that you can move the point into the 
   prompt area in the minibuffer.

What is confusing about that?  It has often saved me time by allowing
me to copy text from the minibuffer.  The code you propose would
unnecessarily waste people's time by imposing the dull work of typing
in that text manually upon them.  Why would one want to deliberately
destroy such a very useful feature?

Sincerely,

Luc.

RE: Avoiding moving point into minibuffer prompt area

[Drew Adams]

       I think it is quite confusing that you can move the point into the
       prompt area in the minibuffer.

    What is confusing about that?  It has often saved me time by allowing
    me to copy text from the minibuffer.  The code you propose would
    unnecessarily waste people's time by imposing the dull work of typing
    in that text manually upon them.  Why would one want to deliberately
    destroy such a very useful feature?

I think I'm missing something here, and I'd like to learn. What minibuffer
text are you referring to copying - something from the prompt? Can you give
an example?

I might be convinced otherwise, after I understand your use case, but until
then, I think Lennart has a point. This is also something that I have found
annoying.

I note too that, by design, commands like `C-a' do not move into the prompt.
That suggests that it was felt that it would be confusing or annoying to
move into the prompt.

One possible compromise, assuming there is a useful use case for copying
prompt text, would be to permit copying it with the mouse, but still inhibit
moving the cursor into the prompt by command or keyboard. Would that be good
enough?

Re: Avoiding moving point into minibuffer prompt area

[Luc Teirlinck]

Lennart Borgman wrote:

   I think it is quite confusing that you can move the point into the 
   prompt area in the minibuffer. Why don't we use something like the code 
   below to avoid this:

As I already pointed out, I personally do not find this confusing, but
very useful.  For people who do not like it, however, the
functionality you want is already available.

Do 

M-x customize-option RET minibuffer-prompt-properties RET

and check:

Inviolable.

Sincerely,

Luc.

RE: Avoiding moving point into minibuffer prompt area

[Drew Adams]

    As I already pointed out, I personally do not find this confusing, but
    very useful.  For people who do not like it, however, the
    functionality you want is already available.

    M-x customize-option RET minibuffer-prompt-properties RET
    and check: Inviolable.

Thanks. I wasn't aware of that option.

I'd still be interested in knowing what your text-copying use case is.

And a question - ignore, if this has already been beaten to death -
shouldn't "inviolable" be the default value? A novice might get confused and
not know about the option to make the text inviolable; a veteran is more
likely to try to copy prompt text and to discover the open-sesame option, if
it is locked by default.

Re: Avoiding moving point into minibuffer prompt area

[Luc Teirlinck]

Drew Adams wrote:

   I think I'm missing something here, and I'd like to learn. What minibuffer
   text are you referring to copying - something from the prompt? Can you give
   an example?

I am referring to copying the prompt.  This is routinely necessary
when describing bugs or misfeatures involving the minibuffer.

   One possible compromise, assuming there is a useful use case for copying
   prompt text, would be to permit copying it with the mouse, but still inhibit
   moving the cursor into the prompt by command or keyboard. Would that be good
   enough?

That would force one to use the mouse and assumes that one has a mouse
available.

   I note too that, by design, commands like `C-a' do not move into the prompt.

That is because of field properties.  To see this, do C-x C-f, move into the
prompt (sorry) and to C-u x =

Sincerely,

Luc.

Re: Avoiding moving point into minibuffer prompt area

[Luc Teirlinck]

>From my previous reply:

  That is because of field properties.  To see this, do C-x C-f, move into the
  prompt (sorry) and to C-u x =

I meant: "and do C-u C-x ="

Sincerely,

Luc.

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

Luc Teirlinck wrote:

>Lennart Borgman wrote:
>
>   I think it is quite confusing that you can move the point into the 
>   prompt area in the minibuffer. Why don't we use something like the code 
>   below to avoid this:
>
>As I already pointed out, I personally do not find this confusing, but
>very useful.  For people who do not like it, however, the
>functionality you want is already available.
>
>Do 
>
>M-x customize-option RET minibuffer-prompt-properties RET
>
>and check:
>
>Inviolable.
>  
>
Thanks Luc! I supposed someone would say they wanted to copy the prompt 
but I thought then one could turn off the hook (since I supposed those 
who want to are seasoned Emacs users).

I did not know about this option however. The current behaviour is 
probably not what a new user expects. I can't think of any other program 
that behaves like this. Shell prompt for example do not.

I agree with Drew that the default should be that "Inviolable" should be 
on (it should not be possible to move the point into the minibuffer 
prompt). Is not that in line with how we have thought in other similar 
cases?

Re: Avoiding moving point into minibuffer prompt area

[Juri Linkov]

> The current behaviour is probably not what a new user expects.
> I can't think of any other program that behaves like this.
> Shell prompt for example do not.
>
> I agree with Drew that the default should be that "Inviolable"
> should be on (it should not be possible to move the point into the
> minibuffer prompt). Is not that in line with how we have thought in
> other similar cases?

It is useful to move point into the minibuffer prompt without
changing default settings.  But since this can be confusing for
beginners, maybe it should be more difficult to move point into the
prompt area by default?  For example, to disable moving point into
the prompt with C-b, but allow C-a at the beginning of the input
area to move point to the beginning of the prompt.  This is like C-a
(`message-beginning-of-line') works on message header fields.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

Juri Linkov wrote:

>>The current behaviour is probably not what a new user expects.
>>I can't think of any other program that behaves like this.
>>Shell prompt for example do not.
>>
>>I agree with Drew that the default should be that "Inviolable"
>>should be on (it should not be possible to move the point into the
>>minibuffer prompt). Is not that in line with how we have thought in
>>other similar cases?
>>    
>>
>
>It is useful to move point into the minibuffer prompt without
>changing default settings.  But since this can be confusing for
>beginners, maybe it should be more difficult to move point into the
>prompt area by default?  For example, to disable moving point into
>the prompt with C-b, but allow C-a at the beginning of the input
>area to move point to the beginning of the prompt.  This is like C-a
>(`message-beginning-of-line') works on message header fields.
>  
>
Could be an idea, sounds consistent and not to surprising perhaps. But 
it seems easier to change the default for "Inviolable".

BTW the message "Text is readonly" is also confusing when "Inviolable" 
is set. You expect the prompt to be readonly and the message is 
disturbing when you delete character by character and then suddenly this 
text appears over the prompt. The first time you see this you may think 
that something is very wrong, at least that is what I did.

Re: Avoiding moving point into minibuffer prompt area

[Juri Linkov]

>>It is useful to move point into the minibuffer prompt without
>>changing default settings.  But since this can be confusing for
>>beginners, maybe it should be more difficult to move point into the
>>prompt area by default?  For example, to disable moving point into
>>the prompt with C-b, but allow C-a at the beginning of the input
>>area to move point to the beginning of the prompt.  This is like C-a
>>(`message-beginning-of-line') works on message header fields.
>>  
> Could be an idea, sounds consistent and not to surprising perhaps. But 
> it seems easier to change the default for "Inviolable".

Instead of changing the default, please try to find a solution that
will please as much the beginners as the seasoned Emacs users.

> BTW the message "Text is readonly" is also confusing when "Inviolable" 
> is set. You expect the prompt to be readonly and the message is 
> disturbing when you delete character by character and then suddenly this 
> text appears over the prompt. The first time you see this you may think 
> that something is very wrong, at least that is what I did.

What do you expect in this situation?  Trying to delete a character at
bob prints the message "Beginning of buffer".  Perhaps it should print
something like "Beginning of prompt input area" in the minibuffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

Juri Linkov wrote:

>>>It is useful to move point into the minibuffer prompt without
>>>changing default settings.  But since this can be confusing for
>>>beginners, maybe it should be more difficult to move point into the
>>>prompt area by default?  For example, to disable moving point into
>>>the prompt with C-b, but allow C-a at the beginning of the input
>>>area to move point to the beginning of the prompt.  This is like C-a
>>>(`message-beginning-of-line') works on message header fields.
>>> 
>>>      
>>>
>>Could be an idea, sounds consistent and not to surprising perhaps. But 
>>it seems easier to change the default for "Inviolable".
>>    
>>
>
>Instead of changing the default, please try to find a solution that
>will please as much the beginners as the seasoned Emacs users.
>  
>
Well, I am trying, it is not very easy all the time ;-)

Combining what we have said so far I think this could be reasonable and 
useful:

1) Change the default (sorry ;-)
2) Let C-a move first to the beginning of the input area
3) Let more C-a move between beginning of the prompt and input area 
(toggle so to say)

For this to actually work I guess 3 also would toggle Inviolable temporary.

Does this way seems reasonable to you?

>  
>
>>BTW the message "Text is readonly" is also confusing when "Inviolable" 
>>is set. You expect the prompt to be readonly and the message is 
>>disturbing when you delete character by character and then suddenly this 
>>text appears over the prompt. The first time you see this you may think 
>>that something is very wrong, at least that is what I did.
>>    
>>
>
>What do you expect in this situation?  Trying to delete a character at
>bob prints the message "Beginning of buffer".  Perhaps it should print
>something like "Beginning of prompt input area" in the minibuffer.
>  
>
I would expect no message at all in this situation. In my opinion that 
would be better. Alternatively perhaps "You are at the beginning of the 
input area - to move into the prompt area use C-a".

Re: Avoiding moving point into minibuffer prompt area

[Luc Teirlinck]

Lennart Borgman wrote:

   The current behaviour is probably not what a new user expects.

But no harm is done if you move into the prompt.  Just move out of it again.
Once you noticed that you can move into the prompt, you know you can.
No docs to read to find it out.

I do not like any of the compromise "solutions" that have been
proposed.  Solutions to which problem?  A one time only confusion?
What is the concrete problem we are worrying about?

   I can't think of any other program 
   that behaves like this. Shell prompt for example do not.

That depends.  If you run the shell from most terminal emulators you
can not.  But that is just one of the many limitations of terminal
emulators.  If you run the shell from Emacs with `M-x shell' ypu
definitely can move into the prompt.

If you could not move into the prompt, Emacs would not be consistent
with itself.

Sincerely,

Luc.

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

Luc Teirlinck wrote:

>Lennart Borgman wrote:
>
>   The current behaviour is probably not what a new user expects.
>
>But no harm is done if you move into the prompt.  Just move out of it again.
>Once you noticed that you can move into the prompt, you know you can.
>No docs to read to find it out.
>  
>
Thanks for your view, but maybe there is a misunderstanding.

I was trying to see this from a beginners point of view. I do not 
believe a beginner would think the current behaviour is the least 
disturbing option. I think that new users should be distracted as little 
as possible since it is much to learn in the beginning.

So the real problem I am trying to help with is how to make it easier 
for new users to start to use Emacs.

RE: Avoiding moving point into minibuffer prompt area

[Drew Adams]

       One possible compromise, assuming there is a useful use case
       for copying prompt text, would be to permit copying it with the
mouse,
       but still inhibit moving the cursor into the prompt by command
       or keyboard.  Would that be good enough?

    That would force one to use the mouse and assumes that one has a mouse
    available.

Yes, of course. To "Would that be enough?", I guess your answer is "No".

       I note too that, by design, commands like `C-a' do not move
       into the prompt.

    That is because of field properties.  To see this, do C-x C-f,
    move into the prompt (sorry) and to C-u x =

That's the how, not the why. My point was that it is designed purposely to
prevent C-a from moving point to that beginning of the minibuffer (and a
good thing, too).

Re: Avoiding moving point into minibuffer prompt area

[Luc Teirlinck]

Drew Adams wrote:

	  I note too that, by design, commands like `C-a' do not move
	  into the prompt.

       That is because of field properties.  To see this, do C-x C-f,
       move into the prompt (sorry) and to C-u x =

   That's the how, not the why. My point was that it is designed purposely to
   prevent C-a from moving point to that beginning of the minibuffer (and a
   good thing, too).

This C-a design is identical with the way prompts are handled in comint
buffers. e.g. shell buffers, where you can (fortunately) move into the
prompt using the same commands with which you can move into the
minibuffer prompt.  So Emacs is consistent in the way it treats prompts.

Sincerely,

Luc.

Re: Avoiding moving point into minibuffer prompt area

[David Reitter]

On 16 Aug 2005, at 05:51, Drew Adams wrote:

> And a question - ignore, if this has already been beaten to death -
> shouldn't "inviolable" be the default value? A novice might get  
> confused and
> not know about the option to make the text inviolable;

Yes, I agree: it should be default. I used to be first confused, then  
annoyed when it happened repeatedly (I delete text pretty often  
that's in the minibuffer, and then I accidentally get into the  
prompt), so I set 'read-only' (similar to inviolable, i guess) as a  
default in Aquamacs.

> a veteran is more
> likely to try to copy prompt text and to discover the open-sesame  
> option, if
> it is locked by default.

Luc says he likes to copy the prompt when reporting bugs etc., but  
who is Emacs catering for? Its own developers? Its bug-reporting  
users? Or users that actually do productive use? The latter should  
probably be the default assumption, since it agrees with what most  
people do with it...

Re: Avoiding moving point into minibuffer prompt area

[Luc Teirlinck]

David Reitter wrote:

   (I delete text pretty often that's in the minibuffer, and then I
   accidentally get into the prompt), so I set 'read-only' (similar to
   inviolable, i guess) as a default in Aquamacs.

No, read-only prevents you from erasing the text, not from moving into it.
read-only _is_ on by default.

Sincerely,

Luc.

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

Luc Teirlinck wrote:

>David Reitter wrote:
>
>   (I delete text pretty often that's in the minibuffer, and then I
>   accidentally get into the prompt), so I set 'read-only' (similar to
>   inviolable, i guess) as a default in Aquamacs.
>
>No, read-only prevents you from erasing the text, not from moving into it.
>read-only _is_ on by default.
>  
>
Which is a big difference compared to shell buffers where you can erase 
the prompt. That too was a surprise to me in the beginning.

How the prompt is handled does not seem so consistent as you maybe 
hastily thought before. So I must say this area is prone to 
misunderstanding. I still believe the best is to make it simple for 
beginners and not let the point move in to the minibuffer prompt.

Re: Avoiding moving point into minibuffer prompt area

[Richard M. Stallman]

    I think it is quite confusing that you can move the point into the 
    prompt area in the minibuffer. Why don't we use something like the code 
    below to avoid this:

If we want to make it impossible to move point into the prompt,
it should suffice to give it an intangible property of t, right?
People could try that and see if they like it.
However, we've already seen one person say that he finds it
useful to move into the prompt.

Re: Avoiding moving point into minibuffer prompt area

[Luc Teirlinck]

Lennart Borgman wrote:

   Which is a big difference compared to shell buffers where you can erase 
   the prompt. That too was a surprise to me in the beginning.

You can change that by by setting comint-prompt-read-only to t.
But erasing prompts is sometimes useful for cleanup in shell buffers,
whereas actually erasing the prompt is probably really never useful in
the minibuffer (although you can do it if you customize
minibuffer-prompt-properties).

Actually, there are functions that allow you to erase shell prompts
for cleanup, even with comint-prompt-read-only set to t, but you need
to read some docs (the comint-prompt-read-only docstring) and paste
some stuff from there into your .emacs to be able to do that.  This is
why comint-prompt-read-only is nil by default.

I personally have comint-prompt-read-only set to t, but I routinely
use `comint-kill-whole-line' or `comint-kill-region' to clean up
comint buffers.

Sincerely,

Luc.

Re: Avoiding moving point into minibuffer prompt area

[Randal L. Schwartz]

>>>>> "Drew" == Drew Adams <drew.adams@oracle.com> writes:

Drew> I'd still be interested in knowing what your text-copying use case is.

I sometimes use command history to turn an interactive command into a
piece of lisp code to use later, or at least study how it was invoked,
or reinvoke it on a variable instead of a literal string.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Avoiding moving point into minibuffer prompt area

[Richard M. Stallman]

    It is useful to move point into the minibuffer prompt without
    changing default settings.  But since this can be confusing for
    beginners, maybe it should be more difficult to move point into the
    prompt area by default?  For example, to disable moving point into
    the prompt with C-b, but allow C-a at the beginning of the input
    area to move point to the beginning of the prompt.

I don't want to even consider something so complex.

This is the sort of minor issue that can take up lots of everyone's
time, but can't possibly be worth it.  And in the mean time, the tasks
that need to be done for the release are not getting done.

Therefore, I will say right now that I will not consider anything
along these lines.  I ask everyone to drop this thread and not send
any further mail about it.

Re: Avoiding moving point into minibuffer prompt area

[Richard M. Stallman]

    BTW the message "Text is readonly" is also confusing when "Inviolable" 
    is set.

I do not understand.

     You expect the prompt to be readonly and the message is 
    disturbing when you delete character by character and then suddenly this 
    text appears over the prompt.

I can't follow.

Would you please give a clear test case, so we can understand
what behavior you are complaining about?

Re: Avoiding moving point into minibuffer prompt area

[Richard M. Stallman]

    And a question - ignore, if this has already been beaten to death -
    shouldn't "inviolable" be the default value?

That seems like a good argument to me.  I will try that option myself
and see what I think of it.

Re: Avoiding moving point into minibuffer prompt area

[David Reitter]

On 16 Aug 2005, at 18:57, Luc Teirlinck wrote:

> David Reitter wrote:
>
>    (I delete text pretty often that's in the minibuffer, and then I
>    accidentally get into the prompt), so I set 'read-only' (similar to
>    inviolable, i guess) as a default in Aquamacs.
>
> No, read-only prevents you from erasing the text, not from moving  
> into it.
> read-only _is_ on by default.

Correct. It's minibuffer-avoid-prompt that I'm setting as default.  
That, interestingly, is not in the list shown in the customize  
buffer, but it does the job.

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

Luc Teirlinck wrote:

>Lennart Borgman wrote:
>
>   Which is a big difference compared to shell buffers where you can erase 
>   the prompt. That too was a surprise to me in the beginning.
>
>You can change that by by setting comint-prompt-read-only to t.
>But erasing prompts is sometimes useful for cleanup in shell buffers,
>whereas actually erasing the prompt is probably really never useful in
>the minibuffer (although you can do it if you customize
>minibuffer-prompt-properties).
>
Thanks for the explanation. I must admit I knew nothing about that.

You inspired me to read on a bit about shell. My impression has been 
that it could perhaps be broken on w32 since you could edit the prompt 
and it seems like the edited prompt could be sent as a command etc. I 
kept my fingers away, but now... - it suddenly seems more usable.

As a notorious shell user I of course started to see if up and down 
arrows could be used for command recall. Just a few elisp lines and it 
works. (But are not others looking for this?)

However have not changed my opinion about Inviolable and the minibuffer 
prompt. ;-)

Re: Avoiding moving point into minibuffer prompt area

[Luc Teirlinck]

Lennart Borgman wrote:

   As a notorious shell user I of course started to see if up and down 
   arrows could be used for command recall.

Just the up and down arrows could not work, because in Shell mode, you
are supposed to be able to move through the buffer, so the arrows need
to have their usual meaning.  But M-p or C-up and M-n or C-down work.
It is explained in `(emacs)Shell Ring'.

   Just a few elisp lines and it works. (But are not others looking
   for this?)

Looking for what exactly?

Sincerely,

Luc.

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

Richard M. Stallman wrote:

>    BTW the message "Text is readonly" is also confusing when "Inviolable" 
>    is set.
>
>I do not understand.
>
>     You expect the prompt to be readonly and the message is 
>    disturbing when you delete character by character and then suddenly this 
>    text appears over the prompt.
>
>I can't follow.
>
>Would you please give a clear test case, so we can understand
>what behavior you are complaining about?
>  
>
This is not very important, but I did find it very annoying indeed. If 
you at a minibuffer prompt just hold down backspace to delete entered 
characters (this is quite common behaviour in situations like that) then 
Emacs will delete all characters up to the prompt and then show "Text is 
read-only".

That message sits there in front of the prompt and you really wonder 
what has happened. This is nothing you are used to from other 
applications in similar situations. "What could I have done? Did I do 
something else than just delete those characters? How can I know?"

Then you discover that the message disappear but you still feel a bit 
unsure. After a while you begin to understand (after carefully checking 
for changes in the files, shutting down Emacs and starting it again 
perhaps). Even when you find the message most annoying because you have 
to wait until it disappears - at least you believe that because you have 
not yet learned...

----
Making a good UI is of course about carefully thinking about issues like 
the one above. What to do is by no means easy to decide. My intention is 
just to draw your attention to this and tell my view.

And I am sorry that I was not able to state this short and clear from 
the beginning. But it is not easy since I have noticed that issues like 
this often get handled on the wrong level. No surprise of course, 
thinking is not a small bit about beeing able to simplify. That is good, 
I know of no other way, but sometimes you must go back and see what 
might have been lost, maybe even changing the strategy a bit.

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

Luc Teirlinck wrote:

>Lennart Borgman wrote:
>
>   As a notorious shell user I of course started to see if up and down 
>   arrows could be used for command recall.
>
>Just the up and down arrows could not work, because in Shell mode, you
>are supposed to be able to move through the buffer, so the arrows need
>to have their usual meaning.  But M-p or C-up and M-n or C-down work.
>It is explained in `(emacs)Shell Ring'.
>
>   Just a few elisp lines and it works. (But are not others looking
>   for this?)
>
>Looking for what exactly?
>  
>
Using the up and down arrow keys to recall commands in shell buffers. My 
simple solution is just to let it work that way after the prompt and let 
them move around in the buffer otherwise. I prefer that because I am 
used to this recall commands this way at command prompts. (But that may 
be only me.)

RE: Avoiding moving point into minibuffer prompt area

[Drew Adams]

On a related subject, and being a bit nit-picky - does anyone else think
that these things should be harmonized & better documented?

 - Neither the Emacs manual nor the Emacs-Lisp manual contains the word
"inviolable".

 - Both manuals refer to the "intangible" property.

 - Is "intangible" not the same property as what Customize refers to as
"inviolable"? More precisely, isn't the "intangible" property what makes the
minibuffer-prompt area "inviolable"?

 - If so, wouldn't it be better to stick to the same term, whichever we
choose? Especially since "inviolable" conveys no more meaning to the
uninitiated than "intangible" - nothing is gained by using it, except
another layer of obfuscation.

Of the two terms, "intangible" is more accurate, IMO.

Someone will perhaps reply that "inviolable" applies to the
minibuffer-prompt area, indicating that it cannot be entered ("violated"),
while "intangible" is the corresponding text property of that area. Even so,
I think more would be gained by using the same term ("intangible") in
Customize. That would help users make the link with all of the doc that
describes the characteristics of the "intangible" property.

RE: Avoiding moving point into minibuffer prompt area

[Drew Adams]

      I'd still be interested in knowing what your text-copying
      use case is.

    I sometimes use command history to turn an interactive command into a
    piece of lisp code to use later, or at least study how it was invoked,
    or reinvoke it on a variable instead of a literal string.

Sorry, it's unclear to me what you are saying. Could you elaborate or be
more specific? How does putting the cursor in the minibuffer-prompt area
help you - how do you use that feature?

Re: Avoiding moving point into minibuffer prompt area

[Randal L. Schwartz]

>>>>> "Drew" == Drew Adams <drew.adams@oracle.com> writes:

Drew>       I'd still be interested in knowing what your text-copying
Drew>       use case is.

Drew>     I sometimes use command history to turn an interactive command into a
Drew>     piece of lisp code to use later, or at least study how it was invoked,
Drew>     or reinvoke it on a variable instead of a literal string.

Drew> Sorry, it's unclear to me what you are saying. Could you elaborate or be
Drew> more specific? How does putting the cursor in the minibuffer-prompt area
Drew> help you - how do you use that feature?

Well, now that I'm clear on the rest of the thread, I realize I'm
talking about a different part.  No, I've never moved dot into the prompt.
Just around within the response to the prompt.

Sorry.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

RE: Avoiding moving point into minibuffer prompt area

[Drew Adams]

    Well, now that I'm clear on the rest of the thread, I realize I'm
    talking about a different part.  No, I've never moved dot into 
    the prompt.
    
OK. Thanks for clearing it up.

Re: Avoiding moving point into minibuffer prompt area

[Luc Teirlinck]

Drew Adams wrote:
    
    - Neither the Emacs manual nor the Emacs-Lisp manual contains the word
   "inviolable".
    
"Inviolable" is just an internal Custom tag.  From cus-start.el:

(const :tag "Inviolable"
       :doc "Prevent point from ever entering prompt"
       :format "%t%n%h"
       :inline t
       (point-entered minibuffer-avoid-prompt))

    - Is "intangible" not the same property as what Customize refers to as
   "inviolable"? More precisely, isn't the "intangible" property what makes the
   minibuffer-prompt area "inviolable"?

No, it is the point-entered property, as you can see from the above.
If it were the intangible property, you would be able to move to the
beginning of the prompt, you would just not be able to move _inside_
the prompt.  In other words, C-b would not stop just after the
prompt.  Instead, it would move from just after the prompt to the
beginning of the minibuffer with one single C-b.

    - If so,

It is not so, so I guess that makes the remainder of the message irrelevant.

Sincerely,

Luc.

Re: Avoiding moving point into minibuffer prompt area

[Luc Teirlinck]

>From my previous message:

   "Inviolable" is just an internal Custom tag.

Well, that was a little bit misformulated.  It is not "internal",
because it appears user-visibly in the Custom buffer.  What I meant
with "internal to Custom" is that it is strictly a Custom thing, and
meaningless in as far as Elisp is concerned.  It is just a tag that
appears in the Custom buffer and nothing else.

Sincerely,

Luc.

Re: Avoiding moving point into minibuffer prompt area

[Emilio Lopes]

Richard M Stallman writes:

>     I think it is quite confusing that you can move the point into
>     the prompt area in the minibuffer. Why don't we use something
>     like the code below to avoid this:

> If we want to make it impossible to move point into the prompt, it
> should suffice to give it an intangible property of t, right?
> People could try that and see if they like it.  However, we've
> already seen one person say that he finds it useful to move into the
> prompt.

I think the situation is somewhat similar with the case of e-mail
headers in Rmail.  Having used fascist e-mail clients before I was
scared that with Emacs you could indeed *change* the headers yourself
and maybe even break something.  But with time I learned to appreciate
the extra power.

I myself don't move into the prompt that often, but I like to know
that I can if I need to, without having to hunt for some newly added
user option.

So, comfort and ease-of-use, yes; restriction and over-protection, no.

 -ECL

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

Emilio Lopes wrote:

>Richard M Stallman writes:
>
>  
>
>>    I think it is quite confusing that you can move the point into
>>    the prompt area in the minibuffer. Why don't we use something
>>    like the code below to avoid this:
>>    
>>
>
>  
>
>>If we want to make it impossible to move point into the prompt, it
>>should suffice to give it an intangible property of t, right?
>>People could try that and see if they like it.  However, we've
>>already seen one person say that he finds it useful to move into the
>>prompt.
>>    
>>
>
>I think the situation is somewhat similar with the case of e-mail
>headers in Rmail.  Having used fascist e-mail clients before I was
>scared that with Emacs you could indeed *change* the headers yourself
>and maybe even break something.  But with time I learned to appreciate
>the extra power.
>
>I myself don't move into the prompt that often, but I like to know
>that I can if I need to, without having to hunt for some newly added
>user option.
>
>So, comfort and ease-of-use, yes; restriction and over-protection, no.
>
> -ECL
>  
>
But you are asking for protection (for yourself) aren't you? ;-)

I will not answer on the list since Richard asked us not to discuss this 
their any more.

Best wishes,
Lennart

Re: Avoiding moving point into minibuffer prompt area

[Richard M. Stallman]

    you at a minibuffer prompt just hold down backspace to delete entered 
    characters (this is quite common behaviour in situations like that) then 
    Emacs will delete all characters up to the prompt and then show "Text is 
    read-only".

Now I understand the issue.  What change could we make?

We could change the error message to say "Prompt is read-only".
Would that make it clearer, do you think?

Re: Avoiding moving point into minibuffer prompt area

[Richard M. Stallman]

     - Neither the Emacs manual nor the Emacs-Lisp manual contains the word
    "inviolable".

I think I will change it to "don't enter".

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

Richard M. Stallman wrote:

>    you at a minibuffer prompt just hold down backspace to delete entered 
>    characters (this is quite common behaviour in situations like that) then 
>    Emacs will delete all characters up to the prompt and then show "Text is 
>    read-only".
>
>Now I understand the issue.  What change could we make?
>
>We could change the error message to say "Prompt is read-only".
>Would that make it clearer, do you think?
>  
>
Thanks, but as I tried to explain I do not think it is the best to do 
so. My suggestion is two make two changes:

1) Change the default for Inviolable to on.

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.

RE: Avoiding moving point into minibuffer prompt area

[Drew Adams]

         - Neither the Emacs manual nor the Emacs-Lisp manual 
           contains the word "inviolable".
    
    I think I will change it to "don't enter".

Simple and clear. Thanks.

Re: Avoiding moving point into minibuffer prompt area

[Richard M. Stallman]

    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?

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

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.

Re: Avoiding moving point into minibuffer prompt area

[Richard M. Stallman]

    >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... point to stop where it is then.

Normally, delete-backward-char at the beginning of the buffer
gives an error, "Beginning of buffer".  It would seem strange
if, when just after the prompt, it did nothing at all.

    In the minibuffer there is by default (emacs -Q) no color that tells 
    where the prompt ends.

The prompt uses the face `minibuffer-prompt'.  Are you saying this
does not work for you?  It works for me.

It is hard for me to understand the rest of your message.  It seems
to cover many topics and I do not see the relationship between them.

Re: Avoiding moving point into minibuffer prompt area

[Lennart Borgman]

Richard M. Stallman wrote:

>    >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... point to stop where it is then.
>
>Normally, delete-backward-char at the beginning of the buffer
>gives an error, "Beginning of buffer".  It would seem strange
>if, when just after the prompt, it did nothing at all.
>  
>
Perhaps not. Is not this another situation. The buffer could be scrolled 
down (for example).

>    In the minibuffer there is by default (emacs -Q) no color that tells 
>    where the prompt ends.
>
>The prompt uses the face `minibuffer-prompt'.  Are you saying this
>does not work for you?  It works for me.
>  
>
No. I tried to say that the default face for the minibuffer prompt does 
not have any special background color.

>It is hard for me to understand the rest of your message.  It seems
>to cover many topics and I do not see the relationship between them.
>  
>
Maybe I should have to learn that communication by email is a bit 
different than in real life. What I tried to say was that it is common 
GUI design to use a special background color for the areas you can not 
move into in a window (Emacs frame). Emacs does that to. For example for 
the mode line, the menu bar etc. The same kind of visual clue could be 
used for the prompt in the minibuffer.

And I will not say more now. I stop to make this a clear starting point.

Re: Avoiding moving point into minibuffer prompt area

[Richard M. Stallman]

    >The prompt uses the face `minibuffer-prompt'.  Are you saying this
    >does not work for you?  It works for me.
    >  
    >
    No. I tried to say that the default face for the minibuffer prompt does 
    not have any special background color.

Can you debug that and see why it doesn't work for you?

Re: Avoiding moving point into minibuffer prompt area

[Richard M. Stallman]

    >Normally, delete-backward-char at the beginning of the buffer
    >gives an error, "Beginning of buffer".  It would seem strange
    >if, when just after the prompt, it did nothing at all.
    >  
    >
    Perhaps not. Is not this another situation. The buffer could be scrolled 
    down (for example).

I don't understand; I think we are failing to communicate.