From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel,gmane.emacs.bidi Subject: Re: Mixed L2R and R2L paragraphs and horizontal scroll Date: Sat, 30 Jan 2010 15:14:28 +0000 Message-ID: <4B644CD4.2080200@harpegolden.net> References: <83tyu3iu6b.fsf@gnu.org> 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 1264864486 18934 80.91.229.12 (30 Jan 2010 15:14:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Jan 2010 15:14:46 +0000 (UTC) Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 30 16:14:44 2010 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.69) (envelope-from ) id 1NbF22-0005vH-OB for ged-emacs-devel@m.gmane.org; Sat, 30 Jan 2010 16:14:43 +0100 Original-Received: from localhost ([127.0.0.1]:52123 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NbF22-0004YF-39 for ged-emacs-devel@m.gmane.org; Sat, 30 Jan 2010 10:14:42 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NbF1w-0004X8-JL for emacs-devel@gnu.org; Sat, 30 Jan 2010 10:14:36 -0500 Original-Received: from [199.232.76.173] (port=46467 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NbF1v-0004WK-9S for emacs-devel@gnu.org; Sat, 30 Jan 2010 10:14:35 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NbF1u-0005lX-O6 for emacs-devel@gnu.org; Sat, 30 Jan 2010 10:14:35 -0500 Original-Received: from harpegolden.net ([65.99.215.13]:45283) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NbF1s-0005l1-2m; Sat, 30 Jan 2010 10:14:32 -0500 Original-Received: from [87.198.47.32] (87-198-47-32.ptr.magnet.ie [87.198.47.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTP id B94F18B52; Sat, 30 Jan 2010 15:14:30 +0000 (GMT) User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) In-Reply-To: <83tyu3iu6b.fsf@gnu.org> X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:120702 gmane.emacs.bidi:467 Archived-At: Eli Zaretskii wrote: > Does this behavior look reasonable? If not, what are the > alternatives? Note that any alternative should be consistent about > the fact that Emacs does not have a rigid line length, therefore any > initial relative horizontal position of characters (before we split > the window) is arbitrary, and is a function of the window's initial > arbitrary width. > > Eh, not saying it's a good alternative, maybe one could just _introduce_ a hard R2L paragraph start column setting, not coupled to window width /or L2R line length/, any more than fill-column being 70 stops particular L2R lines being longer than 70. In some cases, unwrapped long L2R lines might thus spill past the R2L start column. ...Probably pretty obnoxious... setting R2L start at max(render length of L2R lines given adequate space, or window width iff wrapping on)+C (C probably at or near 0) is not quite the same thing as a word-processor page-dimensions-based rigid length and could maybe work if that was known for the whole buffer, but as per other recent thread, emacs in particular probably doesn't have the luxury of such info in general.