From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: emacs 24's forward-char vs right-char behavior Date: Thu, 26 Apr 2012 18:00:50 +0300 Message-ID: <83ehraillp.fsf@gnu.org> References: <379c8837-79c2-4692-8103-0bfa473f221e@wp13g2000pbb.googlegroups.com> <6251ec09-a82e-4843-9b52-1074dc20eaf1@a8g2000pbe.googlegroups.com> <976d7086-55cd-4d39-8ed6-1f49c7c1b0ed@u4g2000pbu.googlegroups.com> NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1335452509 19566 80.91.229.3 (26 Apr 2012 15:01:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 26 Apr 2012 15:01:49 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Apr 26 17:01:49 2012 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 1SNQCa-00043r-VR for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Apr 2012 17:01:49 +0200 Original-Received: from localhost ([::1]:47125 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNQCa-0002MC-A9 for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Apr 2012 11:01:48 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNQCQ-0002Lr-Us for help-gnu-emacs@gnu.org; Thu, 26 Apr 2012 11:01:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SNQCK-0008RI-Lw for help-gnu-emacs@gnu.org; Thu, 26 Apr 2012 11:01:38 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:38964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNQCK-0008R8-Co for help-gnu-emacs@gnu.org; Thu, 26 Apr 2012 11:01:32 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M3300E00DFD6W00@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Thu, 26 Apr 2012 18:00:49 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.249.186]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M3300EBTDPC0L50@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Thu, 26 Apr 2012 18:00:49 +0300 (IDT) In-reply-to: <976d7086-55cd-4d39-8ed6-1f49c7c1b0ed@u4g2000pbu.googlegroups.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:84645 Archived-At: > From: Xah Lee > Date: Thu, 26 Apr 2012 07:24:06 -0700 (PDT) > > can't right-char always move to the right even in mixed R2L/L2R > situations? It can: that's what "visual" cursor motion is about. But moving always to the right requires that after each move, Emacs figures out the value of point, because moving by one screen position no longer means moving by one buffer position; it could potentially mean jumping over many buffer positions. By contrast, the current "logical" cursor motion always moves point by one buffer position, then positions the cursor accordingly. The only new aspect of right-char in Emacs 24 is that sometimes it moves forward in the buffer and sometimes backward. But it still moves only one buffer position. The significant difference between logical and visual cursor motion is that the former doesn't care about what's on the screen, because it moves by buffer positions. Therefore, it can easily and predictably do its job even when the Emacs display is not up to date (e.g., because Emacs cannot keep up with input events, or has some prolonged command running). By contrast, visual cursor movement needs either to consult the contents of the screen (which would mean difficulties when you move the cursor off the screen, or if the display is not yet up to date), or figure out how the text _would_ be displayed (which means each keypress will need to do much more work than it does now). These difficulties are the reason why visual cursor motion was not yet implemented in Emacs.