From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: point-min and 1 Date: Thu, 13 Aug 2009 14:38:05 +0200 Organization: Organization?!? Message-ID: <87ws57nb2q.fsf@lola.goethe.zz> References: <83vdkvjbet.fsf@gnu.org> <83skfyjj56.fsf@gnu.org> <4A83E28E.2090808@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1250167117 19549 80.91.229.12 (13 Aug 2009 12:38:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Aug 2009 12:38:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 13 14:38:33 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MbZZf-00063P-BO for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 14:38:31 +0200 Original-Received: from localhost ([127.0.0.1]:55699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbZZc-0001Jo-Ik for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 08:38:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbZZX-0001Jj-32 for emacs-devel@gnu.org; Thu, 13 Aug 2009 08:38:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbZZS-0001EO-N0 for emacs-devel@gnu.org; Thu, 13 Aug 2009 08:38:22 -0400 Original-Received: from [199.232.76.173] (port=59900 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbZZS-0001Dp-IM for emacs-devel@gnu.org; Thu, 13 Aug 2009 08:38:18 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:40980 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MbZZS-0003Zb-1z for emacs-devel@gnu.org; Thu, 13 Aug 2009 08:38:18 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MbZZP-00038z-5a for emacs-devel@gnu.org; Thu, 13 Aug 2009 12:38:15 +0000 Original-Received: from p5b2c2b80.dip.t-dialin.net ([91.44.43.128]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Aug 2009 12:38:15 +0000 Original-Received: from dak by p5b2c2b80.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Aug 2009 12:38:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 53 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p5b2c2b80.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:c4C7CC9pjEOiF7u/4cZmjUGvjWk= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114174 Archived-At: martin rudalics writes: >> As a general rule, using 1 rather than (point-min) tends to also >> introduce bugs where code only works when the buffer is widened, > > What sort of bugs? I suppose for every buffer > > 1 <= (point-min) > > holds invariantly. If the buffer is narrowed, clip_to_bounds asserts > that (goto-char 1) goes to (goto-char (point-min)) so these two idioms > are semantically equivalent regardless of whether a buffer is narrowed > or not. Or what am I missing? We have goto-char is an interactive built-in function in `C source code'. It is bound to . (goto-char POSITION) Set point to POSITION, a number or marker. Beginning of buffer is position (point-min), end is (point-max). The return value is POSITION. [back] Can you guess from that what is done and returned when the buffer is narrowed and you call (cons (goto-char 1) (point))? >From the DOC string, you could get an error thrown, or point is put outside of the narrowed region and a number of different things. It is not at all clear that you get no error, and something like (1 . 90) is returned. In order to find that out, you have not only to read the doc string, but the actual source code. Whether or not the actual result turns out what it is, it is a lousy idea to have to dig through the source code and all intricacies before being able to tell what some code does. The less information and detail you need to access before figuring out the function of some code, the better. Not least of all because you don't have dozens of accidental dependencies if at one point of time some of the incidental semantics are chosen to change. -- David Kastrup