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: "... the window start at a meaningless point within a line." Date: Thu, 01 Oct 2015 15:03:09 +0300 Message-ID: <83egheaj9e.fsf@gnu.org> References: <20150930204513.GA3174@acm.fritz.box> <83mvw39dp3.fsf@gnu.org> <20151001094138.GA2515@acm.fritz.box> <83h9maao7w.fsf@gnu.org> <20151001110204.GB2515@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1443715339 9018 80.91.229.3 (1 Oct 2015 16:02:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 16:02:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 01 18:02:07 2015 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 1ZhgJ3-0002Xv-7O for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 18:02:05 +0200 Original-Received: from localhost ([::1]:52459 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhgJ2-0003v2-LH for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 12:02:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhca5-0003hg-VJ for emacs-devel@gnu.org; Thu, 01 Oct 2015 08:03:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zhca1-0008IA-Iy for emacs-devel@gnu.org; Thu, 01 Oct 2015 08:03:25 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:61487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhca1-0008Gz-9G for emacs-devel@gnu.org; Thu, 01 Oct 2015 08:03:21 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NVJ00800IR5V700@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Thu, 01 Oct 2015 15:03:19 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVJ008PJITJQU20@a-mtaout22.012.net.il>; Thu, 01 Oct 2015 15:03:19 +0300 (IDT) In-reply-to: <20151001110204.GB2515@acm.fritz.box> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:190555 Archived-At: > Date: Thu, 1 Oct 2015 11:02:04 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > The display engine always starts from the physical BOL when it lays > > out buffer text. That's because only at a physical BOL it knows that > > the window-relative X coordinate is zero. Otherwise, there's no > > anchor for it to start at. > > OK, so such a change would be, at least somewhat, non-trivial. Could the > supplied window start position, as in (set-window-start line-middle-pos > nil t), not count as such an anchor? It cannot act as an anchor, because the horizontal X coordinate is not (and cannot be) known by the caller. > > Invalidating this basic assumption will cause strange effects, > > including the horizontal scrolling I mentioned. > > This horizontal scrolling (of a long line at the top of W3, when a > scroll-down brings the beginning of the line onto the window) would be > precisely what's wanted here. Then go ahead and make the change. The display engine will cope. I'm not sure what users will say, but that's not my problem here ;-) > > > In the worst case, very difficult. Indeed, with three follow windows, > > > all of slightly different widths, and a fiendish specially constructed > > > file, it could be that when you scroll the buffer a single screen line to > > > deal with a break between W1 and W2, you create the same problem between > > > W2 and W3. In such a scenario, you might end up scrolling the buffer > > > quite a long way in the search for no "broken" continued lines at either > > > boundary. With such a file there might be NO position where there isn't > > > a break. > > > Are you talking about lines so long that they take more than one > > window-full to display? If so, let's not bother about those for the > > moment. Do you see such problem with reasonably short lines? > > No, I was just thinking of ordinary 100 character lines in ordinary > windows. Then I don't see the problem. yes, you will need to scroll several lines, but why is that a problem? > Let me outline the problem I saw: I have a command `scrolldown-n', bound > to S-. With point in W3, S- was failing to scroll the screen. > The cause was the split line making (window-end W2) different from > (window-start W3), which messed up Follow Mode's window alignment > routines. I understood. If you never break in the middle of a continued line, this should not happen. > Another (lesser) problem is moving point from W2 to W3 with C-x o > sometimes causes W1 and W2 to scroll up one line; this has the same > cause. It is suboptimal. IIUC, you will not be able to fix this. Changes near the boundary between 2 windows will always be likely to cause some scrolling like that. > > > If we were to go this route (of repositioning to avoid line breaks > > > between follow windows), there would have to be a limit on how far one > > > could scroll, with a value such as 3. > > > In what units? Screen lines? Why only 3? > > Yes, 3 screen lines. With a command like `scrolldown-n', or C-u 1 > , the user is requesting a single line scroll. Scrolling more > than this, even 2 or 3 lines, would be puzzling and irritating. Not sure if horizontal scrolling will be more or less irritating, but I guess we will find out soon.