From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Politz Newsgroups: gmane.emacs.help Subject: Re: Why save-excursion doesn't restore cursor position after 3 kill-line calls? Date: Fri, 28 Nov 2008 23:35:01 +0100 Organization: FH-Trier Message-ID: <1227911769.432128@arno.fh-trier.de> References: <429c5cab-0015-4eb6-a794-ce990c6255d6@q26g2000prq.googlegroups.com> <9700303c-f0d1-42b6-b1d0-a74e3fe2ab33@t26g2000prh.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1227912154 14388 80.91.229.12 (28 Nov 2008 22:42:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Nov 2008 22:42:34 +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 28 23:43:36 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L6C3b-0000F3-Gf for geh-help-gnu-emacs@m.gmane.org; Fri, 28 Nov 2008 23:43:27 +0100 Original-Received: from localhost ([127.0.0.1]:37064 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6C2R-0006Sv-Mu for geh-help-gnu-emacs@m.gmane.org; Fri, 28 Nov 2008 17:42:15 -0500 Original-Path: news.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed00.sul.t-online.de!t-online.de!inka.de!peernews!news.belwue.de!news.uni-kl.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 82 Original-NNTP-Posting-Host: 143-93-54-11.arno.fh-trier.de Original-X-Trace: news.uni-kl.de 1227911810 5873 143.93.54.11 (28 Nov 2008 22:36:50 GMT) Original-X-Complaints-To: usenet@news.uni-kl.de Original-NNTP-Posting-Date: Fri, 28 Nov 2008 22:36:50 +0000 (UTC) User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) In-Reply-To: Cache-Post-Path: arno.fh-trier.de!unknown@dslb-084-059-221-066.pools.arcor-ip.net X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) Original-Xref: news.stanford.edu gnu.emacs.help:164878 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:60206 Archived-At: tyler wrote: > Xah Lee writes: > >> On Nov 28, 7:59 am, tyler wrote: >>> Barry Margolin writes: >>>> In article >>>> <429c5cab-0015-4eb6-a794-ce990c625...@q26g2000prq.googlegroups.com>, >>>> "seber...@spawar.navy.mil" wrote: >>>>> I'm trying to map C-d to a function that deletes an entire line and >>>>> stops on the *SAME* column number of the following line.... >>>>> (global-set-key "\^d" (lambda () (interactive) (save-excursion (kill- >>>>> line) >>>>> (kill-line 0) >>>>> (kill-line)))) >>>>> Why doesn't save-excursion preserve the column number after these kill- >>>>> line invocations? >>> I tried Chris' code, first calling (point), then running the command, >>> then running (point) again, and the value has definitely not been >>> restored. It is possible, for example: >>> >>> (defun mykill () >>> (interactive) >>> (let ((p (point))) >>> (kill-line) >>> (kill-line 0) >>> (kill-line) >>> (goto-char p))) >>> >>> I've been confused by save-excursion in other contexts though, so I'm >>> still unclear on why the original version of this function doesn't work. >> Like Barry Margolin has said, save-excursion restore the cursor >> position but not when the text the cursor is on is deleted in your >> code. In other words, it is theoretically senseless to preserve >> something that's not there anymore. > > Cursor-position is point in emacs jargon, no? The documentation clearly > states that point is saved and restored during save-excursion. Point > itself is just an integer, and does not disappear when text is deleted. > >> in your code, your several kill-line code deleted the line the cursor >> is on. >> >> what exactly do you want to do? > > I'm not sure what the OP wanted, but I want to understand why > save-excursion does not do the same thing as my function `mykill' does. > >> if you want to return your cursor to the same column it was on, you >> can get the column position then move your cursor to that afterwards. >> However, that presumes that you are on a line that has enough chars to >> cover the column. Overall, i think you need to clarify the behavior >> you wanted. > > The function provided above does exactly what I wanted (granted for only > simple cases). Try it with point on the u in 'presumes' in the paragraph > above. That line is killed, with point ending up at the same numeric > position where it started - i.e., the same column on the following line. > (This will only be the case when the following line is long enough, of > course). > > The real question is why save-excursion *doesn't* do this. The > documentation states that point is restored. Either 'restoring' point > means something other than setting point to equal the previously saved > value, or there is something missing in the documentation. > > Tyler > > save-excursion stores a marker, not the 'byte' number. When you kill the line where point is, this marker gets replaced to the beginning of the line. ,----[ (info "(elisp)Excursions") ] | *Warning:* Ordinary insertion of text adjacent to the saved point | value relocates the saved value, just as it relocates all markers. | More precisely, the saved value is a marker with insertion type `nil'. | *Note Marker Insertion Types::. Therefore, when the saved point value | is restored, it normally comes before the inserted text. `---- -ap