From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: "... the window start at a meaningless point within a line." Date: Thu, 1 Oct 2015 11:02:04 +0000 Message-ID: <20151001110204.GB2515@acm.fritz.box> References: <20150930204513.GA3174@acm.fritz.box> <83mvw39dp3.fsf@gnu.org> <20151001094138.GA2515@acm.fritz.box> <83h9maao7w.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1443711174 1354 80.91.229.3 (1 Oct 2015 14:52:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 14:52:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 01 16:52:47 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 1ZhfDz-0001bM-5R for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 16:52:47 +0200 Original-Received: from localhost ([::1]:51239 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhfDy-0001cc-EL for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 10:52:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhbbP-0001g8-AO for emacs-devel@gnu.org; Thu, 01 Oct 2015 07:00:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhbbK-0006bB-Rd for emacs-devel@gnu.org; Thu, 01 Oct 2015 07:00:43 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:36002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhbbJ-0006Up-Ud for emacs-devel@gnu.org; Thu, 01 Oct 2015 07:00:38 -0400 Original-Received: (qmail 92288 invoked by uid 3782); 1 Oct 2015 11:00:35 -0000 Original-Received: from acm.muc.de (p5B14722A.dip0.t-ipconnect.de [91.20.114.42]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 01 Oct 2015 13:00:35 +0200 Original-Received: (qmail 2829 invoked by uid 1000); 1 Oct 2015 11:02:04 -0000 Content-Disposition: inline In-Reply-To: <83h9maao7w.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 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:190551 Archived-At: Hello, Eli. On Thu, Oct 01, 2015 at 01:16:03PM +0300, Eli Zaretskii wrote: > > Date: Thu, 1 Oct 2015 09:41:38 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > > In the Elisp manual, page "Window Start and End", it's described how, if > > > > in (set-window-start x) x is a position not at the start of a line, the > > > > display engine will, instead of x, choose some value near x as the > > > > window start. Is this really necessary? > > > The reason for this is that we want the physical beginning of the line > > > (i.e. the character after a newline or at bob) always be aligned at > > > the left edge of the window's text area, even if it is currently out > > > of view. This prevents annoying horizontal scrolling of long lines > > > when the beginning of the line comes into view. > > OK. But we're really talking here about where continuation lines start, > > not physical BOLs. > 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? > 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. This would ensure that every character on the line would be displayed exactly once, both when the line straddles W2 and W3, and after it is scrolled entirely onto W3. > > > But let me turn the table and ask you: how difficult would it be to > > > make sure follow-mode never lets a window end in the middle of a > > > continued line? > > 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. 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. 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. > > In real life? I imagine it's quite common to use Follow Mode with very > > narrow windows (say, four at ~60 wide) when the annoyance of continued > > lines is less important than seeing all of a long function on the screen > > at once. There will then be lots of continued lines, and 3 window > > boundaries, W1-W2, W2-W3, W3-W4. > I don't expect "lots", except in text buffers. Program sources > usually have shorter lines. In any case, it would be rare to see > lines that take more than 2 screen lines. > > 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. -- Alan Mackenzie (Nuremberg, Germany).