From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.bugs Subject: bug#37641: major/minor tick faces bleed into empty lines at the end of buffer Date: Tue, 8 Oct 2019 11:37:04 +0200 Message-ID: References: <83zhiczg1m.fsf@gnu.org> <83sgo3y632.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000052626b059462eb7d" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="70879"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37641@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 08 11:38:14 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iHlwc-000IJn-5I for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Oct 2019 11:38:14 +0200 Original-Received: from localhost ([::1]:52988 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iHlwZ-0005Hq-WB for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Oct 2019 05:38:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37652) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iHlwS-0005HF-2Q for bug-gnu-emacs@gnu.org; Tue, 08 Oct 2019 05:38:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iHlwQ-0002m7-Ic for bug-gnu-emacs@gnu.org; Tue, 08 Oct 2019 05:38:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40773) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iHlwQ-0002lu-Fv for bug-gnu-emacs@gnu.org; Tue, 08 Oct 2019 05:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iHlwQ-00030O-D6 for bug-gnu-emacs@gnu.org; Tue, 08 Oct 2019 05:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juanma Barranquero Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Oct 2019 09:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37641 X-GNU-PR-Package: emacs Original-Received: via spool by 37641-submit@debbugs.gnu.org id=B37641.157052746711525 (code B ref 37641); Tue, 08 Oct 2019 09:38:02 +0000 Original-Received: (at 37641) by debbugs.gnu.org; 8 Oct 2019 09:37:47 +0000 Original-Received: from localhost ([127.0.0.1]:49593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iHlwB-0002zp-D4 for submit@debbugs.gnu.org; Tue, 08 Oct 2019 05:37:47 -0400 Original-Received: from mail-qt1-f177.google.com ([209.85.160.177]:39212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iHlw9-0002zb-4c for 37641@debbugs.gnu.org; Tue, 08 Oct 2019 05:37:45 -0400 Original-Received: by mail-qt1-f177.google.com with SMTP id n7so24223443qtb.6 for <37641@debbugs.gnu.org>; Tue, 08 Oct 2019 02:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XDuaAu/VO6TvxJjH4IIF2ZvWo9ejhbbm6aIgOUShV8Y=; b=lhdrfytWiqp052pVvwjg7tLK/Sn7RoiyFz6Jm5QbEkyBXp3b1/WsNigzvmZ72YrZzi wKwq918zdl9om4U97q8iuNf4ZoFND7okALbNWGNU2w6GIKvSj6qiCeKDsnbtH37k53Th /5v7ACaikigCALuwFxeAK8OG7FjHPS5X0Kri+4KuFrTV9c1iI2RH9vmQKa1ocsu5srek Rrx0LStrbehf3/VzcDNqzENZ72/zjZeZSMQ43MyvcXnIgAVhFm/O15p4Faxx54rTjbP0 9w17P3X0P6Vz3KhFcZGJgOK7IScXsvEt0QxaijnCYyaC8eoZivzsH5yXvQm1+JZrqRCj NdDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XDuaAu/VO6TvxJjH4IIF2ZvWo9ejhbbm6aIgOUShV8Y=; b=QrQHjYSh+Irz9gIxn2zyzAOCN2sZblIAmDks40GsL4M0H/WvBlicKMRjpTJwpFGGjT YdXVdQ5c83ptjqypxHijjeaqENGb1oFZ7p57Hpp4brVE39qE39ZO3xWgviJNaVCV2v2P cE/G/BflfkfcU8Ek4l7YFawzrV9CiCZvdnpboZ1jiySXhkjxSlqWe6PY0HAKFcs/Dufl FVdgWv6YGdEKMlUjRt+BFETJcPjO61fJzdgbpIn/MvI8n4vw8nKQkXGQhKjTWmoktGBR MQZFzyF2Y1RJooTrHrPYwDg3Y94rjHOg7e5EdzbD0ZrcQi7YSSXfsEJ2bYFmZUigvugA 0U2Q== X-Gm-Message-State: APjAAAXEHhCiMYx2xWPTFFy9XoSF6uGjOyXivAD+efhlZAT1k3iagZAy X+kHucYOt7Itxd439S3aes+rzKTHvaCbRjOQfr4RuG9x X-Google-Smtp-Source: APXvYqz5+5idRxoeijUp7lV7s78oOwJeGGnGcV6ZH7JMCSSxobhWjC1hRKT/5A4e+Z/U0qdxhP3JR96yUssIdfttksE= X-Received: by 2002:ac8:5448:: with SMTP id d8mr18214394qtq.287.1570527459302; Tue, 08 Oct 2019 02:37:39 -0700 (PDT) In-Reply-To: <83sgo3y632.fsf@gnu.org> 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: 209.51.188.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:168629 Archived-At: --00000000000052626b059462eb7d Content-Type: text/plain; charset="UTF-8" On Tue, Oct 8, 2019 at 10:50 AM Eli Zaretskii wrote: > Sorry, I don't think I understand what the images show me. They seem > identical. Which face bleeds and where? Please point out what should > I be looking at to understand the difference. In both images, the line numbered 19 is the last line in the buffer. In the it_eob image, the "line" past the end of the buffer has an empty number, drawn with the major-tick face (but obviously without number). The rest of non-lines, until the end of the buffer, have their empty number drawn in the line-number face. In the beyond_zv image, the empty line after the end of the buffer is in the line-number face, as all the other past that point. I think that's the right behavior. There's no reason for the line after the end of the buffer to be drawn with the major-tick face, even if it would be a major-tick line if it existed. It's ugly. > Did you try to arrange for the last line to be a multiple of one of > the ticks as well? In my examples? Yes, that's the whole point of the test: knowing what happens when the line after EOB would match a tick line number. > Also, what happens if you use the beyond_zv test > in all the conditions That's what I've done in the second patch I sent (applied after the first one, not alone). In my simple tests, everything works as expected. > or use the it->what test in all the conditions? I didn't try that, but as the first check (that uses it->what) is trying to decide whether to draw with the current-line-number, I don't think it is relevant to the problem I was trying to fix. It is relevant for consistency, of course. > IOW, I don't understand why we need two different conditions regarding > EOB for displaying a number with different faces. What am I missing? I don't know why (or if) the it->what check is necessary, instead of beyond_zv. I *know* that the other conditions (the ones affecting the choosing of tick faces) need beyond_zv, at least to get what I think is the right behavior (the one in the beyond_zv image). As said, I think that in fact it the first check can be safely replaced by !beyond_zv. > You could simply start with > > tem_it.face_id = lnum_face_id; > > and then have a series of tests for replacing that with another face > ID; it would at least save you the 'else' clause. Yes, good idea. Thanks. > What does "between digits" mean? While producing the glyphs for the > digits of a single line number, no faces can change, because no Lisp > is invoked. Is that what you meant? Yes, thanks. I expected as much, but the way the original code was written, and redisplay being notoriously tricky and an arcane art best left to wizards, I though I was missing something (I'm not joking). --00000000000052626b059462eb7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0 On Tue, Oct 8, 2019 at 10:50 AM Eli Zaretskii <<= a href=3D"mailto:eliz@gnu.org">eliz@gnu.org> wrote:

> Sorr= y, I don't think I understand what the images show me.=C2=A0 They seem<= br>> identical.=C2=A0 Which face bleeds and where?=C2=A0 Please point ou= t what should
> I be looking at to understand the difference.

= In both images, the line numbered 19 is the last line in the buffer.
In the it_eob image, the "line" past the end of the buffer has a= n empty number,
drawn with the major-tick face (but obviously without nu= mber). The rest of non-lines,
until the end of the buffer, have their em= pty number drawn in the line-number face.

In the beyond_zv image, th= e empty line after the end of the buffer is in the
line-number face, as = all the other past that point. I think that's the right behavior.
There's no reason for the line after the end of the buffer to be draw= n with the
major-tick face, even if it would be a major-tick line if it = existed. It's ugly.

> Did you try to arrange for the last lin= e to be a multiple of one of
> the ticks as well?

In my exampl= es? Yes, that's the whole point of the test: knowing what happens when<= br>the line after EOB would match a tick line number.

> =C2=A0Als= o, what happens if you use the beyond_zv test
> in all the conditions=

That's what I've done in the second patch I sent (applied a= fter the first one, not
alone). In my simple tests, everything works as = expected.

> or use the it->what test in all the conditions?
I didn't try that, but as the first check (that uses it->what) = is trying to decide
whether to draw with the current-line-number, I don&= #39;t think it is relevant to
the problem I was trying to fix. It is rel= evant for consistency, of course.

> IOW, I don't understand w= hy we need two different conditions regarding
> EOB for displaying a = number with different faces.=C2=A0 What am I missing?

I don't kn= ow why (or if) the it->what check is necessary, instead of beyond_zv.I *know* that the other conditions (the ones affecting the choosing of tic= k faces)
need beyond_zv, at least to get what I think is the right behav= ior (the one in the
beyond_zv image). As said, I think that in fact it t= he first check can be safely
replaced by !beyond_zv.

> You cou= ld simply start with
>
> =C2=A0 tem_it.face_id =3D lnum_face_id= ;
>
> and then have a series of tests for replacing that with a= nother face
> ID; it would at least save you the 'else' claus= e.

Yes, good idea. Thanks.

> What does "between digit= s" mean?=C2=A0 While producing the glyphs for the
> digits of a = single line number, no faces can change, because no Lisp
> is invoked= .=C2=A0 Is that what you meant? =C2=A0

Yes, thanks. I expected as mu= ch, but the way the original code was written, and
redisplay being notor= iously tricky and an arcane art best left to wizards, I
though I was mis= sing something (I'm not joking).
--00000000000052626b059462eb7d--