[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: Fri, 7 Sep 2018 10:17:12 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 07.09.2018 06:42, Leo Liu wrote:
On 2018-09-06 21:01 +0200, Andreas Röhler wrote:
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?

I carefully considered this case when preparing the patch.

In the last 10 years (thing-at-point 'list) always returns the enclosing
list so I opted to keep this for now. It is confusing and I don't like
it personally.

To check the current correct behavior insert the following lines and try the command provided below:

(foo\n(a ;(b c d)
e) bar)

(defun mylist ()
    (goto-char (point-min))
    (search-forward "(a")
    (forward-char -1)
    (thing-at-point 'list t)))

From "(" it reads the list opened at point.

reply via email to

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