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.