From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Changes in frame/window code Date: Mon, 28 Jul 2014 16:38:14 +0300 Message-ID: <83fvhlhad5.fsf@gnu.org> 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> <53D6172A.5010909@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1406554705 24556 80.91.229.3 (28 Jul 2014 13:38:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Jul 2014 13:38:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 28 15:38:18 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 1XBl86-00064c-7Q for ged-emacs-devel@m.gmane.org; Mon, 28 Jul 2014 15:38:18 +0200 Original-Received: from localhost ([::1]:39781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBl85-0001gh-Rr for ged-emacs-devel@m.gmane.org; Mon, 28 Jul 2014 09:38:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBl7w-0001fX-Vb for emacs-devel@gnu.org; Mon, 28 Jul 2014 09:38:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBl7o-0004eu-P8 for emacs-devel@gnu.org; Mon, 28 Jul 2014 09:38:08 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:33631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBl7o-0004en-HP for emacs-devel@gnu.org; Mon, 28 Jul 2014 09:38:00 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0N9F00100CB2QX00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Mon, 28 Jul 2014 16:37:58 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9F0012HCJAMWA0@a-mtaout21.012.net.il>; Mon, 28 Jul 2014 16:37:58 +0300 (IDT) In-reply-to: <53D6172A.5010909@gmx.at> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:173211 Archived-At: > Date: Mon, 28 Jul 2014 11:26:02 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org > > >> 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? If you include the space on the left, then the width of an R2L display line is always exactly equal to the window width. This is how the display engine computes the width of the stretch glyph that represents "the space on the left". If you want the line width without the stretch, then you calculate it exactly like with L2R lines: columns and line widths are computed in the logical order. > > 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. Yes. But that is true for strictly L2R text as well, no? I mean, the size of the scroll-bar thumb should depend on the width of the line at point, right? > > 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. Of course, but that's not what I meant. I meant to point out how Emacs in its default text display modes differs from WYSIWYG word processors, where fixed width of the text comes in naturally. > > 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? It does work correctly when you click on the scroll-bar arrows or between them and the slider. It doesn't work when you drag the slider. When you drag the slider, the text is scrolled in the wrong direction. The underlying problem is that the slider starts in a wrong position -- it should be all the way to the right, not to the left. AFAIU, this can only be fixed on the C level. (Btw, shouldn't GTK scroll bars already support bidirectional text out of the box? Perhaps you need to set some flag(s) to get that.)