[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Looking at function
Re: Looking at function
Mon, 11 Jul 2022 04:26:15 +0300
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
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
1. There is 1 call in isearch.el in ‘isearch-search-and-update’:
(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
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
2. Call the search function as above but afterwards check if
(match-beginning 0) is equal to the original position.
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
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.