killing the result of isearch

killing the result of isearch

[Jean-Christophe Helary]

I must be missing something big...

I have an isearch that highlights a string, and I just want to delete that string.

In other editors I'd just hit delete on that selection, but that won't work in emacs...



Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

RE: killing the result of isearch

[Drew Adams]

> I must be missing something big...

No, you're not.

> I have an isearch that highlights a string, and I just 
> want to delete that string.
> 
> In other editors I'd just hit delete on that selection,
> but that won't work in emacs...

Not in vanilla Emacs, no; it won't work.

If you use Isearch+ then you can hit `C-M-RET' to delete the
search hit.  (The current search hit is not the "selection",
BTW, in the sense of being the Emacs region.)

[If you prefer that the key for this be, say, the `<delete>'
key, then just bind command `isearchp-act-on-demand' to
`(kbd "<delete>")' in `isearch-mode-map'.]

With Isearch+, `C-M-RET' performs an action on the current
search hit.  By default, the action is to replace it with
some replacement text.  And by default that replacement
text is empty (""), i.e., the search hit is deleted.

The value of option `isearchp-on-demand-action-function'
is the function that acts on the current search hit, which
it is passed when you hit `C-M-RET', along with the buffer
start and end positions of the search hit.

After applying the action, search moves to the next hit in
the same search direction, so just repeating `C-M-RET'
carries out the action on subsequent hits.

With a prefix argument, `C-M-RET'  prompts for the
replacement text, which is used thereafter until you again
use a prefix arg.  (Again, no prefix arg means empty
replacement text, i.e., deletion.)

Since you can use a prefix arg at any time, you can
provide different replacements for different search hits
corresponding to the same search pattern.

[To use a prefix arg within Isearch, you must set
`isearch-allow-prefix' to non-`nil'.]

There's more you can do with it.  See here:

https://www.emacswiki.org/emacs/IsearchPlus#isearchp-act-on-demand

Re: killing the result of isearch

[Jean-Christophe Helary]

> On Nov 7, 2017, at 14:34, Drew Adams <drew.adams@oracle.com> wrote:
> 
>> I must be missing something big...
> 
> No, you're not.

I'm not sure that makes me feel better... But that you very much for the thorough reply.

>> I have an isearch that highlights a string, and I just want to delete that string.
>> 
>> In other editors I'd just hit delete on that selection, but that won't work in emacs...
> 
> Not in vanilla Emacs, no; it won't work.

> If you use Isearch+

Is there a way to emulate that in vanilla emacs?
Well, I guess yes, by creating the adequate function, etc.

But, isn't it something emacs users do normally? Search for a string and just delete it? Doesn't it look like a function that could be useful in vanilla emacs?

Jean-Christophe 

> then you can hit `C-M-RET' to delete the
> search hit.  (The current search hit is not the "selection",
> BTW, in the sense of being the Emacs region.)
> 
> [If you prefer that the key for this be, say, the `<delete>'
> key, then just bind command `isearchp-act-on-demand' to
> `(kbd "<delete>")' in `isearch-mode-map'.]
> 
> With Isearch+, `C-M-RET' performs an action on the current
> search hit.  By default, the action is to replace it with
> some replacement text.  And by default that replacement
> text is empty (""), i.e., the search hit is deleted.
> 
> The value of option `isearchp-on-demand-action-function'
> is the function that acts on the current search hit, which
> it is passed when you hit `C-M-RET', along with the buffer
> start and end positions of the search hit.
> 
> After applying the action, search moves to the next hit in
> the same search direction, so just repeating `C-M-RET'
> carries out the action on subsequent hits.
> 
> With a prefix argument, `C-M-RET'  prompts for the
> replacement text, which is used thereafter until you again
> use a prefix arg.  (Again, no prefix arg means empty
> replacement text, i.e., deletion.)
> 
> Since you can use a prefix arg at any time, you can
> provide different replacements for different search hits
> corresponding to the same search pattern.
> 
> [To use a prefix arg within Isearch, you must set
> `isearch-allow-prefix' to non-`nil'.]
> 
> There's more you can do with it.  See here:
> 
> https://www.emacswiki.org/emacs/IsearchPlus#isearchp-act-on-demand
> 

Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Søren Pilgård]

On Nov 7, 2017 7:04 AM, "Jean-Christophe Helary" <
jean.christophe.helary@gmail.com> wrote:



> On Nov 7, 2017, at 14:34, Drew Adams <drew.adams@oracle.com> wrote:
>
>> I must be missing something big...
>
> No, you're not.

I'm not sure that makes me feel better... But that you very much for the
thorough reply.

>> I have an isearch that highlights a string, and I just want to delete
that string.
>>
>> In other editors I'd just hit delete on that selection, but that won't
work in emacs...
>
> Not in vanilla Emacs, no; it won't work.

> If you use Isearch+

Is there a way to emulate that in vanilla emacs?
Well, I guess yes, by creating the adequate function, etc.

But, isn't it something emacs users do normally? Search for a string and
just delete it? Doesn't it look like a function that could be useful in
vanilla emacs?

Jean-Christophe

> then you can hit `C-M-RET' to delete the
> search hit.  (The current search hit is not the "selection",
> BTW, in the sense of being the Emacs region.)
>
> [If you prefer that the key for this be, say, the `<delete>'
> key, then just bind command `isearchp-act-on-demand' to
> `(kbd "<delete>")' in `isearch-mode-map'.]
>
> With Isearch+, `C-M-RET' performs an action on the current
> search hit.  By default, the action is to replace it with
> some replacement text.  And by default that replacement
> text is empty (""), i.e., the search hit is deleted.
>
> The value of option `isearchp-on-demand-action-function'
> is the function that acts on the current search hit, which
> it is passed when you hit `C-M-RET', along with the buffer
> start and end positions of the search hit.
>
> After applying the action, search moves to the next hit in
> the same search direction, so just repeating `C-M-RET'
> carries out the action on subsequent hits.
>
> With a prefix argument, `C-M-RET'  prompts for the
> replacement text, which is used thereafter until you again
> use a prefix arg.  (Again, no prefix arg means empty
> replacement text, i.e., deletion.)
>
> Since you can use a prefix arg at any time, you can
> provide different replacements for different search hits
> corresponding to the same search pattern.
>
> [To use a prefix arg within Isearch, you must set
> `isearch-allow-prefix' to non-`nil'.]
>
> There's more you can do with it.  See here:
>
> https://www.emacswiki.org/emacs/IsearchPlus#isearchp-act-on-demand
>

Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com


You could just use the query-replace functionality with an empty string.

Re: killing the result of isearch

[Loris Bennett]

Søren Pilgård <fiskomaten@gmail.com> writes:

> On Nov 7, 2017 7:04 AM, "Jean-Christophe Helary" <
> jean.christophe.helary@gmail.com> wrote:
>
>
>
>> On Nov 7, 2017, at 14:34, Drew Adams <drew.adams@oracle.com> wrote:
>>
>>> I must be missing something big...
>>
>> No, you're not.
>
> I'm not sure that makes me feel better... But that you very much for the
> thorough reply.
>
>>> I have an isearch that highlights a string, and I just want to delete
> that string.
>>>
>>> In other editors I'd just hit delete on that selection, but that won't
> work in emacs...
>>
>> Not in vanilla Emacs, no; it won't work.
>
>> If you use Isearch+
>
> Is there a way to emulate that in vanilla emacs?
> Well, I guess yes, by creating the adequate function, etc.
>
> But, isn't it something emacs users do normally? Search for a string and
> just delete it? Doesn't it look like a function that could be useful in
> vanilla emacs?

I can sort of imagine that such a function might be useful, but in
several decades of using Emacs, both writing code and prose, I've
honestly never missed it.  What is your use case?  The closest I come is
search and replace, so you could just replace with an empty string.
However, searching and then doing 'C-backspace' deletes the word found
on my system.

Cheers,

Loris

> Jean-Christophe
>
>> then you can hit `C-M-RET' to delete the
>> search hit.  (The current search hit is not the "selection",
>> BTW, in the sense of being the Emacs region.)
>>
>> [If you prefer that the key for this be, say, the `<delete>'
>> key, then just bind command `isearchp-act-on-demand' to
>> `(kbd "<delete>")' in `isearch-mode-map'.]
>>
>> With Isearch+, `C-M-RET' performs an action on the current
>> search hit.  By default, the action is to replace it with
>> some replacement text.  And by default that replacement
>> text is empty (""), i.e., the search hit is deleted.
>>
>> The value of option `isearchp-on-demand-action-function'
>> is the function that acts on the current search hit, which
>> it is passed when you hit `C-M-RET', along with the buffer
>> start and end positions of the search hit.
>>
>> After applying the action, search moves to the next hit in
>> the same search direction, so just repeating `C-M-RET'
>> carries out the action on subsequent hits.
>>
>> With a prefix argument, `C-M-RET'  prompts for the
>> replacement text, which is used thereafter until you again
>> use a prefix arg.  (Again, no prefix arg means empty
>> replacement text, i.e., deletion.)
>>
>> Since you can use a prefix arg at any time, you can
>> provide different replacements for different search hits
>> corresponding to the same search pattern.
>>
>> [To use a prefix arg within Isearch, you must set
>> `isearch-allow-prefix' to non-`nil'.]
>>
>> There's more you can do with it.  See here:
>>
>> https://www.emacswiki.org/emacs/IsearchPlus#isearchp-act-on-demand
>>
>
> Jean-Christophe Helary
> -----------------------------------------------
> @brandelune http://mac4translators.blogspot.com
>
>
> You could just use the query-replace functionality with an empty string.

-- 
Dr. Loris Bennett (Mr.)
ZEDAT, Freie Universität Berlin         Email loris.bennett@fu-berlin.de

Re: killing the result of isearch

[Jean-Christophe Helary]

> On Nov 7, 2017, at 16:07, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
> 
> I can sort of imagine that such a function might be useful, but in several decades of using Emacs, both writing code and prose, I've honestly never missed it.  What is your use case?

Acting on the matching string. Yank, kill, overwrite. Things that you can do in other editors where the result of a search is a selection.

> The closest I come is search and replace, so you could just replace with an empty string.

isearch
isearch-query-replace
C-w


> However, searching and then doing 'C-backspace' deletes the word found on my system.

Thank you, I guess that's what I was looking for.

It's confusing to have "delete" act where point is *not* (ie in the mini buffer).


Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Marcin Borkowski]

On 2017-11-07, at 07:01, Jean-Christophe Helary <jean.christophe.helary@gmail.com> wrote:

> But, isn't it something emacs users do normally? Search for a string and just delete it? Doesn't it look like a function that could be useful in vanilla emacs?

How about this?

C-s whatever M-% RET .

Explanation: when in isearch, typing M-% starts query-replace
prepopulated with isearched string.  RET makes the replacement empty.
`.' (period) performs a replacements and exits query-replace.

Hth,

--
Marcin Borkowski

Re: killing the result of isearch

[Jean-Christophe Helary]

> On Nov 7, 2017, at 16:07, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
> 
> However, searching and then doing 'C-backspace' deletes the word found

But it does not delete any arbitrary string matching the search. It just happens to look like it works because the point is at the end of the matching string and what you searched was a word.

If I search for
="2" 
C-backspace will only delete the last 2 characters.

So I'm back to the beginning.


Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Loris Bennett]

Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:

>> On Nov 7, 2017, at 16:07, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
>> 
>> However, searching and then doing 'C-backspace' deletes the word found
>
> But it does not delete any arbitrary string matching the search. It
> just happens to look like it works because the point is at the end of
> the matching string and what you searched was a word.
>
> If I search for
> ="2" 
> C-backspace will only delete the last 2 characters.
>
> So I'm back to the beginning.

So doesn't searching-and-replace with an empty replacement work?

In any case, as Drew pointed out, I think your expectation of how Emacs
regions behaves is not justified.  If you start marking part of a word
with C-<space>, you also can't just overwrite it.

As to Emacs behaving differently to other editors, I think it is the
other way round ;-)

Cheers,

Loris

-- 
Dr. Loris Bennett (Mr.)
ZEDAT, Freie Universität Berlin         Email loris.bennett@fu-berlin.de

Re: killing the result of isearch

[Jean-Christophe Helary]

> On Nov 7, 2017, at 19:49, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
> 
> 
> So doesn't searching-and-replace with an empty replacement work?

It works to accomplish the same result but it takes many more step as I wrote earlier:

isearch string
isearch-query-replace
(replace with nothing)

> As to Emacs behaving differently to other editors, I think it is the
> other way round ;-)

No, actually it really is the other way round. Emacs is not a text editor, it is a Lisp virtual machine with text editing functions. Applications that are created to be specialized in text editing are closer to what the users need in terms of interaction. Which is the point of the current discussion.

The problem with emacs and searches, is that you only search, you don't *find*, as in the action of searching does not result in an object that you can act upon. Which defeats the purpose of searching.

A simple "search" does nothing but put the point at the end of the match. it is nice to navigate the document but it does nothing about the match. isearch is even more treacherous since it makes it look like you are finding something, when actually you have also just moved the point in the buffer and nothing more.

A simple "search" should at least be able to create a region on the match, it doesn't even do that.



Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Loris Bennett]

Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:

>> On Nov 7, 2017, at 19:49, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
>> 
>> 
>> So doesn't searching-and-replace with an empty replacement work?
>
> It works to accomplish the same result but it takes many more step as I wrote
> earlier:
>
> isearch string isearch-query-replace (replace with nothing)
>
>> As to Emacs behaving differently to other editors, I think it is the other way
>> round ;-)
>
> No, actually it really is the other way round. Emacs is not a text editor, it is
> a Lisp virtual machine with text editing functions.

According to https://www.gnu.org/software/emacs/ GNU Emacs is:

  An extensible, customizable, free/libre text editor — and more.

> Applications that are created to be specialized in text editing are
> closer to what the users need in terms of interaction. Which is the
> point of the current discussion.

My point was that you are comparing the editing idiom of Emacs, which
arose in the 1980s, with that of more modern editors.  In addition, you
are talking about what you need, rather than what "users" need.

> The problem with emacs and searches, is that you only search, you don't *find*,
> as in the action of searching does not result in an object that you can act
> upon. Which defeats the purpose of searching.
>
> A simple "search" does nothing but put the point at the end of the match. it is
> nice to navigate the document but it does nothing about the match. isearch is
> even more treacherous since it makes it look like you are finding something,
> when actually you have also just moved the point in the buffer and nothing more.
>
> A simple "search" should at least be able to create a region on the match, it
> doesn't even do that.

If Emacs doesn't do something, to me, that suggests it is not a very
common thing to do.  However, fortunately Emacs is extensible and
customizable and so you can make it do less common things too.

Cheers,

Loris

-- 
Dr. Loris Bennett (Mr.)
ZEDAT, Freie Universität Berlin         Email loris.bennett@fu-berlin.de

RE: killing the result of isearch

[Drew Adams]

> > If you use Isearch+
> 
> Is there a way to emulate that in vanilla emacs?
> Well, I guess yes, by creating the adequate function, etc.

Isearch+ is defined using vanilla Emacs. ;-)

And yes, any or all of it could be added to Emacs, if
someone were interested.  Or you can just use it as is.
Why not?  It's not a big deal to load a Lisp file.

> But, isn't it something emacs users do normally? Search for a string and
> just delete it? Doesn't it look like a function that could be useful in
> vanilla emacs?

Some Emacs users long ago suggested that setting the
region around the final search target (the last search
hit you visit) can be useful - including for killing it.
I added that feature to Isearch+ in 2006.

It was later (2013, I think) that I added the ability to
act arbitrarily on any number of search hits, selectively
(on demand) during (not after) Isearch.

RE: killing the result of isearch

[Drew Adams]

> > So doesn't searching-and-replace with an empty replacement work?
> 
> It works to accomplish the same result but it takes many more step as I
> wrote earlier:
> 
> isearch string
> isearch-query-replace
> (replace with nothing)
...
> The problem with emacs and searches, is that you only search, you don't
> *find*, as in the action of searching does not result in an object that you
> can act upon. Which defeats the purpose of searching.

It does result in an object you can act upon, if you want
that.  Isearch+ gives you that possibility, including the
possibility of setting the region on that object.

> A simple "search" does nothing but put the point at the end of the match.
> it is nice to navigate the document but it does nothing about the match.
> isearch is even more treacherous since it makes it look like you are
> finding something, when actually you have also just moved the point in the
> buffer and nothing more.
> 
> A simple "search" should at least be able to create a region on the match,
> it doesn't even do that.

Have you actually tried Isearch+?  As I mentioned, I think
it offers what you're requesting.

As for those who propose query-replace as a substitute for
acting on search hits during Isearch:

* q-r is OK for replacing, but that's the only action it knows

* q-r is one-directional, and not embedded in Isearch: The
  search pattern and replacement patterns are fixed, once
  and for all.

The search-hit replacement (or other action) provided by
Isearch+ is on-demand, and you can change what it acts
on (search pattern, hence search hits) and the replacement
text at any time.

Q-r is nice, and it's good you can invoke it from Isearch,
but it is not the same thing as on-demand replacement
during search.

Re: killing the result of isearch

[Jean-Christophe Helary]

> On Nov 8, 2017, at 0:08, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
> 
>> Emacs is not a text editor, it is
>> a Lisp virtual machine with text editing functions.
> 
> According to https://www.gnu.org/software/emacs/ GNU Emacs is:
>  An extensible, customizable, free/libre text editor — and more.

Obviously. Who wants a Lisp virtual machine nowadays.

> My point was that you are comparing the editing idiom of Emacs, which
> arose in the 1980s, with that of more modern editors.  In addition, you
> are talking about what you need, rather than what "users" need.

No, I am actually talking about expectations from using emacs where regions are highlighted, like what isearch seems like doing. What I am seeing is what looks like a region (and except for the active match, all the others are highlighted exactly as a region would be), but it doesn't act like a region. So there is a UI promise that's broken.


Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Jean-Christophe Helary]

> On Nov 8, 2017, at 0:26, Drew Adams <drew.adams@oracle.com> wrote:
> 
>>> So doesn't searching-and-replace with an empty replacement work?
>> 
>> It works to accomplish the same result but it takes many more step as I
>> wrote earlier:
>> 
>> isearch string
>> isearch-query-replace
>> (replace with nothing)
> ...
>> The problem with emacs and searches, is that you only search, you don't
>> *find*, as in the action of searching does not result in an object that you
>> can act upon. Which defeats the purpose of searching.
> 
> It does result in an object you can act upon, if you want
> that.

Would you mind being more specific ?

I have no problem using new libraries, but I want to understand why I am missing what I think I am missing. If I understood searches (isearches ?) better, maybe I would not have my questions.

> Q-r is nice, and it's good you can invoke it from Isearch,
> but it is not the same thing as on-demand replacement
> during search.

Exactly.

Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

RE: killing the result of isearch

[Drew Adams]

> Who wants a Lisp virtual machine nowadays.

I do.  What better plaything is there?

> I am actually talking about expectations from using emacs where regions
> are highlighted, like what isearch seems like doing. What I am seeing is
> what looks like a region (and except for the active match, all the others
> are highlighted exactly as a region would be), but it doesn't act like a
> region. So there is a UI promise that's broken.

That's not what I see in vanilla Emacs: `emacs -Q'.

I had to check, because I don't generally use `emacs -Q'.
I was half expecting you might be right, in which case I
would have suggested that you use `M-x report-emacs-bug' to
request that different faces be used for Isearch and for
the region.  But I see that that is already the case, as it
should be

You must be using some customization (perhaps from a
library you use), which gives face `lazy-highlight' and
face `region' the same appearance.  Their appearance is
quite different in virginal Emacs.

RE: killing the result of isearch

[Drew Adams]

> > It does result in an object you can act upon, if you want
> > that.
> 
> Would you mind being more specific ?

The code finds a match (over and over: successive matches).
Code (hence you) can act on the current match.  Or code/you
can act on only the last match that you visit.

Everything you need to code the feature you ask for is in the
Isearch source code.  If you don't want to dig into that code
yourself, you're lucky: Isearch+ already provides what you need:

1. A variable whose value can be any function you want,
   tailor-made to act on any current match when you hit a key.

   Write any number of commands, which bind that variable
   to different action functions.  Bind those commands to
   keys in `isearch-mode-map'.  Now you have N keys you can
   hit to perform N different actions on a search hit.
   Pretty good, no?

2. As for acting on the last-visited match, after searching:
   Isearch+ lets you automatically, or on-demand, select it
   as the active region.  You can then use any Emacs command
   that acts on the active region to act on it.  And you can
   define your own such commands, to act on it any way you like.

Be aware too that after you exit Isearch, you can always use
the many Emacs commands that act on text before point or that
move point backward.  There is a lot you can do to the text
before point, even without selecting the part that matches
your last search.  Emacs has commands for moving among and
killing sexps, for example.

> I have no problem using new libraries, but I want to understand why I am
> missing what I think I am missing. If I understood searches (isearches ?)
> better, maybe I would not have my questions.

You are missing what you think you are missing from vanilla
Emacs.  Why?  Because either (1) no one has considered them
important/useful enough to add or (2) no one has volunteered
to work on implementing them.

Emacs is developed by volunteers.  Features are added to it
when its core developers decide to do so.  There are tons
of wonderful Emacs features that have not been incorporated
into vanilla Emacs.  Sometimes that's good; sometimes it's
not so good.  What gets done in vanilla Emacs is a function
of those who contribute directly to its development.  They
do what they want (think is best), naturally.

I think that lots of features that Isearch+ provides, perhaps
all, would make sense in vanilla Emacs.  I've volunteered them.
But it's not for me to decide.

In any case, you can use them now - easily.  You don't need
them to be added to vanilla Emacs to take advantage of them.

Above is just my answer to your "Why not?" question.  What
you're looking for is not part of Emacs by default because
those who maintain Emacs haven't added it - nothing more.
That doesn't mean you're not understanding something, and
it doesn't imply that they're not understanding something.
People are different.

> > Q-r is nice, and it's good you can invoke it from Isearch,
> > but it is not the same thing as on-demand replacement
> > during search.
> 
> Exactly.

Re: killing the result of isearch

[Eric Abrahamsen]

Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:

>> On Nov 8, 2017, at 0:26, Drew Adams <drew.adams@oracle.com> wrote:
>> 
>>>> So doesn't searching-and-replace with an empty replacement work?
>>> 
>>> It works to accomplish the same result but it takes many more step as I
>>> wrote earlier:
>>> 
>>> isearch string
>>> isearch-query-replace
>>> (replace with nothing)
>> ...
>>> The problem with emacs and searches, is that you only search, you don't
>>> *find*, as in the action of searching does not result in an object that you
>>> can act upon. Which defeats the purpose of searching.
>> 
>> It does result in an object you can act upon, if you want
>> that.
>
> Would you mind being more specific ?
>
> I have no problem using new libraries, but I want to understand why I
> am missing what I think I am missing. If I understood searches
> (isearches ?) better, maybe I would not have my questions.
>
>> Q-r is nice, and it's good you can invoke it from Isearch,
>> but it is not the same thing as on-demand replacement
>> during search.
>
> Exactly.

Several years ago, when I wanted to do this, I wrote the following:

(define-key isearch-mode-map (kbd "M-m") 'my-isearch-mark-search-as-region)
(defun my-isearch-mark-search-as-region ()
  (interactive)
  (if (not isearch-mode)
      (message "This is only useful during isearch")
    (isearch-exit)
    (push-mark isearch-other-end)
    (activate-mark)))

I guess that's just a tiny half-step in the direction that isearch+ is
headed.

Another very good facility to get comfortable with is recursive editing:
type "C-r" during search mode, do whatever editing you like, then
"C-M-c" to go back into search mode.

I think what people are trying to say is that Emacs' defaults can often
seem lacking, but it makes up for it by giving you enormous power to
create your ideal behavior yourself. I think this is probably born of
decades of strong personalities, wildly varying "ideal behavior", and a
distaste for bikeshedding. I think we all expect that we need to go the
last half-mile ourselves.

Eric

RE: killing the result of isearch

[Drew Adams]

> Several years ago, when I wanted to do this, I wrote the following:
> 
> (define-key isearch-mode-map (kbd "M-m") 'my-isearch-mark-search-as-region)
> (defun my-isearch-mark-search-as-region ()
>   (interactive)
>   (if (not isearch-mode)
>       (message "This is only useful during isearch")
>     (isearch-exit)
>     (push-mark isearch-other-end)
>     (activate-mark)))

That's essentially the same thing used in Isearch+:

(defun isearchp-set-region-around-search-target ()
  "Set the region around the last search or query-replace target."
  (interactive)
  (case last-command
    ((isearch-forward isearch-backward
      isearch-forward-regexp isearch-backward-regexp)
     (push-mark isearch-other-end t 'activate))
    (t (push-mark (match-beginning 0) t 'activate)))
  (setq deactivate-mark  nil))

> I guess that's just a tiny half-step in the direction that isearch+ is
> headed.

Isearch+ isn't really headed anywhere. ;-)  I just add/change things as
they come to me.

> Another very good facility to get comfortable with is recursive editing:
> type "C-r" during search mode, do whatever editing you like, then
> "C-M-c" to go back into search mode.

+1

But that's not in vanilla Emacs, AFAIK.  (It's certainly not
bound to `C-r' by default - `C-r' is ` isearch-repeat-backward'.)

With Isearch+, `C-x o' during Isearch opens a recursive edit.
And `C-M-c' (`exit-recursive-edit') resumes searching.

> I think what people are trying to say is that Emacs' defaults can often
> seem lacking, but it makes up for it by giving you enormous power to
> create your ideal behavior yourself...  I think we all expect that we
> need to go the last half-mile ourselves.

+1

But sometimes it's not so much that we need to go the last
half mile ourselves.  Sometimes it's more that we want to
go the next N miles, for fun and learning.

Re: killing the result of isearch

[Eric Abrahamsen]

Drew Adams <drew.adams@oracle.com> writes:

>> Several years ago, when I wanted to do this, I wrote the following:
>> 
>> (define-key isearch-mode-map (kbd "M-m") 'my-isearch-mark-search-as-region)
>> (defun my-isearch-mark-search-as-region ()
>>   (interactive)
>>   (if (not isearch-mode)
>>       (message "This is only useful during isearch")
>>     (isearch-exit)
>>     (push-mark isearch-other-end)
>>     (activate-mark)))
>
> That's essentially the same thing used in Isearch+:
>
> (defun isearchp-set-region-around-search-target ()
>   "Set the region around the last search or query-replace target."
>   (interactive)
>   (case last-command
>     ((isearch-forward isearch-backward
>       isearch-forward-regexp isearch-backward-regexp)
>      (push-mark isearch-other-end t 'activate))
>     (t (push-mark (match-beginning 0) t 'activate)))
>   (setq deactivate-mark  nil))

Ah, I hadn't noticed the extra arguments to `push-mark', thanks. Anyway,
OP should be happy with `isearch-other-end'.

>> I guess that's just a tiny half-step in the direction that isearch+ is
>> headed.
>
> Isearch+ isn't really headed anywhere. ;-)  I just add/change things as
> they come to me.
>
>> Another very good facility to get comfortable with is recursive editing:
>> type "C-r" during search mode, do whatever editing you like, then
>> "C-M-c" to go back into search mode.
>
> +1
>
> But that's not in vanilla Emacs, AFAIK.  (It's certainly not
> bound to `C-r' by default - `C-r' is ` isearch-repeat-backward'.)
>
> With Isearch+, `C-x o' during Isearch opens a recursive edit.
> And `C-M-c' (`exit-recursive-edit') resumes searching.

Oops, that binding is for query-replace, not search. Another good
argument for simply starting out in (or switching to) query-replace.

>> I think what people are trying to say is that Emacs' defaults can often
>> seem lacking, but it makes up for it by giving you enormous power to
>> create your ideal behavior yourself...  I think we all expect that we
>> need to go the last half-mile ourselves.
>
> +1
>
> But sometimes it's not so much that we need to go the last
> half mile ourselves.  Sometimes it's more that we want to
> go the next N miles, for fun and learning.

Most definitely!

Re: killing the result of isearch

[Stefan Monnier]

> I must be missing something big...
> I have an isearch that highlights a string, and I just want to delete
> that string.

> In other editors I'd just hit delete on that selection, but that won't
> work in Emacs...

It should be fairly easy to get what you want.
You could start with

    (defun sm-isearch-done ()
      ;; Activate the region corresponding to the found string.
      (unless (or isearch-mode-end-hook-quit ;; Leaving with C-g!
                  mark-active)               ;; Already selecting a region!
        (push-mark isearch-other-end nil t)
        (when (eq transient-mark-mode t)
          ;; Mark the selected region in the same way as is done by S-right,
          ;; so that subsequent navigation commands automatically deactivate
          ;; the region.
          (push 'only transient-mark-mode))))
    (add-hook 'isearch-mode-end-hook #'sm-isearch-done)

so you can do `C-s foo <delete>` and it will delete the found `foo`.
You can also do `C-s foo RET DEL` to get the same result.
And if you use `delete-selection-mode`, then `C-s foo RET b` will
replace `foo` with `b'.

Many Emacs users rely on isearch for navigation, in which case the above
could prove annoying.  Also, currently isearch pushes a mark at the
position where you started the search, so you can do

     C-s foo RET C-w

to delete the text between point and the first occurrence of `foo`.
The above will break such usage (as well as various others).

Maybe something like the above code could be added to isearch.el but
I think it'll have to be made conditional on a config var, so users
can elect to use this behavior or not (since old-timers used to the
details of the current behavior will probably want to keep using that).

Feel free to use this code snippet in a feature request (via M-x
report-emacs-bug).


        Stefan

Re: killing the result of isearch

[Bob Proulx]

Jean-Christophe Helary wrote:
> I have an isearch that highlights a string, and I just want to delete
> that string.
...
> But, isn't it something emacs users do normally? Search for a string
> and just delete it? Doesn't it look like a function that could be
> useful in vanilla emacs?

I have been using emacs for a very long time and that isn't a feature
I have ever missed.  However I will say that language shapes the way
you think.  If the language you use does or does not have a construct
then it shapes the way one thinks about it.  Emacs doesn't
intrinsically have that feature but has other features and therefore I
think and use those other features.

The answers suggesting M-% are excellent suggestions.  I think they
are the best suggestions.  But exploring other options are good for
learning how to do things in emacs too.  That is what I want to do at
this moment.

Here you see that in the default emacs configuration the search string
is highlighted (in what looks like purple on my testing, I will call
it purple) in the search face.  (Your colors may be different.)  But
the highlighted region face is what looks like brown to me.  Brown
hightlight means a region and pressing DEL (Backspace) would delete
it.  Purple is the search string.  They are different.

In fact if you have a text like this with the point at the 'N' in the
word "Now".

  Now is the time for all good men to come to the aid of their party.

And then type in "C-s party" it will set the mark at the 'N' and then
move the point to the '.' immedately after "party".  The "party" will
be highlighted in purple.  If you terminate the search then and there
with RET then the point is at the '.' and the mark is at the 'N' and
the region is not active.  The region is always the text between the
point and the mark.  You can use C-x C-x to exchange-point-and-mark to
show the region.  Doing that will activate the region.  At that time
you will see that the region covers the entire text fron 'N' to the
'y' of "party".  (But not the '.' after party since that wasn't between
mark and point.)

The typical deletions (killing text in emacs speak) act upon either
single characters or the region.  The region between the point and the
mark.  In order to make the search string a region one wants to make
the point and mark to be placed surrounding the text to be deleted.
How would someone do that.  How would *I* do that.  I would do it like
this.

I would "C-s party" to move point to the end of party.  Seeing that it
is a single word I would simply use M-DEL backward-kill-word to delete
the word behind.  It will terminate the search and then delete the
word behind.  Voilà!  The task is done exactly as you wish.

But then one might ask, "What about strings that are more than one
word?"  In that case I would do tihs.  I would "C-s party" to move
point to the end of party.  Knowing that mark was left at the previous
location of the point I would then use C-r to reverse search the same
string.  That will move the point to the start of the search string.
The point would be at the 'p' in "party".  I would press RET to
terminate the search.  The mark is still far away at the previous
location of the point.

But the search has been saved.  I would then press C-s C-s twice.
Once to start a new search and again a second time for
isearch-repeat-forward to recall the previous search.  That will move
the point to the end of the search string and will set a new mark at
the previous location at the start of the search string.  At that
point the point and mark are around the text to be deleted.  Then I
will use C-x C-x to exchange-point-and-mark and to activate the region
showing it.  Then C-w to kill-region it.  (Killing text puts it into
the kill ring.)

  Let's change "One-two, Buckle my shoe" to something else.

  C-s one-two, buckle my shoe C-r RET C-s C-s RET C-x C-x C-w

It's more keys than M-% but the above are all mainstream keys that an
emacs user would press a zillion times a day.  I don't even think
about them.  They just happen reflexively.  And at each step along the
way I have positive feedback from the editor telling me what is
highlighted, what is happening, and what will be deleted when I delete
it.  No stress editing.

Personally I never use the highlighted region.  Using C-x C-x to
exchange-point-and-mark is perfect for me to know what is the region
that will be deleted.  This means that instead of using DEL to delete
a highlighted region that I will use C-w to kill-region instead.  Shrug.

Personally I always bind C-s to isearch-forward-regexp instead of
leaving it at isearch-forward.  Regular expressions are so much more
powerful and useful.  "C-s one.*shoe" matches the entire string I want
to change with much fewer characters.  Learning regular expressions
makes for powerful editing capability.

Again using M-% seems perfect here but hopefully at least some of you
enjoyed seeing the thought process another person might use to perform
this task using the mainstream commands.

Bob

RE: killing the result of isearch

[Drew Adams]

>   Let's change "One-two, Buckle my shoe" to something else.
>   C-s one-two, buckle my shoe C-r RET C-s C-s RET C-x C-x C-w

(You don't need the `C-x C-x' here, unless you want to
see highlighted what `C-w' will delete.)

> Personally I always bind C-s to isearch-forward-regexp instead of
> leaving it at isearch-forward.  Regular expressions are so much more
> powerful and useful.

OK, but what you show above does not work, in general,
for regexps.  Regexp search forward and backward do not
find the same text, generally.

If you regexp-search for the same text, `one-two,
buckle my shoe', no problem.  But if you use `o.*oe'
you'll be in trouble.

Re: killing the result of isearch

[Jean-Christophe Helary]

> On Nov 8, 2017, at 1:24, Drew Adams <drew.adams@oracle.com> wrote:
> 
>> Who wants a Lisp virtual machine nowadays.
> 
> I do.  What better plaything is there?

:-) I was just pointing at the fact that saying Emacs is a text editor is merely marketing...

>> I am actually talking about expectations from using emacs where regions
>> are highlighted, like what isearch seems like doing. What I am seeing is
>> what looks like a region (and except for the active match, all the others
>> are highlighted exactly as a region would be), but it doesn't act like a
>> region. So there is a UI promise that's broken.
> 
> That's not what I see in vanilla Emacs: `emacs -Q'.

Interesting. When I do that on one of my local files (with an emacs I built a few days ago) I do get the current match highlighted in purple and the other matches highlighted in blue (after testing a region is highlighted in a slightly different color). The cursor is blinking at the end of the first match.

So it looks as I wrote: this looks like a region, with a cursor blinking where point it, but it does not act as one.

What matters here is not the color, but the fact that point has moved and something that looks like a region is formed. Hence the expectation. And really, if that "object" exists on screen, I'd love to be able to capture it somehow.

Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Jean-Christophe Helary]

> On Nov 8, 2017, at 1:46, Drew Adams <drew.adams@oracle.com> wrote:
> 
>>> It does result in an object you can act upon, if you want
>>> that.
>> 
>> Would you mind being more specific ?
> 
> The code finds a match (over and over: successive matches).
> Code (hence you) can act on the current match.  Or code/you
> can act on only the last match that you visit.
> 
> Everything you need to code the feature you ask for is in the
> Isearch source code.  If you don't want to dig into that code
> yourself, you're lucky: Isearch+ already provides what you need:

Thank you. I'll dig into the code because I'd like to understand.

>> I have no problem using new libraries, but I want to understand why I am
>> missing what I think I am missing. If I understood searches (isearches ?)
>> better, maybe I would not have my questions.
> 
> You are missing what you think you are missing from vanilla
> Emacs.  Why?  Because either (1) no one has considered them
> important/useful enough to add or (2) no one has volunteered
> to work on implementing them.

I was not thinking of *that* missing :) I understand what emacs is. I meant missing as  failing to understand the design/feature.


Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Bob Proulx]

Drew Adams wrote:
> >   Let's change "One-two, Buckle my shoe" to something else.
> >   C-s one-two, buckle my shoe C-r RET C-s C-s RET C-x C-x C-w
> 
> (You don't need the `C-x C-x' here, unless you want to
> see highlighted what `C-w' will delete.)

True.  But I always like the positive feedback about the region that
will be deleted.  So I am almost always using C-x C-x prior to region
commands.

Plus I was originally thinking of using DEL there and that needs the
highlight to be active.  In that case I needed C-x C-x to highlight
the region so that DEL would delete it.

> > Personally I always bind C-s to isearch-forward-regexp instead of
> > leaving it at isearch-forward.  Regular expressions are so much more
> > powerful and useful.
> 
> OK, but what you show above does not work, in general,
> for regexps.  Regexp search forward and backward do not
> find the same text, generally.

In the completely general case, true.  But most of the time they will
work fine.

  One:  One, two, buckle shoe.

  C-s one.*shoe

That will obviously match all of the way back to the "One:" part,
undesirably, when search forward.  But that doesn't invalidate the
technique all of the time.  I certainly wouldn't give up on regular
expressions simply because not every regular expression can be used in
every case.  And in the above if you try it forward with C-s and see
that it matches too much and then reverse direction with C-r one
finds that it matched exactly what was desired with non-greedy
matching.  (I haven't ever dug into figuring out why.)  But all along
the way there is feedback as to what is happening.  It isn't going to
silently do something scary.  I wouldn't avoid it.  Because that would
mean missing out on all of the capabilities of regular expressions.

> If you regexp-search for the same text, `one-two,
> buckle my shoe', no problem.  But if you use `o.*oe'
> you'll be in trouble.

Using "o" trying to match for "one" and "oe" trying to match for
"shoe" doesn't feel solid enough for me.  Matching only one and two
letters feels like it is asking to match something unexpected.  I
suggest putting enough text in there to anchor it firmly.  Remembering
that all of this is interacive editing, if it isn't doing what you
want then take corrective action and be more explicit by adding more
anchoring text.

When I took my CS200 intro to programming class at university some
time ago the first couple of weeks of the class was teaching us how to
use the text editor.  (What?  No programming?  No, learn to edit files
first!  I think today they expect students to already know how to edit
files, yet from what I can see most students could use a class on it.)
And they started us off right at the beginning editing with regular
expressions.  Literally we had to learn REs before even starting to
work on the programming assignments.  The department expected us to be
proficient editing text!  Looking back on it I am glad they did.  It
has been very useful to me.

Bob

RE: killing the result of isearch

[Drew Adams]

> >> I am actually talking about expectations from using emacs where regions
> >> are highlighted, like what isearch seems like doing. What I am seeing is
> >> what looks like a region (and except for the active match, all the
> others
> >> are highlighted exactly as a region would be), but it doesn't act like a
> >> region. So there is a UI promise that's broken.
> >
> > That's not what I see in vanilla Emacs: `emacs -Q'.
> 
> Interesting. When I do that on one of my local files (with an emacs I built
> a few days ago) I do get the current match highlighted in purple and the
> other matches highlighted in blue (after testing a region is highlighted in
> a slightly different color). The cursor is blinking at the end of the first
> match.
> 
> So it looks as I wrote: this looks like a region, with a cursor blinking
> where point it, but it does not act as one.
> 
> What matters here is not the color, but the fact that point has moved and
> something that looks like a region is formed. Hence the expectation. And
> really, if that "object" exists on screen, I'd love to be able to capture
> it somehow.

OK, so you feel that any highlighting that shows a different
background from the default background, and where the cursor
is at one end of a stretch of such highlighting, "looks like
a region".  To you it looks as if that text has been selected,
available to act on (e.g. cut, copy, replace).

Emacs uses background highlighting for lots of different things,
and sometimes the cursor is at the end of such a highlighted
stretch of text.  If you use your interpretation then you are
likely to be disappointed from time to time - such highlighting
does not, in general, indicate "the" Emacs region.

Fortunately, you can customize Emacs faces, so you could, in
order not to be confused, customize all faces that by default
highlight the background, so that they no longer do so.  You
can easily change them to highlight the foreground instead,
for example.  There are not that many, and changing them all
is easily done.  Use `M-x list-faces-display' to see which
faces you use have that problem.

The ones I see, by default (`emacs -Q') are:

cursor
fringe
header-line
header-line-highlight
isearch
isearch-fail
lazy-highlight
match
menu
mode-line
mode-line-highlight
mode-line-inactive
next-error
query-replace
secondary-selection
show-paren-match
show-paren-match-expression
show-paren-mismatch
tool-bar
tooltip
trailing-whitespace
tty-menu-disabled-face
tty-enabled-face
tty-menu-selected-face

Some of those (e.g., fringe, the mode-line ones) are used
in non-buffer-position places, where you cannot place the
cursor anyway, so you need not change them - no possible
confusion with region highlighting there.

Re: killing the result of isearch

[Jean-Christophe Helary]

> On Nov 8, 2017, at 2:53, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> Many Emacs users rely on isearch for navigation, in which case the above could prove annoying.  Also, currently isearch pushes a mark at the position where you started the search

Thank you, that confirms my understanding. I've been using it with that purpose a number of times and it is very practical, but the fact that it does not give access by default to the match makes it more a navigation (find location) function than something to actually use the match.

Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Jean-Christophe Helary]

Bob, thank you very much for the detailed reply.

I've tried again the default behavior in the editor where I usually do my regex search/replaces (BBEdit) and the only (and major) difference is where the mark is put at the beginning of the search. In emacs it is put where the point is at the beginning of the search, in BBEdit it is put at the beginning of the match, so the region "matches" the search match.

Now, I'm not going to argue about which is best, because the designs are different, as Stephan wrote, search in emacs finds a location and allows the user to act on that location while finding the match is not the purpose but just the means to accomplish that, while in BBEdit finding the match is the purpose of the function.


> On Nov 8, 2017, at 5:59, Bob Proulx <bob@proulx.com> wrote:
> 
> Jean-Christophe Helary wrote:
>> I have an isearch that highlights a string, and I just want to delete
>> that string.
> ...
> I have been using emacs for a very long time and that isn't a feature
> I have ever missed.  However I will say that language shapes the way
> you think.  If the language you use does or does not have a construct
> then it shapes the way one thinks about it.  Emacs doesn't
> intrinsically have that feature but has other features and therefore I
> think and use those other features.
> 
> The answers suggesting M-% are excellent suggestions.

Not really, because if I know what kind of regex I'm looking for, I don't always know how I want to change the match, that depends on context, and overwriting a selection is very often more efficient than going through a replace hoop.

Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Bob Proulx]

Jean-Christophe Helary wrote:
> I've tried again the default behavior in the editor where I usually
> do my regex search/replaces (BBEdit) and the only (and major)

I have never used BBEdit and therefore am at a disadvantage in
comparing behaviors.  But perhaps someone else will have used it and
have suggestions.

> difference is where the mark is put at the beginning of the
> search. In emacs it is put where the point is at the beginning of
> the search, in BBEdit it is put at the beginning of the match, so
> the region "matches" the search match.

Yes.  A fundamental difference.  But wasn't that one of the
advantagess of Isearch+?  I recall Drew and another saying that the
additional Isearch+ functionality included the ability to set the mark
around the matched text.  In this case it would leave the mark at the
start of the match and the point at the end of the match which would
create the region between and be exactly what you are saying you are
wanting.  You might give Isearch+ a try and report back with your
experiences with it.

> Now, I'm not going to argue about which is best, because the designs
> are different, as Stephan wrote, search in emacs finds a location
> and allows the user to act on that location while finding the match
> is not the purpose but just the means to accomplish that, while in
> BBEdit finding the match is the purpose of the function.

Right.  They started from different starting points and ended up at
different ending points and we the users are seeing the tools
available and selecting the best one from the set from our
perspective.  Just different.

But emacs can be customized to work the way you want.

> > The answers suggesting M-% are excellent suggestions.
> 
> Not really, because if I know what kind of regex I'm looking for, I
> don't always know how I want to change the match, that depends on
> context, and overwriting a selection is very often more efficient
> than going through a replace hoop.

I think here there is a misunderstanding.  "C-s party M-% RET" will
search for "party" and then delete it.  Start by searching.  In this
case it is an interactive search and therefore you get feedback and
interactively react to it.  Then if you decide to delete the matching
string at that moment type M-% RET from *within* an isearch will
replace the matched text with nothing.  This is different and separate
from M-% standalone *outside* of an isearch.  Outside of it you are
right that you don't know what you will see yet and don't know what
you might decide after you see it.  But within an isearch you will see
what is being matched and might decide to delete it and one way is to
use M-% at that moment which will preload the previous search string
into the match.  I'm being very tedious and explicit here because I
feel that this particular part might have been missed in the previous
discussion.

  Went up the hill to fetch a pail of water.
  C-s SPC of SPC water M-% RET .
  Went up the hill to fetch a pail.

This contains some subtle points of isearch.  Let me break that apart.

  C-s SPC of SPC water

Start an incremental search.  Type in the string I want to match.
Stay in incremental search and type in M-%.  The details can be found
in the documentation.

  https://www.gnu.org/software/emacs/manual/html_node/emacs/Special-Isearch.html#Special-Isearch

While the incremental search is active type in M-% (which the easy
keystrokes for me are ESC Shift-%).  From the manual:

       Typing ‘M-%’ in incremental search invokes ‘query-replace’ or
    ‘query-replace-regexp’ (depending on search mode) with the current
    search string used as the string to replace.  A negative prefix argument
    means to replace backward.  *Note Query Replace::.

Typing "C-s SPC of SPC water" followed by M-% executes this
query-replace from within isearch and preloads the search pattern
prompting you for the replacement pattern.  RET without entering a
replacement sets it to empty effectively deleting it.  Then you are in
interactive query replace mode.  Query replace is documented:

  https://www.gnu.org/software/emacs/manual/html_node/emacs/Query-Replace.html#Query-Replace

The most natural thing would be to hit SPC to make the replacement in
the incremental search.  Then if there are more occurrences further
down it will proceed through all further occurrences.

But if you don't want to replace anything further down the file, want
to replace just that one thing and stop, then '.' is the best way.

    ‘. (Period)’
         to replace this occurrence and then exit without searching for more
         occurrences.

Therefore my trace above is using '.' to replace just that one
occurrence and then stop.

Hope this helps! :-)

Bob

Re: killing the result of isearch

[Jean-Christophe Helary]

> On Nov 8, 2017, at 13:27, Bob Proulx <bob@proulx.com> wrote:
> You might give Isearch+ a try and report back with your experiences with it.

Not before I've convinced myself that it's the only solution left :)

> I think here there is a misunderstanding.  "C-s party M-% RET" will
> search for "party" and then delete it.

Ok, you mean: "C-s party M-% RET ." (the period is omitted here but you put it later in your reply and I could not get the right result without it.

That works, but that's still a lot more keys than something like:

C-s party (some key to indicate that the target is the matching string) delete

Which is also a lot more keys than:

C-something party delete (where "something" would call a "catch a match" thingy)

> Hope this helps! :-)

It did, but I'm not yet where I want to be :-)

But I'm slowly getting there. It looks like this "catch a match" properly implemented as not conflicting with the current behavior would be a nice addition to (at least my) emacs.

Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]


() Jean-Christophe Helary <jean.christophe.helary@gmail.com>
() Tue, 7 Nov 2017 21:45:00 +0900

   The problem with emacs and searches, is that you only search,
   you don't *find*, as in the action of searching does not
   result in an object that you can act upon.  Which defeats the
   purpose of searching.

o Emacs, help me search for peace of mind!
too late?  life bereft of protect-unwind?
  migrate my mumblings,
  fat-finger fumblings,
artless artifacts; such wor{l}ds left behind.

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: killing the result of isearch

[Emanuel Berg]

Thien-Thi Nguyen wrote:

> The problem with emacs and searches, is that
> you only search, you don't *find*, as in the
> action of searching does not result in an
> object that you can act upon. Which defeats
> the purpose of searching.

It is called searching but many times what
happens is it is a form of navigation - a goto
in the text buffer, if you will.

Because I do this all the time, like one of the
most common ways to position point, I get
totally stressed out by the default
"incremental" search.

Here is some code if anyone else is like me and
hasn't got his own file already

    http://user.it.uu.se/~embe8573/emacs-init/wrap-search.el

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: killing the result of isearch

[Bob Proulx]

Jean-Christophe Helary wrote:
> > Bob Proulx wrote:
> > You might give Isearch+ a try and report back with your experiences with it.
> 
> Not before I've convinced myself that it's the only solution left :)

:-)  I applaud you sticking to it.  I understand the sentiment to
limit the customization.

> > I think here there is a misunderstanding.  "C-s party M-% RET" will
> > search for "party" and then delete it.
> 
> Ok, you mean: "C-s party M-% RET ." (the period is omitted here but
> you put it later in your reply and I could not get the right result
> without it.

Oops.  Yes.  Need the '.' there.  It is hard for me to transcribe
interactive commands that I type reflexively without thought into
documentation.  I miss things that I type without thinking about
them.

But on the plus side those things do not limit me either.  The ones
that frustrate me are the tedious ones that I can't type in.  (For
example C-M-% from an ssh text terminal.)

> That works, but that's still a lot more keys than something like:
> C-s party (some key to indicate that the target is the matching string) delete

Agreed.  But as I had said before language shapes the way you think.
Since that hasn't been an editor capability for me I haven't been
thinking I wanted to do it in exactly that way.

Also the "other" editor vi/vim doesn't have a paradigm for it either.
In those I would have the point at the start of the match and would
likely "dw" (delete word forward), or count up and day 5dw to delete
five words forward, until I had deleted what I wanted to delete.

To be honest most of the time in emacs I would search to the end of
the string I want to delete.  Then I would put my left thumb on Alt
and press Backspace for M-DEL and delete words backward until I had
deleted what I wanted to delete.  It hasn't been one of the things I
have wanted to speed up.  (I do have one of those.  I'll post that in
a different thread.)

> Which is also a lot more keys than:
> C-something party delete (where "something" would call a "catch a match" thingy)

For me I use isearch for navigation *all of the time* and I count on
leaving the mark behind at the previous location.  Then depending upon
what I want I can either C-SPC to pop the mark or C-x C-x to exchange
the point and mark, either way, and return to the previous location.
Setting the mark at the beginning of the match would get in the way
for me.  I could possibly live with it as an additional mark and get
used to typing in C-SPC an additional time.

[[Aside: Except on Android I haven't found a way to enter C-SPC.  It
seems to be a missing capability.  Frustrates me every time I try to
use Android as a terminal.]]

> > Hope this helps! :-)
> 
> It did, but I'm not yet where I want to be :-)

I think in the end you will want/need some custom elisp that creates
this behavior for you.  That is part of the joy of emacs.  Being able
to customize and extend it.  Just don't mess it up for the rest of us! :-)

> But I'm slowly getting there. It looks like this "catch a match"
> properly implemented as not conflicting with the current behavior
> would be a nice addition to (at least my) emacs.

Go for it!

Bob

Re: killing the result of isearch

[Tomas Nordin]

Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:

> No, I am actually talking about expectations from using emacs where regions are highlighted, like what isearch seems like doing. What I am seeing is what looks like a region (and except for the active match, all the others are highlighted exactly as a region would be), but it doesn't act like a region. So there is a UI promise that's broken.

Does this imply that in a read-only buffer, there must be no
highlighting of the match for you not to say the UI is broken? You
cannot act on the text there.

Or, in a read-only buffer, is it good that the match(es) are
highlighted? Why?

>
>
> Jean-Christophe Helary
> -----------------------------------------------
> @brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Jean-Christophe Helary]

> On Nov 9, 2017, at 7:24, Tomas Nordin <tomasn@posteo.net> wrote:
> 
> Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:
> 
>> No, I am actually talking about expectations from using emacs where regions are highlighted, like what isearch seems like doing. What I am seeing is what looks like a region (and except for the active match, all the others are highlighted exactly as a region would be), but it doesn't act like a region. So there is a UI promise that's broken.
> 
> Does this imply that in a read-only buffer, there must be no highlighting of the match for you not to say the UI is broken?

Read my text again, and read your question one more time. You probably have the answer you need by now.

> You cannot act on the text there.

I can certainly M-w on any region I like. A region is a region, regardless of the buffer state, afaiu.

> Or, in a read-only buffer, is it good that the match(es) are highlighted? Why?

I may be thick, but it does look like you're trying to make me look like a fool, when it is you who do not seem to properly understand the issue I'm talking about.

Do you actually have anything useful to add to the thread?

Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Re: killing the result of isearch

[Emanuel Berg]

Jean-Christophe Helary wrote:

> Read my text again, and read your question one
> more time. You probably have the answer you
> need by now.

Don't read his text again! You might become
like him if you're exposed too much.

> Do you actually have anything useful to add to
> the thread?

Do you, save for an incorrectly
formated signature?

> Jean-Christophe Helary
> -----------------------------------------------
> @brandelune http://mac4translators.blogspot.com

http://www.ietf.org/rfc/rfc3676.txt , section 4.3.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: killing the result of isearch

[Tomas Nordin]

Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:

>> On Nov 9, 2017, at 7:24, Tomas Nordin <tomasn@posteo.net> wrote:
>> 
>> Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:
>> 
>>> No, I am actually talking about expectations from using emacs where regions are highlighted, like what isearch seems like doing. What I am seeing is what looks like a region (and except for the active match, all the others are highlighted exactly as a region would be), but it doesn't act like a region. So there is a UI promise that's broken.
>> 
>> Does this imply that in a read-only buffer, there must be no highlighting of the match for you not to say the UI is broken?
>
> Read my text again, and read your question one more time. You probably have the answer you need by now.
>
>> You cannot act on the text there.
>
> I can certainly M-w on any region I like. A region is a region, regardless of the buffer state, afaiu.

Ok, in a couple of posts it looked like the lack of possibility to just
delete the thing highlighted was the main distraction. I also got the
impression it is the subject of the thread.

>
>> Or, in a read-only buffer, is it good that the match(es) are highlighted? Why?
>
> I may be thick, but it does look like you're trying to make me look like a fool, when it is you who do not seem to properly understand the issue I'm talking about.

I don't want to upset anyone, and I didn't have that intention. My
wording was maybe unnecessarily short.

I was trying to suggest that a highlight might have other meanings than
that it will be altered by next insertion or deletion.

Anyway, I think I was reacting on the UI promise wording. I don't know
there is such promise. There are expectations of course, based on
peoples habits and prior experience. I agree that in most other
applications, a highlighted region will get replaced by the next
character you insert, or deleted if that is the action.

When I started out with Emacs, I already knew that almost everything is
different from what I was used to. So, for example, visit a file is not
done by "ctrl-O" or a search is not started with "ctrl-f". Things like
that. So many things are different so I never even reflected over that
the region is not replaced just by hitting a character.

About the incremental search thing. I agree that it *could* be useful
maybe to add an in-search command like

      Type C-l to toggle isearch-lock-string.
       The current search string is frozen and next self-insert-command
       or DEL will operate in the current buffer. C-l again from this
       state will revert to normal isearch. In this mode you can hit C-s
       again to get at the next mach.

But then again, I don't know it would save so many key-strokes. If I want
to search and delete, I find it rather fast anyway to just hit C-s again
two times to get to the next match.

I was curious on the expectations based on other editors, so I tried
this at work with notepad++. The first thing tried was a ctrl-f for the
search. That brings up a dialog for the search and it was not possible
to just delete the thing found. I checked a little and it turned out
that pressing <f3> (after a search and dialog closed) would "select"
next match (the first was already consumed by the dialog search) and
move point to the end of it. And then, yes, possible to act directly on
that selection, like delete for example.

However, this required that one first do a regular search (ctrl-f),
escape that dialog and then start to press <f3>.

Its one of the many things that is different in Emacs to other editors
but then I think that other editors differ to each-other as well, and
each promise their own things. But I don't agree that Emacs is braking a
UI promise. But for sure it will have a different method for doing
things compared to some other editor.

I think one exciting thing with Emacs has been the practice that you
never have to use the mouse for anything (if you don't want to). I could
guess that many commands are not even possible to do via the mouse. Then
one could maybe claim that since Emacs often is used a a GUI, its
braking a promise because the mouse cannot be used for this or that
command. But then I wouldn't agree.

As you say, editing in Emacs is done by the lisp interpreter, so almost
any wish for a behavior can be satisfied by some snippets of code, often
provided by the very kind and helpful Emacs help list. Or, if enough
developers agree on a new feature it will even be added into stock
Emacs. To that note by the way, I evaled the code snippets posted by
Stefan and said `M-x delete-selection-mode`, and after that I got a
behavior exactly as I understand you are looking for. Just don't forget
to hit RET before acting on that region. That post also give some
reasons for the current behavior. I am reading my mail in Emacs so that
behavior slided smoothly into my Emacs just as if it would have been a
feature available through an item in a menu.

--
Tomas

Re: killing the result of isearch

[Jean-Christophe Helary]

   Thank you Thomas for the reply.

     Ok, in a couple of posts it looked like the lack of possibility to
     just
     delete the thing highlighted was the main distraction. I also got
     the
     impression it is the subject of the thread.

   In a way, but because I thought I was seeing a region, which was not
   the case as I eventually understood.

     I don't want to upset anyone, and I didn't have that intention. My
     wording was maybe unnecessarily short.

   Don't worry. Things happen. Thank you for getting back to me.

     Anyway, I think I was reacting on the UI promise wording. I don't
     know
     there is such promise. There are expectations of course, based on
     peoples habits and prior experience. I agree that in most other
     applications, a highlighted region will get replaced by the next
     character you insert, or deleted if that is the action.

   I'm with you here. The problem here is that the result of search is
   *only* to move point and *not* to create a region of the highlighted
   matching string. So what appears on the screen carries actually very
   little meaning *because* with vanilla emacs, there is not isearch
   function (or any other search function for that matter) that creates a
   region out of that match. So it really is only a decoration. That's
   what I eventually understood, and that's why I wrote that it creates
   wrong UI expectations. If something should be highlighted, it should be
   the position of point, not how point found its way there, or at least
   the full region created by the search. Anything else has little meaning
   in the context of isearch.

     About the incremental search thing. I agree that it *could* be
     useful
     maybe to add an in-search command like
         Type C-l to toggle isearch-lock-string.
          The current search string is frozen and next
     self-insert-command
          or DEL will operate in the current buffer. C-l again from this
          state will revert to normal isearch. In this mode you can hit
     C-s
          again to get at the next mach.
     But then again, I don't know it would save so many key-strokes. If I
     want
     to search and delete, I find it rather fast anyway to just hit C-s
     again
     two times to get to the next match.

   You're right. Any solution that adds a layer between selecting the
   match and acting on it is not efficient. There should be a new function
   that acts directly on the match.
   Jean-Christophe Helary
   -----------------------------------------------
   @brandelune http://mac4translators.blogspot.com

RE: killing the result of isearch

[Drew Adams]

> The problem here is that the result of search is
> *only* to move point and *not* to create a region of the highlighted
> matching string. So what appears on the screen carries actually very
> little meaning *because* with vanilla emacs, there is not isearch
> function (or any other search function for that matter) that creates a
> region out of that match.

Not to belabor this too much, but `query-replace' sounds
like it might be something closer to what you are looking
for.  It is exactly about finding some text and _optionally_
replacing or deleting it.

 `RET' just finds it and exits.
 `.' replaces/deletes it and exits.
 `C-w' deletes it and exits.
 `SPC' replaces/deletes it and moves to the next occurrence.
 `!' replaces/deletes all occurrences.

 You can move backward, undo, and change replacement string.

`query-replace' is _designed to act_ on the highlighted
text (the matches).  Isearch is _not_ designed to act on
it.  (But Isearch+ also let you do that, and in any number
of ways.)

The strength of Isearch is the "I" part: _incremental_
changes to the search string are reflected in the matches.
That behavior is not really available to `query-replace',
except in a roundabout, clumsy way - it was designed
for incremental replacement decisions, but not for
incrementally changing the search pattern.

> So it really is only a decoration.

Mere "decoration", if you like.  But it's decoration with
a lot of meaning.  It _shows you what matches_ your search
pattern.  How else would you know what matches?  Is seeing
the targets clearly just decoration, or is it an important
feature?

> If something should be highlighted, it should be the position
> of point, not how point found its way there, or at least the
> full region created by the search.

Dunno what you mean by the last part.  What full region
are you suggesting might be useful to highlight?  Do you
mean the region from the current search hit back to where
search started?  If you just mean full search hits then
that's the longstanding behavior.

> Anything else has little meaning in the context of isearch.

I disagree strongly here.  For search the _most important_
things to highlight (point out in some way) are the search
hits.

If I show you an aerial photo of a region, and you ask for
the locations of the cafes (or churches or playgrounds or
restrooms) don't you think it would be helpful for me to
highlight them for you?

Which also points out that Isearch is _not_ just about
navigation - moving to some search-hit location.  It's
also - perhaps mainly - about identifying/seeing the
search hits.

It's about pointing them out: highlighting them.

That's what I use it for much of the time, when working
with code, for example.  Whether I end up moving to any
search hit, even temporarily, is a separate thing.  Just
being able to see clearly the matches is often all I need.

That many other-application "find" operations highlight
only the current search hit is a drawback, IMO, not an
advantage.

And seeing all of the search hits in the current window
is especially important for an _incremental_ search
operation, where you often change the search pattern.

If you keep to the same search pattern throughout a
static "find" operation then perhaps it's not so
important to highlight all of the search hits.

Meaning no offense, I'd suggest (in hopes that it
helps) that your reaction here sounds a bit like that
of someone encountering a frying pan for the first
time and complaining that it is not as good as a deep
pot for boiling water.  A frying pan is its own thing.

Incremental search is a thing.  It has its own features
and advantages.  It's not the only way to find things,
and it was not designed as a way to find and act on
something.  It's still useful, as designed.

But Emacs offers plenty of other ways to find things
and act on them, from `query-replace' to `grep' and
`occur', and on beyond.  Most importantly, you can
roll your own - limited only by one's imagination.

Re: killing the result of isearch

[Charles A. Roelli]

> From: Emanuel Berg <moasen@zoho.com>
> Date: Wed, 08 Nov 2017 14:47:16 +0100
> 
> It is called searching but many times what
> happens is it is a form of navigation - a goto
> in the text buffer, if you will.
> 
> Because I do this all the time, like one of the
> most common ways to position point, I get
> totally stressed out by the default
> "incremental" search.
> 
> Here is some code if anyone else is like me and
> hasn't got his own file already
> 
>     http://user.it.uu.se/~embe8573/emacs-init/wrap-search.el

I was also looking for a less nervous way to search through a buffer
recently, and I found that the "/" command in view-mode fits the bill
exactly.  You hit "/ foo RET", and you are brought to the next match
for "foo", starting from the bottom of the window.  You can hit "n"
and "p" to go forward and backward between matches.  What's useful is
the omission of some information when you navigate between matches --
only one match per screenful is highlighted, and when you hit "n" or
"p" the next time, the search starts from the end or start of the
window, respectively.  It's useful for getting a rough idea of the
matches for a regexp, without actually cycling through all the matches
with C-s.  And if you need a more fine-grained search, "s" and "r" are
bound to isearch-forward and isearch-backward.

"/" also comes with some other goodies, see:

  / runs the command View-search-regexp-forward (found in
  view-mode-map), which is an interactive compiled Lisp function in
  ‘view.el’.

  It is bound to /.

  (View-search-regexp-forward N REGEXP)

  Search forward for first (or prefix Nth) occurrence of REGEXP in View mode.

  Displays line found at center of window.  Sets mark at starting position and
  pushes mark ring.

  Characters @ and ! are special at the beginning of REGEXP.  They modify
  the search rather than become part of the pattern searched for.
  @ means search all the buffer i.e. start search at the beginning of buffer.
  ! means search for a line that contains no match for the pattern.
  If REGEXP is empty or only consist of these control characters, then
  an earlier remembered REGEXP is used, otherwise REGEXP is remembered
  for use by later search commands.

Re: killing the result of isearch

[Tomas Nordin]

Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:

>> On Nov 8, 2017, at 2:53, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 
>> Many Emacs users rely on isearch for navigation, in which case the above could prove annoying.  Also, currently isearch pushes a mark at the position where you started the search
>
> Thank you, that confirms my understanding. I've been using it with that purpose a number of times and it is very practical, but the fact that it does not give access by default to the match makes it more a navigation (find location) function than something to actually use the match.

As an exercise I wrote this. Can you try it. I think it behaves the way
you expect sort of.

(defun tn-frozen-search (arg &optional start-point)
  "Search forward for a preloaded frozen term.

With a prefix argument prompt for a search term (a regular
expression). With no prefix argument, use the last search from
the search-ring.

Activate the match as a region. Then, if `delete-selection-mode'
has been toggled on, one can \"just act\" on that region.

This function is for interactive use only. There will be an
overwrap with no ding."

  (interactive "P")
  (when arg
    (push (read-string "Search: ") search-ring))
  (unless start-point
    (push-mark nil t nil))
  (let ((success (re-search-forward (car search-ring) nil t)))
    (cond
     (success
      (push-mark (car (match-data)) t t))
     ((and (= (point) (point-min)) (not success))
      (if start-point
          ;; if search fail and start-point is defined, go back to start
          ;; point (recursive call)
          (goto-char start-point)
        )
      (ding)
      (message "No match for %S" (car search-ring)))
     ((not success)
      (if (not start-point)
          (setq start-point (point)))
      ;; this makes it just over-wrap with no ding
      (goto-char (point-min))
      (message "frozen search ****OVERWRAP****")
      (tn-frozen-search nil start-point)) 
     (t
      (message "semantic error in code"))))) ; hit C-x C-e

(global-set-key (kbd "<f9>") 'tn-frozen-search)

With this setup, hitting F9 will search and select the last searched
term. Hitting C-u F9 will giva a prompt for a search term.

There are room for improvement of course, but as a starting point maybe.

Re: killing the result of isearch

[Emanuel Berg]

Tomas Nordin wrote:

> As an exercise I wrote this

-1 for too much modesty.

OK, let's see...

WARNING! Now there will be a lot at once. You,
and many other people, will not agree to
everything I say. That is completely natural as
these are complicated matters. It is not like
a single speed rear hub from Torpedo which has
a limited number of parts that are put together
in one and only one way. Everyone
understands that.

> (defun tn-frozen-search (arg &optional
> start-point)

arg is something that one sees in Elisp source.
But it isn't good. It is like calling a module
"main". It is lazy and do not contribute to the
understanding of what it is or what it does.
You call it "term" later, and while I'm not
sure how much clearer that is, its better than
arg. With arg, might as well call the function
"function" and the file "file".

> "Search forward for a preloaded frozen term.

Here, "preloaded" and "frozen" aren't familiar
designations. If you use them, explain
immediately what they mean. Or rephrase.

Also, in the docstring, the arguments, all
arguments, should appear in o r d e r and in
CAPS. So if you change arg into term, it should
be ~"Search forward for TERM.
Blablablah START-POINT etc."

> With a prefix argument prompt for a search
> term (a regular expression). With no prefix
> argument, use the last search from the
> search-ring.

`search-ring' to mark it an Emacs item and make
it a hypertext button.

> Activate the match as a region. Then, if
> `delete-selection-mode' has been toggled on,
> one can \"just act\" on that region.

OK, the docstring should be as non-technical as
possible. This is sometimes not an easy thing
to do. Imagine the user to be a skilled
computer user, but not necessarily an Emacs
afficionado. Always try to formulate the
docstring in terms of what it does for the
user, not how this is implemented or the
mechanics how it works under the hood. Again,
this is often easier said than done. It is more
like an intention one should have in mind.

> This function is for interactive use only.

Why?

> There will be an overwrap with no ding."

... you mean if it isn't used interactively?

Try to make it work regardless. What exactly is
it that prevents both-way use?

> (cond
>   (success
>     (push-mark (car (match-data)) t t))
>   ((and (= (point) (point-min)) (not success))

Isn't (not success) always true there as
otherwise success would be true above?

> (if start-point
>   ;; if search fail and start-point is defined, go back to start
>   ;; point (recursive call)
>   (goto-char start-point)
> )

I don't know if moving point back qualifies as
a recursive call? That ("recursive call")
sounds like recursion, i.e. function f calling
function f down to a base case where recursion
ends. (Btw, Google "recursion" for a nice
little joke. Yes, Google, none other SE.)

In general, resetting point manually should be
avoided, instead use `save-excursion'.

> (let ((success (re-search-forward (car search-ring) nil t)))
> [...]
> (message "No match for %S" (car search-ring)))

(car search-ring) two times! Better put it
above success in the `let' clause and then use
`let*' instead.

> (if (not start-point)
>   (setq start-point (point)))

`unless'? And: Avoid `setq' in functions if
possible. Rely on `let'! Make it part of your
game like the pawns in Chess or the artillery
in the Red Army.

> (tn-frozen-search nil start-point)

OK, so it *is* recursive! Still, I don't
understand the first reference to recursion?

Again, in general recursion should be avoided
because Elisp isn't the fastest of languages
and especially piling functions on top of each
other can bring it down faster than the tower
of Babel.

> (t
>       (message "semantic error in code"))))) ; hit C-x C-e

How can that ever happen? Since the first
clause is success, and the third (not success)?
You could have the third t and remove the
fourth what I can see. (?)

> (global-set-key (kbd "<f9>") 'tn-frozen-search)

(global-set-key [f9] #'tn-frozen-search)

I always said the function keys should be
avoided as it requires the hands to be moved
from and back to typing asdf/jkl; position.
Speed kills. So hang on to it :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: killing the result of isearch

[Tomas Nordin]

Emanuel Berg <moasen@zoho.com> writes:

> WARNING! Now there will be a lot at once. You,
> and many other people, will not agree to
> everything I say. That is completely natural as
> these are complicated matters. It is not like
> a single speed rear hub from Torpedo which has
> a limited number of parts that are put together
> in one and only one way. Everyone
> understands that.

I am warned, thanks for feedback.

>
>> (defun tn-frozen-search (arg &optional
>> start-point)
>
> arg is something that one sees in Elisp source.
> But it isn't good. It is like calling a module
> "main". It is lazy and do not contribute to the
> understanding of what it is or what it does.
> You call it "term" later, and while I'm not
> sure how much clearer that is, its better than
> arg. With arg, might as well call the function
> "function" and the file "file".

It could be called PROMPT or something like that. If non-nil, a prefix
argument was given and a search string is prompted for.

>
>> "Search forward for a preloaded frozen term.
>
> Here, "preloaded" and "frozen" aren't familiar
> designations. If you use them, explain
> immediately what they mean. Or rephrase.
>
> Also, in the docstring, the arguments, all
> arguments, should appear in o r d e r and in
> CAPS. So if you change arg into term, it should
> be ~"Search forward for TERM.
> Blablablah START-POINT etc."

Actually, I don't think any of the docstring try to explain the
arguments. It tries to explain how to use the function interactively.

>> This function is for interactive use only.
>
> Why?
>
>> There will be an overwrap with no ding."
>
> ... you mean if it isn't used interactively?

I mean that it is written only with the interactive use in mind. Nothing
blows up if it is called by other code, but I don't think it is
meaningful. I don't know how un-elispy it is to write functions mainly
for interactive use. It should be emacsy at least?

>> (cond
>>   (success
>>     (push-mark (car (match-data)) t t))
>>   ((and (= (point) (point-min)) (not success))
>
> Isn't (not success) always true there as
> otherwise success would be true above?

You must be right.

> (car search-ring) two times! Better put it
> above success in the `let' clause and then use
> `let*' instead.

Hmmmm, ehhhh, jaahhh, maybe... But the variable is there already? A car
call cannot be very costly.

>
>> (if (not start-point)
>>   (setq start-point (point)))
>
> `unless'? And: Avoid `setq' in functions if
> possible. Rely on `let'! Make it part of your
> game like the pawns in Chess or the artillery
> in the Red Army.

unless, ok. But the setq is manipulating a function argument, it's local
already, no?

>> (tn-frozen-search nil start-point)
>
> OK, so it *is* recursive! Still, I don't
> understand the first reference to recursion?

It refers to this call that will end up where the comment is. So this
start-point argument is for the recursive case, and this is partly why I
say the function doesn't make much sense in other code.

> Again, in general recursion should be avoided
> because Elisp isn't the fastest of languages
> and especially piling functions on top of each
> other can bring it down faster than the tower
> of Babel.

But there will be only one level of recursion that I am aware of. Is a
recursive function call slower than a regular function call? I am aware
there is a maximum recursion depth.

>
>> (t
>>       (message "semantic error in code"))))) ; hit C-x C-e
>
> How can that ever happen? Since the first
> clause is success, and the third (not success)?
> You could have the third t and remove the
> fourth what I can see. (?)

Yes. In some earlier iteration the fourth clause made sense, but not
now.

>
>> (global-set-key (kbd "<f9>") 'tn-frozen-search)
>
> (global-set-key [f9] #'tn-frozen-search)
>
> I always said the function keys should be
> avoided as it requires the hands to be moved
> from and back to typing asdf/jkl; position.
> Speed kills. So hang on to it :)

Yea, they are a bit far away. This is a suggestion. I wanted it to be
some available single-stroke combination. What would you pick?

Let me say though that this function was mainly trying to address part of
the OP:s expectation as I understand it, to see if that understanding is
correct.

Re: killing the result of isearch

[Emanuel Berg]

Tomas Nordin wrote:

>> "Search forward for a preloaded frozen term.
>> Here, "preloaded" and "frozen" aren't
>> familiar designations. If you use them,
>> explain immediately what they mean.
>> Or rephrase. Also, in the docstring, the
>> arguments, all arguments, should appear in
>> o r d e r and in CAPS. So if you change arg
>> into term, it should be ~"Search forward for
>> TERM. Blablablah START-POINT etc."
>
> Actually, I don't think any of the docstring
> try to explain the arguments. It tries to
> explain how to use the
> function interactively.

Let's put it this way, any docstring to any
function with arguments is incomplete without
a reference to each argument, in o r d e r and
in CAPS. E.g.,

    (defun do-magic (spell victim &optional alternative-incantation)
      "Invoke SPELL on VICTIM.
      If ALTERNATIVE-INCANTATION is provided, use
      that instead of the default method."
      (interactive ...) ...)

Use this to check your code:

    (defun check-package-style ()
      (interactive)
      (checkdoc-current-buffer t) ; TAKE-NOTES
      (message "Style check done.") )

> I mean that it is written only with the
> interactive use in mind. Nothing blows up if
> it is called by other code, but I don't think
> it is meaningful.

It doesn't matter. If it works both ways, don't
mention it as it is only confusing and the
implication is something will brake if you do.

> I don't know how un-elispy it is to write
> functions mainly for interactive use.
> It should be emacsy at least?

But if there is no reason why complicate
matters and limit the possibilities what one
can do with it?

>> (car search-ring) two times! Better put it
>> above success in the `let' clause and then
>> use `let*' instead.
>
> Hmmmm, ehhhh, jaahhh, maybe... But the
> variable is there already? A car call cannot
> be very costly.

It is a style and maintenance issue.

Say you have the data item 5 three times in
your code: 5, 5, and 5.

Is it faster to have a literal 5 three times
rather than one variable? Perhaps (?) but
probably not as that should be optimized
anyway.

However, say that that 5 is to be changed into
6. Now if there is a single variable, it has to
be changed *once*, with no risk of overlooking
the other twos! Much more relaxed and less
error prone to edit/read such clear code.

Here, of course the 5s shouldn't be bunched
together because they are the same value!
If one 5 refers to the five fingers, and two 5s
refer to the points of a star, there should be
- you guessed it - two variables instead
of one.

> unless, ok. But the setq is manipulating
> a function argument, it's local already, no?

More of a style issue.

> It refers to this call that will end up where
> the comment is. So this start-point argument
> is for the recursive case, and this is partly
> why I say the function doesn't make much
> sense in other code.

People come up with all sorts of crazy stuff to
do with code and actually any type of
equipment. It is not always what the
developer/producer had in mind.

> But there will be only one level of recursion
> that I am aware of. Is a recursive function
> call slower than a regular function call?

A function call, recursive or not, is slow.
So if you have recursion which can be replaced
with a loop, this will always be faster as no
stockpiling of functions on the stack.

> Yea, they are a bit far away. This is
> a suggestion. I wanted it to be some
> available single-stroke combination.
> What would you pick?

Look down on your fingers! asdf and jkl; are
the best keys. Every step away from them is one
step down the key hierarchy. The most basic
functions, that works generally and in most
modes, should get those. Functions that are
seldom used - well, by all means those can be
assigned a function key - however what I would
do is assign them a short alias and then do
M-x. It is a trade-off. Long combination of
close keys are sometimes faster than a single,
distant key. However make them too long and you
won't remember them. So best fiddle with it
back and forth until reach a state when you are
happy.

The rule is "make the common [frequent] case
fast and the rare case correct".

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: killing the result of isearch

[Emanuel Berg]

Tomas Nordin wrote:

> (= (point) (point-min))

I knew this was there the moment I read it,
I just couldn't find it. As always, coupl'a
days later, I found it - at the back of my
mind

    (bobp)

also

    (eobp)

and

    https://www.youtube.com/watch?v=L5sQYUFGAc0

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: killing the result of isearch

[Emanuel Berg]

Tomas Nordin wrote:

> But there will be only one level of recursion
> that I am aware of. Is a recursive function
> call slower than a regular function call?
> I am aware there is a maximum
> recursion depth.

Here is what it says in the manual [1]

    Use iteration rather than recursion
    whenever possible. Function calls are slow
    in Emacs Lisp even when a compiled function
    is calling another compiled function.

Which is what I said, right? But it also says

    Using the primitive list-searching
    functions ‘memq’, ‘member’, ‘assq’, or
    ‘assoc’ is even faster than explicit
    iteration. It can be worth rearranging
    a data structure so that one of these
    primitive search functions can be used.

"Explicit iteration" = e.g., a `while' loop
with a condition and the increment of
a variable. This is everyday loop usage in
languages such as C, C++ ...

"Primitive" = "A 'primitive function' is
a function callable from Lisp but written in
the C programming language." [2]

[1] (info "(elisp) Compilation Tips"
[2] (info "(elisp) Primitive Function Type")

-- 
underground experts united
http://user.it.uu.se/~embe8573