[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andreas Röhler
Subject: bug#31772: 26.1; (thing-at-point 'list) regression
Date: Thu, 6 Sep 2018 21:01:55 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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.


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?

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]