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

Previous Next

Full log

Message #59 received at 31772 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 31772 <at> debbugs.gnu.org, tino.calancha <at> gmail.com
Subject: Re: bug#31772: 26.1; (thing-at-point 'list) regression
Date: Tue, 11 Sep 2018 11:31:43 +0300

> From:  Leo Liu <sdl.web <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Tino Calancha <tino.calancha <at> gmail.com>
> Date: Thu, 06 Sep 2018 18:37:11 +0800
> 
> I have been using 26.1 as my main editor for the last few months and
> this breakage remains a pain point in my day-to-day editing. For example
> whenever I rewrite a function, I normally comment out the old one (to
> keep the linter, pretty-printer or whatnot happy) and write the new one
> from scratch, occasionally copy things from the old one to save typing
> and this bug gets in the way many times a day. I propose a patch that
> doesn't divert too much from the old and tried behaviour.

Thanks.  Can you summarize how the behavior with your patch will be
different from what we had in Emacs 25 and before?

> The idea that is currently in thing-at-point-bounds-of-list-at-point is
> fine for a higher level function such as list-at-point but doing it
> there affects all functions that build on it including some from
> thingatpt.el itself.

Would it be possible to modify list-at-point so that it keeps the
current behavior, perhaps as an option?  I'd like to find a solution
that doesn't just revert to the old behavior, but allows those who
need the new behavior to have it in some reasonable way.

Thanks.

Previous Next

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