find-file and backward-kill-word

find-file and backward-kill-word

[Reinhard Kotucha]

When I run find-file I get a prompt like this:

Find file: /tmp/reinhard/

I can edit everything on the right to the space after the colon.  For
instance, beginning-of-line moves the cursor to the first slash.

So far so good.  But if I then run the command backward-kill-word
(M-DEL), the cursor moves to the "f" of the word "file" and I get the
message

Text is read-only: #<buffer  *Minibuf-1*>

I'm sure you can reproduce the problem because I can can even
reproduce it with a precompiled binary for Widows I use at work.

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-4592165
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha@web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------

Re: find-file and backward-kill-word

[Luc Teirlinck]

Reinhard Kotucha wrote:

   When I run find-file I get a prompt like this:

   Find file: /tmp/reinhard/

   I can edit everything on the right to the space after the colon.  For
   instance, beginning-of-line moves the cursor to the first slash.

   So far so good.  But if I then run the command backward-kill-word
   (M-DEL), the cursor moves to the "f" of the word "file" and I get the
   message

   Text is read-only: #<buffer  *Minibuf-1*>

That is not a bug.  You are right after the prompt: `Find file: '.
`backward-kill-word' kills the preceding word, in this case `file: '.
Of course, `file: ' is read-only, so it can not be deleted.  But it is
copied to the kill ring, which in certain situations could be useful.
The cursor moves to the `f' to allow a following `backward-kill-word'
to prepend `Find ' to the kill-ring entry, which would then be `Find file: '.

See `(emacs)Killing' for details.

Sincerely,

Luc.

Re: find-file and backward-kill-word

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Reinhard Kotucha wrote:
>
>    When I run find-file I get a prompt like this:
>
>    Find file: /tmp/reinhard/
>
>    I can edit everything on the right to the space after the colon.  For
>    instance, beginning-of-line moves the cursor to the first slash.
>
>    So far so good.  But if I then run the command backward-kill-word
>    (M-DEL), the cursor moves to the "f" of the word "file" and I get the
>    message
>
>    Text is read-only: #<buffer  *Minibuf-1*>
>
> That is not a bug.

It is also not pretty.

> You are right after the prompt: `Find file: '.  `backward-kill-word'
> kills the preceding word, in this case `file: '.  Of course, `file:
> ' is read-only, so it can not be deleted.  But it is copied to the
> kill ring, which in certain situations could be useful.  The cursor
> moves to the `f' to allow a following `backward-kill-word' to
> prepend `Find ' to the kill-ring entry, which would then be `Find
> file: '.
>
> See `(emacs)Killing' for details.

Perhaps we should not move the cursor when "killing" readonly
material?  It would have the disadvantage that using kill-word three
times will not copy three words into the kill buffer, but I don't
think that killing readonly text is used so often that we need to
provide this sort of "convenience".  If we signal an error, I don't
think we should really move point, either.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: find-file and backward-kill-word

[Luc Teirlinck]

David Kastrup wrote:

   Perhaps we should not move the cursor when "killing" readonly
   material?  It would have the disadvantage that using kill-word three
   times will not copy three words into the kill buffer, but I don't
   think that killing readonly text is used so often that we need to
   provide this sort of "convenience".  If we signal an error, I don't
   think we should really move point, either.

I kill text in read-only buffers all the time.  On the other hand, I
would hope that people would not try to edit read-only buffers
countless times each day.  Having to reposition point in such a,
hopefully rare, case is not a major inconvenience.  It is not like
loosing editing, mistakenly deleting files, unknowingly breaking hard
links or the like.

On the other hand, I do not know why the default value of
`kill-read-only-ok' is nil.  I believe that what causes confusion is
that the error message is misleading and does not tell the user what
really happened.  We not only moved point, but also copied text to the
kill ring.  We _have_ to tell the user that, or the next yank will be
a much bigger surprise than the point motion.  If `kill-read-only-ok'
is t, the message you get is "Read only text copied to kill ring"
which tells you exactly what happened.  If `kill-read-only-ok' is nil
you get "Buffer is read-only: #<buffer *info*>", which is misleading,
since it suggests that nothing happened.

I believe that we should not just change the default of
`kill-read-only-ok' to t, I believe we could quite as well eliminate
the variable and hardcode the `t' behavior.  The `nil' behavior makes
no sense.

Sincerely,

Luc.

Re: find-file and backward-kill-word

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> David Kastrup wrote:
>
>    Perhaps we should not move the cursor when "killing" readonly
>    material?  It would have the disadvantage that using kill-word three
>    times will not copy three words into the kill buffer, but I don't
>    think that killing readonly text is used so often that we need to
>    provide this sort of "convenience".  If we signal an error, I don't
>    think we should really move point, either.
>
> I kill text in read-only buffers all the time.  On the other hand, I
> would hope that people would not try to edit read-only buffers
> countless times each day.  Having to reposition point in such a,
> hopefully rare, case is not a major inconvenience.  It is not like
> loosing editing, mistakenly deleting files, unknowingly breaking hard
> links or the like.
>
> On the other hand, I do not know why the default value of
> `kill-read-only-ok' is nil.  I believe that what causes confusion is
> that the error message is misleading and does not tell the user what
> really happened.  We not only moved point, but also copied text to the
> kill ring.  We _have_ to tell the user that, or the next yank will be
> a much bigger surprise than the point motion.  If `kill-read-only-ok'
> is t, the message you get is "Read only text copied to kill ring"
> which tells you exactly what happened.  If `kill-read-only-ok' is nil
> you get "Buffer is read-only: #<buffer *info*>", which is misleading,
> since it suggests that nothing happened.
>
> I believe that we should not just change the default of
> `kill-read-only-ok' to t, I believe we could quite as well eliminate
> the variable and hardcode the `t' behavior.  The `nil' behavior makes
> no sense.

An error stops a complex editing operation in the course of a Lisp
program or keyboard macro before it does half-baked nonsensical
things.

I don't want complex operations to merrily complete "successfully"
after having done a number of incomplete steps.  Improving the error
message is ok, but not at the cost of dropping the error.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: find-file and backward-kill-word

[Alan Shutko]

David Kastrup <dak@gnu.org> writes:

> Perhaps we should not move the cursor when "killing" readonly
> material? 

Is the problem here really "killing" readonly material?  IMO, the
problem is killing into the prompt, which is a fairly recent Emacs
behavior.  I have 

    minibuffer-prompt-properties's value is 
    (read-only t point-entered minibuffer-avoid-prompt)


    Text properties that are added to minibuffer prompts.
    These are in addition to the basic `field' property, and stickiness
    properties.

    You can customize this variable.

    Defined in `C source code'.

This fixes the problem completely for me, with no ill effects save
that I can't copy the prompt.  Since I've never wanted to do that, I'm
not unhappy.

Perhaps minibuffer-avoid-prompt should be made the default.

(I think the reason that "killing" moves the prompt is that it allows
you to kill a larger segment of text, if you want to.  It beeps a lot,
but I have found it useful occasionally outside the minibuffer.)

-- 
Alan Shutko <ats@acm.org> - I am the rocks.
Just when you thought it was safe to go outside...

Re: find-file and backward-kill-word

[Reinhard Kotucha]

>>>>> "Alan" == Alan Shutko <ats@acm.org> writes:

    >     minibuffer-prompt-properties's value is (read-only t
    > point-entered minibuffer-avoid-prompt)

It solves my problem.  Can't this be the default?  

>>>>> "Luc" == Luc Teirlinck <teirllm@dms.auburn.edu> writes:

    > I kill text in read-only buffers all the time.

This is still possible with this configuration.  Except with the
minibuffer prompt.  But I assume that this is ok for you.

I think that most users expect that the cursor runs against a wall
rather than move into the read-only portion of the minibuffer.

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-4592165
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha@web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------

Re: find-file and backward-kill-word

[Luc Teirlinck]

Reinhard Kotucha wrote:

   This is still possible with this configuration.  Except with the
   minibuffer prompt.  But I assume that this is ok for you.

   I think that most users expect that the cursor runs against a wall
   rather than move into the read-only portion of the minibuffer.

The question is not whether most users would expect that, but whether
most users would find that more useful.

With the proposed new default value of minibuffer-prompt-properties, namely
(read-only t point-entered minibuffer-avoid-prompt face minibuffer-prompt),
it at first view seems difficult (impossible?) to kill and yank any
part of the prompt in any way.  (I might be missing something.)
Killing and yanking the prompt is sometimes useful, say, when filing a
bug report or discussing Emacs' behavior over email.

On the other hand, I do not often accidentally enter the minibuffer
prompt and even if I do, it is no big deal, a variety of conveniently
bound commands get me out of there in a hurry.

Note that Custom makes it very convenient to get the behavior you
want.  When you customize minibuffer-prompt-properties through Custom
and click on "Show Value", you get:

    Minibuffer Prompt Properties: Hide Value
    [X] Read-Only
	Prevent prompt from being modified
    [ ] Inviolable
	Prevent point from ever entering prompt
    Other Properties:
    INS DEL Property: face
		Value: minibuffer-prompt
    INS
       State: this option has been changed outside the customize buffer.

Just check `inviolable' and save.

Sincerely,

Luc.

Re: find-file and backward-kill-word

[Richard Stallman]

    I don't want complex operations to merrily complete "successfully"
    after having done a number of incomplete steps.  Improving the error
    message is ok, but not at the cost of dropping the error.

I agree.

It was done this way on the idea that there's no harm in putting the
text in the kill ring before getting the error.  If people think that
is confusing, we could change it to get the error before altering the
kill ring when kill-read-only-ok is nil.

But this feature was introduced in 1994, so people are apparently
not complaining much.  Therefore let's leave it alone.

Re: find-file and backward-kill-word

[Alan Shutko]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> With the proposed new default value of minibuffer-prompt-properties, namely
> (read-only t point-entered minibuffer-avoid-prompt face minibuffer-prompt),
> it at first view seems difficult (impossible?) to kill and yank any
> part of the prompt in any way.


That's correct.  However, I've had this setting since Emacs started
letting one enter the prompt, and I've never missed the ability to
kill anything in the prompt.

-- 
Alan Shutko <ats@acm.org> - I am the rocks.
Soon my Army will STORM Gotham City...

Re: find-file and backward-kill-word

[Richard Stallman]

    That's correct.  However, I've had this setting since Emacs started
    letting one enter the prompt, and I've never missed the ability to
    kill anything in the prompt.

ISTR that the main reason for including the prompt in the buffer
was for the sake of simplifying redisplay.  It no longer has to treat
the prompt as a special case, and other special cases such as a prompt
longer than one line now work.  The ability to move into the prompt
sort of followed from that.

If making it in general impossible to move into the prompt makes
things less confusing in general for users, it might be a good idea.

Re: find-file and backward-kill-word

[Stefan Daschek]

Richard Stallman <rms@gnu.org> writes:

> If making it in general impossible to move into the prompt makes
> things less confusing in general for users, it might be a good idea.

I'd vote for it. It happened to me occasionally that I unintentionally
moved the cursor into the prompt and I always thought of it as a bug. 

What confuses me even more in this situation is that the prompt gets
replaced by another message (like "Read only text copied to kill
ring") for some seconds.

stefan