From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joe Corneli Newsgroups: gmane.emacs.help Subject: Re: Is Emacs becoming Word? Date: Sun, 27 Mar 2005 18:54:12 -0600 Message-ID: References: <20050328001728.GA29944@dionysus.ucolick.org> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1111971596 17861 80.91.229.2 (28 Mar 2005 00:59:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 28 Mar 2005 00:59:56 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Mar 28 02:59:54 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DFibW-0001LV-C2 for geh-help-gnu-emacs@m.gmane.org; Mon, 28 Mar 2005 02:59:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DFirV-0008Ci-UP for geh-help-gnu-emacs@m.gmane.org; Sun, 27 Mar 2005 20:16:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DFir3-000871-3t for help-gnu-emacs@gnu.org; Sun, 27 Mar 2005 20:15:45 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DFiqy-00084O-Sy for help-gnu-emacs@gnu.org; Sun, 27 Mar 2005 20:15:41 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DFiqy-00082L-9W for help-gnu-emacs@gnu.org; Sun, 27 Mar 2005 20:15:40 -0500 Original-Received: from [146.6.139.124] (helo=dell3.ma.utexas.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DFiWE-00057R-EH for help-gnu-emacs@gnu.org; Sun, 27 Mar 2005 19:54:14 -0500 Original-Received: from lab45.ma.utexas.edu (mail@lab45.ma.utexas.edu [128.83.133.159]) by dell3.ma.utexas.edu (8.11.0.Beta3/8.10.2) with ESMTP id j2S0sCC20471; Sun, 27 Mar 2005 18:54:12 -0600 Original-Received: from jcorneli by lab45.ma.utexas.edu with local (Exim 3.36 #1 (Debian)) id 1DFiWC-0005pz-00; Sun, 27 Mar 2005 18:54:12 -0600 Original-To: help-gnu-emacs@gnu.org In-reply-to: <20050328001728.GA29944@dionysus.ucolick.org> (message from Greg Novak on Sun, 27 Mar 2005 16:17:28 -0800) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:25223 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:25223 > But now I'm thinking that it might be even nicer to be able to get > help on the last event, or sequence of events... I was thinking along the same lines and was just about to try to throw together a proof-of-principle bit of code. When something odd happens, the user would use something like "M-x what-just-happened" and get info about what Emacs thinks its doing, how to shut it off, etc. I think it probably wouldn't be too ungodly hard to write a `what-just-happened' function (but I'm not sure). Like you pointed out, Retrofitting existing code to actually provide good context-sensitive information would seem to be a herculean task. But nevertheless, documentation of this sort _should_ exist. Unless we're told how to turn things off (for example) we'll get confused. Writing the documentation would probably be the hard part, patching it in to `what-just-happened' seems like it would be relatively easy. One thing that would be especially useful would be code that would show where exactly the variables relevant to a certain event were set. It probably isn't hard to say where a given variable is set. The difficulty is in specifying internally which variables are relevant to which events. 2) This will only help Emacs users who know that the what-just-happened command exists. That is, the situation which prompted this discussion was that Emacs was translating certain inputs into special characters and I didn't understand why. If I didn't know about the what-just-happened command, I would remain confused. I don't think this is a huge concern, because if the command existed it would be listed by C-h ? and either you'd have figured that out, or you'd have posted here and been told about the command, then used it, and probably still found it to be useful quite useful. (I.e. once you learn of the command it would reduce confusion many times, and you only have to learn it once.) Advantages of the second (verbose minibuffer messages for tentatively enabled functionality) approach include: 1) By design, the information only has to be added to new user-visible functionality. This seems much easier than trying to bring a fully general contextual help system to fruition. 2) Presumably all Emacs users read messages in the minibuffer, so the information about new user-visible changes will reach everyone as they encounter it, rather than having to go digging for it in the NEWS file, for example. One could think of this as a dynamic way of reading the NEWS file. Disadvantages include: 1) This approach cannot be described as unobtrusive. All Emacs users would see an increased number of messages in the minibuffer, at least until they decide to permanently enable the new functionality. But it could be turned off. I've only recently started digging through significant amounts of elisp code, so I defer to the judgment of others concerning the feasibility of either of these two ideas. The second one requires appears to be technically no different from `disable-command'. The first one is harder, but if you can write a `what-just-happened' prototype, certainly people can begin to do the gruntwork (german/english pun :)) to further populate its output with useful documentation.