GNU bug report logs - #31772
26.1; (thing-at-point 'list) regression

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: npostavs <at> users.sourceforge.net, 31772 <at> debbugs.gnu.org, dgutov <at> yandex.ru, tino.calancha <at> gmail.com
Subject: bug#31772: 26.1; (thing-at-point 'list) regression
Date: Mon, 11 Jun 2018 18:10:38 +0300

> From:  Leo Liu <sdl.web <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  31772 <at> debbugs.gnu.org,  Noam Postavsky <npostavs <at> users.sourceforge.net>,  Dmitry Gutov <dgutov <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.