[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: killing the result of isearch
Re: killing the result of isearch
Mon, 13 Nov 2017 22:17:16 +0100
Emanuel Berg <address@hidden> 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
> 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.
>> 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?
>> (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
>> (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.
>> (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
>> (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
Re: killing the result of isearch, Stefan Monnier, 2017/11/07
Re: killing the result of isearch, Emanuel Berg, 2017/11/15