From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: killing the result of isearch Date: Sun, 12 Nov 2017 23:13:34 +0100 Message-ID: <86r2t32lip.fsf@zoho.com> References: <8EEDAF80-5CD1-4BEE-8DB2-262BEDA7C829@gmail.com> <87wp2vw9j6.fsf@fliptop> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1510524861 4612 195.159.176.226 (12 Nov 2017 22:14:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 12 Nov 2017 22:14:21 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Nov 12 23:14:17 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 1eE0W6-0000rq-UZ for geh-help-gnu-emacs@m.gmane.org; Sun, 12 Nov 2017 23:14:15 +0100 Original-Received: from localhost ([::1]:51434 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eE0WE-000666-76 for geh-help-gnu-emacs@m.gmane.org; Sun, 12 Nov 2017 17:14:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eE0Vi-00065q-0Y for help-gnu-emacs@gnu.org; Sun, 12 Nov 2017 17:13:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eE0Ve-0003DO-Q2 for help-gnu-emacs@gnu.org; Sun, 12 Nov 2017 17:13:49 -0500 Original-Received: from [195.159.176.226] (port=42999 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eE0Ve-0003D5-IE for help-gnu-emacs@gnu.org; Sun, 12 Nov 2017 17:13:46 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eE0VR-0007Eh-Ve for help-gnu-emacs@gnu.org; Sun, 12 Nov 2017 23:13:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Original-Lines: 146 Original-X-Complaints-To: usenet@blaine.gmane.org Mail-Copies-To: never Cancel-Lock: sha1:/duB9RXSWSmaWaKZ89HsUA2pJ2g= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:114867 Archived-At: 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 "") '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