Re: isearch region or thing at point.

["Basil L. Contovounesios" <contovob@tcd.ie>]

Ergus <spacibba@aol.com> writes:

> On Tue, Apr 30, 2019 at 11:39:11PM +0100, Basil L. Contovounesios wrote:
>>Ergus <spacibba@aol.com> 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