Re: isearch region or thing at point.

[Basil L. Contovounesios]

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
similar.

>>>     (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
integer.

Thanks,

-- 
Basil