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