From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tomas Nordin Newsgroups: gmane.emacs.help Subject: Re: killing the result of isearch Date: Mon, 13 Nov 2017 22:17:16 +0100 Message-ID: <87o9o5x4ir.fsf@fliptop> References: <8EEDAF80-5CD1-4BEE-8DB2-262BEDA7C829@gmail.com> <87wp2vw9j6.fsf@fliptop> <86r2t32lip.fsf@zoho.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1510607876 1814 195.159.176.226 (13 Nov 2017 21:17:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 21:17:56 +0000 (UTC) To: Emanuel Berg , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Nov 13 22:17:52 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEM72-0008Qn-Cz for geh-help-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 22:17:48 +0100 Original-Received: from localhost ([::1]:56360 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEM78-0005MB-2q for geh-help-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 16:17:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEM6i-0005Lu-Jz for help-gnu-emacs@gnu.org; Mon, 13 Nov 2017 16:17:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEM6f-0001Fz-EQ for help-gnu-emacs@gnu.org; Mon, 13 Nov 2017 16:17:28 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:43753) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eEM6f-0001ED-4Q for help-gnu-emacs@gnu.org; Mon, 13 Nov 2017 16:17:25 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 4E2252099B for ; Mon, 13 Nov 2017 22:17:19 +0100 (CET) Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3ybNkh5br2z108f; Mon, 13 Nov 2017 22:17:16 +0100 (CET) In-Reply-To: <86r2t32lip.fsf@zoho.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 185.67.36.66 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:114873 Archived-At: Emanuel Berg 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 "") '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.