Idea for determining what users use

Idea for determining what users use

[Richard Stallman]

We have no good way to determine if anyone still uses a feature.
Maybe we can create one.

Imagine a function called note-feature-used.
You call it like this:  (note-feature-used 'foo "Foo").
The first time you call it, it sends mail to
emacs-features-used@gnu.org with subject Foo,
asking you for permission to send it,
and it records (setq foo t) in your .emacs file.
If you call it again, it does nothing.

We could put these calls into various files and functions 
in order to find out (after the next release) whether anyone uses them.

Re: Idea for determining what users use

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> We have no good way to determine if anyone still uses a feature.
> Maybe we can create one.
> 
> Imagine a function called note-feature-used.
> You call it like this:  (note-feature-used 'foo "Foo").
> The first time you call it, it sends mail to
> emacs-features-used@gnu.org with subject Foo,
> asking you for permission to send it,
> and it records (setq foo t) in your .emacs file.
> If you call it again, it does nothing.
> 
> We could put these calls into various files and functions in order
> to find out (after the next release) whether anyone uses them.

Quite dangerous since it could be felt as a sort of privacy issue.
It must be carefully voiced.

Something like

Feature foo has been deprecated (? for info).  Complain (y/n)?

and then offer the usual "use it this time/don't ask again" dialog we
use for disabled commands.

After a while, one can remove the feature/command and instead do

Feature foo has been removed (? for info).  Complain (y/n)?

The info should explain why something is removed/deprecated and what
to use instead.  The mail buffer should be set up in a way that the
user can add his own comments and send, not just do this silently.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Idea for determining what users use

[Vincent LADEUIL]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

    rms> We have no good way to determine if anyone still uses a
    rms> feature.  Maybe we can create one.

    rms> Imagine a function called note-feature-used.  You call
    rms> it like this: (note-feature-used 'foo "Foo").  

    rms> The  first   time  you  call   it,  it  sends   mail  to
    rms> emacs-features-used@gnu.org with subject Foo, asking you
    rms> for permission to  send it, and it records  (setq foo t)
    rms> in your .emacs file.

What about people  who use emacs for other things  than mail ? Or
those  more  generally  who  cannot  send mail  from  emacs  (for
whatever reason).

    rms> If you call it again, it does nothing.

What  about  collecting all  these  infos  and  prepare a  buffer
containing the mail  to be sent (that could  be an alternate mean
to report usages).

    rms> We  could  put  these   calls  into  various  files  and
    rms> functions in order to  find out (after the next release)
    rms> whether anyone uses them.

Isn't it possible to only  instrument 'eval' to get all functions
(or interesting ones) used ?

        Vincent

Re: Idea for determining what users use

[Stefan Monnier]

> We have no good way to determine if anyone still uses a feature.
> Maybe we can create one.
> 
> Imagine a function called note-feature-used.
> You call it like this:  (note-feature-used 'foo "Foo").
> The first time you call it, it sends mail to
> emacs-features-used@gnu.org with subject Foo,
> asking you for permission to send it,
> and it records (setq foo t) in your .emacs file.
> If you call it again, it does nothing.
> 
> We could put these calls into various files and functions
> in order to find out (after the next release) whether anyone uses them.

I think such an approach is much too much "in your face" and as a user
I'd run screaming.  OTOH I thought that was already the idea behing
the `obsolete' subdirectory:
The way I see it work, moving a package to `obsolete' is telling
users "we think this is not used any more and we're planning to
get rid of it.  If we're wrong, you'd better tell us soon".  Now
the problem is that people might not notice that a package is obsolete.
My recent patch for `load' to output a warning message when loading
an `obsolete' package is a small step towards making users more
aware of the issue.  We could go a little further, of course.

In any case, based on my analysis I think we should not be afraid
to move stuff into `obsolete', since we can always revert it if people
start complaining.


	Stefan

Re: Idea for determining what users use

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

RMS wrote:
> The first time you call it, it sends mail to
> emacs-features-used@gnu.org with subject Foo,
> asking you for permission to send it,
> and it records (setq foo t) in your .emacs file.
> If you call it again, it does nothing.

I don't really like this approach.

Rather, I agree with Stefan:

> OTOH I thought that was already the idea behing
> the `obsolete' subdirectory:
> The way I see it work, moving a package to `obsolete' is telling
> users "we think this is not used any more and we're planning to
> get rid of it.  If we're wrong, you'd better tell us soon".  Now
> the problem is that people might not notice that a package is obsolete.

> My recent patch for `load' to output a warning message when loading
> an `obsolete' package is a small step towards making users more
> aware of the issue.  

That's a good feature IMO.

>                      We could go a little further, of course.

.. By telling the user that he may use "report emacs bug" to tell us
why he finds the obsoleted package useful.

In any case, I don't really see why we need to (ever) remove
anything from obsolete/ -- as long as we say that packages that
are in obsolete/ are `no longer actively supported'.

The only reason for actually removing a package from obsolete/
would be if  we change basic things in emacs that causes the
package to break ... then we may choose to remove it if it is
too much work to fix.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Idea for determining what users use

[Juanma Barranquero]

On 28 May 2003 02:43:24 +0200
storm@cua.dk (Kim F. Storm) wrote:

> The only reason for actually removing a package from obsolete/
> would be if  we change basic things in emacs that causes the
> package to break ... then we may choose to remove it if it is
> too much work to fix.

We've already done that at least once: c-mode.el / cplus-md.el.

                                                                Juanma

Re: Idea for determining what users use

[Richard Stallman]

    I think such an approach is much too much "in your face" and as a user
    I'd run screaming.

Why?

I don't see it.

Re: Idea for determining what users use

[Stefan Monnier]

>     I think such an approach is much too much "in your face" and as a user
>     I'd run screaming.
> Why?

I don't know exactly, but I generally expect a program to just
do what I ask it to, and if it comes back telling me "I noticed this
and that, do you want me to send an email for you" I instinctively
cringe.   And it could be made worse if the program is actually unable
to send the email anyway (because it's not properly configured or
because there's no access to the net, ...).

In any case, whether the warning is just the current "package foo is
obsolete" message, or whether it's extended to be more noticeable (maybe
by adding a 2s sleep) or by adding a "do you want to complain about it?"
question or whatever else, is rather secondary (to me) at this point.

My point was more about the fact that I think the basis for such a
feature should be "is it in the `obsolete' directory?" rather than
some other new annotations.  The reason for it is that otherwise we
simply add another step "first annotate it for `about-to-be-obsoleted'",
then "move it to obsolete", then "maybe remove it".  I don't see the
need for the new first step since moving a package to "obsolete" does
not make it less functional.

And the conclusion of all that was that any package for which "it seems
like it's unused, but we're not 100% sure" can be moved to the
`obsolete' directory.


	Stefan

Re: Idea for determining what users use

[Richard Stallman]

    My point was more about the fact that I think the basis for such a
    feature should be "is it in the `obsolete' directory?" rather than
    some other new annotations.

That approach might work ok, as a way of deciding when to issue the
message.  However, it would require making this a low-level mechanism
rather a function that can be called.  Also, we would not be able to
use it in specific places.

Re: Idea for determining what users use

[Thien-Thi Nguyen]

Richard Stallman <rms@gnu.org> writes:

   Imagine a function called note-feature-used.
   You call it like this:  (note-feature-used 'foo "Foo").
   The first time you call it, it sends mail to
   emacs-features-used@gnu.org with subject Foo,
   asking you for permission to send it,
   and it records (setq foo t) in your .emacs file.
   If you call it again, it does nothing.

knowing how ego-driven programmers are, i fear this would lead to lots
of spam as every little (sub-)feature is instrumented so.  perhaps this
can be ameliorated somewhat by batching up the samples into one var, say
`*$USER-features-used*' and providing `M-x report-used-features'.  this
allows any externalizable object to be reported (not just symbols), and
sidesteps the possibility of clobbering useful variables due to the ever
odious single-namespace problem.  we use $USER because a single ~/.emacs
can be used by many people.

some aspects of this two-phase approach are demonstrated by the poll at:

 http://www.glug.org/people/ttn/software/minor-mode-survey/

the relevant elisp is below for those w/o www access.

   We could put these calls into various files and functions 
   in order to find out (after the next release) whether anyone uses them.

IMHO, it is better not to tie such a poll to any specific release, since
a release is just a snapshot of various disparate albeit concurrent
activities.  release info could be included in `*$USER-features-used*',
however (along w/ extra commentary, etc).

another thing to keep in mind: at some installations there is a local
emacs guru who sets up the site-lisp dir, etc.  if a two-phase approach
is taken, it should allow the sampled data to be vetted through this
person as they usually have additional insight into the local emacs
situation apart from the end user.  in fact, whatever mechanism we
settle on could be a good tool for these people as well as for emacs
programmers w/ savannah write privs.

thi


______________________________________________
;;; minor-mode-survey.el
;;; author: ttn@gnu.org
;;; created: 2001/03/09 03:28:44
;;; modified: 2001/03/16 02:33:06 -- ignore errors in `buffer-modes-usage'
;;; public domain

;; these were mailed to gnu-emacs-help@gnu.org

(defun buffer-modes-usage (buffer)
  (with-current-buffer buffer
    (cons major-mode
          (let ((acc nil) (mma minor-mode-alist))
            (while mma                  ; avoid cl :-P
              (ignore-errors
                (let ((minor-mode (caar mma)))
                  ;; use `describe-mode' inclusion method -- see help.el
                  (when (and (symbol-value minor-mode)
                             (fboundp minor-mode))
                    (setq acc (cons minor-mode acc)))))
              (setq mma (cdr mma)))
            acc))))

(defun compose-mode-usage-mail ()
  (interactive)
  (let ((forms (mapcar 'buffer-modes-usage (buffer-list)))
        (mail-self-blind nil))
    (compose-mail "ttn@gnu.org" "minor mode survey response")
    (goto-char (point-max))
    (let ((standard-output (current-buffer)))
      (mapcar '(lambda (form)
                 (unless (= 1 (length form)) ; ignorance is bliss
                   (print form)))
              forms)))
  (setq fill-prefix ";;; ")
  (insert "\n;;; additional comments (fill-prefix set to \""
          fill-prefix
          "\")\n;;; "))

;; new stuff

(require 'cl)                           ; use the source luke!

(defun sort-freq-hash (hash)
  (let (unsorted)
    (maphash (lambda (x count) (push (cons count x) unsorted)) hash)
    (sort unsorted (lambda (a b) (> (car a) (car b))))))

(defun insert-compressed-freq-list (ls)
  (let ((last-seen 0))
    (dolist (x ls)
      (insert (if (= (car x) last-seen)
                  (format " %s" (cdr x))
                (setq last-seen (car x))
                (format "\n- %d %s" (car x) (cdr x))))))
  (insert "\n\n"))

(defun analyze-mode-usage-response (data)
  (insert (format "%d buffers scanned" (length data)))
  (dolist (x data) (setcdr x (remove-duplicates (sort (cdr x) 'string<))))
  (setq data (delete-duplicates data :test 'equal))
  (insert (format " (%d w/ unique mode signatures)\n" (length data)))
  (dolist (x data) (insert (format "- %s\n" x)))
  (insert "\n")
  ;; major mode summary
  (let ((majs (make-hash-table)))
    (dolist (x data) (incf (gethash (car x) majs 0)))
    (insert (format "%d unique major modes, sorted by instances in unique sig"
                    (hash-table-count majs)))
    (insert-compressed-freq-list (sort-freq-hash majs)))
  ;; minor mode
  (let ((mins (make-hash-table)) sorted)
    ;; summary
    (dolist (x (apply 'append (mapcar 'cdr data))) (incf (gethash x mins 0)))
    (insert (format "%d unique minor modes, sorted by instances in unique sig"
                    (hash-table-count mins)))
    (setq sorted (sort-freq-hash mins))
    (insert-compressed-freq-list sorted)
    ;; details: clumps and bros
    (insert "FOO-MINOR-MODE: CONCURRENT:COUNT CONCURRENT:COUNT ...\n"
            "- MOST CONCURRENT MINOR MODE\n"
            "- NEXT MOST CONCURRENT MINOR MODE\n"
            "- ...\n\n")
    (dolist (m (mapcar 'cdr sorted))
      (insert (format "%s:" m))
      (let* ((mdata (mapcar 'cdr data))
             (hood (remove-if-not (lambda (sig) (memq m (cdr sig))) mdata))
             (clumps (make-hash-table))
             (bros (make-hash-table)))
        (dolist (h hood) (incf (gethash (1- (length h)) clumps 0)))
        (dolist (b (remove m (apply 'append hood))) (incf (gethash b bros 0)))
        (dolist (x (sort (sort-freq-hash clumps)
                         (lambda (a b) (< (cdr a) (cdr b)))))
          (insert (format " %d:%d" (cdr x) (car x))))
        (insert-compressed-freq-list (sort-freq-hash bros))))))

(defun summarize-mode-usage-responses (file)
  (interactive "fMail file: ")
  (find-file file)
  (unless (eq 'rmail-mode major-mode)
    (error "wrong file, dude"))
  (let (data comments)
    (do ((i 1 (1+ i)))
        ((> i rmail-total-messages))
      (rmail-show-message i)
      (goto-char (point-min))
      (search-forward "\n\n")
      ;; pass twice to handle interspersed comments
      (let ((beg (point)))
        (goto-char beg)
        (ignore-errors (while t (push (read (current-buffer)) data)))
        (goto-char beg)
        (while (re-search-forward "^;;;\\(.+\n\\)" (point-max) t)
          (push (match-string 1) comments)))
      (push "----------------------------\n" comments))
    (kill-buffer (current-buffer))
    (switch-to-buffer "*Mode Usage Response Summary*")
    (erase-buffer)
    (analyze-mode-usage-response data)
    (insert "\n")
    (dolist (comment (reverse comments)) (insert comment))
    ;; gratuitous prettiness
    (while (re-search-backward "^---+\n\\s-*\n" (point-min) t)
      (replace-match ""))
    (re-search-backward "^---+\n" (point-min) t)
    (while (search-backward "-mode" (point-min) 1)
      (replace-match ""))))

;;; minor-mode-survey.el ends here

Re: Idea for determining what users use

[Stephen J. Turnbull]

>>>>> "Thien-Thi" == Thien-Thi Nguyen <ttn@glug.org> writes:

    Thien-Thi> knowing how ego-driven programmers are, i fear this
    Thien-Thi> would lead to lots of spam as every little
    Thien-Thi> (sub-)feature is instrumented so.

XEmacs bug reports all include (1) the Installation file (which gives
options to configure and autodetected); (2) the list of autoloaded
packages; and (3) the value of `features', as well as the traditional
output from view-lossage.

We've had no complaints on the basis of privacy or bandwidth.  People
might be a little more worried if we included the features used as
well as those available, but I suspect not.  So you could add
feature-reporter output to bug reports, although this is a little
unclean.

Alternatively, the feature reporter would be an ideal candidate for a
separate alias which fed into a statistics 'bot.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: Idea for determining what users use

[Richard Stallman]

    knowing how ego-driven programmers are, i fear this would lead to lots
    of spam as every little (sub-)feature is instrumented so.

I think you must have misunderstood the proposal.  We will insert
these calls when and where we want them.  I can't see why we would
have any problems as a result.

Mail sent to emacs-features-used@gnu.org will just be dumped into a
file.  We will search the file when we want to search it.

    IMHO, it is better not to tie such a poll to any specific release, since
    a release is just a snapshot of various disparate albeit concurrent
    activities.

It is impossible to avoid this.  Whatever we put into the code,
to indicate which functions etc. we are interested in,
that thing will appear in certain Emacs releases and not others.


Someone suggested "batching" these responses.  That can't be done
because you never know that the same user will encounter another one
of these calls.  The one he has encountered today may be the last one.

It is also unnecessary, because these calls will be few and not
frequent.  We will put them in features for which we don't know of any
users.  Most users will not encounter any of them.  Of those who
encounter one, most will never encounter another.

We know about surveys.  This is not a survey.

Re: Idea for determining what users use

[Thien-Thi Nguyen]

   From: Richard Stallman <rms@gnu.org>
   Date: Wed, 28 May 2003 19:58:12 -0400

   I think you must have misunderstood the proposal.  We will insert
   these calls when and where we want them.  I can't see why we would
   have any problems as a result.

i deliberately widened the scope of my interpretation of the proposal
because such a facility is useful for all programmers in a similar
manner to how autoload.el, bytecomp.el and reporter.el facilities are
useful to third party programmers.

   Mail sent to emacs-features-used@gnu.org will just be dumped into a
   file.  We will search the file when we want to search it.

that is one way to do it.

   It is impossible to avoid this.  Whatever we put into the code,
   to indicate which functions etc. we are interested in,
   that thing will appear in certain Emacs releases and not others.

this presumes emacs maintainers are the only ones to make use of such a
facility.  that is fine, but i think a little forethought about the
mindset behind the initiative (to find out what is in actual use, i.e.,
to formalize one communication channel between users and programmers) is
valuable to making the design useful outside the scope of the code that
happens to be in the gnu cvs repo.

   Someone suggested "batching" these responses.  That can't be done
   because you never know that the same user will encounter another one
   of these calls.  The one he has encountered today may be the last one.

whether one hit or multiple hits, IMHO it is better to separate the
collection and reporting sub-activities, not only for efficiency but
also to support user control/privacy.

   It is also unnecessary, because these calls will be few and not
   frequent.  We will put them in features for which we don't know of
   any users.  Most users will not encounter any of them.  Of those who
   encounter one, most will never encounter another.

like any code, its frequency of use is really up to its users once it
gets into the wild.  in this case, the code in question is code to get
feedback on programs, so its users will likely be programmers interested
in getting feedback on their programs, the numbers of which are hardly
small and constantly growing (although not at a constant rate ;-).  that
is, although we apply the techniques extremely judiciously, you can't
trust programmers not to be extreme in unexpected directions...

   We know about surveys.  This is not a survey.

the intent may not not be to do a survey, but the components of this
idea share many aspects w/ those of a survey.  it differs from the
various surveys in the past in that the results are partially machine
generated.  perhaps it could be called an assay instead of a survey.

thi

Re: Idea for determining what users use

[Richard Stallman]

    i deliberately widened the scope of my interpretation of the proposal
    because such a facility is useful for all programmers in a similar
    manner to how autoload.el, bytecomp.el and reporter.el facilities are
    useful to third party programmers.

We could try to make it useful to other programmers--I have nothing
against trying.  But not in a way that interferes with the original
intended purpose, which is use for us.

For others to be able to use this, they need to be able to specify the
email address in the call.  That won't be hard.

       Someone suggested "batching" these responses.  That can't be done
       because you never know that the same user will encounter another one
       of these calls.  The one he has encountered today may be the last one.

    whether one hit or multiple hits, IMHO it is better to separate the
    collection and reporting sub-activities, not only for efficiency but
    also to support user control/privacy.

I don't see how this could possibly make sense, but if you show me a
specific alternative scenario, I will think about whether it is
better.

    like any code, its frequency of use is really up to its users once it
    gets into the wild.

The purpose of this feature is for us to use it for low-frequency
messages.  There is no sense in redesigning it to optimize
for some other scenario at the expense of the intended purpose.

If you have some other application in mind and this feature isn't
good for your application, then design some other feature.

Re: Idea for determining what users use

[Thien-Thi Nguyen]

   From: Richard Stallman <rms@gnu.org>
   Date: Thu, 29 May 2003 20:48:58 -0400

   We could try to make it useful to other programmers--I have nothing
   against trying.  But not in a way that interferes with the original
   intended purpose, which is use for us.

certainly.  it sounds like the requirements for us are that we get
extremely compacted information (1-bit per feature) associated w/ a
particular release.

   For others to be able to use this, they need to be able to specify
   the email address in the call.  That won't be hard.

agreed.

       whether one hit or multiple hits, IMHO it is better to separate the
       collection and reporting sub-activities, not only for efficiency but
       also to support user control/privacy.

   I don't see how this could possibly make sense, but if you show me a
   specific alternative scenario, I will think about whether it is
   better.

sorry, i should have used the word "features" instead of "hits".  in our
case, for any feature, it is desirable to get only one bit of info (that
it is, whether the feature is indeed being used).  also, the number of
features is likely to be small.

for the more general instrumentation i'm slowly fulminating (since the
design of spyware is not the most happy activity, but i feel if it must
be done, might as well do a good job and include proper warnings and
explanations), there may be more bits involved along w/ more complicated
collection methods, some requiring repeated sampling.

an example of this would be, in hideshow.el, to answer the question "how
often does hs-headline usage lose due to C-g?".  i would need to collect
(repeatedly) hs-headline usage info along w/ "fixing the lossage" info,
represented in part by back-to-back invocations of M-x hs-minor-mode
(see Commentary).  to do this i would add something like:

  (snitch-collect-incf '(hideshow using-hs-headline))

to those places where hs-headline is set, and

  (when (eq 'hs-minor-mode last-command)
    (snitch-collect-incf '(hideshow back-to-back-hs-minor-mode)))

to hs-minor-mode.  `snitch-collect-incf' is a specialization of the
general `snitch-assoc-apply' (access $USER-snitched assoc list, munge as
needed, in this case incrementing a counter).

anyway, given this base, we can do something like:

(defun note-used-feature (name description)
  (snitch-assoc-apply name (lambda (current)
                             (unless current    ; one-shot
                               (compose-mail
                                 *feature-assay-email-address*
                                 (format "%s: %s" emacs-version
                                                  description)
                                 ...)
                               ;; retval is stashed in $USER-snitched
                               t))))

disclaimer: i don't actually intend to use snitch for official
hideshow.el maintenance in this way, but such a facility would be nice
for prereleases and other unofficial stuff.  to be annoyingly redundant,
IMHO the compose-mail call should be moved to a second-phase; the
example above is solely to demonstrate conformance to your original
design requirements.
                        
       like any code, its frequency of use is really up to its users
       once it gets into the wild.

   The purpose of this feature is for us to use it for low-frequency
   messages.  There is no sense in redesigning it to optimize
   for some other scenario at the expense of the intended purpose.

well i hope the design i have sketched is supportive of both our needs
and other needs.  i haven't thought too much on whether or not it is
optimized for one or the other in particular.  the main thing i like to
optimize for is effort (reducing it over the long run ;-).

   If you have some other application in mind and this feature isn't
   good for your application, then design some other feature.

ok, will check in a snitch.el independently at some point.  thanks for
triggering these interesting thoughts w/ your idea.

thi

Re: Idea for determining what users use

[Richard Stallman]

    an example of this would be, in hideshow.el, to answer the question "how
    often does hs-headline usage lose due to C-g?".

It sounds like you're concerned with a very different kind of question
from the one I had in mind.  I am not sure what the issue is regarding
hs-headline, but I get the impression you are considering an issue of
preferences between two possible ways a feature could work.  For that
kind of case, we usually just take a poll.

Re: Idea for determining what users use

[Thien-Thi Nguyen]

Richard Stallman <rms@gnu.org> writes:

   It sounds like you're concerned with a very different kind of
   question from the one I had in mind.

it is different in some ways and alike in some ways.  whether or not
that passes the "very" threshold is a matter of interpretation.  no
worries, emacs' interpreter can handle it all. ;->

   I am not sure what the issue is regarding hs-headline, but I get
   the impression you are considering an issue of preferences between
   two possible ways a feature could work.  For that kind of case, we
   usually just take a poll.

whatever you call it, when a programmer asks a question (any question)
of me as a user about a program, i consider it a poll.  if the question
is hidden or put forth in a sneaky way, i wonder why it couldn't be
asked openly, since i am very pleased to give feedback in that scenario.

because i don't know the all details of a program, i make a distinction
between questions that are indirect and those that are sneaky, not
minding the former so much as the latter.  all these are considerations
are present when i think about things from the programmer pov, to figure
how to best ask a question (any question) of a person like myself, to
preserve relations.

in another post you said people will correct others' misperceptions.
that's fine, too.  perhaps we will need to FAQify those corrections.

thi

Re: Idea for determining what users use

[Richard Stallman]

    whatever you call it, when a programmer asks a question (any question)
    of me as a user about a program, i consider it a poll.

I think that level of generalization is too abstract for useful thinking.

Re: Idea for determining what users use

[Richard Stallman]

    What about people  who use emacs for other things  than mail ?

I don't see why that would be a problem.

								   Or
    those  more  generally  who  cannot  send mail  from  emacs  (for
    whatever reason).

I guess there is nothing we can do about that.

    What  about  collecting all  these  infos  and  prepare a  buffer
    containing the mail  to be sent (that could  be an alternate mean
    to report usages).

It doesn't seem like a useful idea.  These messages will probably
be rare.

    Isn't it possible to only  instrument 'eval' to get all functions
    (or interesting ones) used ?

It is possible, but I think an implementation that avoids intrusion
into the guts of Emacs is a superior one.

Re: Idea for determining what users use

[Vincent LADEUIL]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

    vila> What about people who use emacs for other things than
    vila> mail ?

    rms> I don't see why that would be a problem.

Because they may not have configured emacs to send mail.

    vila> Or those more generally who cannot send mail from emacs
    vila> (for whatever reason).

    rms> I guess there is nothing we can do about that.

My proposal  was to help them cut&paste  the relevant information
into *their* favorite email tool.

    vila> What about collecting all these infos and prepare a
    vila> buffer containing the mail to be sent (that could be an
    vila> alternate mean to report usages).

    rms> It doesn't seem like a useful idea.  These messages will
    rms> probably be rare.

Ok, my  experience regarding  emacs users is  that only a  few of
them use it for mail. I can very well be wrong on that point.

But as the subject of  the thread is "determining what users use"
it could  be interesting to  instrument more functions  than just
the obsoleted  ones (mail, sub-processes, major  and minor modes,
etc.).


    vila> Isn't it possible to only instrument 'eval' to get all
    vila> functions (or interesting ones) used ?

    rms> It is possible, but I think an implementation that
    rms> avoids intrusion into the guts of Emacs is a superior
    rms> one.

So  what   about  instrumenting  "autoload"  ?   Or  defining  an
autoload-obsolete function ?

        Vincent

Re: Idea for determining what users use

[Richard Stallman]

	vila> What about people who use emacs for other things than
	vila> mail ?

	rms> I don't see why that would be a problem.

    Because they may not have configured emacs to send mail.

Emacs does not need any special configuration to send mail.
If the machine can send mail, Emacs can do it.

	vila> Or those more generally who cannot send mail from emacs
	vila> (for whatever reason).

	rms> I guess there is nothing we can do about that.

    My proposal  was to help them cut&paste  the relevant information
    into *their* favorite email tool.

I didn't see that proposal, but they could certainly do this if they
want to.  (Nothing would stop them.)  I don't see that anything
special is needed.

    Ok, my  experience regarding  emacs users is  that only a  few of
    them use it for mail. I can very well be wrong on that point.

Whether they use Emacs for mail on other occasions has no effect.
It is not a relevant issue.

    So  what   about  instrumenting  "autoload"  ?   Or  defining  an
    autoload-obsolete function ?

Sorry, I don't know what that would mean.  I see no need for this
to have any connection with the autoload mechanism.  It will work
just fine in autoloaded files.

Re: Idea for determining what users use

[Jan D.]

>     Because they may not have configured emacs to send mail.
>
> Emacs does not need any special configuration to send mail.
> If the machine can send mail, Emacs can do it.

Many machines can't send mail, but mail applications running on those
machines can.  For many mail applications you specify incoming 
(pop3/imap)
server and outgoing SMTP server.  Emacs can not know about these unless 
told.
Emacs uses the local sendmail by default (on Unix at least).
I have machines where I can read and send mail with mail applications,
but not with Emacs.  Any mail Emacs would try to send would go to
/var/spool/mqueue and stay there forever.

	Jan D.

Re: Idea for determining what users use

[Stefan Monnier]

> Many machines can't send mail, but mail applications running on those
> machines can.  For many mail applications you specify incoming
> (pop3/imap)
> server and outgoing SMTP server.  Emacs can not know about these unless
> told.

Actually, I feel like there should be a way to get Emacs to use
a more useful default by detecting those situations and using
the mail application's config.
I know that EMacro tries to do such things (typically things like
trying to parse .netscape/prefs.js) and while most of it is rather
ad-hoc&ugly I suspect that there's a way to "do it right" using
the registry (on W32) or things like that.

> I have machines where I can read and send mail with mail applications,
> but not with Emacs.  Any mail Emacs would try to send would go to
> /var/spool/mqueue and stay there forever.

These are very badly configured machines.
Complain to whoever is responsible for such a brain dead behavior.
A missing sendmail or a sendmail that returns a particular error
could be a useful hint to convince Emacs to automatically try the
smtpmail package.


	Stefan

Re: Idea for determining what users use

[Jan D.]

>> I have machines where I can read and send mail with mail applications,
>> but not with Emacs.  Any mail Emacs would try to send would go to
>> /var/spool/mqueue and stay there forever.
>
> These are very badly configured machines.
> Complain to whoever is responsible for such a brain dead behavior.

That would be me :-)

> A missing sendmail or a sendmail that returns a particular error
> could be a useful hint to convince Emacs to automatically try the
> smtpmail package.

Sendmail is not missing and does not return any error message.  The
sendmail daemon is not running, that is all.  Why should it?  Nobody
is using it, and a potential security risk is removed.  It seems 
excessive
to configure sendmail and start a daemon just because Emacs might want
to send a mail.

	Jan D.

Re: Idea for determining what users use

[Stefan Monnier]

> > These are very badly configured machines.
> > Complain to whoever is responsible for such a brain dead behavior.
> That would be me :-)

Are you saying that consciously installed sendmail and set up
its config so that it does the wrong thing ?

> > A missing sendmail or a sendmail that returns a particular error
> > could be a useful hint to convince Emacs to automatically try the
> > smtpmail package.
> 
> Sendmail is not missing and does not return any error message.  The
> sendmail daemon is not running, that is all.  Why should it?  Nobody
> is using it, and a potential security risk is removed.  It seems
> excessive
> to configure sendmail and start a daemon just because Emacs might want
> to send a mail.

The default install of sendmail should not do what you describe,
because of its obvious tendency to behave as a blackhole.
Complain to whoever is responsible for this default config.
I'm not saying you should run it as a daemon.  I'm saying that running
it should report a "not configured" error.


	Stefan


PS: why have it installed if you don't use it and it doesn't work ?

Re: Idea for determining what users use

[Alex Schroeder]

"Stefan Monnier" <monnier+misc/ads@rum.cs.yale.edu> writes:

>> > These are very badly configured machines.
>> > Complain to whoever is responsible for such a brain dead behavior.
>> That would be me :-)
>
> Are you saying that consciously installed sendmail and set up
> its config so that it does the wrong thing ?

Well, kind of.  I'm using exim for local mail delivery, so that the
cron jobs can mail me their output.  But all my mail goes via
external hosts directly -- and this is configured in my Emacs only.
The reason is that it was easier for me to configure Emacs correctly
than to configure Exim correctly.

Exim had a problem with my machine not having a hostname.  For some
time I tricked exim into thinking that my machine was
confusibombus.emacswiki.org -- but www.emacswiki.org is just the web
hosting somewhere in Germany, so then other problems started to
appear.  And before I thinking it all through, I decided to do an
Emacs-only solution.

Alex.
-- 
http://www.emacswiki.org/cgi-bin/alex.pl

Re: Idea for determining what users use

[Richard Stallman]

    Well, kind of.  I'm using exim for local mail delivery, so that the
    cron jobs can mail me their output.  But all my mail goes via
    external hosts directly -- and this is configured in my Emacs only.
    The reason is that it was easier for me to configure Emacs correctly
    than to configure Exim correctly.

Should Exim have additional features so it can handle your machine?

Anyway, if you normally send mail thru Emacs, there won't be a problem.
This feature would use compose-mail, like everything else in Emacs that
sends mail, so these messages would go through your setup and would work.

Re: Idea for determining what users use

[Peter Lee]

>>>> On Sat, 31 May 2003 15:51:57 -0400, Richard Stallman <rms@gnu.org> said:
    rms> Anyway, if you normally send mail thru Emacs, there won't be
    rms> a problem.  This feature would use compose-mail, like
    rms> everything else in Emacs that sends mail, so these messages
    rms> would go through your setup and would work.

I use Emacs for mail.  Every now and again when I send mail it
hangs Emacs for 1-2.5 minutes.  Since it happens infrequently I'm
assuming it's just my smtp server.

I don't mind this normally as I don't send out all that much mail and
when I do, since I'm in mail-mode (figuratively), it's not a
distraction.  But if I'm busy working on something and hit a function
that's considered dated, it would be extremely aggravating to have
everything hang while it mailed some usage info on the func I just
hit.  Having it prompt and ask me if it was ok to send the mail would
only be slightly less annoying.

Just this user's opinion.

Re: Idea for determining what users use

[Luc Teirlinck]

Richard Stallman wrote:

   Anyway, if you normally send mail thru Emacs, there won't be a problem.
   This feature would use compose-mail, like everything else in Emacs that
   sends mail, so these messages would go through your setup and would work.

Thien-Thi Nguyen wrote:

   it sounds like the requirements for us are that we get extremely
   compacted information (1-bit per feature) associated w/ a
   particular release.

and:

   in our case, for any feature, it is desirable to get only one bit
   of info (that it is, whether the feature is indeed being used).

If somebody files a "bug report" after proper thought, we get to see
why he needs the feature, or believes he does.  With the proposed
system, if somebody sends a reply ranting and raving about how much he
resents the "intrusion on his privacy" we will just conclude that he
uses the feature.

Popping up a mail buffer makes it super-easy to complain for people
with permanent internet access and inconveniences other people.  If we
just pop up information and an email address (bug-gnu-emacs@gnu.org
maybe), then only people who really care about the feature will
complain (and if people do not really care, then what is the problem?)
and we will see why they still need the feature.  Maybe we can still
get rid of the feature, but add the needed functionality to the
feature that replaced it.

What is the need for the extremely compacted information Thien-Thi is
referring to?  If we really need extremely compacted information then
there is no problem: the feature is incredibly useful and should not be
obsoleted.  If we care enough about this to inconvenience (and
potentially antagonize) users, we should also care enough to read what
they have to say.

Sincerely,

Luc.

Re: Idea for determining what users use

[Luc Teirlinck]

Also it seems that a user who wants the mail buffer can always get it
using M-x report-emacs-bug or using the menu.  If we want something
more specialized for the purpose, we could add separate commands and
menu items.  That way the user can mail his complaint just as
conveniently, but on his terms, when he is ready (and when he has
internet access), rather than feeling rushed.  The user is likely
busy doing something else at the time.

Sincerely,

Luc.

Re: Idea for determining what users use

[Richard Stallman]

    Also it seems that a user who wants the mail buffer can always get it
    using M-x report-emacs-bug or using the menu.

A user who decides "I want to tell the Emacs developers something"
might do this.  The idea of my proposal is to get people to send us
mail about issues which they did not know about.

Re: Idea for determining what users use

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Also it seems that a user who wants the mail buffer can always get it
>     using M-x report-emacs-bug or using the menu.
> 
> A user who decides "I want to tell the Emacs developers something"
> might do this.  The idea of my proposal is to get people to send us
> mail about issues which they did not know about.

I still think we are wasting our time on this issue.

IMHO there is a much simpler solution:

- If we think a package has been superseded by something better,
  we move the package to lisp/obsolete/

- We describe this very clearly in NEWS by creating a new section:
         * Obsoleted features in 21.5
  This will describe what packages are obsoleted, what the user should
  do to stop using the obsolete feature, and what alternative
  solutions we recommend instead.

- If a user uses the obsolete feature, he gets a warning in his
  *Messages* buffer telling him there is a better alternative (could
  refer the user to NEWS for more info).

- The user may overlook or disregard this warning ... and continue to
  use the obsolete feature, probably for several emacs releases to
  come.

- We simply keep the obsolete feature in future releases of emacs,
  unless the feature is too difficult to maintain.

- If a user really cares about using the obsolete package, he is
  welcome to report a bug about it, and tell us clearly why he
  thinks obsoleting the old package is wrong.


So Richard, please answer these questions:

1) What additional benefits do we get from "annoying" users with the
   proposed "usage polls", compared to the simple scheme above?

2) How many users should report to be using a feature for us to move
   it out of obsolete again?  Less than five?  (In that case, I would
   argue that having the package in obsolete could indeed the right
   place for it!)

3) If we have moved a package to obsolete because we have something
   better, how do you interpret what the usage polls tells us?  In
   most cases, the right choice for the user is simply to switch to
   the new package (he probably just wasn't aware of the new package,
   or has been too lazy to switch).  Only in rare cases, the user
   continues to use the obsolete package because it provides some
   feature that isn't provided by the new package -- any with your
   1-bit polls, you won't really know what that specific feature is --
   so we cannot fix the new package.


In any case, I think that we need to make this a user option,
so it can be easily turned off.  (I would expect the various
GNU/Linux distributions would do this, independent of whether
we enable it by default).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Idea for determining what users use

[Richard Stallman]

    1) What additional benefits do we get from "annoying" users with the
       proposed "usage polls", compared to the simple scheme above?

There are cases where we have simply removed a feature rather than
just putting a file into the `obsolete' subdirectory.  I am not
thinking of using this for just moving something into the `obsolete'
subdirectory.

Re: Idea for determining what users use

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     1) What additional benefits do we get from "annoying" users with the
>        proposed "usage polls", compared to the simple scheme above?
> 
> There are cases where we have simply removed a feature rather than
> just putting a file into the `obsolete' subdirectory.  I am not
> thinking of using this for just moving something into the `obsolete'
> subdirectory.

Ok, but considering the frequency by which we make new major
releases of emacs, it may take us 2-3 years to determine whether
a given feature can be "safely" removed:

In emacs 21.1, we had a feature X, that we want to remove.

So in emacs 21.5, we mark feature X so that usage is reported back to
the emacs team.

In the 2-3 years before we release emacs 22.1, we have gathered enough
"no responses" to decide feature X may be removed in 22.1.


IMO, it would be much simpler just to move the feature to obsolete in
21.5, and if we don't get any feedback on the feature, we may decide to
remove it in 22.1 -- or just leave it in.


There's just so little useful information to gain from the proposed
"usage-polls" that I still think it's not worth spending our precious
resources on.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Idea for determining what users use

[Richard Stallman]

    IMO, it would be much simpler just to move the feature to obsolete in
    21.5, and if we don't get any feedback on the feature, we may decide to
    remove it in 22.1 -- or just leave it in.

We are talking about different scenarios.  Lisp files can be moved
to the obsolete directory.  Some features are not files, or even
specific parts of files; they cannot easily be moved anywhere.


    So in emacs 21.5, we mark feature X so that usage is reported back to
    the emacs team.

    In the 2-3 years before we release emacs 22.1, we have gathered enough
    "no responses" to decide feature X may be removed in 22.1.

It won't take 2-3 years after 21.5 is released to find out whether
there is substantial usage of a feature.

Re: Idea for determining what users use

[Jan D.]

> Are you saying that consciously installed sendmail and set up
> its config so that it does the wrong thing ?

Just install any Linux distribution with some standard choice of
packages, it will be included.  There is not much point in wading
through tons of install menus just to remove sendmail.

> The default install of sendmail should not do what you describe,
> because of its obvious tendency to behave as a blackhole.

It does on all Linux and FreeBSD installations I've made.

> PS: why have it installed if you don't use it and it doesn't work ?

Se above.  For example, selecting some configuration called "developer
workstation" will install it.  For Solaris it is always included.
If I would go through the trouble to not install all commands that are
not used, I would never get any installations done :-)

	Jan D.

Re: Idea for determining what users use

[Stefan Monnier]

> > Are you saying that consciously installed sendmail and set up
> > its config so that it does the wrong thing ?
> 
> Just install any Linux distribution with some standard choice of
> packages, it will be included.  There is not much point in wading
> through tons of install menus just to remove sendmail.

So *you* indeed didn't do it.  It's simply the default.
You're not responsible for it.

> > The default install of sendmail should not do what you describe,
> > because of its obvious tendency to behave as a blackhole.
> 
> It does on all Linux and FreeBSD installations I've made.

I know and it sucks and we should all complain loudly so they fix it.
It should either work or fail, but no blackhole, please!


	Stefan

Re: Idea for determining what users use

[Richard Stallman]

    > Many machines can't send mail, but mail applications running on those
    > machines can.  For many mail applications you specify incoming
    > (pop3/imap)
    > server and outgoing SMTP server.  Emacs can not know about these unless
    > told.

    These are very badly configured machines.

Maybe, but that may not be the local user's fault.
It could be a case of unmodular design in the system.

When there are new ways of sending mail, the system should be set up
so that `mail' interfaces to them properly, so that applications that
occasonally send mail will work and don't all need to know all these
ways.

It could be that this hasn't been done, and ought to be changed in
various mailers.

Re: Idea for determining what users use

[Kim F. Storm]

The more I think about this proposal, the more I dislike it.

So if I have a vote on this, it's a definite NO.


For the un-informed public (read journalists, m$-evangelists, etc),
putting such a feature into emacs could be used to bad-mouth the
GNU project for installing "SPY-ware" on the users' systems.


Furthermore, I think the benefits of the proposed features are very
limited, and that our efforts are better spent on new features.  As
Stefan has pointed out, there's already a warning if people are using
a package in the obsolete directory -- I think that's the right
approach: Tell the user that the feature is considered obsolete, 
so if he disagrees, he should send us a bug-report.


There are some technical problems with the "simple approach" too:

How are we going to present the question to someone who upgrades
from an older version of emacs who loads one of the obsolete features?
I guess he will presented with the question after loading of his
emacs is complete.  That adds further complexity if he has loaded
multiple obsolete packages.


And we don't really get realiable measurements this way either:

Consider a user who finds a feature that we have marked obsolete and
decides to try it out ... SURPRISE, he's asked whether he wants to
send mail to the emacs team about actively using this feature ...

Well, he hasn't had a chance to try it yet, so he may do one of
four things:

1) Answer yes (causing the mail to be sent), and actually like
   the feature, so he continues to use it.

2) Answer yes (causing the mail to be sent), but then finds
   the feature is useless, so he doesn't actually use it.

3) Answer no -- because he's doesn't want us to spy on him.
   And maybe be aggrevated at the same time...

4) Answer no -- because he doesn't know whether he's going to use it
   yet, but he intends to tell us the next time he loads the feature
   if he likes it.  But I assume that we are not going to ask him
   again (because we wrote something in his .emacs).

That means that only in one of four cases do we get a useful
answer, and probably get a number of false answers too ....

And then there's the problem of not being able to send mail from
emacs in some setups.


Finally, what if only one or two users report using a specific feature
-- is that enough "audience" to keep an obsolete feature?




Richard Stallman <rms@gnu.org> writes:

> We have no good way to determine if anyone still uses a feature.
> Maybe we can create one.
> 
> Imagine a function called note-feature-used.
> You call it like this:  (note-feature-used 'foo "Foo").
> The first time you call it, it sends mail to
> emacs-features-used@gnu.org with subject Foo,
> asking you for permission to send it,
> and it records (setq foo t) in your .emacs file.
> If you call it again, it does nothing.
> 
> We could put these calls into various files and functions 
> in order to find out (after the next release) whether anyone uses them.
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> 
> 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Idea for determining what users use

[Miles Bader]

On Sat, May 31, 2003 at 01:47:49AM +0200, Kim F. Storm wrote:
> For the un-informed public (read journalists, m$-evangelists, etc),
> putting such a feature into emacs could be used to bad-mouth the
> GNU project for installing "SPY-ware" on the users' systems.

Yeah, I agree with this -- I've seen it happen before.  No matter how careful
you are to confirm with the user, there are a _lot_ of people out there who
will get their panties in a twist over it (you know, the same people who
encrypt their laundry-list).

So while I personally rather like such features (I like to know that I'm
having some influence!), I think it would probably cause more problems for
emacs than it would solve.

At best, I think you could get away with making it a feature that was off by
default, and had to be turned on explicitly -- this is obviously much worse
because doing so would skew the results highly, but it might be better than
doing polls, as the user would only have to enable it once, and wouldn't have
to bother with answering individual polls.

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: Idea for determining what users use

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> At best, I think you could get away with making it a feature that was off by
> default, and had to be turned on explicitly -- this is obviously much worse
> because doing so would skew the results highly, but it might be better than
> doing polls, as the user would only have to enable it once, and wouldn't have
> to bother with answering individual polls.

I think this is a good approach.  Of course, we should present this in a 
positive tone in NEWS -- something like this:

You can now participate in the collection of various "package usage
statistics" that will tell the emacs development team which Lisp
packages are actually used.  [add some blurb about privacy etc.]  
To participate, you need to configure the smtpmail-default-mail-server
variable and then set the enable-emacs-statistics-mails variable to t.



-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: { SPAM 2 }::Re: Idea for determining what users use

[Luc Teirlinck]

Kim Storm wrote:

   Furthermore, I think the benefits of the proposed features are very
   limited, and that our efforts are better spent on new features.  As
   Stefan has pointed out, there's already a warning if people are using
   a package in the obsolete directory -- I think that's the right
   approach: Tell the user that the feature is considered obsolete, 
   so if he disagrees, he should send us a bug-report.

I basically agree, but there is one problem for which one might still
want to find a solution in this case:

If I do:

M-x load-library RETURN x-menu,

I indeed get a warning.

If I put:

(require 'x-menu)

in my .emacs, or some other file, I will only notice the warning if I
examine the *Messages* buffer, assuming it is not gone by then (due to
the size limit on the *Messages* buffer).

I do not think one should try to pressure the user to mail a
"complaint", before he has had any chance to investigate the situation
and try to find out for himself why the package was obsoleted.

He should get a chance to see stuff like:

;;; uncompress.el --- auto-decompression hook for visiting .Z files

;; M-x auto-compression-mode is a more modern replacement for this
   package.

Or:

;; profile.el --- Emacs profiler (OBSOLETE; use elp.el instead)

But there must be a way to make the message less easy to overlook, as
well as, maybe, to include the above info in the message, or
instructions on where to look for such info, and an email address to
mail counterarguments to.

Sincerely,

Luc.

Re: { SPAM 2 }::Re: Idea for determining what users use

[Luc Teirlinck]

Actually, I was playing around with x-menu and the like, just to see
what would happen, when I suddenly noticed the line:

Package rsz-mini is obsolete

in the *Messages* buffer (buried deep within tons of harmless stuff).
That was mot intentional.  It is a leftover from when that was
necessary.  I removed the line:

(resize-minibuffer-mode t)

from my .emacs.  This shows how easy such messages are to overlook.

Note:

;;; Commentary:

;; This package is obsolete.  Emacs now resizes mini-windows
;; automatically

Sincerely,

Luc.

Re: { SPAM 2 }::Re: Idea for determining what users use

[Kai Großjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> If I put:
>
> (require 'x-menu)
>
> in my .emacs, or some other file, I will only notice the warning if I
> examine the *Messages* buffer, assuming it is not gone by then (due to
> the size limit on the *Messages* buffer).

Maybe Emacs can do like it does now for errors in the init file.
When there is an error, you get a *Messages* buffer with useful contents.
-- 
This line is not blank.

Re: Idea for determining what users use

[Richard Stallman]

    For the un-informed public (read journalists, m$-evangelists, etc),
    putting such a feature into emacs could be used to bad-mouth the
    GNU project for installing "SPY-ware" on the users' systems.

It isn't spyware, and it obviously isn't spyware.  A few people
might get confused, but others would straighten them out.

    Consider a user who finds a feature that we have marked obsolete and
    decides to try it out ... SURPRISE, he's asked whether he wants to
    send mail to the emacs team about actively using this feature ...

He will read the message, and decide whether he wants to send it.
If he isn't really using the feature, he won't send the message.

Re: Idea for determining what users use

[Luc Teirlinck]

What about the following alternative:

When the user uses an obsoleted feature, we print a message in the
echo area, like now.  In some situations, some of which I pointed out
before, the user will never notice that message.  However, we also
copy the name of the feature in a file specially dedicated for that
purpose, .obsolete_features_used or whatever.  That file is in a
special major mode.  The user puts point on one of the features and
then has commands allowing to view our reasons for obsoleting the
feature, sending mail complaining about the feature being obsoleted,
in a specially prepared mail buffer, and so on.  There also is a
command for "tracking" the feature, after which the user gets notified
more emphatically when he uses the feature (what that means exactly
could be discussed).  Of course there also is a command for turning
tracking off.  That way there never is any inconvenience to the user,
no buffers popping up, no minibuffer questions nothing, unless the
user decides that it is worth the trouble.  The user could also
decide to track all obsolete features.

Most of the time, the user will realize that the problem is in .emacs.
He can then remove the line from .emacs and delete the feature from
the file, or complain.

We could also provide a command that produces a buffer with all
obsoleted features, whether ever used by the user or not, in the same
major mode.

Of course, all of this only matters if we really want to actually remove
obsolete stuff.  Otherwise, it does not seem worth the trouble, but
neither do the alternatives in that case.

Sincerely,

Luc.

Re: Idea for determining what users use

[Richard Stallman]

      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.

Re: Idea for determining what users use

[Luc Teirlinck]

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.

Re: Idea for determining what users use

[Richard Stallman]

    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.

For this situation--a feature that we are thinking of eliminating--my
idea was to get a head count.  However, we could invite the user
to add explanatory material to the message before sending it.

By the way, we have indeed eliminated features in the past.  We
eliminated a number of features in 21.1.  Sometimes they are features
of a specific functions, rather than separate files.

    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.

That seems like a good idea.  It fits naturally with the Emacs facilities
for sending a message.  And it will be clear that nothing will be sent
unless the user types C-c C-c.

Re: Idea for determining what users use

[Luc Teirlinck]

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.

In addition to what I said in my previous message, we could have a
menu item under "Help" for visiting the file and one for listing all
obsolete features.  C-h o is undefined and "o" being the first letter
of obsolete, we could bind it to a command for visiting the file (the
same as the one invoked by the menu item), while C-h O could list all
obsolete features.

Sincerely,

Luc.