`*' interactive spec in some text-killing functions

`*' interactive spec in some text-killing functions

[Juanma Barranquero]

The following functions from simple.el do not have the `*' interactive
spec: zap-to-char, kill-line, kill-whole-line, kill-word,
backward-kill-word. (They don't have a call to
`barf-if-buffer-read-only', either).

Using any of them in a read-only buffer does not delete text, but it
moves the point forward (or backward, in the case of
`backward-kill-word'), which is weird.

Is that intended, or should they have `*' in the interactive spec?

Additionally, `overwrite-mode' and `binary-overwrite-mode' do not have
`*' either. It is customary not to do so for minor modes, it is an
oversight, or it is really preferred not to get an error message in
interactive uses of the overwrite modes?

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> The following functions from simple.el do not have the `*' interactive
> spec: zap-to-char, kill-line, kill-whole-line, kill-word,
> backward-kill-word. (They don't have a call to
> `barf-if-buffer-read-only', either).
>
> Using any of them in a read-only buffer does not delete text, but it
> moves the point forward (or backward, in the case of
> `backward-kill-word'), which is weird.
>
> Is that intended, or should they have `*' in the interactive spec?

The purpose of not having `*' presumably is to have them affect the
kill-ring.  In order to provide similar behavior upon multiple kills
as in a non-readonly-buffer, it appears reasonable to move across the
(non-happening) kill.

> Additionally, `overwrite-mode' and `binary-overwrite-mode' do not
> have `*' either. It is customary not to do so for minor modes, it is
> an oversight, or it is really preferred not to get an error message
> in interactive uses of the overwrite modes?

Uh what?  Switching to overwrite-mode/binary-overwrite-mode does not
change the buffer, does it?

-- 
David Kastrup

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/27/07, David Kastrup <dak@gnu.org> wrote:

> The purpose of not having `*' presumably is to have them affect the
> kill-ring.  In order to provide similar behavior upon multiple kills
> as in a non-readonly-buffer, it appears reasonable to move across the
> (non-happening) kill.

I'm not sure I understand. Do you mean that people routinely does kill
operations on a read-only buffer in order to copy text to the kill
ring?

> Uh what?  Switching to overwrite-mode/binary-overwrite-mode does not
> change the buffer, does it?

No. But it seems like an error to *interactively* change to
overwrite-mode in a read-only buffer, doesn't it?

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/27/07, David Kastrup <dak@gnu.org> wrote:
>
>> The purpose of not having `*' presumably is to have them affect the
>> kill-ring.  In order to provide similar behavior upon multiple kills
>> as in a non-readonly-buffer, it appears reasonable to move across the
>> (non-happening) kill.
>
> I'm not sure I understand. Do you mean that people routinely does
> kill operations on a read-only buffer in order to copy text to the
> kill ring?

(info "(emacs) Killing")

[...]

       You cannot kill read-only text, since such text does not allow
    any kind of modification.  But some users like to use the kill
    commands to copy read-only text into the kill ring, without
    actually changing it.  Therefore, the kill commands work specially
    in a read-only buffer: they move over text, and copy it to the
    kill ring, without actually deleting it from the buffer.
    Normally, kill commands beep and display an error message when
    this happens.  But if you set the variable `kill-read-only-ok' to
    a non-`nil' value, they just print a message in the echo area to
    explain why the text has not been erased.

>> Uh what?  Switching to overwrite-mode/binary-overwrite-mode does not
>> change the buffer, does it?
>
> No. But it seems like an error to *interactively* change to
> overwrite-mode in a read-only buffer, doesn't it?

Why?  It does not make the act of typing characters more or less
legitimate.

-- 
David Kastrup

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/27/07, David Kastrup <dak@gnu.org> wrote:
> "Juanma Barranquero" <lekktu@gmail.com> writes:

> But some users like to use the kill
> commands to copy read-only text into the kill ring, without
> actually changing it.

Interesting, thanks.

> Why?  It does not make the act of typing characters more or less
> legitimate.

Typing text in a read-only buffer won't have much of an effect, unless
the keys are bound to some commands other than `self-insert-command'.
And if they are, I really doubt these commands use the value of
`overwrite-mode' to select among several different behaviors, except
in very specialized cases. In most normal uses, activating
overwrite-mode in a read-only mode is an error, if a harmless one.

But this is not really important, I was just curious. For my own use
it *is* an error to set overwrite-mode in a read-only buffer, so I'll
defadvice around the issue.

             Juanma

Re: `*' interactive spec in some text-killing functions

[Andreas Schwab]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/27/07, David Kastrup <dak@gnu.org> wrote:
>
>> The purpose of not having `*' presumably is to have them affect the
>> kill-ring.  In order to provide similar behavior upon multiple kills
>> as in a non-readonly-buffer, it appears reasonable to move across the
>> (non-happening) kill.
>
> I'm not sure I understand. Do you mean that people routinely does kill
> operations on a read-only buffer in order to copy text to the kill
> ring?

Please read the history.  This feature has been added 15 years ago.

>> Uh what?  Switching to overwrite-mode/binary-overwrite-mode does not
>> change the buffer, does it?
>
> No. But it seems like an error to *interactively* change to
> overwrite-mode in a read-only buffer, doesn't it?

Would you also forbid enabling auto-fill-mode or abbrev-mode in a
read-only buffer?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/27/07, Andreas Schwab <schwab@suse.de> wrote:

> Please read the history.  This feature has been added 15 years ago.

Emacs is big. I didn't know it. I don't use that feature (and now that
I know it, I still don't think I'll ever use it). What's the problem
with asking?

> Would you also forbid enabling auto-fill-mode or abbrev-mode in a
> read-only buffer?

Perhaps. If they cause confusion.

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/27/07, Andreas Schwab <schwab@suse.de> wrote:
>
>> Please read the history.  This feature has been added 15 years ago.
>
> Emacs is big. I didn't know it. I don't use that feature (and now that
> I know it, I still don't think I'll ever use it). What's the problem
> with asking?
>
>> Would you also forbid enabling auto-fill-mode or abbrev-mode in a
>> read-only buffer?
>
> Perhaps. If they cause confusion.

I don't see what confusion is caused by being able to switch from
insert-mode to overwrite-mode and back in a readonly buffer.  Would
you also prohibit switching _off_ overwrite-mode?  If yes, why?  If
no, why?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/27/07, David Kastrup <dak@gnu.org> wrote:

> I don't see what confusion is caused by being able to switch from
> insert-mode to overwrite-mode and back in a readonly buffer.

This is about angels on a pin's head, isn't it? Because I already said
that the issue was not really important...

But anyway, it is a cognitive dissonance. Nothing more, nothing less.
If I switch to overwrite mode in a read-only buffer, the problem is
not that it is *going to* cause me confusion, the problem is that I
*am* already confused; because, in most cases, it is a meaningless
action.

When I'm at the beginning of a buffer and I do PgUP, which runs
scroll-down, I get a "Beginning of buffer" message. It's not really
necessary. But it is helpful.

> Would
> you also prohibit switching _off_ overwrite-mode?  If yes, why?  If
> no, why?

Prohibit? (overwrite-mode 1) works regardless of `*', so certainly
code would be able to switch it, if really needed. I wasn't talking
about "prohibiting", but about "warning" (that's what the `*' does
IMHO).

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/27/07, David Kastrup <dak@gnu.org> wrote:

>> Would you also prohibit switching _off_ overwrite-mode?  If yes,
>> why?  If no, why?
>
> Prohibit? (overwrite-mode 1) works regardless of `*', so certainly
> code would be able to switch it, if really needed. I wasn't talking
> about "prohibiting", but about "warning" (that's what the `*' does
> IMHO).

No.  `*' does not warn, it throws an error.  The function is not
entered interactively at all.  That is the reason that the kill
functions that want to affect the kill buffer can't use `*'.

And a readonly buffer does not get a warning when you try to change
it, but again throws an error, and nothing happens.  Regardless
whether you try it interactively or not.  `*' does not change that: it
might just throw an error at a more convenient time.  Especially, when
otherwise the interactive form or the function will laboriously
require some user input/interaction, only to throw an error
afterwards.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, David Kastrup <dak@gnu.org> wrote:

> No.  `*' does not warn, it throws an error.

Interactively, what's an error but a warning to the user? I get a
non-intrusive "Buffer is read-only: #<buffer my-buffer>" message, and
that's all. And non-interactively there's no change in behavior.

> That is the reason that the kill
> functions that want to affect the kill buffer can't use `*'.

I understand that, which is irrelevant to my point.

> And a readonly buffer does not get a warning when you try to change
> it, but again throws an error, and nothing happens.  Regardless
> whether you try it interactively or not.  `*' does not change that: it
> might just throw an error at a more convenient time.

I'm not sure what are you trying to say here.

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/28/07, David Kastrup <dak@gnu.org> wrote:
>
>> No.  `*' does not warn, it throws an error.
>
> Interactively, what's an error but a warning to the user?

A warning causes an action to continue (and usually no beep), an error
aborts the current operation (including a keyboard macro) and beeps.

>> And a readonly buffer does not get a warning when you try to change
>> it, but again throws an error, and nothing happens.  Regardless
>> whether you try it interactively or not.  `*' does not change that: it
>> might just throw an error at a more convenient time.
>
> I'm not sure what are you trying to say here.

Well, that's only fair.  On my side, I have no clue whatsoever what
you are trying to achieve with your proposal that one should not be
able to change between overwrite and insertion mode in a readonly
buffer.

For example, I find it completely legitimate to change to overwrite
mode, then lock out a file from RCS (which makes it writable), work on
it, check it in and then change back from overwrite mode (even though
the buffer is already again readonly).

I see no point whatsoever to throw an error in that situation.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, David Kastrup <dak@gnu.org> wrote:

> A warning causes an action to continue (and usually no beep), an error
> aborts the current operation (including a keyboard macro) and beeps.

I *know*. When I said "a warning" I added "IMHO". I wasn't (am not)
talking in general, but about overwrite-mode. Or do you mean that it
would be very different

 (defun overwrite-mode (&optional arg)
   (interactive "*P")
   ...

from

 (defun overwrite-mode (&optional arg)
   (interactive "P")
   (when buffer-read-only
      (message "Arggg!"))
   ...)

*other* than the fact that the second one really changes the mode
(which is not very important for the issue I'm discussing).

> Well, that's only fair.

It was a literal truth. I didn't understand what you were trying to
say. My fault.

> On my side, I have no clue whatsoever what
> you are trying to achieve with your proposal that one should not be
> able to change between overwrite and insertion mode in a readonly
> buffer.

I don't remember proposing that. Honestly, what I'm saying wouldn't be
very affected by using the second alternative above (the
message/warning one) instead of the error one. I'm not talking about
interrupting the change (that's irrelevant), but warning the user of a
likely error.

> For example, I find it completely legitimate to change to overwrite
> mode, then lock out a file from RCS (which makes it writable), work on
> it, check it in and then change back from overwrite mode (even though
> the buffer is already again readonly).

That's an specific example. Good. Are there many more situations in
which switching to overwrite in a read-only buffer is meaningful and
more-or-less frequent?

> I see no point whatsoever to throw an error in that situation.

Fine. Would you feel different if I proposed adding

 (when buffer-read-only
    (message "Warning: buffer is read-only"))

at the top of overwrite-mode?

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/28/07, David Kastrup <dak@gnu.org> wrote:

[...]

> I don't remember proposing that. Honestly, what I'm saying wouldn't
> be very affected by using the second alternative above (the
> message/warning one) instead of the error one. I'm not talking about
> interrupting the change (that's irrelevant), but warning the user of
> a likely error.

What error?  The problem is an attempt to _change_ the buffer.
Changing something like overwrite-mode does not change the sets of
legitimate and refused operations.

>> For example, I find it completely legitimate to change to overwrite
>> mode, then lock out a file from RCS (which makes it writable), work
>> on it, check it in and then change back from overwrite mode (even
>> though the buffer is already again readonly).
>
> That's an specific example. Good. Are there many more situations in
> which switching to overwrite in a read-only buffer is meaningful and
> more-or-less frequent?

Can you name a single situation where the user gets _any_ benefits
from balking at toggling overwrite-mode?  It is not like work is
getting lost or something.

>> I see no point whatsoever to throw an error in that situation.
>
> Fine. Would you feel different if I proposed adding
>
> (when buffer-read-only
>    (message "Warning: buffer is read-only"))
>
> at the top of overwrite-mode?

Why would you want to do that?  In what situation would the user
derive any benefit from that?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, David Kastrup <dak@gnu.org> wrote:

> Why would you want to do that?  In what situation would the user
> derive any benefit from that?

In the same situation that doing PgUp when at the beginning of the
buffer would present him with a message "Beginning of buffer".

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/28/07, David Kastrup <dak@gnu.org> wrote:
>
>> Why would you want to do that?  In what situation would the user
>> derive any benefit from that?
>
> In the same situation that doing PgUp when at the beginning of the
> buffer would present him with a message "Beginning of buffer".

No, it wouldn't.  Page Up is _not_ executed at the beginning of
buffer, and the message gives the reason.  But Emacs _can_ toggle
overwrite-mode, it _does_ so, and it displays this in the mode line.
There _is_ a permanent effect, and the command behaves as usual.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, David Kastrup <dak@gnu.org> wrote:

> No, it wouldn't.

Well, I'm a user, and *I* would benefit in the same way, which is:
"Uh? Ah, OK, that wasn't very smart."

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/28/07, David Kastrup <dak@gnu.org> wrote:
>
>> No, it wouldn't.
>
> Well, I'm a user, and *I* would benefit in the same way, which is:
> "Uh? Ah, OK, that wasn't very smart."

But _why_ wouldn't it be "smart"?  The command _is_ executed, it has
the normal effect (which may become relevant if the buffer-read-only
state changes), and it does _absolutely_ no harm to the buffer
contents or anything else.

You still have not presented a single case where a notice would be of
any use at all, even if just to prevent the user from wasting time or
energy.

All that you have stated so far is that you want a warning.  What for?
What help will it provide to the user?  Do you fear that a user will
spend hours toggling Overwrite mode without noticing that he can't
insert or overwrite?

Why should Emacs warn about executing a command that it can perfectly
well execute?

I don't get it, and you are not exactly making a convincing, or even
any case for it.

-- 
David Kastrup

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, David Kastrup <dak@gnu.org> wrote:

> But _why_ wouldn't it be "smart"?  The command _is_ executed, it has
> the normal effect (which may become relevant if the buffer-read-only
> state changes), and it does _absolutely_ no harm to the buffer
> contents or anything else.

Neither does any harm to PgUp at the beginning of a buffer. What is
the message for? To alert me that I cannot go up? Well, my overwrite
message is to alert me that I cannot overwrite even if I just changed
to overwrite, and that I shouldn't expect most normal keys to act
differently just because I changed to overwrite.

> You still have not presented a single case where a notice would be of
> any use at all, even if just to prevent the user from wasting time or
> energy.

Do you mean that the PgUp case is better because it prevents the user
from endlessly looping doing PgUp without noticing that he's at the
beginning of the buffer (which is also displayed in the mode line, at
least on the default line-number-mode configuration) and that nothing
is moving?

> I don't get it, and you are not exactly making a convincing, or even
> any case for it.

I stopped trying to convince you around the "angels on a pin's head"
message, if not earlier. But you are unable to accept that I'm saying
that I would find it convenient: you try to convince me that I
wouldn't. That's ridiculous.

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/28/07, David Kastrup <dak@gnu.org> wrote:
>
>> But _why_ wouldn't it be "smart"?  The command _is_ executed, it has
>> the normal effect (which may become relevant if the buffer-read-only
>> state changes), and it does _absolutely_ no harm to the buffer
>> contents or anything else.
>
> Neither does any harm to PgUp at the beginning of a buffer.

If the command would get executed, the screen would be blank.  Emacs
can't execute the command, however.

> What is the message for? To alert me that I cannot go up?

To alert you that Emacs is _not_ executing the command.

> Well, my overwrite message is to alert me that I cannot overwrite
> even if I just changed to overwrite,

So WHAT?  Emacs _does_ change to overwrite mode.  It _completes_ the
command _properly_.  And it _will_ alert you if you actually try
inserting or overwriting any characters.

> and that I shouldn't expect most normal keys to act differently just
> because I changed to overwrite.

There are _billions_ of prospective variables you can change or toggle
that won't make a difference in particular modes or other stuff.  So
_WHAT_?  _Why_ should Emacs warn you whenever you do something that
_might_ not have an effect later unless certain other conditions are
changed?

Why?  How does it help the user?  How does it keep harm from him?

>> You still have not presented a single case where a notice would be
>> of any use at all, even if just to prevent the user from wasting
>> time or energy.
>
> Do you mean that the PgUp case is better because it prevents the
> user from endlessly looping doing PgUp without noticing that he's at
> the beginning of the buffer (which is also displayed in the mode
> line, at least on the default line-number-mode configuration) and
> that nothing is moving?

Page-Up is _not_ being executed.  Emacs tells the user why it can't do
his demand.  But overwrite-mode _is_ toggled, and the toggling _will_
show an effect when the buffer gets changed to read-write, or when
inhibit-read-only gets temporarily enabled, or when you do C-x C-w to
a different file or a number of other things.  Emacs _executes_ your
command, and there are a number of cases where executing it will make
a difference.  And even if it didn't: I don't want Emacs to alert me
whenever it executes a command that may not make a difference.

>> I don't get it, and you are not exactly making a convincing, or
>> even any case for it.
>
> I stopped trying to convince you around the "angels on a pin's head"
> message, if not earlier. But you are unable to accept that I'm
> saying that I would find it convenient: you try to convince me that
> I wouldn't. That's ridiculous.

WHY?!?!?  WHY would it be convenient?  PLEASE, PLEASE, PLEASE, explain
in what respect it would help you at all save time, confusion or
whatever.  _Why_ can't you explain what gains you would draw from such
a message?

-- 
David Kastrup

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, David Kastrup <dak@gnu.org> wrote:

> WHY?!?!?  WHY would it be convenient?  PLEASE, PLEASE, PLEASE, explain
> in what respect it would help you at all save time, confusion or
> whatever.  _Why_ can't you explain what gains you would draw from such
> a message?

David, I explained many messages ago, and you're refusing to listen:
If I do a command, and the result of this command is irrelevant, I
consider it an error. I want a warning (and please don't explain me
again the differences between warnings and errors: I understood it
already the first time I used "warning", but I didn't have the insight
to be very precise in my use of Emacs terminology because I didn't
imagine that would turn into that kind of discussion).

You're arguing that is not irrelevant because the mode gets changed
and, in some situations, it is even useful. I don't have *any* useful
day to day activity with Emacs where switching to overwrite in a
read-only buffer is useful, so *I* want to get a message telling me
that I'm doing something superfluous. You're arguing that the PgUp
command case is different (and yes, I understand quite well how it
works, thanks), but it is *not*: PgUp could refuse to work without
alerting the user, and nothing would be different *at all*, except
that the user would take a few seconds to notice what was he doing
wrong. The message in the PgUp case is *just* *to* *say* *the* *user*
*he's* *doing* *something* *not* *useful*.

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/28/07, David Kastrup <dak@gnu.org> wrote:
>
>> WHY?!?!?  WHY would it be convenient?  PLEASE, PLEASE, PLEASE, explain
>> in what respect it would help you at all save time, confusion or
>> whatever.  _Why_ can't you explain what gains you would draw from such
>> a message?
>
> David, I explained many messages ago, and you're refusing to listen:
> If I do a command, and the result of this command is irrelevant, I
> consider it an error.

But the result of the command is _not_ irrelevant since the buffer
need not remain read-only.

Should we get an error for C-s RET as well since the cursor has not
moved?  Or whenever if we copy something into the kill ring?

"Warning: the copy into the kill ring will remain irrelevant unless
you yank it elsewhere".

> I want a warning (and please don't explain me again the differences
> between warnings and errors:

Then why do you come up with the PgUp example all the time which is an
_error_, not a warning?  It throws a signal which will abort the
current operation _unless_ there is a signal handler for it.  Even
then, the command will not complete but rather execute the signal
handler.

windows.c:5145:

      else
	{
	  if (w->vscroll != 0)
	    /* The first line was only partially visible, make it fully
	       visible. */
	    w->vscroll = 0;
	  else if (noerror)
	    return;
	  else
	    xsignal0 (Qbeginning_of_buffer);
	}

> I understood it already the first time I used "warning", but I
> didn't have the insight to be very precise in my use of Emacs
> terminology because I didn't imagine that would turn into that kind
> of discussion).

So could you come up with an example with similar behavior that gives
a _warning_, not an _error_, and which _completes_ the operation?

> You're arguing that is not irrelevant because the mode gets changed
> and, in some situations, it is even useful. I don't have *any*
> useful day to day activity with Emacs where switching to overwrite
> in a read-only buffer is useful, so *I* want to get a message
> telling me that I'm doing something superfluous.

Something _prospectively_ superfluous in _certain_ situations.  So
please, please, please, give one usage case where such a warning would
save you time, data loss, or anything else that would even offset the
inconvenience of having the *Message* buffer filling with warnings
because I fell asleep on the "Insert" key.

I don't have any situation where
(setq fdsajglghragh t)
would be useful, and I don't want a message telling me.

> You're arguing that the PgUp command case is different (and yes, I
> understand quite well how it works, thanks), but it is *not*: PgUp
> could refuse to work without alerting the user, and nothing would be
> different *at all*,

But Emacs does _not_ refuse to toggle overwrite mode.  Take a look at
the mode line: it toggles it quite fine.  No warning necessary.  It
will not accept buffer modifications in either state, yielding an
error in either state.

> except that the user would take a few seconds to notice what was he
> doing wrong. The message in the PgUp case is *just* *to* *say* *the*
> *user* *he's* *doing* *something* *not* *useful*.

Not useful _yet_.  And it does not cause the user to invest any amount
of time and work that would go to waste.

"Warning: you changed overwrite-mode, and this might mean you want to
change the buffer at some point of time.  When you will try doing
that, it will not work."

This is complete nonsense: we can give an _error_ if and when the user
changes the buffer, and we could give that warning at almost any point
of time.  "Warning: you pressed C-u.  If you now press a
self-inserting character, I still won't change the buffer."

A warning is only useful if there are _consequences_ for not heeding
the warning.  But there _aren't_ in this case.

-- 
David Kastrup

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, David Kastrup <dak@gnu.org> wrote:

> A warning is only useful if there are _consequences_ for not heeding
> the warning.  But there _aren't_ in this case.

I'm not sure what are the consequences of doing PgUp ten times in a
row, other than wasted time and finger wear.

You remind me of a boss who once tried to convince me that his way to
do mental calculations was more efficient for me, even when I tried it
and said him it was not the case.

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/28/07, David Kastrup <dak@gnu.org> wrote:
>
>> A warning is only useful if there are _consequences_ for not heeding
>> the warning.  But there _aren't_ in this case.
>
> I'm not sure what are the consequences of doing PgUp ten times in a
> row, other than wasted time and finger wear.

You still choose to ignore the difference between a warning and an
error.  PgUp throws an _error_ 'beginning-of-buffer since it can't
_complete_ the requested command.  This will beep and abort keyboard
macros.  It will cause an action you can only catch with
condition-case.  It is an _error_ for Emacs not to be able to do a
requested command.

But Emacs _can_ execute (overwrite-mode 'toggle) a billion times in a
row.

-- 
David Kastrup

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, David Kastrup <dak@gnu.org> wrote:

> You still choose to ignore the difference between a warning and an
> error.

And you insist in conflating what the error/warning distinction does
programmatically (which I'm not talking about) with the transmision of
information (irrelevant to you, not to me) to the user.

And you do so through contrived examples. I've never ever done (setq
xkkdkqqrqwefv t) by accident. Have you?

             Juanma

Re: `*' interactive spec in some text-killing functions

[Andreas Schwab]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> And you insist in conflating what the error/warning distinction does
> programmatically (which I'm not talking about) with the transmision of
> information (irrelevant to you, not to me) to the user.

The information is already there.  Look at the mode line.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, Andreas Schwab <schwab@suse.de> wrote:

> The information is already there.  Look at the mode line.

Really?

             Juanma

Re: `*' interactive spec in some text-killing functions

[Andreas Schwab]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/28/07, Andreas Schwab <schwab@suse.de> wrote:
>
>> The information is already there.  Look at the mode line.
>
> Really?

Yes.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, Andreas Schwab <schwab@suse.de> wrote:

> Yes.

Nice of you to explain it. I thought it was the same case as PgUp,
where the user does not know he's at the beginning of the buffer
because the line number is not displayed on the mode line. Now I see
the deep difference.

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/28/07, David Kastrup <dak@gnu.org> wrote:
>
>> You still choose to ignore the difference between a warning and an
>> error.
>
> And you insist in conflating what the error/warning distinction does
> programmatically (which I'm not talking about) with the transmision of
> information (irrelevant to you, not to me) to the user.
>
> And you do so through contrived examples. I've never ever done (setq
> xkkdkqqrqwefv t) by accident. Have you?

I have done a lot of setq commands with a non-existing variable name
by accident, yes.

Anyway, what does it imply to toggle overwrite-mode _by_ _accident_ in
a readonly buffer?  It is not unheard of that it is toggled
accidentally since the Insert key is easy to hit by accident.

But the _one_ case where this accident will have no unexpected
consequences at all, namely in a readonly buffer, you want a warning.

What for?  What are the ill consequences of not heeding the warning?
You can't even destroy text accidentally with the changed setting
since the buffer is readonly.

-- 
David Kastrup

Re: `*' interactive spec in some text-killing functions

[Stefan Monnier]

> If I do a command, and the result of this command is irrelevant, I
> consider it an error.

The result is not irrelevant because you may do C-x C-q afterwards.
But maybe a little warning reminding the user that the buffer is not yet
writable could be added.  It doesn't seem tremendously useful, tho: she'll
figure it out soon enough.


        Stefan

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If I do a command, and the result of this command is irrelevant, I
>> consider it an error.
>
> The result is not irrelevant because you may do C-x C-q afterwards.
> But maybe a little warning reminding the user that the buffer is not yet
> writable could be added.  It doesn't seem tremendously useful, tho: she'll
> figure it out soon enough.

But the result will be the same whether or not overwrite-mode is
active.  So there is no sense in connecting the warning with
overwrite-mode.  And I don't see _any_ usefulness for this warning
since we'll get an error, anyway, once the readonly buffer is tried to
be written, without affecting the buffer.  Of course, if the user has
made a definition
(defadvice beep (after wwiii) (launch-missiles))
he will be happy about any such warning before actually committing an
error.  But other than that, Emacs' reaction to writing over readonly
text is perfectly harmless, and there is no reason to _warn_ people
that an error _might_ occur given certain behavior.

We also don't warn people one screen _before_ reaching the top of the
buffer "Further pressing of PgUp might lead to an error.  Be careful
now".

-- 
David Kastrup

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The result is not irrelevant because you may do C-x C-q afterwards.

Yes, and David (before embarking on a crusade to convince me of what
do I find confusing, or why I shouldn't) already pointed out an
example of how switching to overwrite in a read-only buffer can
sometimes be useful. I don't know how common is, but it is certainly
useful.

> But maybe a little warning reminding the user that the buffer is not yet
> writable could be added.

Well, thanks! That was exactly my point: that it could warn "Buffer is
read-only".

> It doesn't seem tremendously useful, tho: she'll
> figure it out soon enough.

Agreed: it's not tremendously useful, not even very useful; just nice
to some people, newbies perhaps. That's why I've been using the PgUp
example: the warning about "Beginning of buffer" is not very useful,
but it can be helpful to a newbie that suddenly doesn't understand why
the buffer is not scrolling. David and others have reminded me a
couple times or four that the read-only status is visible on the
modeline. And it is: `--' turns into  `%%', or `-*' to `-%'. Not the
most conspicuous of clues, if you're new to Emacs, I think.

Thanks,

             Juanma

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/28/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> The result is not irrelevant because you may do C-x C-q afterwards.
>
> Yes, and David (before embarking on a crusade to convince me of what
> do I find confusing, or why I shouldn't) already pointed out an
> example of how switching to overwrite in a read-only buffer can
> sometimes be useful. I don't know how common is, but it is certainly
> useful.

I have about 20 times asked what purpose a warning should achieve when
overwrite-mode is changed in readonly buffers.  What action should it
prevent?

Why do you ignore every request to explain how the warning can be
useful, and how it would be related to toggling overwrite-mode?

>> But maybe a little warning reminding the user that the buffer is
>> not yet writable could be added.
>
> Well, thanks! That was exactly my point: that it could warn "Buffer
> is read-only".

Why warn about a read-only buffer when toggling overwrite-mode?  There
is no connection whatsoever with overwrite-mode: the same operations
will lead to errors (not catastrophes or lost work or whatever)
regardless of the setting of overwrite-mode.

>> It doesn't seem tremendously useful, tho: she'll figure it out soon
>> enough.
>
> Agreed: it's not tremendously useful, not even very useful; just
> nice to some people, newbies perhaps.

But why?  What information _relevant_ to overwrite-mode is conveyed?
What information that is not much better conveyed by an actual error
_when_ the error condition happens?

> That's why I've been using the PgUp example: the warning about
> "Beginning of buffer" is not very useful,

It is not a warning, it is an error: Emacs can't do the requested job.
A warning would be "Warning: you are close to the top of the buffer.
Pressing PgUp again would cause an error beep".  And this warning
would actually be _connected_ with scroll-down, as opposed to the
proposed write-only warning for the entirely unrelated overwrite-mode.

> but it can be helpful to a newbie that suddenly doesn't understand
> why the buffer is not scrolling.

It is an error, not a warning.  Emacs does not do the job that is
asked from it and aborts any keyboard macro.

> David and others have reminded me a couple times or four that the
> read-only status is visible on the modeline.

I have never ever reminded you of that a single time, nor did anybody
else as far as I can see.

> And it is: `--' turns into `%%', or `-*' to `-%'. Not the most
> conspicuous of clues, if you're new to Emacs, I think.

I think Andreas was talking about the "Ovwrt" tag in the modeline
rather.

I don't think that the "Buffer is readonly: #<buffer myreadonlyfile>"
message is unconspicous, and it will be there with a beep in case you
do something which actually is _relevant_.

-- 
David Kastrup

Re: `*' interactive spec in some text-killing functions

[Vinicius Jose Latorre]

Juanma Barranquero wrote:
> On 6/28/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> The result is not irrelevant because you may do C-x C-q afterwards.
>
> Yes, and David (before embarking on a crusade to convince me of what
> do I find confusing, or why I shouldn't) already pointed out an
> example of how switching to overwrite in a read-only buffer can
> sometimes be useful. I don't know how common is, but it is certainly
> useful.
>
>> But maybe a little warning reminding the user that the buffer is not yet
>> writable could be added.
>
> Well, thanks! That was exactly my point: that it could warn "Buffer is
> read-only".
>
>> It doesn't seem tremendously useful, tho: she'll
>> figure it out soon enough.
>
> Agreed: it's not tremendously useful, not even very useful; just nice
> to some people, newbies perhaps. That's why I've been using the PgUp
> example: the warning about "Beginning of buffer" is not very useful,
> but it can be helpful to a newbie that suddenly doesn't understand why
> the buffer is not scrolling. David and others have reminded me a
> couple times or four that the read-only status is visible on the
> modeline. And it is: `--' turns into  `%%', or `-*' to `-%'. Not the
> most conspicuous of clues, if you're new to Emacs, I think.

And if the background color of "Ovwrt" in the modeline is changed to 
another color (for example, red as in custom-invalid face)?

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

Vinicius Jose Latorre <viniciusjl@ig.com.br> writes:

> And if the background color of "Ovwrt" in the modeline is changed to
> another color (for example, red as in custom-invalid face)?

What has Ovwrt to do with it?  If at all, we can _flash_ the readonly
mark in the mode line red for a few seconds _when_ somebody tries
changing a readonly buffer: _that_ is the mode/mark/button that is
relevant for the error, and clicking _there_ can change the readonly
state.

But Ovwrt has _nothing_ to do with this at all.  Whether or not it is
active does not change one iota about what keys lead to errors and
what keys don't.

If you turn it red in readonly buffers, it will be nothing but a red
herring.  It is completely unrelated to any prospective error/problem.

-- 
David Kastrup

Re: `*' interactive spec in some text-killing functions

[Luc Teirlinck]

   But maybe a little warning reminding the user that the buffer is not yet
   writable could be added.

Please do not.  Warnings can be distracting and one should not
multiply warnings without _real_ reason, such as danger of loosing a
lot of work.  What next?  Adding a warning when the user hits M-q in
an empty buffer, C-a at the beginning of a line, C-e at the end of
line and countless other stuff like that?  Any of these would actually
make _more_ sense, since these commands are _really_ useless.  (But
please do not add warnings in these cases either.)

Why does Juanma not just defadvice overwrite mode in his .emacs (if he
has not already done this) after which we could stop this thread.

Sincerely,

Luc.

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> Why does Juanma not just defadvice overwrite mode in his .emacs (if he
> has not already done this) after which we could stop this thread.

Luc, I said that I would do *exactly that* in the FIFTH message in the
thread: "But this is not really important, I was just curious. For my
own use it *is* an error to set overwrite-mode in a read-only buffer,
so I'll defadvice around the issue."

http://article.gmane.org/gmane.emacs.devel/73925

The rest is David (with a little help from Andreas) failing to
convince me that I cannot possibly be confused when I do type <insert>
in a read-only buffer (and, as a corollary, that no one could possibly
be, or that if we are, that's illogical because No Harm Is Done).

This discussion ceased to be about technical matters very soon, and
turned into psychology of perception. Alas, I refuse to be told by
others how I do perceive my environment :)

             Juanma

Re: `*' interactive spec in some text-killing functions

[Mathias Dahl]

> This discussion ceased to be about technical matters very soon...

But it was amusing, a bit like a ping pong match... :)

FWIW, I think you are both right; toggling overwrite mode in an
read-only buffer is probably, in most cases, not something you meant
to do, so it might be useful to hint this to the user in an
educational sense. However, it makes no harm whatsoever, it is mostly
just meaningless operation, and you have to weigh the harm of this
meaninglessness against the possible inflation in echo area messages.

A defadvice, like you suggested yourself, seems to be the win-win
solution here. You are happy, David is happy and this means we all are
happy :)

Good night!

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Mathias Dahl" <mathias.dahl@gmail.com> writes:

>> This discussion ceased to be about technical matters very soon...
>
> But it was amusing, a bit like a ping pong match... :)

I don't see that I succeeded soliciting the ping, though not for lack
of trying.

> A defadvice, like you suggested yourself, seems to be the win-win
> solution here. You are happy, David is happy and this means we all
> are happy :)

If I understood Juanma correctly (actually, rather unlikely), he had a
particular application where toggling overwrite-mode in read-only
buffers was causing him problems.

I have no clue what problems, and I have been completely unable to
coerce him into producing any argument that would make me get his
point.  While he accuses me that I wanted to convince him of being
mistaken or whatever, in fact I was rather begging to be convinced, to
no avail.  I have seen _nothing_ from him that I would have considered
a plausible basis for his wish.  Plausible in that it would explain to
me why _he_ considers his proposal a good idea, never mind whether _I_
would come to different conclusions from the same basis.

But I completely fail to see what could make him (never mind myself)
consider his proposal a worthwhile idea.  It's not just that I have a
different opinion: I don't _understand_ his position at all.  It is
completely void of any purpose I can discern.  I am just _baffled_.

Whatever.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/29/07, David Kastrup <dak@gnu.org> wrote:

> If I understood Juanma correctly

No.

> he had a
> particular application where toggling overwrite-mode in read-only
> buffers was causing him problems.

No.

> I have no clue what problems, and I have been completely unable to
> coerce him into producing any argument that would make me get his
> point.

No.

> While he accuses me that I wanted to convince him of being
> mistaken or whatever

No. Of not accepting that what causes me confusion can not be asserted by you.

> Plausible in that it would explain to
> me why _he_ considers his proposal a good idea

Proposal?

> But I completely fail to see what could make him (never mind myself)
> consider his proposal a worthwhile idea.

Proposal?

> It's not just that I have a
> different opinion: I don't _understand_ his position at all.

Yes.

> It is
> completely void of any purpose I can discern.

Yes.

> I am just _baffled_.

Yes.

> Whatever.

Agreed.

             Juanma

Re: `*' interactive spec in some text-killing functions

[Robert J. Chassell]

   But maybe a little warning reminding the user that the buffer is
   not yet writable could be added.

We already have a warning.  I think it is major and fine.  Please do
not do more; not only is it not needed, unfortunate experience tells
us that in computers, cars, and airplanes (as well as in other places)
too many warnings become notices that are ignored.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: `*' interactive spec in some text-killing functions

[Davis Herring]

>> WHY?!?!?  WHY would it be convenient?  PLEASE, PLEASE, PLEASE, explain
>> in what respect it would help you at all save time, confusion or
>> whatever.  _Why_ can't you explain what gains you would draw from such
>> a message?
>
> David, I explained many messages ago, and you're refusing to listen:
> If I do a command, and the result of this command is irrelevant, I
> consider it an error. I want a warning (and please don't explain me
> again the differences between warnings and errors: I understood it
> already the first time I used "warning", but I didn't have the insight
> to be very precise in my use of Emacs terminology because I didn't
> imagine that would turn into that kind of discussion).

A command failing to accomplish anything useful is not an error; a command
being impossible to execute is.  (I'm not harping on error/warning here,
just error/no-error.)  That's why `save-buffer' prints a message and
doesn't signal an error when the buffer is unmodified; saving is
_possible_ and _valid_, but useless (and so optimized out).  Similarly C-a
C-a does not even print a message the second time, though surely a user is
confused if they type that.  But since exactly what the user asked for has
happened, they aren't listening for a hard disk click or so, and no damage
has occurred or become likely, it's not even considered worthwhile to
print something.

The same sort of judgment call is needed for `overwrite-mode': however,
since it did do precisely what was asked, did have an effect, and still
poses no threat, it might actually be confusing to have it jabber about
its feelings of inadequacy.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: `*' interactive spec in some text-killing functions

[Juanma Barranquero]

On 6/28/07, Davis Herring <herring@lanl.gov> wrote:

> A command failing to accomplish anything useful is not an error; a command
> being impossible to execute is.  (I'm not harping on error/warning here,
> just error/no-error.)

I'm not talking about errors. In the hierarchy of warnings, I'm
talking more of an `info', or `notice' ( i.e., "there's something that
you should perhaps notice").

             Juanma

Re: `*' interactive spec in some text-killing functions

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 6/28/07, David Kastrup <dak@gnu.org> wrote:
> 
>> But _why_ wouldn't it be "smart"?  The command _is_ executed, it has
>> the normal effect (which may become relevant if the buffer-read-only
>> state changes), and it does _absolutely_ no harm to the buffer
>> contents or anything else.
> 
> Neither does any harm to PgUp at the beginning of a buffer. What is
> the message for? To alert me that I cannot go up? Well, my overwrite
> message is to alert me that I cannot overwrite even if I just changed
> to overwrite, and that I shouldn't expect most normal keys to act
> differently just because I changed to overwrite.


I have often wanted colored messages for different levels of seriousity. 
I think that might make it easier to decide in some situations like this.

Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Juanma Barranquero wrote:
>> On 6/28/07, David Kastrup <dak@gnu.org> wrote:
>>
>>> But _why_ wouldn't it be "smart"?  The command _is_ executed, it has
>>> the normal effect (which may become relevant if the buffer-read-only
>>> state changes), and it does _absolutely_ no harm to the buffer
>>> contents or anything else.
>>
>> Neither does any harm to PgUp at the beginning of a buffer. What is
>> the message for? To alert me that I cannot go up? Well, my overwrite
>> message is to alert me that I cannot overwrite even if I just changed
>> to overwrite, and that I shouldn't expect most normal keys to act
>> differently just because I changed to overwrite.
>
>
> I have often wanted colored messages for different levels of
> seriousity. I think that might make it easier to decide in some
> situations like this.

I don't see that we have a situation.  We have a command that is
trivially executed without taking time or effort and has _no_ ill
consequences at all.  Toggling overwrite-mode is completely orthogonal
to the buffer being read-only, and it is displayed in the mode line
what effects it had.

There is nothing, absolutely nothing to warn about here.

"Warning: command completed successfully, but you would need to do
other things before you would notice its effect." is just nonsense.
You could show such a "warning" for millions of cases.

-- 
David Kastrup