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, 18 Aug 2014 10:31:38 +0200 Message-ID: <53F1B9EA.6030808@gmx.at> References: <53CE6A44.1010708@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> <831tt4h58x.fsf@gnu.org> <83y4vcfoqi.fsf@gnu.org> <53D77BDB.1090500@gmx.at> <83wqawflgj.fsf@gnu.org> <53D7A981.30909@gmx.at> <83lhrctdzr.fsf@gnu.org> <53D7C10C.4010402@gmx.at> <83k36wta5m.fsf@gnu.org> <53D7E6B0.7040504@gmx.at> <83egx4t3nq.fsf@gnu.org> <53D917B5.2050604@gmx.at> <837g2uu80w.fsf@gnu.org> <53D9211C.7010000@gmx.at> <834mxyu5jg.fsf@gnu.org> <53D92D04.3010006@gmx.at> <83zjfqspfw.fsf@gnu.org> <53DA0310.4010706@gmx.at> <53DA15C4.5050006@gmx.at> <83mwbpss6s.fsf@gnu.org> <53DA29EC.3000504@gmx.at> <837g2ssg30.fsf@gnu.org> <53DB6B08.7000305@gmx.at> <834mxws6a0.fsf@gnu.org> <53DBB268.2020909@gmx.at> <831tt0rwyp.fsf@gnu.org> <53EE2CD5.50603@gmx.a> <83tx5demej.fsf@gnu.org> <53EF25F2.9010909@gmx.at> <83iolsekqd.fsf@gnu.org> <53EF609C.2090303@gmx> <83wqa7cfoy.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1408350732 3282 80.91.229.3 (18 Aug 2014 08:32:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Aug 2014 08:32:12 +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 Aug 18 10:32:05 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 1XJIMH-0005Ym-AB for ged-emacs-devel@m.gmane.org; Mon, 18 Aug 2014 10:32:05 +0200 Original-Received: from localhost ([::1]:42377 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJIMG-0008Nr-Qy for ged-emacs-devel@m.gmane.org; Mon, 18 Aug 2014 04:32:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJIM5-0008Mq-6Z for emacs-devel@gnu.org; Mon, 18 Aug 2014 04:32:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XJILx-0002Lf-Lc for emacs-devel@gnu.org; Mon, 18 Aug 2014 04:31:53 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:62819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJILx-0002LW-Br; Mon, 18 Aug 2014 04:31:45 -0400 Original-Received: from [178.190.166.128] ([178.190.166.128]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lfjxq-1WZS4b1wWQ-00pL1x; Mon, 18 Aug 2014 10:31:43 +0200 In-Reply-To: <83wqa7cfoy.fsf@gnu.org> X-Provags-ID: V03:K0:2y0k1s1vq1SwHgoTkSN9ZqAwGZyPnbkefKWITbaGRnNmcoOuj78 xuQ9dI0MR7rsreTGWNnQecJojgKN/+cDRojmN2+eA16h9Vx/BOZBkYUSe8f0Cc3eFRJ9gn/ lXmk8kOzfpU64WqH9WLPom6mX/GGsODgDxbExcV/ZLx2dvzEXAhPPCNXbbcsrbJjxCyKe+W KMN84K9sjh6Drghq96uFQ== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.15.18 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:173735 Archived-At: >> (1) When dragging I cannot move the slider entirely to the right and >> make the first column of R2L lines visible until I release the = mouse >> button. I suppose this is due to some off-by-one failure here = but >> there might be more to it. > > I'm not sure this is at all related to R2L lines. I wrote a trivial > function which just displays the mouse event, and bound it to clicks > on the horizontal scroll bar. When I drag the scroll bar, even in an > entirely L2R buffer, I see some strange phenomena: e.g., more often > than not, when I drag the bar all the way to the right, releasing the > mouse button without moving the mouse reports slightly different > coordinates than the ones reported before releasing the mouse. > Moreover, many time the 2nd coordinate reported after releasing the > mouse is -1. Try it. Maybe it's Windows-specific, I don't know. I suppose the -1 is due to the si.nPage =3D min (portion, si.nMax) + 1; you mention below and that's likely the culprit for the effect described in (1). > Btw, it looks like the information returned by mouse events on the > horizontal scroll bar is not described anywhere, not even in NEWS. > Your use of (cdr (nth 2 start-position)) in > scroll-bar-horizontal-drag-1 got my jaw dropped for a few seconds, > before I realized it was not the Y coordinate... I'm not sure yet where to eventually put this and whether it's the right solution at all. IIUC the scroll bar area on the right of the thumb stan= ds for w->hscroll in R2L text and this was the easiest way to pass on that value from what GetScrollInfo returns without consing. If you have any suggestion how to handle this cleanly I'd be all ears. > Also, I don't understand the subtlety of +1 in setting up the scroll > info, e.g.: > > /* Allow nPage to be one larger than nPos so we don't allow to scro= ll > an already fully visible buffer. */ > si.nPage =3D min (portion, si.nMax) + 1; > si.nPos =3D min (position, si.nMax); > > The comment doesn't correspond to the code, and I couldn't understand > what's behind this trick. The idea is that if I do not add 1 to nPage, the displayed thumb gets too small. This means that although I see the entire text I can still scroll it and make the first column disappear, which is distracting. I've not found a better solution yet. In any case, this is my probably poor interpretation of how SetScrollInfo works (compare http://msdn.microsoft.com/en-us/library/windows/desktop/bb787595%28v=3Dvs= =2E85%29.aspx The nPage member must specify a value from 0 to nMax - nMin +1. The nPos member must specify a value between nMin and nMax - max( nPage=E2=80=93 1= , 0)). And yes, the comment is obviously wrong. >> (2) Sometimes during dragging the slider starts moving for-/backward = in >> some erratic fashion. I'm not yet sure whether this is caused = by an >> hmargin issue or something else. > > I could only see this in the very first line of the tutorial. There > was an old and very subtle bug in xdisp.c, revealed by > set_horizontal_scroll_bar, which caused broken cursor motion in that > line. This is now fixed in r117711 on the trunk. If you still see > something like that, and it's not related to the few L2R lines in the > tutorial, please report a bug with the recipe. I can see it only with my personal setup here. With emacs -Q I can reproduce it by setting (set-frame-parameter nil 'right-divider-width 7) and scrolling the tutorial in the left window of a C-x 3 split frame. >> (3) Line 121 (written backwards as) >> >> =D7=90=D7=9D =D7=94=D7=A1=D7=9E=D7=9F =D7=A0=D7=9E=D7=A6=D7=90 =D7=91= =D7=90=D7=9E=D7=A6=D7=A2 =D7=9E=D7=99=D7=9C=D7=94, M-f =D7=96=D7=96 =D7=9C= =D7=A1=D7=95=D7=A3 =D7=94=D7=9E=D7=99=D7=9C=D7=94. =D7=90=D7=9D =D7=94=D7= =A1=D7=9E=D7=9F =D7=A0=D7=9E=D7=A6=D7=90 =D7=91=D7=99=D7=9F =D7=A9=D7=AA=D7= =99 =D7=9E=D7=9C=D7=99=D7=9D, >> >> of the tutorial presents a special problem: When I'm repeatedly = doing >> `next-line' on the rightmost column before that line and are abo= ut >> to move to that line I enter some strange sort of loop with the >> slider in the center of the scroll bar trying to move back- and >> forward. C-g gets me out of it but I can't tell so far why I'm = stuck >> there. > > This is now fixed in r117447 on the release branch. The previous > revision fixed bug #18277. Fine. These work well now. martin