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: Tue, 29 Jul 2014 12:41:02 +0300 Message-ID: <831tt4h58x.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> <83egx5h86z.fsf@gnu.org> <53D68806.9080101@gmx.at> <838undgxiu.fsf@gnu.org> <53D76758.2030707@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1406626868 10860 80.91.229.3 (29 Jul 2014 09:41:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Jul 2014 09:41:08 +0000 (UTC) Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 29 11:41:00 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 1XC3u0-0000eD-6z for ged-emacs-devel@m.gmane.org; Tue, 29 Jul 2014 11:41:00 +0200 Original-Received: from localhost ([::1]:44429 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XC3tz-0007XG-Pl for ged-emacs-devel@m.gmane.org; Tue, 29 Jul 2014 05:40:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XC3ts-0007Wy-VM for emacs-devel@gnu.org; Tue, 29 Jul 2014 05:40:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XC3tn-0004z6-EJ for emacs-devel@gnu.org; Tue, 29 Jul 2014 05:40:52 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:47866) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XC3tn-0004yu-0V for emacs-devel@gnu.org; Tue, 29 Jul 2014 05:40:47 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N9G00J00VUWDH00@mtaout27.012.net.il> for emacs-devel@gnu.org; Tue, 29 Jul 2014 12:36:08 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9G009YCW08HSA0@mtaout27.012.net.il>; Tue, 29 Jul 2014 12:36:08 +0300 (IDT) In-reply-to: <53D76758.2030707@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:173240 Archived-At: > Date: Tue, 29 Jul 2014 11:20:24 +0200 > From: martin rudalics > CC: jan.h.d@swipnet.se, emacs-devel@gnu.org > > >> I still have no feeling for how hscrolling works with bidi text. IIUC > >> with L2R and R2L paragraphs in the same window, like > >> > >> LLLLLLLLLLLLLLLLLLLLLL2RRRRRRRRRRRRRRRRRRR > >> > >> RRRRRRR2LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL > >> > >> hscrolling will NOT preserve the aspect that the two "2" visually appear > >> above each other. Correct? > > > > Yes. As the hscroll amount grows, the characters in the L2R lines > > will move to the left, while characters in the R2L lines will move to > > the right. > > I have to think about the possible implications of this. Maybe there > are none but putting this model into my brain will take some time. As long as we use logical-order columns, there really isn't any alternative to this behavior. > > It's a hard problem primarily because it's hard to know what is TRT, > > and there's no "prior art" to follow. > > Because all the others keep the "2"s from my example fixed above each > other, I presume. Yes, because all the others (those I know of) are WYSIWYG word processors, where the page size has a well-defined meaning and is fixed within a given document. > I didn't mean that you should check whether hscroll works. What I meant > was to check whether the slider/thumb size really relates to the size of > the longest line of text, disregarding the fact that it is L2R or R2L. Line width calculations, like column calculations, are unaffected by bidi. These calculations are done using buffer text in its logical order, so the way text is displayed cannot have any effect on that. So if we can correctly compute the length of the longest line at all, we can do it with any text, bidi or not. Therefore, the size of the thumb will always be true (and is, I checked that, of course). > > You need to reverse the meaning of START and END for the R2L case: > > > > end = whole - w->hscroll * FRAME_COLUMN_WIDTH (WINDOW_XFRAME (w)); > > start = end - box_width; > > > > (Note that current-bidi-paragraph-direction returns the results at > > buffer's point, so you will need to temporarily go to the window's > > point marker.) > > As soon as you have some spare time (I know you never do) please try it. I can only try this on MS-Windows.