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#5718: scroll-margin in buffer with small line count. Date: Sun, 22 Jan 2017 19:58:32 +0200 Message-ID: <83shob3rjr.fsf@gnu.org> References: <4B9D1C61.70903@gmail.com> <87mvkjy0l5.fsf@users.sourceforge.net> <83fuqbfhpb.fsf@gnu.org> <87a8ggwcoo.fsf@users.sourceforge.net> <83inv4cc0s.fsf@gnu.org> <87d1ka17dr.fsf@users.sourceforge.net> <834m5l9g1d.fsf@gnu.org> <874m5j19wi.fsf@users.sourceforge.net> <83zina75pa.fsf@gnu.org> <87pok555q4.fsf@users.sourceforge.net> <831swfcmhz.fsf@gnu.org> <871sw6z32n.fsf@users.sourceforge.net> <83o9zaax8x.fsf@gnu.org> <87k29wxam1.fsf@users.sourceforge.net> <83a8ar9bl6.fsf@gnu.org> <87pojguu7m.fsf@users.sourceforge.net> <83d1fg5iku.fsf@gnu.org> <87inp7ui27.fsf@users.sourceforge.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1485108021 18709 195.159.176.226 (22 Jan 2017 18:00:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2017 18:00:21 +0000 (UTC) Cc: ahyatt@gmail.com, 5718@debbugs.gnu.org, gavenkoa@gmail.com To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 22 19:00:17 2017 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 1cVMR1-00045j-KB for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Jan 2017 19:00:11 +0100 Original-Received: from localhost ([::1]:37264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVMR6-00075x-SY for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Jan 2017 13:00:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVMQw-00071E-OT for bug-gnu-emacs@gnu.org; Sun, 22 Jan 2017 13:00:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cVMQt-0003Qj-NO for bug-gnu-emacs@gnu.org; Sun, 22 Jan 2017 13:00:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40258) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cVMQt-0003QX-Ke for bug-gnu-emacs@gnu.org; Sun, 22 Jan 2017 13:00:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cVMQt-0000RM-A4 for bug-gnu-emacs@gnu.org; Sun, 22 Jan 2017 13:00:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Jan 2017 18:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5718 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 5718-submit@debbugs.gnu.org id=B5718.14851079421586 (code B ref 5718); Sun, 22 Jan 2017 18:00:03 +0000 Original-Received: (at 5718) by debbugs.gnu.org; 22 Jan 2017 17:59:02 +0000 Original-Received: from localhost ([127.0.0.1]:38457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cVMPu-0000PV-Ku for submit@debbugs.gnu.org; Sun, 22 Jan 2017 12:59:02 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:43054) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cVMPt-0000P3-Hn for 5718@debbugs.gnu.org; Sun, 22 Jan 2017 12:59:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cVMPl-0003DD-3k for 5718@debbugs.gnu.org; Sun, 22 Jan 2017 12:58:56 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43528) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVMPY-00035b-TB; Sun, 22 Jan 2017 12:58:40 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3917 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cVMPU-0008Gy-P5; Sun, 22 Jan 2017 12:58:37 -0500 In-reply-to: <87inp7ui27.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) 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:128312 Archived-At: > From: npostavs@users.sourceforge.net > Cc: 5718@debbugs.gnu.org, ahyatt@gmail.com, gavenkoa@gmail.com > Date: Sun, 22 Jan 2017 12:21:20 -0500 > > > When you copy the iterator structure and modify the copy, you need to > > save and restore the bidi cache, using SAVE_IT and RESTORE_IT macros. > > Otherwise, the code which calls this function will work incorrectly if > > it uses the original iterator after the call, because the bidi cache > > is not restored to its state before the call. > > I came up with this modified version of partial_line_height, which does > actually work. It looks good to me, thanks. > Having to do RESTORE_IT (&it, &it, it_data) is a bit > unintuitive though. I don't understand what the typical use case of > this macro is, if it's going to copy back the new state into the > original `it', then why use a separate `it' in the first place? If you don't modify the original iterator object, then you indeed don't need to copy back, you only need to restore the bidi cache state, by calling bidi_unshelve_cache directly, as some code fragments actually do. (The macro refrains from copying if the two arguments point to the same object, so it transparently does this for you.) More generally, two separate arguments are needed because some of the macro uses choose one of several copies to copy back. For example: if (result == MOVE_LINE_CONTINUED && it->line_wrap == WORD_WRAP && wrap_it.sp >= 0 && ((atpos_it.sp >= 0 && wrap_it.current_x < atpos_it.current_x) || (atx_it.sp >= 0 && wrap_it.current_x < atx_it.current_x))) RESTORE_IT (it, &wrap_it, wrap_data); else if (atpos_it.sp >= 0) RESTORE_IT (it, &atpos_it, atpos_data); else if (atx_it.sp >= 0) RESTORE_IT (it, &atx_it, atx_data); The general paradigm is: . save 'it' in some local variable . modify 'it' . restore 'it' from the local variable . continue using 'it' as if the modification never happened > By the way, while testing I noticed that `set-window-text-height' > doesn't take `line-spacing' into account, should it? No, because it returns its value in canonical line units, which means no line-spacing.