From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#21835: 25.0.50; cursor height wrong when line-spacing is used Date: Mon, 21 Mar 2016 17:58:45 +0200 Message-ID: <8337rj7rgq.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1458576030 19343 80.91.229.3 (21 Mar 2016 16:00:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2016 16:00:30 +0000 (UTC) Cc: 21835@debbugs.gnu.org To: Nick Helm Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 21 17:00:19 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ai2Fe-0007f4-UR for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Mar 2016 17:00:19 +0100 Original-Received: from localhost ([::1]:58578 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ai2Fe-0007sG-71 for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Mar 2016 12:00:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ai2FT-0007fU-Mw for bug-gnu-emacs@gnu.org; Mon, 21 Mar 2016 12:00:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ai2FP-0001nx-5Q for bug-gnu-emacs@gnu.org; Mon, 21 Mar 2016 12:00:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ai2FP-0001nt-24 for bug-gnu-emacs@gnu.org; Mon, 21 Mar 2016 12:00:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ai2FO-00008C-Py for bug-gnu-emacs@gnu.org; Mon, 21 Mar 2016 12:00: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: Mon, 21 Mar 2016 16:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21835 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21835-submit@debbugs.gnu.org id=B21835.1458575958416 (code B ref 21835); Mon, 21 Mar 2016 16:00:02 +0000 Original-Received: (at 21835) by debbugs.gnu.org; 21 Mar 2016 15:59:18 +0000 Original-Received: from localhost ([127.0.0.1]:57135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ai2Eg-00006a-A3 for submit@debbugs.gnu.org; Mon, 21 Mar 2016 11:59:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58457) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ai2Ef-00006N-Ha for 21835@debbugs.gnu.org; Mon, 21 Mar 2016 11:59:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ai2EW-0001fA-5N for 21835@debbugs.gnu.org; Mon, 21 Mar 2016 11:59:12 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ai2EW-0001f1-22; Mon, 21 Mar 2016 11:59:08 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2810 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ai2EV-0007hB-6K; Mon, 21 Mar 2016 11:59:07 -0400 In-reply-to: (message from Nick Helm on Mon, 21 Mar 2016 17:03:42 +1300) 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115238 Archived-At: > From: Nick Helm > Date: Mon, 21 Mar 2016 17:03:42 +1300 > > Could the EOL cursor-height be set to the height of the tallest glyph in the > line? I don't think your problem is the height of the cursor. I think your problem is the vertical position of the lower edge of the cursor block. You should keep in mind that a glyph can (and normally does) rise above the base line of the display line, but it can also descent below that base line. So the height alone does not determine the cursor appearance, unless you also specify the vertical position of its lower edge. But to answer your question: we already do that, in a way. The display engine records the maximum vertical dimensions of the glyphs in a display line as it lays out each line. The EOL cursor simply uses these maximum values, both the max ascent value and the max descent value; the latter includes the line spacing. > In Emacs 24, my understanding is that cursor-height = line-height, where > line-height was determined by adding the height of the tallest glyph in the line > to the top and bottom vertical spacing. No, Emacs 24 didn't use the height of the tallest glyph. It didn't even track the height of individual glyphs. Instead, it used a single global value of height specified by the font. Some fonts specify very large value there, so this was changed to provide a better display. I explained this up-thread, see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21835#8 > Alternatively, how about setting the EOL cursor-height to the same height as the > last *displayable* glyph in the line, but with a lower size boundary? Tried that, it gave much worse results when the last glyph is very small -- a surprisingly frequent situation, because some fonts have their SPC glyph specify a small height. Limitation from below doesn't work because there are display features, such as the 'line-height' property, that become broken by such limitations. And then there are empty lines, of course. > If there are > no displayable glyphs in the line or the line is empty, could the height of the > closest previous displayable glyph be used, even if it's on an earlier line? If > the buffer is empty or contains no displayable glyphs, use (default line-height > - > line-spacing). This would slow down redisplay in many important cases, because redisplay optimizations frequently cause Emacs to lay out a single display line. What you suggest would require searching for the last non-empty line followed by costly layout of that line (to determine its height) even though that line doesn't need to be redrawn at all. The case of the empty line is actually one of the main reasons for the current behavior: we want the cursor on an empty line look the same as the EOL cursor on a non-empty line, and we want to do that without examining the glyphs of any other display lines. The other gotcha is to make sure the hollow cursor, drawn by default in non-selected windows, will have the same dimensions as the block cursor on the same character, otherwise switching to a different window will have unpleasant effect. These two cursors are drawn using 2 very different methods, so there be dragons. Anyway, you (or anyone else) are welcome to try different ideas for making the display of EOL cursor better, the relevant function is append_space_for_newline in xdisp.c. Just make sure you cover all the use cases uncovered by the various bugs referenced in the commits that changed the code of this function in the past ("git log -L" will show them). > If none of that's possible or causes more grief than it's worth, how about also > letting the user arbitrarily set the cursor height? I think you can do that already by customizing cursor-type to '(hbar . N)' where N is some suitable number that produces the cursor you like.