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 17:25:08 +0300 Message-ID: <83egx5h86z.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> <83fvhlhad5.fsf@gnu.org> <53D656BB.3010201@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1406557519 3751 80.91.229.3 (28 Jul 2014 14:25:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Jul 2014 14:25:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics , Jan =?iso-8859-15?Q?Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 28 16:25:12 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 1XBlrS-0000W5-31 for ged-emacs-devel@m.gmane.org; Mon, 28 Jul 2014 16:25:10 +0200 Original-Received: from localhost ([::1]:40028 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBlrR-000598-NE for ged-emacs-devel@m.gmane.org; Mon, 28 Jul 2014 10:25:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBlrK-00055n-52 for emacs-devel@gnu.org; Mon, 28 Jul 2014 10:25:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBlrC-00045D-Ut for emacs-devel@gnu.org; Mon, 28 Jul 2014 10:25:02 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:36059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBlrC-00044g-Ht for emacs-devel@gnu.org; Mon, 28 Jul 2014 10:24:54 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N9F00O00E8LYU00@mtaout27.012.net.il> for emacs-devel@gnu.org; Mon, 28 Jul 2014 17:20:17 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9F00L2YEHS9S50@mtaout27.012.net.il>; Mon, 28 Jul 2014 17:20:17 +0300 (IDT) In-reply-to: <53D656BB.3010201@gmx.at> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 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:173213 Archived-At: > Date: Mon, 28 Jul 2014 15:57:15 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org > > > 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". > > But if that R2L line starts on the right of the right window edge it's > larger, I presume. You mean, if it's hscrolled? Yes, of course -- exactly like an L2R line. I feel there's some misunderstanding here, because I don't believe you'd ask about such trivia. What am I missing? What's bothering you? Perhaps it will help if I say (something that should be obvious, but maybe it's only obvious to me...) that an R2L line behaves wrt hscrolling the same as an L2R line, except that it is reversed on display. E.g., when the amount of hscroll gets larger, and R2L line moves to the right, thus removing from sight the first (rightmost on display) characters of the line. > > 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. > > Hmmm... That would mean my calculations in > > whole = move_it_to (&it, -1, INT_MAX, window_box_height (w), -1, > MOVE_TO_X | MOVE_TO_Y); > > of set_horizontal_scroll_bar have a flaw. No, I don't think there's a flaw. The move_it_* family of functions doesn't know about reversal of R2L lines on display, they think an R2L line is displayed starting at the left margin of the window. See the commentary about that at the beginning of xdisp.c. > >> 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? > > No. The slider size repesents the width of the window with respect to > the longest line shown in the window. Try moving point through the > first column within a window - the slider size should not change. Then I don't see why you think this should change when there's bidirectional text in the buffer. The same arguments work in that case as well. R2L lines do not affect the window width in any way that L2R lines don't. > > 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. > > Is the size of the slider correct in the sense described above? Yes. > Then fixing the position should not be that difficult. I never said it was difficult, just that it has to be on the C level, not on the Lisp level, where I fixed the clicks on the scroll bar. > > (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.) > > No idea. Maybe Jan (CC'ed) can help us out. > In any case I would have to tell GTK whether the "current text" > (whatever that is) is L2R or R2L I suppose. Yes, but we have current-bidi-paragraph-direction for that.