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

[Andreas Röhler]

On 06.09.2018 12:37, Leo Liu wrote:
> Hi there,
>
> 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.
>
> 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.
>
> I hope you can find time to review the patch and come to a solution for
> 26.2 which I very much look forward to.
>
> Thanks,
> Leo

Hi Leo,

lets consider the following proposed change of tests:

-                         ("(foo\n(a ;(b c d)\ne) bar)" . (a e))
+                         ("(foo\n(a ;(b c d)\ne) bar)" . (foo (a e) bar))

As the ert-test mentioned  calls (re-search-backward "\\((a\\|^a\\)")

point will be behind foo at "(a". I.e. "foo" belongs to outer list, not 
to list-at-point. The desired result shown by this change looks wrong, 
"(foo" should not be part of.

Maybe I'm missing something.
May you provide a standalone example where current behavior breaks your 
code?

Thanks,
Andreas
gladly using GNU Emacs 27.0.50 (build 1, i686-pc-linux-gnu, GTK+ Version 
3.14.5) of 2018-08-29