From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Lennart Borgman (gmail)" Newsgroups: gmane.emacs.devel Subject: Re: line-move-visual never set to nil? Date: Fri, 01 Aug 2008 02:37:43 +0200 Message-ID: <48925AD7.8010907@gmail.com> References: <18571.25125.311010.324079@gargle.gargle.HOWL> <87od4k1nj5.fsf@stupidchicken.com> <1F7E32D0-7C19-4950-94DB-F6CD33A56EB0@gmail.com> <6161f3180807290043l2b0cc1as85a338204687f183@mail.gmail.com> <87y73kbvz3.fsf@stupidchicken.com> <4891F546.2080505@gmail.com> <8763ql7hmk.fsf@catnip.gol.com> <48924CE0.9090603@gmail.com> <87wsj160bf.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1217551101 17907 80.91.229.12 (1 Aug 2008 00:38:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Aug 2008 00:38:21 +0000 (UTC) Cc: rms@gnu.org, david.reitter@gmail.com, Chong Yidong , andrew.w.nosenko@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, raman@users.sourceforge.net To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 01 02:39:10 2008 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 1KOifi-0005yO-Q4 for ged-emacs-devel@m.gmane.org; Fri, 01 Aug 2008 02:39:07 +0200 Original-Received: from localhost ([127.0.0.1]:43080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOien-0008SO-E9 for ged-emacs-devel@m.gmane.org; Thu, 31 Jul 2008 20:38:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KOiei-0008Pw-OY for emacs-devel@gnu.org; Thu, 31 Jul 2008 20:38:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KOieh-0008NP-29 for emacs-devel@gnu.org; Thu, 31 Jul 2008 20:38:04 -0400 Original-Received: from [199.232.76.173] (port=51574 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOieg-0008N5-Lc for emacs-devel@gnu.org; Thu, 31 Jul 2008 20:38:02 -0400 Original-Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]:57453) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KOieX-0001tt-Eh; Thu, 31 Jul 2008 20:37:54 -0400 Original-Received: from c83-254-151-176.bredband.comhem.se ([83.254.151.176]:60215 helo=[127.0.0.1]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1KOieS-0007eN-6I; Fri, 01 Aug 2008 02:37:49 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 In-Reply-To: <87wsj160bf.fsf@catnip.gol.com> X-Antivirus: avast! (VPS 080731-0, 2008-07-31), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.151.176 X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1KOieS-0007eN-6I. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1KOieS-0007eN-6I 87904bda3d0e72128cb1537fa4f0eac5 X-detected-kernel: by monty-python.gnu.org: Linux 2.6? (barebone, rare!) 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:101838 Archived-At: Miles Bader wrote: > "Lennart Borgman (gmail)" writes: >>> Macros do not -- and cannot -- make any guarantees about what happens if >>> you execute them in a different environment, or on different text, than >>> where they were recorded. >> Do you mean that there is something that prevents us from temporary >> turning things off during keyboard macro recording and execution? In >> that case: what? > > The point is that it doesn't actually help -- there are a million other > cases that can trip up the user, and the only general solution is for > users to be aware of problems that can crop up during macro replying and > be fairly conservative in how they make macros. I think this case is special. The special thing is the relation between the visual move and the buffer point. That relation changes according to something that is rather unrelated with the buffer contents but can easily be changed by the user. That makes the relation very volatile. > Having commands work _differently_ during macro recording is guaranteed > to confuse people, and doing so will probably cause as many problems as > it "solves". > > -Miles >