From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Greg Novak Newsgroups: gmane.emacs.help Subject: Re: Is Emacs becoming Word? Date: Sun, 27 Mar 2005 16:17:28 -0800 Message-ID: <20050328001728.GA29944@dionysus.ucolick.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1111970327 15467 80.91.229.2 (28 Mar 2005 00:38:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 28 Mar 2005 00:38:47 +0000 (UTC) Cc: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Mar 28 02:38:45 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DFiGc-0008M6-7b for geh-help-gnu-emacs@m.gmane.org; Mon, 28 Mar 2005 02:38:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DFiWb-0008Lp-Hl for geh-help-gnu-emacs@m.gmane.org; Sun, 27 Mar 2005 19:54:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DFiW2-0008EQ-C7 for help-gnu-emacs@gnu.org; Sun, 27 Mar 2005 19:54:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DFiVw-0008B1-PQ for help-gnu-emacs@gnu.org; Sun, 27 Mar 2005 19:53:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DFiVr-00085b-Bg for help-gnu-emacs@gnu.org; Sun, 27 Mar 2005 19:53:51 -0500 Original-Received: from [128.114.22.17] (helo=dionysus.ucolick.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1DFhwg-0002d4-2M for help-gnu-emacs@gnu.org; Sun, 27 Mar 2005 19:17:30 -0500 Original-Received: from dionysus.ucolick.org (localhost.localdomain [127.0.0.1]) by dionysus.ucolick.org (8.13.1/8.13.1) with ESMTP id j2S0HSZX029966; Sun, 27 Mar 2005 16:17:28 -0800 Original-Received: (from novak@localhost) by dionysus.ucolick.org (8.13.1/8.13.1/Submit) id j2S0HSJT029965; Sun, 27 Mar 2005 16:17:28 -0800 Original-To: Joe Corneli Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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:25222 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:25222 * Joe Corneli wrote: > 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. A perhaps simpler alternative would be to have new user-visible functionality come enabled by default, but with verbose mini-buffer entries, like "Type 'M-x describe-extended-character-sets' for more information." Fully enabling the new functionality would make the mini-buffer entries go away. As I see it, the advantages of the first approach ("M-x what-just-happened") are: 1) As already pointed out, it's a facility for generic contextual help 2) It's unobtrusive unless the user asks for the information. Disadvantages include: 1) Retrofitting existing code to actually provide good context-sensitive information would seem to be a herculean task. 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. 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. 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. Greg