bug#31772: 26.1; (thing-at-point 'list) regression

[Eli Zaretskii]

> From:  Leo Liu <sdl.web@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  31772@debbugs.gnu.org,  Noam Postavsky 
> <npostavs@users.sourceforge.net>,  Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 Jun 2018 11:17:08 +0800
> 
> > If you are in a buffer in emacs-lisp-mode, I just see
> > one list of length 3 in the following line:
> > ("foo" "(bar)" "baz")
> >
> > "(bar)" is a string.
> 
> I think you are solving the problem the wrong way. The original
> behaviour of (thing-at-point 'list) relied on up-list and is intuitive
> and sensible.

But up-list signals an error in the comment in *scratch*, for example,
so I'm not sure what consistency are we talking about here.

> But the point is a decade-old function that is functional and used in
> people's init or packages are changed in drastically incompatible way. I
> noticed the issue only after upgrade to emacs 26.1 a few days ago and
> discovered https://github.com/leoliu/easy-kill/issues/28.
> 
> *SIDE NOTE*
> 
> One of the issues with Emacs development (I feel it more deeply after I
> changed to use stable releases), people (in most cases only 1 user) find
> some feature doesn't entirely suit their needs and they change it often
> without full-perspective how it is used.

That's unfair, to say the least.  During the entire development of
Emacs 26, there was a conscious effort to avoid backward-incompatible
changes as much as possible, and in many cases leave an option behind
that would get previous behavior, sometimes people felt it was too
zealous.  Yes, several incompatible changes might have fallen through
the cracks, but if you think it's too much, please consider being more
active on the development list, and make sure your voice is heard when
these decisions are made.