Re: Looking at function

[Dmitry Gutov]

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.