From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joe Corneli Newsgroups: gmane.emacs.devel Subject: contextual help on new features Date: Sat, 26 Mar 2005 02:54:31 -0600 Message-ID: NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1111828622 22554 80.91.229.2 (26 Mar 2005 09:17:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 26 Mar 2005 09:17:02 +0000 (UTC) Cc: Greg Novak Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 26 10:17:02 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DF7Pa-0002NH-Qo for ged-emacs-devel@m.gmane.org; Sat, 26 Mar 2005 10:16:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DF7fE-0006Ao-T7 for ged-emacs-devel@m.gmane.org; Sat, 26 Mar 2005 04:33:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DF7XD-0005Uu-68 for emacs-devel@gnu.org; Sat, 26 Mar 2005 04:24:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DF7XA-0005UQ-FY for emacs-devel@gnu.org; Sat, 26 Mar 2005 04:24:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DF7X8-0005Mk-81 for emacs-devel@gnu.org; Sat, 26 Mar 2005 04:24:42 -0500 Original-Received: from [146.6.139.124] (helo=dell3.ma.utexas.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DF73w-0005VK-FV for emacs-devel@gnu.org; Sat, 26 Mar 2005 03:54:32 -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 j2Q8sVC15906; Sat, 26 Mar 2005 02:54:31 -0600 Original-Received: from jcorneli by lab45.ma.utexas.edu with local (Exim 3.36 #1 (Debian)) id 1DF73v-0002ek-00; Sat, 26 Mar 2005 02:54:31 -0600 Original-To: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: news.gmane.org gmane.emacs.devel:35193 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:35193 Greg Novak recently kicked off a thread in the help.gnu.emacs forum, entitled "Is Emacs becoming Word?". What he appears to have meant by this question is Emacs is becoming increasingly WYSIWYG (by default), and I find that annoying. The replies he received were mixed. Some people liked the new WYSIWYG features. Some people hated them. Some people liked the fact that they exist, but don't use them personally. Etc. We see discussions of this nature in help.gnu.emacs fairly frequently. The real point of the thread was - how easy is it to turn off new features that you don't like (again, a frequent topic of discussion). But also, more generally, how easy is it to make the most of new features - to learn how to use them well (even if that means, for you, turning them off). I mentioned that it would be nice to have contextual help, of some sort, on new features. For example, the the first time "\pi" automatically turns into a greek symbol in the current buffer, you might see a message telling you what's just happened. In addition to being informative, this message should have an "actionable" aspect to it -- specifically, the user could be given the choice to either "accept" the new feature, or "reject" it. Upon accepting the feature, this particual message would go away. Upon rejecting the feature, not only would the messages go away, but your .emacs would get set up with a configuration item that stops the feature from activating in the future. The actual definitions of "accept" and "reject" are somewhat context-dependent. For example, the first time you get a prompt about discarding undo data, "reject" should mean "don't prompt me again, just do it next time!", *not* "don't discard undo data." In some cases, more than one option might be offered. (Perhaps features could be accepted on a trial basis, as in "Ask me again next week, I'm not sure whether I like this yet or not.") This does not seem so different from two things that we are used to in emacs - `customize' and `disable-command'. In effect, the suggestion is "why not make new features 'tentatively-enabled', so that they run, but also automatically display information about themselves, and furthermore come packaged with the relevant customization apparatus?" If implemented, I think that this suggestion would help support good coding style. New features would be sure to come packaged with useful documentation and also with easy access to the code users need to use them effectively. Accepting a new feature would be no more or less pain-less/-ful than rejecting the feature, which would give users a sense of balance that I think they many currently find lacking. This idea could grow into a somewhat enriched help subsystem, eg. "`rich-help-last-command'" might not only bring up a buffer describing the last command, but also provide relevant customization items. I'm reminded a little bit of Word's annoying talking paperclip. (Which no one seems to be able to figure out how to turn off.) Of course, the first feature that one should be able to turn off using the new feature I'm describing here would be that very feature. On the one hand, I might expect to get flamed now for promoting an idea that already is already implemented, or otherwise inessential/non-useful. Well, I acknowledge that the basic components of a system like this seem to exist, and its usefulness is a matter of opinion. On the other hand, I might also expect to get flamed for promoting an idea that is too different from what emacs users are used to, or too far off course from what the emacs project is aiming for right now. I can't really argue one way or another about that. I will leave it to persons more experienced than me to think these matters over.