unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ergus <spacibba@aol.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 36858@debbugs.gnu.org, rotim.davor@gmail.com
Subject: bug#36858: 27.0.50; display bugs with display-fill-column-indicator-mode
Date: Tue, 6 Aug 2019 01:54:05 +0200	[thread overview]
Message-ID: <20190805235403.o4lvxzbggm3cnk6n@Ergus> (raw)
In-Reply-To: <83r263g4w5.fsf@gnu.org>

Hi Eli:

There are two different behaviors for tui and gui in
extend_face_to_end_of_line.

In gui the face is automatically extended.  It is unclear for me what
face it is using, because this has to do with the issue that in X the
last character is extended automatically, so no loop or stretch_glyph is
needed. But it seems to be using the default face because the underline
is not extend after the text and the space for the cursor.

ON the other hand, for the tui there is

      if (it->glyph_row->ends_at_zv_p)
	it->face_id = default_face->id;
      else
	it->face_id = face->id;

which extends the face using the face of the last glyph. this extends
the underline until the end of the row; but it is different to the gui
behavior, so it is incoherent.

Whats the right behavior in the general case?

Extend the underline the whole line or fit it to the text?

If it is the second whats the right face to fill until the end of the
row

Does the same policy applies to append_space_for_newline? Because now
there is an extra underlined space after the text.

I am just waiting for your recommendation in order to submit a fix for
this issue.

Thanks in advance

Esgus.


On Fri, Aug 02, 2019 at 02:53:30PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 02 Aug 2019 12:25:15 +0200
>> CC: 36858@debbugs.gnu.org,Davor Rotim <rotim.davor@gmail.com>
>> From: Ergus <spacibba@aol.com>
>>
>> I will give a look the next week.
>
>Thanks.
>
>> The org mode issue seems more or less easy to fix.
>>
>> But for the company-mode I need to check if there is a condition to distinguish normal text from the company
>> popups. From the display engine. Else we could consider to extend the line always until the end of the
>> screen... If that is possible...
>
>The glyph rows generated by Company should all have their ends_at_zv_p
>flag set in this use case, AFAIR.  Maybe this will help.





  reply	other threads:[~2019-08-05 23:54 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30 18:11 bug#36858: 27.0.50; display bugs with display-fill-column-indicator-mode Davor Rotim
2019-08-02  9:16 ` Eli Zaretskii
2019-08-02 10:25   ` Ergus
2019-08-02 11:53     ` Eli Zaretskii
2019-08-05 23:54       ` Ergus [this message]
2019-08-05 15:27   ` Ergus
2019-08-07 14:38     ` Eli Zaretskii
2019-08-07 16:20       ` Ergus
2019-08-07 16:37         ` Eli Zaretskii
2019-08-07 17:06           ` Ergus
2019-08-07 17:29             ` Eli Zaretskii
2019-08-07 19:46               ` Ergus
2019-08-08  7:17                 ` Ergus
2019-08-08 17:33                   ` Eli Zaretskii
2019-08-08 22:29                     ` Ergus
2019-08-08 17:31                 ` Eli Zaretskii
2019-08-08 22:32                   ` Ergus
2019-08-06 10:44 ` Dmitry Gutov
2019-08-10  8:22 ` Eli Zaretskii
2019-08-10  8:35   ` Davor Rotim
2019-08-10  9:58     ` Eli Zaretskii
2019-08-10 10:12       ` Davor Rotim
2019-08-10 10:45         ` Eli Zaretskii
2019-08-10 11:53           ` Eli Zaretskii
2019-08-10 13:21             ` Carsten Dominik
2019-08-10 13:38               ` Eli Zaretskii
2019-08-10 14:17                 ` Carsten Dominik
2019-08-10 14:41                   ` Eli Zaretskii
2019-08-12  7:10                     ` Carsten Dominik
2019-08-12 14:26                       ` Eli Zaretskii
2019-08-10 18:02                 ` Ergus
2019-10-20 22:12 ` bug#36858: (no subject) Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found] <<CAMWA6ANTAsSz4ckRGSTuVRCHJKZMDEd1SsBaJetW3bWRjPTRNQ@mail.gmail.com>
     [not found] ` <<83zhkh8m5n.fsf@gnu.org>
     [not found]   ` <<CAMWA6AMvD5Vt=fDcHjufcrVUPy__tQ00tk9aobYjyrgoaSiF=w@mail.gmail.com>
     [not found]     ` <<83mugh8hqg.fsf@gnu.org>
     [not found]       ` <<CAMWA6ANXJvdCptHYV_qzXuwtfdoXM3Ygo577gPorgLRD1EQAJw@mail.gmail.com>
     [not found]         ` <<83imr58fji.fsf@gnu.org>
     [not found]           ` <<83d0hd8ceh.fsf@gnu.org>
     [not found]             ` <<CADn3Z2Ke4S+BCaniLWYxT3Vf6-gqt-oHCqcHj6rz22tG0ntw8g@mail.gmail.com>
     [not found]               ` <<83a7ch87j8.fsf@gnu.org>
2019-08-10 16:15                 ` bug#36858: 27.0.50; display bugs with display-fill-column-indicator-mode Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190805235403.o4lvxzbggm3cnk6n@Ergus \
    --to=spacibba@aol.com \
    --cc=36858@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=rotim.davor@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).