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: Mon, 13 Nov 2017 23:13:10 +0100 Message-ID: <86efp13k09.fsf@zoho.com> References: <8EEDAF80-5CD1-4BEE-8DB2-262BEDA7C829@gmail.com> <87wp2vw9j6.fsf@fliptop> <86r2t32lip.fsf@zoho.com> <87o9o5x4ir.fsf@fliptop> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1510611235 25871 195.159.176.226 (13 Nov 2017 22:13:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 22:13:55 +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 Mon Nov 13 23:13:50 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 1eEMzG-0006O4-3O for geh-help-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 23:13:50 +0100 Original-Received: from localhost ([::1]:56526 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEMzN-0007yl-Cc for geh-help-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 17:13:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEMys-0007yd-4m for help-gnu-emacs@gnu.org; Mon, 13 Nov 2017 17:13:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEMyo-0003wd-T3 for help-gnu-emacs@gnu.org; Mon, 13 Nov 2017 17:13:26 -0500 Original-Received: from [195.159.176.226] (port=54421 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eEMyo-0003w0-L3 for help-gnu-emacs@gnu.org; Mon, 13 Nov 2017 17:13:22 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eEMyd-0004Lb-L7 for help-gnu-emacs@gnu.org; Mon, 13 Nov 2017 23:13:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Original-Lines: 134 Original-X-Complaints-To: usenet@blaine.gmane.org Mail-Copies-To: never Cancel-Lock: sha1:if3ypmfpClMD33UPogdaTwgdEC4= 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:114874 Archived-At: 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