Re: Idea for determining what users use

[Thien-Thi Nguyen]

   From: Richard Stallman <address@hidden>
   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