From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Idea for determining what users use Date: Mon, 2 Jun 2003 21:43:56 -0500 (CDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200306030243.h532hup24488@eel.dms.auburn.edu> References: NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1054608203 8681 80.91.224.249 (3 Jun 2003 02:43:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 3 Jun 2003 02:43:23 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jun 03 04:43:21 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19N1lh-0002Fq-00 for ; Tue, 03 Jun 2003 04:43:21 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19N22a-0007RC-00 for ; Tue, 03 Jun 2003 05:00:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19N1nE-0004nK-TA for emacs-devel@quimby.gnus.org; Mon, 02 Jun 2003 22:44:56 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19N1mN-0003nE-Hr for emacs-devel@gnu.org; Mon, 02 Jun 2003 22:44:03 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19N1mD-0003TC-ND for emacs-devel@gnu.org; Mon, 02 Jun 2003 22:43:54 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19N1mA-0003M4-3y; Mon, 02 Jun 2003 22:43:50 -0400 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) h532hmoc006611; Mon, 2 Jun 2003 21:43:49 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.11.6+Sun/8.11.6) id h532hup24488; Mon, 2 Jun 2003 21:43:56 -0500 (CDT) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Mon, 02 Jun 2003 07:16:09 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:14604 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14604 Richard Stallman wrote: However, we also copy the name of the feature in a file specially dedicated for that purpose, .obsolete_features_used or whatever. Users are unlikely to notice that this file exists. With that name, they won't even see it in directory listings. Unless you can design something to call their attention to it strongly, it may as well not exist. I will address the above issue below, but, first of all, is the intent to just have a head-count, nothing else, or is the intent to get feedback? The feature I propose is designed to get feedback from the user. It would not be that useful for a mere head-count. I personally believe that feedback would be a lot more useful than a mere head-count. As I mentioned before, suppose some users keep using an obsolete alternative for a much nicer new feature because there is one particular functionality the old feature has that is crucial to these particular users and that was somehow inadvertently omitted from the new feature. Should we decide to keep maintaining the old feature or should we decide to add the functionality to the new feature? It would seem that the latter makes clearly more sense, but with the head-count we would never know what was really going on. Now to the problem of making the user aware of the file. Somehow we need to inform the user about his use of obsolete features in a way that produces the least inconvenience possible. So let us compare the inconvenience caused by the proposed mailing system and that caused by the need to inform the user about the file. With the mailing system we have to decide whether we want to ask a yes-or-no-p question or pop up a buffer. Let us look at yes-or-no-p. The user is busy working. All of a sudden and not as part of a deliberately invoked command by the user, Emacs, instead of responding to the user goes: Beep! Beep! Beep! Fellow, I asked you a question and you better give me an answer right now: Yes or No? This is OK in response to a command deliberately invoked by the user or when there is some other really good reason to do this, without better alternatives. Popping up a non-selected buffer with a clickable field to mail, would in my opinion be less intrusive, because it allows the user to, say at least finish typing his current thoughts before worrying about the question. We could mess up the user's window-configuration, but maybe the function could save and offer to restore that configuration. So if we go for the mailing I clearly would prefer the latter (with saving the window configuration). That buffer would tell the user about the possibility of disabling the pop-up-buffer feature, using some variable (and offer to automatically do so), while still being kept informed about obsoleted features he is using (as well as about other obsoleted features), using the file and commands I proposed. One-time-inconvenience versus indefinite number of times, as features keep getting obsoleted over time. The Emacs manual also would have to explain some of this, so users know what to expect and why. There are various other possibilities, but this is one. Sincerely, Luc.