From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marcin Borkowski Newsgroups: gmane.emacs.help Subject: Re: How to test if the current line contains only white-spache? Date: Tue, 17 Nov 2015 21:38:32 +0100 Message-ID: <87r3jobbuf.fsf@mbork.pl> References: <87r3js7e8l.fsf@linux-qg7d.fritz.box> <874mgnystc.fsf@point.pointsman.de> <874mglbhdp.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447792768 4053 80.91.229.3 (17 Nov 2015 20:39:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 20:39:28 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Emanuel Berg Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Nov 17 21:39:14 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 1Zyn20-0000MA-G0 for geh-help-gnu-emacs@m.gmane.org; Tue, 17 Nov 2015 21:39:12 +0100 Original-Received: from localhost ([::1]:60576 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyn1z-0003Se-Mf for geh-help-gnu-emacs@m.gmane.org; Tue, 17 Nov 2015 15:39:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyn1o-0003SN-DA for help-gnu-emacs@gnu.org; Tue, 17 Nov 2015 15:39:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zyn1j-00089V-VD for help-gnu-emacs@gnu.org; Tue, 17 Nov 2015 15:39:00 -0500 Original-Received: from mail.mojserwer.eu ([2a01:5e00:2:52::8]:53104) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyn1j-00088U-P0 for help-gnu-emacs@gnu.org; Tue, 17 Nov 2015 15:38:55 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id AA2988F2003; Tue, 17 Nov 2015 21:38:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.mojserwer.eu Original-Received: from mail.mojserwer.eu ([127.0.0.1]) by localhost (mail.mojserwer.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsESrAYEsddH; Tue, 17 Nov 2015 21:38:44 +0100 (CET) Original-Received: from localhost (unknown [109.232.24.28]) by mail.mojserwer.eu (Postfix) with ESMTPSA id 5521B8F2002; Tue, 17 Nov 2015 21:38:43 +0100 (CET) User-agent: mu4e 0.9.15; emacs 25.0.50.1 In-reply-to: <874mglbhdp.fsf@debian.uxu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a01:5e00:2:52::8 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:108117 Archived-At: On 2015-11-17, at 01:26, Emanuel Berg wrote: > Rolf Ade writes: > >> Works fine and is much simpler. Thanks. > > Here is another solution that is all C, and doesn't > move point. Is that an advantage? ... (Open question.) > > (defun blank-line () > (interactive) > (message (if > (string-match "^[[:space:]]*$" > (buffer-substring-no-properties > (line-beginning-position) > (line-end-position) )) "blank" "not so") )) > > Non-interactive use could be: > > (defun blank-line-p () > (string-match "^[[:space:]]*$" > (buffer-substring-no-properties > (line-beginning-position) > (line-end-position) ))) > > (blank-line-p) ; nil > > (progn (previous-line 2) > (blank-line-p) ) ; 0, i.e. non-nil - (when 0 t) => t > ; (when nil t) => nil > > Keep it up! I would be a bit afraid about performance if using this idea many times. Using strings /might/ cause GC to run more often. Some time ago I wrote a small template mechanism for Emacs, and benchmarked two versions of it: a buffer-based one and a string-based one. Admittedly, there was /changing/ strings (or: creating new ones) involved, but the string-based one was terribly slow on larger data. I will be writing about this with more details in a future blog post (which is largely written and waits for its time). Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University