unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: Idea for determining what users use
Date: Mon, 2 Jun 2003 21:43:56 -0500 (CDT)	[thread overview]
Message-ID: <200306030243.h532hup24488@eel.dms.auburn.edu> (raw)
In-Reply-To: <E19MnIP-00069M-TA@fencepost.gnu.org> (message from Richard Stallman on Mon, 02 Jun 2003 07:16:09 -0400)

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.

  reply	other threads:[~2003-06-03  2:43 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-27 12:45 Idea for determining what users use Richard Stallman
2003-05-27 13:27 ` David Kastrup
2003-05-27 14:16 ` Vincent LADEUIL
2003-05-27 14:28 ` Stefan Monnier
2003-05-28  0:43   ` Kim F. Storm
2003-05-28  7:04     ` Juanma Barranquero
2003-05-28 13:54   ` Richard Stallman
2003-05-28 14:33     ` Stefan Monnier
2003-05-30  0:49       ` Richard Stallman
2003-05-27 14:39 ` Thien-Thi Nguyen
2003-05-27 15:32   ` Stephen J. Turnbull
2003-05-28 23:58   ` Richard Stallman
2003-05-29 11:35     ` Thien-Thi Nguyen
2003-05-30  0:48       ` Richard Stallman
2003-05-31 12:37         ` Thien-Thi Nguyen
2003-06-01 15:53           ` Richard Stallman
2003-06-01 20:26             ` Thien-Thi Nguyen
2003-06-03  4:06               ` Richard Stallman
     [not found] ` <m1r86ktqxx.fsf@vila.local.>
2003-05-28 13:54   ` Richard Stallman
2003-05-28 14:40     ` Vincent LADEUIL
     [not found]     ` <m1y90rp221.fsf@vila.local.>
2003-05-30  0:49       ` Richard Stallman
2003-05-30  7:28         ` Jan D.
2003-05-30 13:29           ` Stefan Monnier
2003-05-30 14:52             ` Jan D.
2003-05-30 15:40               ` Stefan Monnier
2003-05-30 16:32                 ` Alex Schroeder
2003-05-31 19:51                   ` Richard Stallman
2003-06-01  0:48                     ` Peter Lee
2003-06-01  1:24                     ` Luc Teirlinck
2003-06-01  1:59                       ` Luc Teirlinck
2003-06-02 11:16                         ` Richard Stallman
2003-06-03 22:55                           ` Kim F. Storm
2003-06-05  0:08                             ` Richard Stallman
2003-06-06  0:21                               ` Kim F. Storm
2003-06-07 10:22                                 ` Richard Stallman
2003-05-30 16:45                 ` Jan D.
2003-05-30 16:57                   ` Stefan Monnier
2003-05-31 19:51             ` Richard Stallman
2003-05-30 23:47 ` Kim F. Storm
2003-05-30 23:04   ` Miles Bader
2003-06-03 22:24     ` Kim F. Storm
2003-05-30 23:14   ` { SPAM 2 }::Re: " Luc Teirlinck
2003-05-30 23:40     ` Luc Teirlinck
2003-05-31 10:45     ` Kai Großjohann
2003-06-01 15:52   ` Richard Stallman
2003-06-01  5:06 ` Luc Teirlinck
2003-06-02 11:16   ` Richard Stallman
2003-06-03  2:43     ` Luc Teirlinck [this message]
2003-06-04  8:53       ` Richard Stallman
2003-06-03  4:05     ` Luc Teirlinck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200306030243.h532hup24488@eel.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).