[Top][All Lists]

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

Re: isearch region or thing at point.

From: Basil L. Contovounesios
Subject: Re: isearch region or thing at point.
Date: Wed, 01 May 2019 00:33:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Ergus <address@hidden> writes:

> On Tue, Apr 30, 2019 at 11:39:11PM +0100, Basil L. Contovounesios wrote:
>>Ergus <address@hidden> writes:
>>>                      (region-bounds)))
>>>         (contiguous (= (length bounds) 1)) ;; Region is contiguous
>>Better to use the function region-noncontiguous-p.
> I already had the bounds.. I didn't want to do the funcall again... but
> I know it is probably not important.. I am just an obsessed.

The higher-level and more flexible region-extract-function will handle
this for you in any case.

>>>         (region-string (and (= (count-lines region-beg region-end) 1)
>>>                             (buffer-substring-no-properties
>>>                              region-beg region-end)))
>>Why can't the region span multiple lines?  Better to use
>>region-extract-function for this, as it is more flexible.
> I don't thing that searching multiple lines will be very useful in
> practice and could potentially produce some corner cases. But I
> will think about that a bit more.

AFAIK, isearch is designed to work perfectly fine with multiple lines,
and I use this feature a lot, especially in the context of lax
whitespace matches in Info manuals, for example.

Providing a dedicated region isearch command which is limited to a
single line sounds hardly better than using isearch-yank-word-or-char or

>>>     (isearch-yank-string region-string)
>>>     (when-let (count (and arg (prefix-numeric-value arg)))
>>>       (isearch-repeat-forward count)))
>>This can be simplified as per Noam's suggestion.
> Yes, sorry, I was concerned if somehow the prefix could be non-nil, but
> (prefix-numeric-value arg) could return nil... I don't really know the
> fancy valued that prefix could potentially have. But probably there is
> not any danger there.

All potential prefix values are listed under (info "(elisp) Prefix
Command Arguments"), and prefix-numeric-value is guaranteed to return an



reply via email to

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