From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 75d9a55: Fix bug 32543 Date: Tue, 18 Sep 2018 17:11:24 -0400 Message-ID: References: <20180918123203.24597.514@vcs0.savannah.gnu.org> <20180918123205.8BE9B204DF@vcs0.savannah.gnu.org> <87bm8u906v.fsf@calancha-pc.dy.bbexcite.jp> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1537305008 20062 195.159.176.226 (18 Sep 2018 21:10:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Sep 2018 21:10:08 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Tino Calancha Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 18 23:10:04 2018 Return-path: Envelope-to: ged-emacs-devel@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 1g2NFw-0004zI-Sw for ged-emacs-devel@m.gmane.org; Tue, 18 Sep 2018 23:10:00 +0200 Original-Received: from localhost ([::1]:42609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2NI3-0008V6-8w for ged-emacs-devel@m.gmane.org; Tue, 18 Sep 2018 17:12:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2NHO-0008Us-Pi for emacs-devel@gnu.org; Tue, 18 Sep 2018 17:11:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g2NHK-0007OC-Jj for emacs-devel@gnu.org; Tue, 18 Sep 2018 17:11:30 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:37387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2NHK-0007Ni-DX for emacs-devel@gnu.org; Tue, 18 Sep 2018 17:11:26 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w8ILBOsf008861; Tue, 18 Sep 2018 17:11:24 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 9EEC86A64E; Tue, 18 Sep 2018 17:11:24 -0400 (EDT) In-Reply-To: <87bm8u906v.fsf@calancha-pc.dy.bbexcite.jp> (Tino Calancha's message of "Wed, 19 Sep 2018 02:37:12 +0900") X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Rules: 3 Rules triggered TRK_NCM1=0.1, EDT_SA_DN_PASS=0, RV6376=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6376> : inlines <6884> : streams <1798840> : uri <2713263> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229955 Archived-At: >> - why store this info in text-properties rather than in >> buffer-local variables? > I realized the buffer was already saved there with property > `occur-title'; I didn't wanted to scatter around related info. Hmmm... do you happen to have some intuition about why the buffer was saved in a text-property rather than in a buffer-local var? It's a really odd choice (less efficient, more work for the coder, with various side-problems like "on which char should I put it", etc...). [ Also, why is it saved under a name like `occur-title` rather than, say `occur-buffer`? ] >>> + (with-current-buffer buffer >>> + (when (wholenump orig-line) >>> + (goto-char 1) >> >> I'd recommend `point-min` instead of 1 here. > OK. I always remember the discussion at > https://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00520.html > but I forgot which was the encouraged practice there: in these cases > I follow the 50% rule to reject 0% success ratio (I know, it brings > 50% failure ratio: life is full of injustice). I just always recommend `point-min`. Hard-coded constants are always weird in source code, whereas `point-min` clearly says what this constant is (and in terms of efficiency, it's a wash, or `point-min` might even be marginally more efficient). Stefan