From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Re: Undesired interactive call of major mode command Date: Sat, 22 Nov 2014 23:19:44 +0100 Message-ID: <87ppceop33.fsf@rosalinde.fritz.box> References: <87lhn3gvq8.fsf@rosalinde.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416694820 13057 80.91.229.3 (22 Nov 2014 22:20:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Nov 2014 22:20:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 22 23:20:11 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XsJ2F-00072z-SH for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2014 23:20:08 +0100 Original-Received: from localhost ([::1]:46951 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsJ2F-0003JE-9n for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2014 17:20:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsJ26-0003Hs-1J for emacs-devel@gnu.org; Sat, 22 Nov 2014 17:20:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsJ20-0007ZF-3R for emacs-devel@gnu.org; Sat, 22 Nov 2014 17:19:57 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:56464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsJ1z-0007Yf-Oj for emacs-devel@gnu.org; Sat, 22 Nov 2014 17:19:52 -0500 Original-Received: from rosalinde.fritz.box ([89.245.78.19]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MBFgr-1XkMYI2wcP-00AC3A; Sat, 22 Nov 2014 23:19:47 +0100 In-Reply-To: (Stefan Monnier's message of "Sat, 22 Nov 2014 11:15:15 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-Provags-ID: V03:K0:HtJW3V6/Sn6YJHlm539RWs1HOGZknA+qJDoUIRIJP84jcikiAVU k8kuf8hON4IXuT/JUErKZ6ASz+pEVJdy2LAYPebMNe91LAhWcyrLIMY7HEb8eHXJC68+p1v fhNfC53OzReyuGD9OOhLRF5UGFxAHN7p3mYPaCRuQmrOpmvUblJBTIBw+sl8+hnQcQB+rCF vY3b2mQ58D0OFXXF1KSkA== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.15.18 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:178039 Archived-At: On Sat, 22 Nov 2014 11:15:15 -0500 Stefan Monnier 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