Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Jonas Bernoulli]

I am a bit surprised Stefan Monnier is fine with these deprecation.
If I remember correctly it was him who added the generalized variables,
and back when he did it, I got the impression that there was more to come.

I never used many of these, so I am generally fine with this change,
just somewhat surprised.  Unintuitive side-effects sounds like a good
reason to deprecate them, on the other hand I don't necessarily agree
that, e.g., (setf (point) n) is not intuitive, once you have wrapped
your head around setf.  But seeing that in the wild never-the-less
felt a bit weird.

> I found this in some code of mine, now generating warnings:
>
>     (if (> (point) (mark))
>         (progn (cl-incf (point)) (cl-decf (mark)))
>       (cl-incf (mark)) (cl-decf (point)))
>
> I guess the replacements would be forward-char and set-mark?  Is there
> anything simpler?

As I understood it the idea behind generalized variables wasn't to use
them mainly with setf, when a perfectly fine, explicit setter function
exists; but to use them in situations like this, with other functions
that understand generalized variables.  Made sense to me when the
feature was introduced.

I guess I am just wondering whether generalized variables are generally
seen as a failed experiment, and if so why exactly.  Or if not, I would
be interested in some guidance on when it is considered good practice to
use them and when not.

(Maybe we are going a bit overboard with the deprecations? Maybe we
should instead focus on documenting potentially surprising effects.
If we can think of reasonable use-cases (such as, IMO, the above) then
maybe we should not deprecate.  But again, I don't actually care that
much, just expressing my surprise and resulting uncertainties.

There is one generalized variable that I would like to see undeprecated
though:

   (setf (buffer-local-value 'var buffer) val)

That made a lot of sense to me.  I don't look forward to having to
wrap some (setq-local var val) with with-current-buffer again.  And it
appears I am not the only one you used buffer-local-value like this; 5%
of the out-tree packages that I have installed use it, and they are not
all authored by me.

     Jonas