From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#31276: 27.0.50; "Spurious" empty first line from before-string Date: Sat, 28 Apr 2018 17:04:09 +0300 Message-ID: <838t97tokm.fsf@gnu.org> References: <83fu3fu0r9.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1524924189 4327 195.159.176.226 (28 Apr 2018 14:03:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 28 Apr 2018 14:03:09 +0000 (UTC) Cc: 31276@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 28 16:03:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fCQRM-00011W-RM for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Apr 2018 16:03:05 +0200 Original-Received: from localhost ([::1]:52260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fCQTS-0003me-TA for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Apr 2018 10:05:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fCQTK-0003mY-2V for bug-gnu-emacs@gnu.org; Sat, 28 Apr 2018 10:05:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fCQTG-00031u-Re for bug-gnu-emacs@gnu.org; Sat, 28 Apr 2018 10:05:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34218) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fCQTG-00031i-O3 for bug-gnu-emacs@gnu.org; Sat, 28 Apr 2018 10:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fCQTG-0006FB-D6 for bug-gnu-emacs@gnu.org; Sat, 28 Apr 2018 10:05:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Apr 2018 14:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31276 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31276-submit@debbugs.gnu.org id=B31276.152492427823962 (code B ref 31276); Sat, 28 Apr 2018 14:05:02 +0000 Original-Received: (at 31276) by debbugs.gnu.org; 28 Apr 2018 14:04:38 +0000 Original-Received: from localhost ([127.0.0.1]:42115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fCQSr-0006EQ-RW for submit@debbugs.gnu.org; Sat, 28 Apr 2018 10:04:38 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fCQSq-0006EE-2x for 31276@debbugs.gnu.org; Sat, 28 Apr 2018 10:04:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fCQSh-0002iU-Ol for 31276@debbugs.gnu.org; Sat, 28 Apr 2018 10:04:30 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fCQSh-0002iM-LY; Sat, 28 Apr 2018 10:04:27 -0400 Original-Received: from [176.228.60.248] (port=3732 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fCQSh-0002Ju-5y; Sat, 28 Apr 2018 10:04:27 -0400 In-reply-to: (message from Stefan Monnier on Sat, 28 Apr 2018 09:13:18 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:145802 Archived-At: > From: Stefan Monnier > Cc: 31276@debbugs.gnu.org > Date: Sat, 28 Apr 2018 09:13:18 -0400 > > >> % src/emacs -Q etc/NEWS --eval '(let ((ol (make-overlay (+ (point) 10) > >> (+ (point) 10)))) (overlay-put ol (quote before-string) "\nhello\n"))' > >> C-u 1 C-v > >> You should see that the "scroll by 1 line" didn't actually scroll: it just > >> removed the "GNU Emacs " from your sight and left an empty line instead. > > After "C-u 1 C-v", type C-p, then type "C-u 1 C-v" again. What do you > > see? > > I see the display go > > GNU Emacs > > hello > NEWS ... > > i.e. I get a *really* spurious line. This one is clearly a bug. Is it? The overlay string starts with a newline, and that's what you see here. Buffer position 11 is the 'N' of NEWS, and you asked Emacs to prepend "\nhello\n" to that, which it did. The newline after "Emacs", which comes from the buffer text, is still visible. So why is this a bug? > > It sounds very strange to me to do so. > > That was also my first reaction, but redisplay can arguably choose (to > some extent) at which line it starts the display, so if you skip some > leading newline you still get a valid result. The "to some extent" is > because sometimes the redisplay can't really choose (i.e. when > window-start has been fixed), but in the current case, even if > window-start is fixed there are several possible choices of "first line" > to display, so even in that case the result is still valid. window-start is a buffer position. The way redisplay is designed, scrolling determines which buffer position will serve as window-start, and then it advises redisplay to use that window-start. But the only information passed to redisplay is the buffer position, so we currently cannot tell redisplay "use that position, but skip such-and-such parts of the overlay string at that position. As result, Emacs will display starting at that position, and the first thing it finds there is the overlay string. So it displays that string. > > Whoever puts the newlines there does that for a reason, > > To divide the (previous) line, but not to introduce an empty line. Two consecutive newlines, one comping from buffer text, the other from an overlay string _must_ produce an empty line. What else can you expect? > > and I'm sure will object to having them effectively removed in > > some situations. > > I put the newlines there and I definitely would not object. > Better yet, I'd report a bug if the newline isn't removed. That's exactly what's strange to me. You put the newline there, but you don't want to see it? Then don't put it there in the first place. I'm probably missing something here.