Undesired interactive call of major mode command

Undesired interactive call of major mode command

[Stephen Berman]

Bug#19112 reports an error resulting from typing `M-x todo-mode RET'.
The real issue (at least for me, as the maintainer of Todo mode) is not
the error but that todo-mode, although it is the "major mode command",
is not intended to be invoked interactively.  I'm not sure how best to
deal with this.  Three alternatives have occurred to me.  (i) Tell
users: "Don't do that."  (ii) Add to todo-mode the condition
(called-interactively-p 'any) and if it returns t either show a message
saying how to enter todo mode or simply call the intended (and
documented) Todo mode entry command (todo-show).  But this has the
problem that, as soon as todo-mode is invoked, the current buffer
changes to Todo mode; this is because todo-mode is defined with
define-derived-mode.  (iii) The only way I can see to avoid this is not
to use define-derived-mode.  Then I could also make todo-mode
noninteractive.  Of course, this goes against the convention that major
modes have a major mode command.  But there are precedents,
e.g. dired-mode.

Is there a best-practice recommendation for this situation, or is there
another alternative I've overlooked?  I'd be grateful for any advice.

Steve Berman

Re: Undesired interactive call of major mode command

[Stefan Monnier]

> Bug#19112 reports an error resulting from typing `M-x todo-mode RET'.
> The real issue (at least for me, as the maintainer of Todo mode) is not
> the error but that todo-mode, although it is the "major mode command",
> is not intended to be invoked interactively.

There are several such major-modes.  It's OK if doing M-x foo-mode RET
doesn't really "do the right thing" in that case, as long as it doesn't
burp loudly.

> deal with this.  Three alternatives have occurred to me.
> (i) Tell users: "Don't do that."

That's a good first step.

> (ii) Add to todo-mode the condition
> (called-interactively-p 'any) and if it returns t either show a message
> saying how to enter todo mode or simply call the intended (and
> documented) Todo mode entry command (todo-show).

Better just emit a message.

> But this has the problem that, as soon as todo-mode is invoked, the
> current buffer changes to Todo mode;

Why is it a problem that the current buffer changed to todo-mode?


        Stefan

Re: Undesired interactive call of major mode command

[Stephen Berman]

On Sat, 22 Nov 2014 11:15:15 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

>> Bug#19112 reports an error resulting from typing `M-x todo-mode RET'.
>> The real issue (at least for me, as the maintainer of Todo mode) is not
>> the error but that todo-mode, although it is the "major mode command",
>> is not intended to be invoked interactively.
>
> There are several such major-modes.  It's OK if doing M-x foo-mode RET
> doesn't really "do the right thing" in that case, as long as it doesn't
> burp loudly.

The current burps are presumably too loud:
- If you call todo-mode in an empty non-file buffer, you get the error
  (wrong-type-argument arrayp nil) because todo-mode calls
  (file-truename (buffer-file-name)) (this was the error of bug#19112).
- If you call todo-mode in a non-empty buffer (whether or not it is
  visiting a file (except a Todo mode file, of course), you get the
  Todo mode error "Invalid or missing todo-categories sexp", because the
  buffer text does not conform to the Todo mode file format.
- If you call todo-mode in a buffer visiting an empty file, you get no
  error, but since the buffer is then in Todo mode, if you invoke any
  Todo mode command you'll get an error, again because of the invalid
  file format for Todo mode.

>> deal with this.  Three alternatives have occurred to me.
>> (i) Tell users: "Don't do that."
>
> That's a good first step.
>
>> (ii) Add to todo-mode the condition
>> (called-interactively-p 'any) and if it returns t either show a message
>> saying how to enter todo mode or simply call the intended (and
>> documented) Todo mode entry command (todo-show).
>
> Better just emit a message.
>
>> But this has the problem that, as soon as todo-mode is invoked, the
>> current buffer changes to Todo mode;
>
> Why is it a problem that the current buffer changed to todo-mode?

Well, it's not a problem in the sense of data loss or unrecoverable file
corruption, but if the user expected the buffer to be a usable Todo mode
buffer, he'll be disappointed.  On the other hand, I guess it's
reasonable to consider calling todo-mode in any buffer simply
user-error, like calling rmail-mode or an arbitrary programming mode.

So is it sufficient to fix the code to prevent the above errors and
display the message "Type M-x todo-show to enter Todo mode", and not
worry about the buffer changing to todo-mode?

Steve Berman

Re: Undesired interactive call of major mode command

[Stefan Monnier]

> - If you call todo-mode in an empty non-file buffer, you get the error
>   (wrong-type-argument arrayp nil) because todo-mode calls
>   (file-truename (buffer-file-name)) (this was the error of bug#19112).

Signaling such an error is indeed a bug here.  Better emit a message.

> - If you call todo-mode in a non-empty buffer (whether or not it is
>   visiting a file (except a Todo mode file, of course), you get the
>   Todo mode error "Invalid or missing todo-categories sexp", because the
>   buffer text does not conform to the Todo mode file format.

That's probably OK.

> - If you call todo-mode in a buffer visiting an empty file, you get no
>   error, but since the buffer is then in Todo mode, if you invoke any
>   Todo mode command you'll get an error, again because of the invalid
>   file format for Todo mode.

Of course, an alternative might be to move some of the code outside of
todo-mode to some other function.


        Stefan

Re: Undesired interactive call of major mode command

[Stephen Berman]

On Sun, 23 Nov 2014 22:56:16 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

>> - If you call todo-mode in an empty non-file buffer, you get the error
>>   (wrong-type-argument arrayp nil) because todo-mode calls
>>   (file-truename (buffer-file-name)) (this was the error of bug#19112).
>
> Signaling such an error is indeed a bug here.  Better emit a message.

Ok.

>> - If you call todo-mode in a non-empty buffer (whether or not it is
>>   visiting a file (except a Todo mode file, of course), you get the
>>   Todo mode error "Invalid or missing todo-categories sexp", because the
>>   buffer text does not conform to the Todo mode file format.
>
> That's probably OK.
>
>> - If you call todo-mode in a buffer visiting an empty file, you get no
>>   error, but since the buffer is then in Todo mode, if you invoke any
>>   Todo mode command you'll get an error, again because of the invalid
>>   file format for Todo mode.
>
> Of course, an alternative might be to move some of the code outside of
> todo-mode to some other function.

Sorry, I don't follow you; what code?

Steve Berman

Re: Undesired interactive call of major mode command

[Stefan Monnier]

>> Of course, an alternative might be to move some of the code outside of
>> todo-mode to some other function.
> Sorry, I don't follow you; what code?

Sorry, I don't follow myself either.  I think I was talking about the
previous problem (the "Invalid or missing todo-categories sexp"), and
mistakenly placed it after this text.

Regarding the problem of running todo-mode commands in an empty buffer,
I think that signaling a clean error when running a command in
a wrongly-formatted buffer is OK.

        Stefan

Re: Undesired interactive call of major mode command

[Stephen Berman]

On Tue, 25 Nov 2014 21:16:04 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

>>> Of course, an alternative might be to move some of the code outside of
>>> todo-mode to some other function.
>> Sorry, I don't follow you; what code?
>
> Sorry, I don't follow myself either.  I think I was talking about the
> previous problem (the "Invalid or missing todo-categories sexp"), and
> mistakenly placed it after this text.
>
> Regarding the problem of running todo-mode commands in an empty buffer,
> I think that signaling a clean error when running a command in
> a wrongly-formatted buffer is OK.

Ok, then I'll just go with the minimal fix of displaying an informative
message on interactively calling todo-mode.  Thanks for the feedback.

Steve Berman