[Top][All Lists]

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

Re: Looking at function

From: Dmitry Gutov
Subject: Re: Looking at function
Date: Mon, 11 Jul 2022 04:26:15 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

Hi Juri,

On 28.06.2022 21:01, Juri Linkov wrote:
Any use of the function ‘looking-at’ is incompatible with a non-default value
of ‘isearch-search-fun-function’.  So there are following problematic uses
of ‘looking-at’:

1. There is 1 call in isearch.el in ‘isearch-search-and-update’:

                   (looking-at (cond
                                ((functionp isearch-regexp-function)
                                 (funcall isearch-regexp-function 
isearch-string t))
                                (isearch-regexp-function (word-search-regexp 
isearch-string t))
                                (isearch-regexp isearch-string)
                                (t (regexp-quote isearch-string))))

    It doesn't call a non-default search function when using a key sequence like
    ‘C-M-r ^’ on rectangular regions — it matches outside of regions
    when the search function restricts the search within the region bounds.

2. In replace.el ‘looking-at/back’ are used only in ‘perform-replace’
    to check if the next match is adjacent.  This causes problems during
    rectangular replacements to find matches based on a non-default
    search function.

These possible solutions were proposed in bug#54733:

1. Replace ‘looking-at’ with a call to the search function,
    but keep it at point by prepending ‘\\=’ to the regexp.
    Can it break a complex regexp?

I suppose it can. Even a simple one (that has \\| inside without a grouping).

2. Call the search function as above but afterwards check if
    (match-beginning 0) is equal to the original position.
    Less efficient.

I don't think efficiency would be a problem here, but tricky search functions could be. Like ones that expect to be called a specific number of times (replace-re-search-function inside xref--query-replace-1 is one such example).

But if the code could be rearranged such that the search function is called the same number of times but does something different when it's found right away. Or of course we could mandate that the search functions are never written this way (it's pretty ad-hoc).

3. Use looking-at only when the search function is default.

Probably would fail some of the scenarios similar to which the looking-at hack was added for.

4. Add a new variable ‘looking-at-function’.
    It could be like ‘isearch-search-fun-function’, so redefining
    the search function will also require redefining the
    looking-at function with similar code that doesn't move point.

I suppose this is a safe alternative.

Any better ideas how to replace looking-at with something
that uses a search function?

Do we have a clear understanding of the idea behind this looking-at call?

The comment says:

          ;; Otherwise, if matching a regular expression, do the next
          ;; match now, since the replacement for this match may
          ;; affect whether the next match is adjacent to this one.
          ;; If that match is empty, don't use it.

What happens if there are multiple adjacent matches in a row, not just 2? I suppose the replacement could be performed for the first one, then the next one is "popped" becoming the current and looking-at is called again near its end?

If so, perhaps a good alternative is to stop caring about whether those matches are adjacent and always store the latest two matches, whether they are next to each other or not.

reply via email to

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