From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rolf Ade Newsgroups: gmane.emacs.help Subject: Re: How to test if the current line contains only white-space? Date: Fri, 20 Nov 2015 01:48:21 +0100 Organization: Me Message-ID: <87h9kg6ckd.fsf@linux-qg7d.fritz.box> References: <87r3js7e8l.fsf@linux-qg7d.fritz.box> <874mgnystc.fsf@point.pointsman.de> <87d1v67nwo.fsf@linux-qg7d.fritz.box> <877fle6qnc.fsf@linux-qg7d.fritz.box> <87bnaqvwvx.fsf@mbork.pl> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448025328 19284 80.91.229.3 (20 Nov 2015 13:15:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Nov 2015 13:15:28 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Nov 20 14:15:28 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZzlXB-00027j-VH for geh-help-gnu-emacs@m.gmane.org; Fri, 20 Nov 2015 14:15:26 +0100 Original-Received: from localhost ([::1]:47268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzlXB-0005MO-DM for geh-help-gnu-emacs@m.gmane.org; Fri, 20 Nov 2015 08:15:25 -0500 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 57 Original-X-Trace: individual.net SnXnsEoBVa9lviMBdcsAmgAeSi0G+Pa9aOpiTfM7d7P5lkFZs= Cancel-Lock: sha1:msjKrz37PCESUrt0TZxc6Xyp01c= sha1:89bYd3D+9pY61RUXyRtqhEjvudk= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-From-Line: nobody Fri Nov 20 01:48:21 2015 Original-Xref: usenet.stanford.edu gnu.emacs.help:215876 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 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-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:108163 Archived-At: Emanuel Berg writes: > As for "side-effects" that is the phantom menace the > Haskell buffs came up with, when actually side effects > are the reason we use computers. Nah, it's not that easy. ("I don't think you can be categorical about it." ;-) > Rather, in this case it is clear which is preferable > of > > (save-excursion (beginning-of-line) (point)) > > and > > (line-beginning-position) > > The code is easier and faster to write, read, > and understand. Yes. That are general principles and they are important judgement rules for me. (I'd sort it understand, read, write, but anyway.) > This is even more true when the example isn't as basic > as that, but when everything appears in nested forms > and loops and what have you. If you rely on moving > point around, this will demand of you to be a better > programmer than you would have to be, less it will get > out of hands pretty quickly. Well, yeah. If you start digging a bit more into emacs lisp programming, as I do atm, a lot of details showing up. While I enjoy that emacs, the editor, mostly do The Right Thing depending on the "context" (e.g mode of the buffer) it makes me nervous that within emacs, the programming enviroment, the effect of my elisp code often depends on settings and circumstances that are not under my (the programmer) control. (And more important I may not know about. The one I know about I'm able to handle.) In the current, very simple case ("How to test if the current line contains only white-space?") I learned the difference between looking-at and looking-at-p. At some stage I used beginning-of-line-text and quickly realized that the result of that defun depends on adaptive-fill-mode being on or off. And so on. > That is one aspect. The other aspect is that often > moving point to the correct place to extract some data > seems straightforward in the lab. In the field all > sorts of unexpected situations appear and suddenly > point doesn't land where it should (or remotely so!). > Now the code once again can quickly get out of hands > if you try to compensate if `looking-at' something > `forward-char' else - and so on: not good! Yeah. See above.