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