GNU bug report logs - #19812
24.4; suggest `shell-mode' not interactive

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19812 in the body.
You can then email your comments to 19812 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kevin Ryde <user42_kevin <at> yahoo.com.au>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4; suggest `shell-mode' not interactive
Date: Sun, 08 Feb 2015 15:07:39 +1100

Severity: wishlist

The `shell-mode' function is interactive, but I think perhaps it should
not be since it is not designed for use as M-x shell-mode in an
arbitrary buffer, but only after the `shell' function makes various
setups.

I struck this when a brain fade confused me between shell-command,
shell-mode and shell and I did M-x shell-mode in a file buffer and
nearly made a big mess.  The problem is only seen when shell.el has been
loaded (for any reason) since shell-mode is not autoloaded.

Similar could apply to other special modes, maybe even to most modes
derived from `special-mode'.


In GNU Emacs 24.4.1 (i586-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2014-12-20 on brahms, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11602901
Configured using:
 `configure --build i586-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --build i586-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=lucid --with-toolkit-scroll-bars
 --without-gconf --without-gsettings 'CFLAGS=-g -O2
 -fstack-protector-strong -Wformat -Werror=format-security -Wall'
 CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-z,relro'

Message #8 received at 19812 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Ryde <user42_kevin <at> yahoo.com.au>
Cc: 19812 <at> debbugs.gnu.org
Subject: Re: bug#19812: 24.4; suggest `shell-mode' not interactive
Date: Fri, 02 Aug 2019 21:52:17 +0200

Kevin Ryde <user42_kevin <at> yahoo.com.au> writes:

> The `shell-mode' function is interactive, but I think perhaps it should
> not be since it is not designed for use as M-x shell-mode in an
> arbitrary buffer, but only after the `shell' function makes various
> setups.
>
> I struck this when a brain fade confused me between shell-command,
> shell-mode and shell and I did M-x shell-mode in a file buffer and
> nearly made a big mess.  The problem is only seen when shell.el has been
> loaded (for any reason) since shell-mode is not autoloaded.
>
> Similar could apply to other special modes, maybe even to most modes
> derived from `special-mode'.

As you point out, there's a lot of modes that only make sense in certain
limited contexts, and having them be interactive isn't very helpful.
I'm not sure it's that much of a problem in general, but it is a
particular an issue with `shell-mode', since I'd guess that a lot of
people type that instead of `M-x shell-script-mode' when starting to
write new shell scripts.

The following fixes this particular issue.  Would something like this be
welcome?

A different fix would be to extend defined-derived-mode to take a
:noninteractive flag to just not include the `(interactive)' in the
defun.  It looks fairly straightforward to implement -- is that a better
idea, perhaps?

(That is, if we want to fix this at all.)

diff --git a/lisp/shell.el b/lisp/shell.el
index 2914d1d2c8..ba7515e7ba 100644
--- a/lisp/shell.el
+++ b/lisp/shell.el
@@ -553,6 +553,8 @@ shell-mode
 `comint-scroll-to-bottom-on-input' and `comint-scroll-to-bottom-on-output'
 control whether input and output cause the window to scroll to the end of the
 buffer."
+  (when (called-interactively-p 'any)
+    (error "Can't be called interactively; did you mean `shell-script-mode' instead?"))
   (setq comint-prompt-regexp shell-prompt-pattern)
   (shell-completion-vars)
   (setq-local paragraph-separate "\\'")


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #13 received at 19812 <at> debbugs.gnu.org (full text, mbox):

From: Kevin Ryde <user42_kevin <at> yahoo.com.au>
To: 19812 <at> debbugs.gnu.org
Subject: Re: bug#19812: 24.4; suggest `shell-mode' not interactive
Date: Sat, 03 Aug 2019 09:54:51 +1000

Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> A different fix would be to extend defined-derived-mode to take a
> :noninteractive flag to just not include the `(interactive)' in the
> defun.  It looks fairly straightforward to implement -- is that a better
> idea, perhaps?

Maybe :interactive, just to write it in the positive sense.  The default
must be t for compatibility.  A couple of words in the docs could note
that special modes usually should be nil.

Perhaps special-mode itself would be the second customer for this.
I presume special-mode is not intended for interactive use, and it
doesn't do much helpful (set buffer-read-only).

Message #16 received at 19812 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: user42_kevin <at> yahoo.com.au, 19812 <at> debbugs.gnu.org
Subject: Re: bug#19812: 24.4; suggest `shell-mode' not interactive
Date: Sat, 03 Aug 2019 10:22:44 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 02 Aug 2019 21:52:17 +0200
> Cc: 19812 <at> debbugs.gnu.org
> 
> As you point out, there's a lot of modes that only make sense in certain
> limited contexts, and having them be interactive isn't very helpful.
> I'm not sure it's that much of a problem in general, but it is a
> particular an issue with `shell-mode', since I'd guess that a lot of
> people type that instead of `M-x shell-script-mode' when starting to
> write new shell scripts.
> 
> The following fixes this particular issue.  Would something like this be
> welcome?

Are there no valid use cases where invoking shell-mode interactively
makes sense?  If there are such use cases, we cannot disallow them
now.

Message #19 received at 19812 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: user42_kevin <at> yahoo.com.au, 19812 <at> debbugs.gnu.org
Subject: Re: bug#19812: 24.4; suggest `shell-mode' not interactive
Date: Sat, 03 Aug 2019 13:08:27 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Are there no valid use cases where invoking shell-mode interactively
> makes sense?  If there are such use cases, we cannot disallow them
> now.

I can't think of any cases where you'd call `shell-mode'
interactively.

Hm.  Perhaps if you've started a comint buffer using another mode and
then wants to switch to `shell-mode'?  But I doubt that that's a thing.

Perhaps somebody else will chime in to say whether they've ever said
`M-x shell-mode' and it wasn't a mistake.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #22 received at 19812 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Ryde <user42_kevin <at> yahoo.com.au>
Cc: 19812 <at> debbugs.gnu.org
Subject: Re: bug#19812: 24.4; suggest `shell-mode' not interactive
Date: Sat, 03 Aug 2019 13:11:40 +0200

Kevin Ryde <user42_kevin <at> yahoo.com.au> writes:

> Maybe :interactive, just to write it in the positive sense.  The default
> must be t for compatibility.

That makes sense, and is easy to implement in this case.  We usually
treat the absence of a parameter the same as nil (since Emacs Lisp isn't
Common Lisp), but we don't have to do that here.

> A couple of words in the docs could note that special modes usually
> should be nil.

True, but I don't think we need to limit the interactivity here, though.
When there's little chance of confusion, having the mode be interactive
isn't that big a deal (and might be useful for somebody, sometime).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #25 received at 19812 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: user42_kevin <at> yahoo.com.au, Eli Zaretskii <eliz <at> gnu.org>,
 19812 <at> debbugs.gnu.org
Subject: Re: bug#19812: 24.4; suggest `shell-mode' not interactive
Date: Sun, 04 Aug 2019 22:11:31 +0300

> Perhaps somebody else will chime in to say whether they've ever said
> `M-x shell-mode' and it wasn't a mistake.  :-)

It might be useful to visit log files previously saved from shell buffers,
like compilation-mode adds such local-variable prop-line:

  -*- mode: compilation -*-

so compilation log saved to files could be visited later.

But one problem with using

  -*- mode: shell -*-

in files saved from previous shells is that it doesn't highlight prompts -
thus it lacks a very important feature of shell-mode.

Message #28 received at 19812 <at> debbugs.gnu.org (full text, mbox):

From: Kevin Ryde <user42_kevin <at> yahoo.com.au>
To: 19812 <at> debbugs.gnu.org
Subject: Re: bug#19812: 24.4; suggest `shell-mode' not interactive
Date: Mon, 05 Aug 2019 18:54:47 +1000

Juri Linkov <juri <at> linkov.net> writes:
>
> It might be useful to visit log files previously saved from shell buffers,
> like compilation-mode adds such local-variable prop-line:
>
>   -*- mode: compilation -*-

I suppose the difference is compilation-mode does useful things when a
compilation has finished, whereas shell-mode and similar would be more
or less entirely for interaction.

I've had file buffers in compilation-mode for stepping error lines in
the way you say.  The only thing I've been tricked by is accidentally
"g" recompile which replaces the file text -- in a sensible way, but for
me usually not what I meant to do :-).



-- 
Monotremes oviparous, ovum meroblastic.  -- Caldwell

Message #31 received at 19812 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Kevin Ryde <user42_kevin <at> yahoo.com.au>
Cc: 19812 <at> debbugs.gnu.org
Subject: Re: bug#19812: 24.4; suggest `shell-mode' not interactive
Date: Tue, 06 Aug 2019 00:59:45 +0300

>> It might be useful to visit log files previously saved from shell buffers,
>> like compilation-mode adds such local-variable prop-line:
>>
>>   -*- mode: compilation -*-
>
> I suppose the difference is compilation-mode does useful things when a
> compilation has finished, whereas shell-mode and similar would be more
> or less entirely for interaction.

It makes sense to visit a previously saved shell buffer only to
see highlighted prompts and command lines (that shell-mode
currently is unable to do).

> I've had file buffers in compilation-mode for stepping error lines in
> the way you say.  The only thing I've been tricked by is accidentally
> "g" recompile which replaces the file text -- in a sensible way, but for
> me usually not what I meant to do :-).

Maybe "g" should check if the compilation buffer is visiting a file,
and not to recompile in this case.

Message #34 received at 19812 <at> debbugs.gnu.org (full text, mbox):

From: Kevin Ryde <user42_kevin <at> yahoo.com.au>
To: 19812 <at> debbugs.gnu.org
Subject: Re: bug#19812: 24.4; suggest `shell-mode' not interactive
Date: Wed, 07 Aug 2019 16:46:13 +1000

Juri Linkov <juri <at> linkov.net> writes:
>
> Maybe "g" should check if the compilation buffer is visiting a file,
> and not to recompile in this case.

I don't know if that'd be too strict, and yet some query-the-user could
be annoying when you know what you're doing - such as having only just
this moment saved a compile buffer to a file.

The scariest bit for me was undo is disabled, so you can't go back when
you realize your mistake.  I suspect making undo the right thing would
be hard, but in a file buffer that's what you reach for first on strange
changes, so it's a bit off-putting.

Message #37 received at 19812 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> mouse.gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: user42_kevin <at> yahoo.com.au, 19812 <at> debbugs.gnu.org
Subject: Re: bug#19812: 24.4; suggest `shell-mode' not interactive
Date: Thu, 22 Aug 2019 17:59:05 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> As you point out, there's a lot of modes that only make sense in certain
>> limited contexts, and having them be interactive isn't very helpful.
>> I'm not sure it's that much of a problem in general, but it is a
>> particular an issue with `shell-mode', since I'd guess that a lot of
>> people type that instead of `M-x shell-script-mode' when starting to
>> write new shell scripts.
>> 
>> The following fixes this particular issue.  Would something like this be
>> welcome?
>
> Are there no valid use cases where invoking shell-mode interactively
> makes sense?  If there are such use cases, we cannot disallow them
> now.

If I read the comments correctly, nobody had a use case for using `M-x
shell-mode'.  It was proposed that it could possibly be useful for
working in log files and the like, but that shell-mode doesn't currently
actually support that, so I went ahead and applied the patch to disable
the interactive use of the mode.

If this leads to problems for anybody, feel free to revert the commit.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #44 received at 19812 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> mouse.gnus.org>
Cc: user42_kevin <at> yahoo.com.au, Eli Zaretskii <eliz <at> gnu.org>,
 19812 <at> debbugs.gnu.org
Subject: Re: bug#19812: 24.4; suggest `shell-mode' not interactive
Date: Wed, 28 Aug 2019 01:13:25 +0300

> If I read the comments correctly, nobody had a use case for using `M-x
> shell-mode'.  It was proposed that it could possibly be useful for
> working in log files and the like, but that shell-mode doesn't currently
> actually support that, so I went ahead and applied the patch to disable
> the interactive use of the mode.

I confirm that `M-x shell-mode' can't be used in saved log files.  I tried:

  (defvar shell-log-font-lock-keywords
    ;; `shell-prompt-pattern' can't be used: it finds too many false matches
    '(("^\\([^#$%>\12]*@[^#$%>\12]*:[^#$%>\12]*[#$%>] *\\)\\(.*\\)$"
       (1 'comint-highlight-prompt)
       (2 'comint-highlight-input)))
    "Shell prompts to highlight in Shell Log mode.")

  (define-derived-mode shell-log-mode shell-mode "Shell-Log"
    "Font-lock for shell logs."
    (put 'shell-log-mode 'mode-class nil)
    (setq-local font-lock-defaults '(shell-log-font-lock-keywords t)))

  (add-to-list 'auto-mode-alist '("\\.log\\'" . shell-log-mode))

but `shell-prompt-pattern' matches too many false positives, and
replacing it with a customized regexp is too ad-hoc and unreliable.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.