From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Changes in frame/window code Date: Mon, 28 Jul 2014 11:26:02 +0200 Message-ID: <53D6172A.5010909@gmx.at> References: <53CE6A44.1010708@gmx.at> <53D4FF76.1060804@gmx.at> <8338dmj1of.fsf@gnu.org> <83wqayhe0o.fsf@gnu.org> <53D542B3.20206@gmx.at> <83tx62hane.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1406539602 4250 80.91.229.3 (28 Jul 2014 09:26:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Jul 2014 09:26:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 28 11:26:35 2014 Return-path: Envelope-to: ged-emacs-devel@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 1XBhCV-0005tC-9W for ged-emacs-devel@m.gmane.org; Mon, 28 Jul 2014 11:26:35 +0200 Original-Received: from localhost ([::1]:38486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBhCU-000625-OX for ged-emacs-devel@m.gmane.org; Mon, 28 Jul 2014 05:26:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBhCK-00061u-OT for emacs-devel@gnu.org; Mon, 28 Jul 2014 05:26:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBhCD-0007uO-9g for emacs-devel@gnu.org; Mon, 28 Jul 2014 05:26:24 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:60744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBhC5-0007qY-4p; Mon, 28 Jul 2014 05:26:09 -0400 Original-Received: from [194.96.36.5] ([194.96.36.5]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MYOCL-1WyrAV04xN-00V5k6; Mon, 28 Jul 2014 11:26:06 +0200 In-Reply-To: <83tx62hane.fsf@gnu.org> X-Provags-ID: V03:K0:j3fAIK1kYkN9lIuRyiYsvyX5K9CbXI+KMcWpbnEtXvKjI9Ry7VH Hzkmt2+/zRWUWGQFdpoPiSv0UFxNaQj8AVYXKHiWHsiOyebWPgumbVH6fTXFUXOwLPmqdOy AhNZNx07KGS+snO2PdkALwYbS6OMHrezkozDScqHaNc81AOCf2QRr/rMG1GllL/Gtrec6Ws +G3y3hKZhPoTeJr47t/QQ== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.17.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:173203 Archived-At: >> Sounds pretty hairy, tho ... With bidi text as above do you have a >> fixed text width? > > I said "simple", didn't I? The width is not fixed. > >> In which (virtual L2R) column does R2L text start? > > Sorry, I don't understand the question. Are you asking about the > "normal" display of R2L text, or are you asking about scrolling? If you have L2R text here .... ..... and R2L text here what is the L2R position after here? If the text width is not fixed how can I calculate the width of a R2L line as it is displayed including any space between the left edge of the display until where the text ends? > What I added only works well if the entire visible portion of the > buffer has the same paragraph direction, either L2R or R2L. If you > have paragraphs in both directions visible, they will scroll in > opposite directions (because columns are counted in logical order, not > in visual order). IIUC this means that the slider width must be calculated paragraph-wise and position and size of the slider are meaningful only with respect to the paragraph point is currently in. > Horizontal scrolling of mixed-direction paragraphs is a hard problem. > A WYSIWYG word processor could behave as if the text width were fixed > (that's what happens on paper), but Emacs is not a WYSIWYG word > processor and supports line continuation. Admittedly, horizontal scroll bars are not very useful when line continuation is on. > So it's not clear what to > do here. The code I added is a stop-gap: it at least will DTRT when > the text on screen has the same base direction. We must have at least > that, or we will be lynched. Does it work now in that case? martin