Fill column indicator functionality

Fill column indicator functionality

[Ergus]

Hi guys:

I am not sure if this is the right mailing list to ask for this.

I can't find any fill column indication functionality in emacs. For 80
(or 120) sacred column rule.

Looking around there is the fill-column-indicator package in melpa that
I have been using for a while, but recently it has been abandoned, but
also it is incompatible with native functionalities like
show-trailing-whitespace, so it enforces to use whitespace-mode instead.

Is it too difficult to add such a functionality native in emacs as you
did with the line numbers in the last release? So it will be much better
and it is not a so fancy functionality?

Thanks in advance.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Tue, 5 Feb 2019 11:53:40 +0100
> From: Ergus <spacibba@aol.com>
> 
> I can't find any fill column indication functionality in emacs. For 80
> (or 120) sacred column rule.

ruler-mode does it, but maybe you are looking for a different kind of
indicator.  If so, would you like to describe how you'd like it to
look?

> Is it too difficult to add such a functionality native in emacs as you
> did with the line numbers in the last release?

Hard to answer this without knowing what functionality is being
sought.

Re: Fill column indicator functionality

[Ergus]

Hi Eli:

Yes, I tried rule mode first, but it is a little bit too much
distracting.

I would like to have something simple like fill-column-indicator mode
package https://github.com/alpaker/Fill-Column-Indicator.

(but without it's conflicts and many issues) even if it only brings the
most basic functionalities. This is a very basic code editing
functionality that shouldn't depend of external packages (like line
numbers for example) in my opinion.

It could be a line | or a background color change up to the X column. This
is very useful, when coding old Fortran or Cobol, but also in C.

The alternative package now is hl-fill-column but I personally don't
like it because I only see the line when is crossed already.

I know you should be very busy, but maybe it is not that hard to
implement, so I had to ask at least.

Regards,

On Tue, Feb 05, 2019 at 06:41:44PM +0200, Eli Zaretskii wrote:
>> Date: Tue, 5 Feb 2019 11:53:40 +0100
>> From: Ergus <spacibba@aol.com>
>>
>> I can't find any fill column indication functionality in emacs. For 80
>> (or 120) sacred column rule.
>
>ruler-mode does it, but maybe you are looking for a different kind of
>indicator.  If so, would you like to describe how you'd like it to
>look?
>
>> Is it too difficult to add such a functionality native in emacs as you
>> did with the line numbers in the last release?
>
>Hard to answer this without knowing what functionality is being
>sought.

RE: Fill column indicator functionality

[Drew Adams]

> I would like to have something simple like fill-column-indicator mode
> (but without it's conflicts and many issues) even if it only brings the
> most basic functionalities. This is a very basic code editing
> functionality that shouldn't depend of external packages (like line
> numbers for example) in my opinion.
> 
> It could be a line | or a background color change up to the X column.

Haven't been following this thread; sorry.

Have you looked at this Emacs Wiki page? Perhaps it will help - it mentions a few ways to indicate a particular column.

https://www.emacswiki.org/emacs/EightyColumnRule

Re: Fill column indicator functionality

[Ergus]

Hi Drew:

Thanks for replying. I saw the page and I tried almost all the options.

My feature request comes from the fact that almost all the options there
are unmaintained and some look like patches in new clothes.

- Column-marker creates a mark only in the crossed lines. But it is more
  intuitive to have something indicating where is the limit before
  reaching it. Like a rule or a background color change.

- ModeLinePosition like ruler-mode shows the indicators in the borders
  and conflicts with spaceline and sml. But it is also far from the
  center of the screen. When editing there.

- FillColumnIndicator is the one I have been using until now, but it is
  abandoned since a long time ago (the last update was in December but
  it was to add in the readme that it is not longer maintained), it has
  many issues and incompatibilities, enforces to use whitespace-mode
  because is incompatible with show-trailing-whitespace.

- Column-Enforce-Mode is like Column-marker, but changes the rest of the
  line, at least for me it becomes annoying after a while. And also
  highlights the line only after crossed. (SO same issue than Column-maker)

There are other options in melpa: hl-fill-column-mode which is more or
less like column-marker.

I think this is a very basic text editing functionality (like line
numbers). And Emacs shouldn't need a plugin for this very basic text
editing functionalities.

On the other hand, making it part of emacs can be guaranteed to have a
similar clean appearance as you did with the line numbers in the last
release. So everything will be more standard by default.

But again, it is my opinion, I don't want to bother with this too much
because you are very busy people. Any design choice that can make it
better, more efficient or simpler will be fine even if it is not what I
had in mind.

Best,

On Tue, Feb 05, 2019 at 07:56:02PM +0000, Drew Adams wrote:
>> I would like to have something simple like fill-column-indicator mode
>> (but without it's conflicts and many issues) even if it only brings the
>> most basic functionalities. This is a very basic code editing
>> functionality that shouldn't depend of external packages (like line
>> numbers for example) in my opinion.
>>
>> It could be a line | or a background color change up to the X column.
>
>Haven't been following this thread; sorry.
>
>Have you looked at this Emacs Wiki page? Perhaps it will help - it mentions a few ways to indicate a particular column.
>
>https://www.emacswiki.org/emacs/EightyColumnRule
>
>

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Tue, 5 Feb 2019 19:47:20 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> I would like to have something simple like fill-column-indicator mode
> package https://github.com/alpaker/Fill-Column-Indicator.
> 
> (but without it's conflicts and many issues) even if it only brings the
> most basic functionalities. This is a very basic code editing
> functionality that shouldn't depend of external packages (like line
> numbers for example) in my opinion.
> 
> It could be a line | or a background color change up to the X column. This
> is very useful, when coding old Fortran or Cobol, but also in C.

How popular are such extensions?  IMO it only makes sense to implement
something like that in core if there's enough demand, like with line
numbers.

Perhaps you should start a poll on Reddit about this, and we can then
see how many people would like to use such a feature.  Do many people
share you dissatisfaction with solutions that show fill-column only
when it is crossed, for example?

There are also some questions about what exactly to do with
continuation lines, and with situations where fill-column is larger
than the window-width.  fci-mode forces you to turn on truncate-lines,
and basically ignores fill-column values larger than the window-width,
but for a core feature we need to figure out what to do in those
cases.  E.g., your proposal of indicating fill-column with background
color will then cause unpleasant display with alternating background
around continued lines.  These aspects could/should also be discussed
on Reddit before implementing.

Re: Fill column indicator functionality

[John Yates]

On Wed, Feb 6, 2019 at 11:09 AM Eli Zaretskii <eliz@gnu.org> wrote:
> Perhaps you should start a poll on Reddit about this, and we can then
> see how many people would like to use such a feature.  Do many people
> share you dissatisfaction with solutions that show fill-column only
> when it is crossed, for example?

I do not follow (proper verb?) Reddit.  That said I have desired
such a feature for years.

My use case (assumed very common) is actively entering / editing
mono-spaced text within a window that is at least somewhat wider
than the column about which I want some visual forewarning.  If I
am merely reading I most likely do not care to have such a visual
clue.

I would be entirely happy with an ability to draw a single
vertical line at a nominal "physical" column (not necessarily the
fill-column).  That line would be drawn irrespective of wrapped
continuations or other edge cases.  If the column is beyond the
window edge then the line simply would not get drawn.  If the
effect is ill-defined / unpalatable I would be happy to do
without as I would be no worse off than I am today.

(This seems reminiscent of recent discussion of "layers".)

/john

Re: Fill column indicator functionality

[Ergus]

That's exactly the same I would like to have. With a small plus of being
compatible with show-trailing-whitespace.

I will start the post in reddit once I understand how to use it.


On Wed, Feb 06, 2019 at 03:48:42PM -0500, John Yates wrote:
>On Wed, Feb 6, 2019 at 11:09 AM Eli Zaretskii <eliz@gnu.org> wrote:
>> Perhaps you should start a poll on Reddit about this, and we can then
>> see how many people would like to use such a feature.  Do many people
>> share you dissatisfaction with solutions that show fill-column only
>> when it is crossed, for example?
>
>I do not follow (proper verb?) Reddit.  That said I have desired
>such a feature for years.
>
>My use case (assumed very common) is actively entering / editing
>mono-spaced text within a window that is at least somewhat wider
>than the column about which I want some visual forewarning.  If I
>am merely reading I most likely do not care to have such a visual
>clue.
>
>I would be entirely happy with an ability to draw a single
>vertical line at a nominal "physical" column (not necessarily the
>fill-column).  That line would be drawn irrespective of wrapped
>continuations or other edge cases.  If the column is beyond the
>window edge then the line simply would not get drawn.  If the
>effect is ill-defined / unpalatable I would be happy to do
>without as I would be no worse off than I am today.
>
>(This seems reminiscent of recent discussion of "layers".)
>
>/john
>

Re: Fill column indicator functionality

[Basil L. Contovounesios]

Ergus <spacibba@aol.com> writes:

> That's exactly the same I would like to have. With a small plus of being
> compatible with show-trailing-whitespace.
>
> I will start the post in reddit once I understand how to use it.
>
>
> On Wed, Feb 06, 2019 at 03:48:42PM -0500, John Yates wrote:
>>On Wed, Feb 6, 2019 at 11:09 AM Eli Zaretskii <eliz@gnu.org> wrote:
>>> Perhaps you should start a poll on Reddit about this, and we can then
>>> see how many people would like to use such a feature.  Do many people
>>> share you dissatisfaction with solutions that show fill-column only
>>> when it is crossed, for example?
>>
>>I do not follow (proper verb?) Reddit.  That said I have desired
>>such a feature for years.
>>
>>My use case (assumed very common) is actively entering / editing
>>mono-spaced text within a window that is at least somewhat wider
>>than the column about which I want some visual forewarning.  If I
>>am merely reading I most likely do not care to have such a visual
>>clue.
>>
>>I would be entirely happy with an ability to draw a single
>>vertical line at a nominal "physical" column (not necessarily the
>>fill-column).  That line would be drawn irrespective of wrapped
>>continuations or other edge cases.  If the column is beyond the
>>window edge then the line simply would not get drawn.  If the
>>effect is ill-defined / unpalatable I would be happy to do
>>without as I would be no worse off than I am today.
>>
>>(This seems reminiscent of recent discussion of "layers".)

Just chiming in because I also do not read Reddit (readit?).

As a beginner Emacsite (and programmer) in 2014, I felt I could not work
without line numbers or a rule at 80 columns.  I, too, eventually
settled on fci-mode after some quick and inexperienced testing of other
packages/solutions.  It was nice to be able to preemptively format/break
lines as they grew closer to the rule, without having to wait for 80
columns to be exceeded before this was visually indicated, for example.

Since then, I have dispensed with both features because of performance
and compatibility issues like the ones already mentioned, and I have
become accustomed to their absence and a more minimalistic (less
maximalistic?) setup.

Nevertheless, I was very happy to see the addition of
display-line-numbers (thanks Eli!), and I would also welcome some sort
of native column indication like that of fci-mode, because these have
been popular editor features in my own past experience and that of my
peers.

Having said that, I appreciate that the design and implementation of
this will be non-trivial, as there are many decisions to be made and
circumstances/options to be supported.

Thanks,

-- 
Basil

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: John Yates <john@yates-sheets.org>,  Eli Zaretskii <eliz@gnu.org>,  Emacs developers <emacs-devel@gnu.org>
> Date: Thu, 07 Feb 2019 01:41:04 +0000
> 
> Having said that, I appreciate that the design and implementation of
> this will be non-trivial, as there are many decisions to be made and
> circumstances/options to be supported.

This doesn't have to be non-trivial, if we are smart enough not to
over-specify the feature.

Re: Fill column indicator functionality

[Ergus]

Hi again:

I have been checking the display engine and the commits to add the
display-line-number functionality. With this, it really looks much
simpler to implement the version of the vertical line (character at
column X).

Do you still think not worth it to try a simpler implementation where the
only specification is the column number and the character to use? (And
probably the face). Not shown when the line is longer or when the window
is narrower.

If someone can advise or start with this I will be very happy to help. I
think that the there is a lot to gain and nothing to lose. This is a
basic text editing functionality. Many text/code editors have it and
there is not any reason we can't replicate it.

And we should improve firstly the editor functionalities, because that's
the reason people starts using emacs, later they discover the rest; but
the first it is, is a text editor.



On Thu, Feb 07, 2019 at 04:31:00PM +0200, Eli Zaretskii wrote:
>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: John Yates <john@yates-sheets.org>,  Eli Zaretskii <eliz@gnu.org>,  Emacs developers <emacs-devel@gnu.org>
>> Date: Thu, 07 Feb 2019 01:41:04 +0000
>>
>> Having said that, I appreciate that the design and implementation of
>> this will be non-trivial, as there are many decisions to be made and
>> circumstances/options to be supported.
>
>This doesn't have to be non-trivial, if we are smart enough not to
>over-specify the feature.
>

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sun, 10 Feb 2019 23:04:54 +0100
> From: Ergus <spacibba@aol.com>
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, emacs-devel@gnu.org,
> 	john@yates-sheets.org
> 
> I have been checking the display engine and the commits to add the
> display-line-number functionality. With this, it really looks much
> simpler to implement the version of the vertical line (character at
> column X).

I'm not sure I understand: much simpler than what alternative?

> Do you still think not worth it to try a simpler implementation where the
> only specification is the column number and the character to use?

Also here: simpler than what alternative(s)?

> If someone can advise or start with this I will be very happy to
> help.

I can describe my idea of implementing this, if that's what you meant,
and point to the places in the code where it should be done.  If you
then decide to work on that, I will gladly help with advice and any
questions you might have.

Thanks.

Re: Fill column indicator functionality

[Jimmy Aguilar Mena]

On Mon, Feb 11, 2019 at 05:55:04PM +0200, Eli Zaretskii wrote:
>> Date: Sun, 10 Feb 2019 23:04:54 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, emacs-devel@gnu.org,
>> 	john@yates-sheets.org
>>
>> I have been checking the display engine and the commits to add the
>> display-line-number functionality. With this, it really looks much
>> simpler to implement the version of the vertical line (character at
>> column X).
>
>I'm not sure I understand: much simpler than what alternative?
>
The color change one.

>> Do you still think not worth it to try a simpler implementation where the
>> only specification is the column number and the character to use?
>
>Also here: simpler than what alternative(s)?
>
>> If someone can advise or start with this I will be very happy to
>> help.
>
>I can describe my idea of implementing this, if that's what you meant,
>and point to the places in the code where it should be done.  If you
>then decide to work on that, I will gladly help with advice and any
>questions you might have.
>
>Thanks.
>
Exactly that's what I mean. BTW, is it there any legal paperwork before
contributing?

http://bsc.es/disclaimer

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Mon, 11 Feb 2019 17:56:36 +0100
> From: Jimmy Aguilar Mena <jimmy.aguilar@bsc.es>
> Cc: Ergus <spacibba@aol.com>, contovob@tcd.ie, john@yates-sheets.org,
>         emacs-devel@gnu.org
> 
> >> I have been checking the display engine and the commits to add the
> >> display-line-number functionality. With this, it really looks much
> >> simpler to implement the version of the vertical line (character at
> >> column X).
> >
> >I'm not sure I understand: much simpler than what alternative?
> >
> The color change one.

I don't think it's easier, I think both could be implemented with
similar efforts, and in the same place in the code.  (Caveat: I only
thought a little bit about the implementation, so I might be missing
some important details.)

> BTW, is it there any legal paperwork before contributing?

If you don't have a copyright assignment for contributing to Emacs,
you should start the legal paperwork rolling, so that it's in place by
the time you will have code to contribute.

Thanks.

Re: Fill column indicator functionality

[Ergus]

Hi all:

I have been playing with the display engine in order to try to implement
this functionality (at least a proof of concept). But after reading the
comments and the ~33E3 lines in xdisp.c there are more questions now
than answers.

The simplest approach I see is to add a '|' (or similar) in the desired
column in the "at_end_of_line:" label. But maybe there is a better
approach?

My approach is somehow based on the display_line_numbers, but taking
into account that in this case the characters are always the same, maybe
there is a way to set them in the background and it will be simpler?

Is it there any documentation about this? specially the relations
between the data structures? because the it and the glyphs are very
confusing.

Any help please?



On Mon, Feb 11, 2019 at 07:13:25PM +0200, Eli Zaretskii wrote:
>> Date: Mon, 11 Feb 2019 17:56:36 +0100
>> From: Jimmy Aguilar Mena <jimmy.aguilar@bsc.es>
>> Cc: Ergus <spacibba@aol.com>, contovob@tcd.ie, john@yates-sheets.org,
>>         emacs-devel@gnu.org
>>
>> >> I have been checking the display engine and the commits to add the
>> >> display-line-number functionality. With this, it really looks much
>> >> simpler to implement the version of the vertical line (character at
>> >> column X).
>> >
>> >I'm not sure I understand: much simpler than what alternative?
>> >
>> The color change one.
>
>I don't think it's easier, I think both could be implemented with
>similar efforts, and in the same place in the code.  (Caveat: I only
>thought a little bit about the implementation, so I might be missing
>some important details.)
>
>> BTW, is it there any legal paperwork before contributing?
>
>If you don't have a copyright assignment for contributing to Emacs,
>you should start the legal paperwork rolling, so that it's in place by
>the time you will have code to contribute.
>
>Thanks.
>

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 8 Mar 2019 19:57:46 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> I have been playing with the display engine in order to try to implement
> this functionality (at least a proof of concept). But after reading the
> comments and the ~33E3 lines in xdisp.c there are more questions now
> than answers.

Feel free to ask the questions here.

> The simplest approach I see is to add a '|' (or similar) in the desired
> column in the "at_end_of_line:" label. But maybe there is a better
> approach?

You are on the right track.  But I'd suggest to do this inside the
function extend_face_to_end_of_line.  It is called near that label,
but you will see that it's called in several more places; I expect at
least some of them to need the same changes.

> My approach is somehow based on the display_line_numbers, but taking
> into account that in this case the characters are always the same, maybe
> there is a way to set them in the background and it will be simpler?

Simpler than what?  Can you tell what kind of complexity did you want
to avoid?

Display of line numbers needs to calculate the number of each screen
line, and that of course is not needed in this case.  You just need
to calculate the width of a stretch glyph that will display as
whitespace between the end of the line and the fill column.  You will
see that extend_face_to_end_of_line already does something similar in
the case of R2L lines.

> Is it there any documentation about this?

Maybe, but to point you to it I need to understand what "this" means
in this context.

> specially the relations between the data structures?

Which data structures? there are quite a few of them, so please be
more specific.

> because the it and the glyphs are very confusing.

Feel free to ask any questions about these two, especially about what
confuses you.

> Any help please?

I'm here to help.

And thanks for working on this.

Re: Fill column indicator functionality

[Ergus]

On Fri, Mar 08, 2019 at 10:06:41PM +0200, Eli Zaretskii wrote:
>> Date: Fri, 8 Mar 2019 19:57:46 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> I have been playing with the display engine in order to try to implement
>> this functionality (at least a proof of concept). But after reading the
>> comments and the ~33E3 lines in xdisp.c there are more questions now
>> than answers.
>
>Feel free to ask the questions here.
>
>> The simplest approach I see is to add a '|' (or similar) in the desired
>> column in the "at_end_of_line:" label. But maybe there is a better
>> approach?
>
>You are on the right track.  But I'd suggest to do this inside the
>function extend_face_to_end_of_line.  It is called near that label,
>but you will see that it's called in several more places; I expect at
>least some of them to need the same changes.
>
Hi Eli, I just finished a working version (pretty simple as a proof of
concept). That works in terminal mode. But in graphical mode we should
look for another approach because extend_face_to_end_of_line returns in:

if (FRAME_WINDOW_P (f)
   && MATRIX_ROW_DISPLAYS_TEXT_P (it->glyph_row)
   && face->box == FACE_NO_BOX
   && FACE_COLOR_TO_PIXEL (face->background, f) == FRAME_BACKGROUND_PIXEL (f)
#ifdef HAVE_WINDOW_SYSTEM
   && !face->stipple
#endif
   && !it->glyph_row->reversed_p)
   return;

So it don't write until the line end.

In graphical mode maybe it is better to do this change writing directly
a vertical line in the windows' frame background. That way it will be maybe
more efficient because we only do it once. But I don't know if this is
possible-recommended.

Else, we can follow a similar approach than in terminal version and
generate a glygh for that cases. What do you think?

BTW: Is it possible to generate a single wider glyph instead of doing a
loop?.

The glyph concept is actually not  clear for me yet, specially in
graphical mode.

>> My approach is somehow based on the display_line_numbers, but taking
>> into account that in this case the characters are always the same, maybe
>> there is a way to set them in the background and it will be simpler?
>
>Simpler than what?  Can you tell what kind of complexity did you want
>to avoid?
>
>Display of line numbers needs to calculate the number of each screen
>line, and that of course is not needed in this case.  You just need
>to calculate the width of a stretch glyph that will display as
>whitespace between the end of the line and the fill column.  You will
>see that extend_face_to_end_of_line already does something similar in
>the case of R2L lines.
>
>> Is it there any documentation about this?
>
>Maybe, but to point you to it I need to understand what "this" means
>in this context.
>
>> specially the relations between the data structures?
>
>Which data structures? there are quite a few of them, so please be
>more specific.
>
glyph <-> it: why this looks so complex? Because "it" has too many
properties I can't understand their functionalities and sometimes I
think I could reinvent the wheel.

>> because the it and the glyphs are very confusing.
>
>Feel free to ask any questions about these two, especially about what
>confuses you.
>
>> Any help please?
>
>I'm here to help.
>
>And thanks for working on this.
>
Thanks to you.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sat, 9 Mar 2019 14:22:09 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> >You are on the right track.  But I'd suggest to do this inside the
> >function extend_face_to_end_of_line.  It is called near that label,
> >but you will see that it's called in several more places; I expect at
> >least some of them to need the same changes.
> >
> Hi Eli, I just finished a working version (pretty simple as a proof of
> concept). That works in terminal mode. But in graphical mode we should
> look for another approach because extend_face_to_end_of_line returns in:
> 
> if (FRAME_WINDOW_P (f)
>    && MATRIX_ROW_DISPLAYS_TEXT_P (it->glyph_row)
>    && face->box == FACE_NO_BOX
>    && FACE_COLOR_TO_PIXEL (face->background, f) == FRAME_BACKGROUND_PIXEL (f)
> #ifdef HAVE_WINDOW_SYSTEM
>    && !face->stipple
> #endif
>    && !it->glyph_row->reversed_p)
>    return;
> 
> So it don't write until the line end.

Yes, you need to add one more condition to that 'if', so that it
doesn't return when this feature is in effect.

> In graphical mode maybe it is better to do this change writing directly
> a vertical line in the windows' frame background.

I don't think we can do this in Emacs, the background is just a color
for us.

> That way it will be maybe more efficient because we only do it
> once.

If it were possible, it still could not be done once, because every
redisplay would have to redraw it.

> But I don't know if this is possible-recommended.

It's not possible with what we have in Emacs today.

> BTW: Is it possible to generate a single wider glyph instead of doing a
> loop?.

Yes, of course: you produce a single stretch glyph of a suitable
width.  Look at what the code does in the "row->reversed_p" case.

> >Which data structures? there are quite a few of them, so please be
> >more specific.
> >
> glyph <-> it: why this looks so complex?

For 2 main reasons:

  . the 'it' structure needs to keep track of several state variables,
    which affect more than one glyph, and it needs to do that without
    relying on the glyphs, because sometimes these functions are
    called with it->glyph_row set to NULL (when we need to simulate
    display without displaying anything, see move_it_to

  . the 'it' structure instance is discarded once the glyphs are
    produced, so if we need to record information about the glyphs, we
    need to keep it with the glyphs themselves

> Because "it" has too many properties I can't understand their
> functionalities and sometimes I think I could reinvent the wheel.

The comments in dispextern.h should help.  If they are not enough, we
can add more comments, but you need to point out the missing
information.

Re: Fill column indicator functionality

[John Yates]

On Sat, Mar 9, 2019 at 8:24 AM Ergus <spacibba@aol.com> wrote:
>
> In graphical mode maybe it is better to do this change writing directly
> a vertical line in the windows' frame background.

That would be much closer to the experience I desire.  I advocate
one small change: draw the vertical line in the foreground.

/john

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: John Yates <john@yates-sheets.org>
> Date: Sat, 9 Mar 2019 13:02:04 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> On Sat, Mar 9, 2019 at 8:24 AM Ergus <spacibba@aol.com> wrote:
> >
> > In graphical mode maybe it is better to do this change writing directly
> > a vertical line in the windows' frame background.
> 
> That would be much closer to the experience I desire.  I advocate
> one small change: draw the vertical line in the foreground.

I'll welcome patches to implement such a capability.  Right now, I
don't think we can do that in Emacs.

Re: Fill column indicator functionality

[Ergus]

Hi again:

I have a simple version for the column indicator line. There are still
missing functionalities like R2L or multiple columns indicator
implementations, but I don't want to go very complex on this in the
first try.

I have 2 questions:

1) In the graphical implementation I generated the column following the
Eli suggestions with something like: 

    struct font *font = face->font ? face->font : FRAME_FONT (f);

    it->char_to_display = '|';
    int stretch_ascent = (((it->ascent + it->descent)
              * FONT_BASE (font)) / FONT_HEIGHT (font));

    memset (&it->position, 0, sizeof it->position);
    it->avoid_cursor_p = true;
    it->face_id = merge_faces (it->w, Qline_number, 0, DEFAULT_FACE_ID);
    it->start_of_box_run_p = false;
    append_stretch_glyph (it, Qnil, width,
                          it->ascent + it->descent, stretch_ascent);

    PRODUCE_GLYPHS (it);

    it->position = saved_pos;
    it->avoid_cursor_p = saved_avoid_cursor;
    it->face_id = saved_face_id;
    it->start_of_box_run_p = saved_box_start;
    it->char_to_display = saved_char;

 The problem is that in this case if (setq show-trailing-whitespace t)
the whitespaces aren't highlighted if they are not longer that the line;
in term mode (with the loop) it works fine.

The function highlight_trailing_whitespace checks for glyph->type ==
STRETCH_GLYPH so I am missing something. 

2) What name do you suggest for this mode? I propose
display-column-indicator.

Thanks in advance.

Ergus

On Sat, Mar 09, 2019 at 04:10:11PM +0200, Eli Zaretskii wrote:
>> Date: Sat, 9 Mar 2019 14:22:09 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> >You are on the right track.  But I'd suggest to do this inside the
>> >function extend_face_to_end_of_line.  It is called near that label,
>> >but you will see that it's called in several more places; I expect at
>> >least some of them to need the same changes.
>> >
>> Hi Eli, I just finished a working version (pretty simple as a proof of
>> concept). That works in terminal mode. But in graphical mode we should
>> look for another approach because extend_face_to_end_of_line returns in:
>>
>> if (FRAME_WINDOW_P (f)
>>    && MATRIX_ROW_DISPLAYS_TEXT_P (it->glyph_row)
>>    && face->box == FACE_NO_BOX
>>    && FACE_COLOR_TO_PIXEL (face->background, f) == FRAME_BACKGROUND_PIXEL (f)
>> #ifdef HAVE_WINDOW_SYSTEM
>>    && !face->stipple
>> #endif
>>    && !it->glyph_row->reversed_p)
>>    return;
>>
>> So it don't write until the line end.
>
>Yes, you need to add one more condition to that 'if', so that it
>doesn't return when this feature is in effect.
>
>> In graphical mode maybe it is better to do this change writing directly
>> a vertical line in the windows' frame background.
>
>I don't think we can do this in Emacs, the background is just a color
>for us.
>
>> That way it will be maybe more efficient because we only do it
>> once.
>
>If it were possible, it still could not be done once, because every
>redisplay would have to redraw it.
>
>> But I don't know if this is possible-recommended.
>
>It's not possible with what we have in Emacs today.
>
>> BTW: Is it possible to generate a single wider glyph instead of doing a
>> loop?.
>
>Yes, of course: you produce a single stretch glyph of a suitable
>width.  Look at what the code does in the "row->reversed_p" case.
>
>> >Which data structures? there are quite a few of them, so please be
>> >more specific.
>> >
>> glyph <-> it: why this looks so complex?
>
>For 2 main reasons:
>
>  . the 'it' structure needs to keep track of several state variables,
>    which affect more than one glyph, and it needs to do that without
>    relying on the glyphs, because sometimes these functions are
>    called with it->glyph_row set to NULL (when we need to simulate
>    display without displaying anything, see move_it_to
>
>  . the 'it' structure instance is discarded once the glyphs are
>    produced, so if we need to record information about the glyphs, we
>    need to keep it with the glyphs themselves
>
>> Because "it" has too many properties I can't understand their
>> functionalities and sometimes I think I could reinvent the wheel.
>
>The comments in dispextern.h should help.  If they are not enough, we
>can add more comments, but you need to point out the missing
>information.
>

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Mon, 11 Mar 2019 11:48:14 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> 1) In the graphical implementation I generated the column following the
> Eli suggestions with something like: 
> 
>     struct font *font = face->font ? face->font : FRAME_FONT (f);
> 
>     it->char_to_display = '|';
>     int stretch_ascent = (((it->ascent + it->descent)
>               * FONT_BASE (font)) / FONT_HEIGHT (font));
> 
>     memset (&it->position, 0, sizeof it->position);
>     it->avoid_cursor_p = true;
>     it->face_id = merge_faces (it->w, Qline_number, 0, DEFAULT_FACE_ID);
>     it->start_of_box_run_p = false;
>     append_stretch_glyph (it, Qnil, width,
>                           it->ascent + it->descent, stretch_ascent);
> 
>     PRODUCE_GLYPHS (it);
> 
>     it->position = saved_pos;
>     it->avoid_cursor_p = saved_avoid_cursor;
>     it->face_id = saved_face_id;
>     it->start_of_box_run_p = saved_box_start;
>     it->char_to_display = saved_char;
> 
>  The problem is that in this case if (setq show-trailing-whitespace t)
> the whitespaces aren't highlighted if they are not longer that the line;
> in term mode (with the loop) it works fine.
> 
> The function highlight_trailing_whitespace checks for glyph->type ==
> STRETCH_GLYPH so I am missing something. 

I think you are missing this:

      /* If last glyph is a space or stretch, and it's trailing
	 whitespace, set the face of all trailing whitespace glyphs in
	 IT->glyph_row to `trailing-whitespace'.  */
      if ((row->reversed_p ? glyph <= start : glyph >= start)
	  && BUFFERP (glyph->object)  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
	  && (glyph->type == STRETCH_GLYPH
	      || (glyph->type == CHAR_GLYPH
		  && glyph->u.ch == ' '))
	  && trailing_whitespace_p (glyph->charpos))

This test is for those stretch glyphs that came from a buffer,
i.e. those generated by TABs and 'space' display properties.  But in
your case, the object of the stretch glyph is nil, as specified by the
2nd argument of append_stretch_glyph:

    append_stretch_glyph (it, Qnil, width,
                          it->ascent + it->descent, stretch_ascent);

Moreover, I believe you are looking at the wrong code fragment to
explain why trailing-whitespace stopped working.  I think the problem
happens a bit earlier, here:

      /* Skip over glyphs inserted to display the cursor at the
	 end of a line, for extending the face of the last glyph
	 to the end of the line on terminals, and for truncation
	 and continuation glyphs.  */
      if (!row->reversed_p)
	{
	  while (glyph >= start
		 && glyph->type == CHAR_GLYPH
		 && NILP (glyph->object))
	    --glyph;
	}

This skips only glyphs of type CHAR_GLYPH, but your change inserts a
STRETCH_GLYPH, which you also want to skip.  So the above condition
should be augmented to include STRETCH_GLYPH as well.

> 2) What name do you suggest for this mode? I propose
> display-column-indicator.

display-fill-column-indicator-mode?

Thanks again for working on this.

P.S. Thanks to you, I just uncovered an old bug, whereby
show-trailing-whitespace didn't work in R2L screen lines, and for the
same reason: the code didn't account for the stretch glyphs inserted
by the display engine at the left edge of such lines.

Re: Fill column indicator functionality

[Andy Moreton]

On Mon 11 Mar 2019, Eli Zaretskii wrote:

>> Date: Mon, 11 Mar 2019 11:48:14 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>
>> 2) What name do you suggest for this mode? I propose
>> display-column-indicator.
>
> display-fill-column-indicator-mode?
>
> Thanks again for working on this.
>
> P.S. Thanks to you, I just uncovered an old bug, whereby
> show-trailing-whitespace didn't work in R2L screen lines, and for the
> same reason: the code didn't account for the stretch glyphs inserted
> by the display engine at the left edge of such lines.

Isn't there some overlap with what Keith Bershatsky is doing ? It may be
worth discussing if there is any anything in common. His posts usually
start with:

  I am working on optimization of feature requests #22873 (multiple fake
  cursors) and #17684 (crosshairs that track the cursor position, and a
  visible fill column indicator).

His work on bug #17684 may be relevant.

    AndyM

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Mon, 11 Mar 2019 19:58:38 +0000
> 
> Isn't there some overlap with what Keith Bershatsky is doing ? It may be
> worth discussing if there is any anything in common. His posts usually
> start with:
> 
>   I am working on optimization of feature requests #22873 (multiple fake
>   cursors) and #17684 (crosshairs that track the cursor position, and a
>   visible fill column indicator).

The approach there is very different, and personally I think it is not
the best route for the fill-column indication.

The main goal of Keith's feature is not the fill-column indication,
it's the "fake cursors", and the fill-column indicator is implemented
as one more "fake cursor" of sorts.  But if we want only the
fill-column indicator, implementing it as a cursor makes much less
sense, and is also significantly more complicated for no good reason.
Just look at the magnitude of the patch.  It's no coincidence that
this present implementation took so much less time and efforts than
the work on fake cursors.

Re: Fill column indicator functionality

[Ergus]

Hi Eli:

Sorry for being so annoying. But this is my first contribution and I am
still understanding the details on the way.

On Mon, Mar 11, 2019 at 05:30:47PM +0200, Eli Zaretskii wrote:
>
>I think you are missing this:
>
>      /* If last glyph is a space or stretch, and it's trailing
>	 whitespace, set the face of all trailing whitespace glyphs in
>	 IT->glyph_row to `trailing-whitespace'.  */
>      if ((row->reversed_p ? glyph <= start : glyph >= start)
>	  && BUFFERP (glyph->object)  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>	  && (glyph->type == STRETCH_GLYPH
>	      || (glyph->type == CHAR_GLYPH
>		  && glyph->u.ch == ' '))
>	  && trailing_whitespace_p (glyph->charpos))
>
>This test is for those stretch glyphs that came from a buffer,
>i.e. those generated by TABs and 'space' display properties.  But in
>your case, the object of the stretch glyph is nil, as specified by the
>2nd argument of append_stretch_glyph:
>
>    append_stretch_glyph (it, Qnil, width,
>                          it->ascent + it->descent, stretch_ascent);
>
>Moreover, I believe you are looking at the wrong code fragment to
>explain why trailing-whitespace stopped working.  I think the problem
>happens a bit earlier, here:
>
>      /* Skip over glyphs inserted to display the cursor at the
>	 end of a line, for extending the face of the last glyph
>	 to the end of the line on terminals, and for truncation
>	 and continuation glyphs.  */
>      if (!row->reversed_p)
>	{
>	  while (glyph >= start
>		 && glyph->type == CHAR_GLYPH
>		 && NILP (glyph->object))
>	    --glyph;
>	}
>
I tried:
    if (!row->reversed_p)
	{
	  while (glyph >= start
	         && (glyph->type == CHAR_GLYPH
	             || glyph->type == STRETCH_GLYPH)
		 && NILP (glyph->object))
	    --glyph;
	}

But it didn't work. The behavior is the same: the whitespace is
highlighted only when the line is crossed.

The other corner case I have is because in graphical mode the space for
the dot is always reserved, so when the last character in the line is
just before the line, the line is not drawn for that line.

I can live with that, but maybe there is a simple fix?

In text mode I fixed this changing a while for a do while, but in
graphical mode the approach is different.

>> 2) What name do you suggest for this mode? I propose
>> display-column-indicator.
>
>display-fill-column-indicator-mode?

done.
>
>Thanks again for working on this.
>
>P.S. Thanks to you, I just uncovered an old bug, whereby
>show-trailing-whitespace didn't work in R2L screen lines, and for the
>same reason: the code didn't account for the stretch glyphs inserted
>by the display engine at the left edge of such lines.
>
Best,

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Tue, 12 Mar 2019 16:29:30 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> Sorry for being so annoying.

Nothing to be sorry about.

> I tried:
>     if (!row->reversed_p)
> 	{
> 	  while (glyph >= start
> 	         && (glyph->type == CHAR_GLYPH
> 	             || glyph->type == STRETCH_GLYPH)
> 		 && NILP (glyph->object))
> 	    --glyph;
> 	}
> 
> But it didn't work. The behavior is the same: the whitespace is
> highlighted only when the line is crossed.

I guess at this point I'd need to see the code to help you more.

Alternatively, you could step with a debugger through the code of
highlight_trailing_whitespace and see why it isn't working.  It should
be something simple, I think.

> The other corner case I have is because in graphical mode the space for
> the dot is always reserved, so when the last character in the line is
> just before the line, the line is not drawn for that line.

Sorry, I don't understand: what is "the dot" in this context, and what
do you mean by "just before the line"?  There are too many "lines" in
this sentence, so I'm confused.

> In text mode I fixed this changing a while for a do while, but in
> graphical mode the approach is different.

Well, it sounds like again seeing the code should explain what I don't
understand.

Re: Fill column indicator functionality

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

Hi Eli:

Here I add a WIP patch for the current implementation so far.

Please tell me any problem you see related or not with my questions to
fix them too. 

Best,
Ergus



On Tue, Mar 12, 2019 at 06:19:34PM +0200, Eli Zaretskii wrote:
>> Date: Tue, 12 Mar 2019 16:29:30 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> Sorry for being so annoying.
>
>Nothing to be sorry about.
>
>> I tried:
>>     if (!row->reversed_p)
>> 	{
>> 	  while (glyph >= start
>> 	         && (glyph->type == CHAR_GLYPH
>> 	             || glyph->type == STRETCH_GLYPH)
>> 		 && NILP (glyph->object))
>> 	    --glyph;
>> 	}
>>
>> But it didn't work. The behavior is the same: the whitespace is
>> highlighted only when the line is crossed.
>
>I guess at this point I'd need to see the code to help you more.
>
>Alternatively, you could step with a debugger through the code of
>highlight_trailing_whitespace and see why it isn't working.  It should
>be something simple, I think.
>
>> The other corner case I have is because in graphical mode the space for
>> the dot is always reserved, so when the last character in the line is
>> just before the line, the line is not drawn for that line.
>
>Sorry, I don't understand: what is "the dot" in this context, and what
>do you mean by "just before the line"?  There are too many "lines" in
>this sentence, so I'm confused.
>
>> In text mode I fixed this changing a while for a do while, but in
>> graphical mode the approach is different.
>
>Well, it sounds like again seeing the code should explain what I don't
>understand.
>

[-- Attachment #2: display-fill-column-indicator_wip.patch --]
[-- Type: text/plain, Size: 11139 bytes --]

diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index baa05d0a89..441d3d5a9b 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -648,6 +648,15 @@ since it could result in memory overflow and make Emacs crash."
                                   (const :tag "Count lines from beginning of narrowed region"
                                          :value nil))
                                  "26.1")
+
+             (display-fill-column-indicator-column display-fill-column-indicator
+                                 (choice
+                                  (const :tag "Dynamically computed"
+                                         :value fill-column)
+                                  (integer :menu-tag "Fixed number of columns"
+                                           :value 70
+                                           :format "%v"))
+                                 "27.1")
 	     ;; xfaces.c
 	     (scalable-fonts-allowed display boolean "22.1")
 	     ;; xfns.c
diff --git a/lisp/display-fill-column-indicator.el b/lisp/display-fill-column-indicator.el
new file mode 100644
index 0000000000..d8f73193af
--- /dev/null
+++ b/lisp/display-fill-column-indicator.el
@@ -0,0 +1,71 @@
+;;; display-fill-column-indicator.el --- interface for display-fill-column-indicator -*- lexical-binding: t -*-
+
+;; Copyright (C) 2017-2019 Free Software Foundation, Inc.
+
+;; Maintainer: emacs-devel@gnu.org
+;; Keywords: convenience
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; Provides a minor mode interface for `display-fill-column-indicator'.
+;;
+;; Toggle display of line numbers with M-x
+;; display-fill-column-indicator-mode.  To enable line numbering in
+;; all buffers, use M-x global-display-fill-column-indicator-mode.  To
+;; change the default line column
+
+
+;; NOTE: Customization variables for `display-fill-column-indicator'
+;; itself are defined in cus-start.el.
+
+;;; Code:
+
+(defgroup display-fill-column-indicator nil
+  "Display line numbers in the buffer."
+  :group 'convenience
+  :group 'display)
+
+
+;;;###autoload
+(define-minor-mode display-fill-column-indicator-mode
+  "Toggle display fill column indicator.
+This uses `display-fill-column-indicator' internally.
+
+To change the position of the line displayed by default,
+customize `display-fill-column-indicator-column'."
+  :lighter nil
+  (if display-fill-column-indicator-mode
+      (progn
+        (setq display-fill-column-indicator t)
+        (unless display-fill-column-indicator-column
+          (setq display-fill-column-indicator-column fill-column)))
+    (setq display-fill-column-indicator nil)))
+
+(defun display-fill-column-indicator--turn-on ()
+  "Turn on `display-fill-column-indicator-mode'."
+  (unless (or (minibufferp)
+              (and (daemonp) (null (frame-parameter nil 'client))))
+    (display-fill-column-indicator-mode)))
+
+;;;###autoload
+(define-globalized-minor-mode global-display-fill-column-indicator-mode
+  display-fill-column-indicator-mode display-fill-column-indicator--turn-on)
+
+(provide 'display-fill-column-indicator)
+
+;;; display-fill-column-indicator.el ends here
diff --git a/lisp/frame.el b/lisp/frame.el
index dd1d5b030f..c0a0c3a903 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -2663,6 +2663,8 @@ See also `toggle-frame-maximized'."
         display-line-numbers-width
         display-line-numbers-current-absolute
         display-line-numbers-widen
+        display-fill-column-indicator
+        display-fill-column-indicator-column
         bidi-paragraph-direction
         bidi-display-reordering))
 
diff --git a/lisp/ldefs-boot.el b/lisp/ldefs-boot.el
index 0e8e5f699b..1227ceb377 100644
--- a/lisp/ldefs-boot.el
+++ b/lisp/ldefs-boot.el
@@ -7734,7 +7734,44 @@ See `display-line-numbers-mode' for more information on Display-Line-Numbers mod
 
 \(fn &optional ARG)" t nil)
 
-(if (fboundp 'register-definition-prefixes) (register-definition-prefixes "display-line-numbers" '("display-line-numbers-")))
+(if (fboundp 'register-definition-prefixes)
+    (register-definition-prefixes "display-line-numbers" '("display-line-numbers-")))
+
+;;;***
+\f
+;;;### (autoloads nil "display-fill-column-indicator" "display-fill-column-indicator.el"
+;;;;;;  (0 0 0 0))
+;;; Generated autoloads from display-fill-column-indicator.el
+
+(autoload 'display-fill-column-indicator-mode "display-fill-column-indicator" "\
+Toggle display fill column indicator.
+This uses `display-fill-column-indicator' internally.
+
+To change the position of the line displayed by default,
+customize `display-fill-column-indicator-column'.
+
+\(fn &optional ARG)" t nil)
+
+(defvar global-display-fill-column-indicator-mode nil "\
+Non-nil if Global Display-fill-column-indicator mode is enabled.
+See the `global-display-fill-column-indicator-mode' command
+for a description of this minor mode.")
+
+(custom-autoload 'global-display-fill-column-indicator-mode
+                 "display-fill-column-indicator" nil)
+
+(autoload 'global-display-fill-column-indicator-mode
+  "display-fill-column-indicator" "\
+Toggle display fill column indicator.
+This uses `display-fill-column-indicator' internally.
+
+To change the position of the line displayed by default,
+customize `display-fill-column-indicator-column'.
+
+\(fn &optional ARG)" t nil)
+
+(if (fboundp 'register-definition-prefixes)
+    (register-definition-prefixes "display-fill-column-indicator" '("display-fill-column-indicator-")))
 
 ;;;***
 \f
diff --git a/src/xdisp.c b/src/xdisp.c
index 6d30afda6d..928949f031 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -20305,7 +20305,8 @@ extend_face_to_end_of_line (struct it *it)
 #ifdef HAVE_WINDOW_SYSTEM
       && !face->stipple
 #endif
-      && !it->glyph_row->reversed_p)
+      && !it->glyph_row->reversed_p
+      && NILP (Vdisplay_fill_column_indicator))
     return;
 
   /* Set the glyph row flag indicating that the face of the last glyph
@@ -20359,6 +20360,47 @@ extend_face_to_end_of_line (struct it *it)
 	    }
 	}
 #ifdef HAVE_WINDOW_SYSTEM
+
+      if (!NILP (Vdisplay_fill_column_indicator))
+        {
+	  const int fill_column_indicator_column =
+		  XFIXNAT (Vdisplay_fill_column_indicator_column) - 1;
+
+	  const int current_x = it->current_x;
+	  const int column_x = it->pixel_width * fill_column_indicator_column
+	                       + it->lnum_pixel_width;
+
+	  if ((current_x <= column_x)
+	      && (column_x < it->last_visible_x))
+	    {
+	      struct font *font = face->font ? face->font : FRAME_FONT (f);
+	      const char saved_char = it->char_to_display;
+	      const struct text_pos saved_pos = it->position;
+	      const bool saved_avoid_cursor = it->avoid_cursor_p;
+	      const int saved_face_id = it->face_id;
+	      const bool saved_box_start = it->start_of_box_run_p;
+	      const int width = column_x - current_x;
+
+	      it->char_to_display = '|';
+	      int stretch_ascent = (((it->ascent + it->descent)
+		    * FONT_BASE (font)) / FONT_HEIGHT (font));
+
+	      memset (&it->position, 0, sizeof it->position);
+	      it->avoid_cursor_p = true;
+	      it->face_id = merge_faces (it->w, Qline_number, 0, DEFAULT_FACE_ID);
+	      it->start_of_box_run_p = false;
+	      append_stretch_glyph (it, Qnil, width,
+	                            it->ascent + it->descent, stretch_ascent);
+
+	      PRODUCE_GLYPHS (it);
+
+	      it->position = saved_pos;
+	      it->avoid_cursor_p = saved_avoid_cursor;
+	      it->face_id = saved_face_id;
+	      it->start_of_box_run_p = saved_box_start;
+	      it->char_to_display = saved_char;
+	    }
+        }
       if (it->glyph_row->reversed_p)
 	{
 	  /* Prepend a stretch glyph to the row, such that the
@@ -20478,10 +20520,34 @@ extend_face_to_end_of_line (struct it *it)
 	it->face_id = default_face->id;
       else
 	it->face_id = face->id;
-      PRODUCE_GLYPHS (it);
 
-      while (it->current_x <= it->last_visible_x)
-	PRODUCE_GLYPHS (it);
+      /* Display fill-column-line if mode is active */
+      if (!NILP (Vdisplay_fill_column_indicator))
+	{
+	  const int fill_column_indicator_line =
+	    XFIXNAT (Vdisplay_fill_column_indicator_column) + it->lnum_pixel_width;
+	  do
+	    {
+	      if (it->current_x == fill_column_indicator_line)
+	        {
+		  const int saved_face = it->face_id;
+		  it->face_id = merge_faces (it->w, Qline_number, 0, DEFAULT_FACE_ID);
+		  it->c = it->char_to_display = '|';
+		  PRODUCE_GLYPHS (it);
+		  it->face_id = saved_face;
+		  it->c = it->char_to_display = ' ';
+	        }
+	      else
+		PRODUCE_GLYPHS (it);
+	    } while (it->current_x < it->last_visible_x);
+	}
+      else
+	{
+          do
+	    {
+	      PRODUCE_GLYPHS (it);
+            } while (it->current_x < it->last_visible_x);
+        }
 
       if (WINDOW_RIGHT_MARGIN_WIDTH (it->w) > 0
 	  && (it->glyph_row->used[RIGHT_MARGIN_AREA]
@@ -20571,14 +20637,16 @@ highlight_trailing_whitespace (struct it *it)
       if (!row->reversed_p)
 	{
 	  while (glyph >= start
-		 && glyph->type == CHAR_GLYPH
+	         && (glyph->type == CHAR_GLYPH
+	             || glyph->type == STRETCH_GLYPH)
 		 && NILP (glyph->object))
 	    --glyph;
 	}
       else
 	{
 	  while (glyph <= start
-		 && glyph->type == CHAR_GLYPH
+		 && (glyph->type == CHAR_GLYPH
+	             || glyph->type == STRETCH_GLYPH)
 		 && NILP (glyph->object))
 	    ++glyph;
 	}
@@ -33213,6 +33281,19 @@ either `relative' or `visual'.  */);
   DEFSYM (Qdisplay_line_numbers_widen, "display-line-numbers-widen");
   Fmake_variable_buffer_local (Qdisplay_line_numbers_widen);
 
+  DEFVAR_LISP ("display-fill-column-indicator", Vdisplay_fill_column_indicator,
+    doc: /* Non-nil means display the fill column indicator line.  */);
+  Vdisplay_fill_column_indicator = Qnil;
+  DEFSYM (Qdisplay_fill_column_indicator, "display-fill-column-indicator");
+  Fmake_variable_buffer_local (Qdisplay_fill_column_indicator);
+
+  DEFVAR_LISP ("display-fill-column-indicator-column", Vdisplay_fill_column_indicator_column,
+    doc: /* Column where to draw the column indicator line when display-column-indicator
+is non-nil .  */);
+  Vdisplay_fill_column_indicator_column = Qnil;
+  DEFSYM (Qdisplay_fill_column_indicator_column, "display-fill-column-indicator-column");
+  Fmake_variable_buffer_local (Qdisplay_fill_column_indicator_column);
+
   DEFVAR_BOOL ("inhibit-eval-during-redisplay", inhibit_eval_during_redisplay,
     doc: /* Non-nil means don't eval Lisp during redisplay.  */);
   inhibit_eval_during_redisplay = false;

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Tue, 12 Mar 2019 20:20:17 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> Please tell me any problem you see related or not with my questions to
> fix them too. 

Thanks, see below.

> >> I tried:
> >>     if (!row->reversed_p)
> >> 	{
> >> 	  while (glyph >= start
> >> 	         && (glyph->type == CHAR_GLYPH
> >> 	             || glyph->type == STRETCH_GLYPH)
> >> 		 && NILP (glyph->object))
> >> 	    --glyph;
> >> 	}
> >>
> >> But it didn't work. The behavior is the same: the whitespace is
> >> highlighted only when the line is crossed.
> >
> >I guess at this point I'd need to see the code to help you more.

The problem here is that the above loop also looks at the object from
which the glyph came, and will only skip glyphs whose object is nil.
But in your code, you didn't set up the object of the '|' character,
which comes from it->object, to be nil, you left it at its previous
value, which usually will be either a buffer or a string, depending
from where the last character of the text line came.

To fix this, add this:

  Lisp_Object save_object = it->object;
  it->object = Qnil;

before the call to PRODUCE_GLYPHS, and then restore it->object to its
previous value after PRODUCE_GLYPHS.

In the TTY case, this was already done for you by the code which
extends the face, that's why it worked on TTY frames.

> >> The other corner case I have is because in graphical mode the space for
> >> the dot is always reserved, so when the last character in the line is
> >> just before the line, the line is not drawn for that line.
> >
> >Sorry, I don't understand: what is "the dot" in this context, and what
> >do you mean by "just before the line"?  There are too many "lines" in
> >this sentence, so I'm confused.

I guess you mean that when the place for the cursor is at fill-column,
the indicator is not visible?  I think to fix this, you will need to
modify the code in the function append_space_for_newline, which is
responsible for adding the space glyph for displaying the cursor at
the end of the line.  That function currently adds a ' ' space
character there; you want to replace that with the indicator character
'|', when this mode is in effect.

A few more comments regarding the code:

> +      if (!NILP (Vdisplay_fill_column_indicator))
> +        {
> +	  const int fill_column_indicator_column =
> +		  XFIXNAT (Vdisplay_fill_column_indicator_column) - 1;

Why "- 1"?  It's confusing, and should at least be explained in a
comment, if not changed to not subtract 1.

Also, it is unsafe to call XFIXNAT without verifying the value is a
fixnum, because if it isn't, Emacs will crash.

> +	  const int column_x = it->pixel_width * fill_column_indicator_column
> +	                       + it->lnum_pixel_width;

Using it->pixel_width here will not work in general, as this is just
the pixel width of the last character or image of the screen line.  I
think you should use the font->average_width, and if that is zero,
then font->space_width.  Here 'font' is the default face's font.  This
is because I believe we want to display the indicator at the X
coordinate that corresponds to fill-column in units of the default
font width, right?  I mean, did you try to see what happens when the
text has faces which make some of the characters appear smaller or
larger than the default face?

> +	      struct font *font = face->font ? face->font : FRAME_FONT (f);

I think this uses the wrong face: you should be using default_face
instead.  The above is the face of the last character of the line.

> +	      it->char_to_display = '|';

This character should be customizable.  Perhaps make
display-fill-column-indicator serve double duty: if non-nil, it should
be the character to use as the indicator.

> +	      it->face_id = merge_faces (it->w, Qline_number, 0, DEFAULT_FACE_ID);

You didn't really mean to use the line-number face here, did you?
This should probably be a separate distinct face.

> +  DEFVAR_LISP ("display-fill-column-indicator", Vdisplay_fill_column_indicator,
> +    doc: /* Non-nil means display the fill column indicator line.  */);

The "line" part of the doc string doesn't belong there, I think.  Just
"indicator" is enough.

> +  DEFVAR_LISP ("display-fill-column-indicator-column", Vdisplay_fill_column_indicator_column,
> +    doc: /* Column where to draw the column indicator line when display-column-indicator
> +is non-nil .  */);

The first line of a doc string should be a complete sentence, and it
should fit the 80column display line.  In this case, I'd shorten it
like this:

  Column to draw the indicator when `display-fill-column-indicator' is non-nil.

Please also say in the doc string what are the possible values and in
what column units they are measured.

Thanks for working on this.

Re: Fill column indicator functionality

[Ergus]

Hi Eli:

On Wed, Mar 13, 2019 at 06:19:40PM +0200, Eli Zaretskii wrote:
>> Date: Tue, 12 Mar 2019 20:20:17 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> Please tell me any problem you see related or not with my questions to
>> fix them too.
>
>Thanks, see below.
>
>> >> I tried:
>> >>     if (!row->reversed_p)
>> >> 	{
>> >> 	  while (glyph >= start
>> >> 	         && (glyph->type == CHAR_GLYPH
>> >> 	             || glyph->type == STRETCH_GLYPH)
>> >> 		 && NILP (glyph->object))
>> >> 	    --glyph;
>> >> 	}
>> >>
>> >> But it didn't work. The behavior is the same: the whitespace is
>> >> highlighted only when the line is crossed.
>> >
>> >I guess at this point I'd need to see the code to help you more.
>
>The problem here is that the above loop also looks at the object from
>which the glyph came, and will only skip glyphs whose object is nil.
>But in your code, you didn't set up the object of the '|' character,
>which comes from it->object, to be nil, you left it at its previous
>value, which usually will be either a buffer or a string, depending
>from where the last character of the text line came.
>
>To fix this, add this:
>
>  Lisp_Object save_object = it->object;
>  it->object = Qnil;
>
>before the call to PRODUCE_GLYPHS, and then restore it->object to its
>previous value after PRODUCE_GLYPHS.
>
I thought that append_stretch_glyph was putting the it->object to Now I
see it didn't.

>In the TTY case, this was already done for you by the code which
>extends the face, that's why it worked on TTY frames.
>
>> >> The other corner case I have is because in graphical mode the space for
>> >> the dot is always reserved, so when the last character in the line is
>> >> just before the line, the line is not drawn for that line.
>> >
>> >Sorry, I don't understand: what is "the dot" in this context, and what
>> >do you mean by "just before the line"?  There are too many "lines" in
>> >this sentence, so I'm confused.
>
>I guess you mean that when the place for the cursor is at fill-column,
>the indicator is not visible?  I think to fix this, you will need to
>modify the code in the function append_space_for_newline, which is
>responsible for adding the space glyph for displaying the cursor at
>the end of the line.  That function currently adds a ' ' space
>character there; you want to replace that with the indicator character
>'|', when this mode is in effect.
>
Yes I was referring to cursor as point. My bad.

>A few more comments regarding the code:
>
>> +      if (!NILP (Vdisplay_fill_column_indicator))
>> +        {
>> +	  const int fill_column_indicator_column =
>> +		  XFIXNAT (Vdisplay_fill_column_indicator_column) - 1;
>
>Why "- 1"?  It's confusing, and should at least be explained in a
>comment, if not changed to not subtract 1.
>
The -1 is related with the extra ' ' added by the extend_face function,
I will try to avoid it, in the final patch, but now this is just a prove
of concept.

>Also, it is unsafe to call XFIXNAT without verifying the value is a
>fixnum, because if it isn't, Emacs will crash.
>
>> +	  const int column_x = it->pixel_width * fill_column_indicator_column
>> +	                       + it->lnum_pixel_width;
>

Ok, I'll prevent this.

>Using it->pixel_width here will not work in general, as this is just
>the pixel width of the last character or image of the screen line.  I
>think you should use the font->average_width, and if that is zero,
>then font->space_width.  Here 'font' is the default face's font.  This
>is because I believe we want to display the indicator at the X
>coordinate that corresponds to fill-column in units of the default
>font width, right?  I mean, did you try to see what happens when the
>text has faces which make some of the characters appear smaller or
>larger than the default face?
>
>> +	      struct font *font = face->font ? face->font : FRAME_FONT (f);
>
You just saved me a lot of time of reading the font and face structs
definitions (I will but not now).

>I think this uses the wrong face: you should be using default_face
>instead.  The above is the face of the last character of the line.
>
>> +	      it->char_to_display = '|';
>
>This character should be customizable.  Perhaps make
>display-fill-column-indicator serve double duty: if non-nil, it should
>be the character to use as the indicator.
>

It is customizable actually in my current version, I just sent you the
basic changes to make it work that exposed the issues with minimal code
changes. In fact the default value will be ?\u2402 (and not ?| as in the
example) if the font supports it because it will look like a contiguous
line.

>> +	      it->face_id = merge_faces (it->w, Qline_number, 0, DEFAULT_FACE_ID);
>
>You didn't really mean to use the line-number face here, did you?
>This should probably be a separate distinct face.
>

Yes, I did, this was a prove of concept. I created a fill_column face.


>> +  DEFVAR_LISP ("display-fill-column-indicator", Vdisplay_fill_column_indicator,
>> +    doc: /* Non-nil means display the fill column indicator line.  */);
>
>The "line" part of the doc string doesn't belong there, I think.  Just
>"indicator" is enough.
>
>> +  DEFVAR_LISP ("display-fill-column-indicator-column", Vdisplay_fill_column_indicator_column,
>> +    doc: /* Column where to draw the column indicator line when display-column-indicator
>> +is non-nil .  */);
>
>The first line of a doc string should be a complete sentence, and it
>should fit the 80column display line.  In this case, I'd shorten it
>like this:
>
>  Column to draw the indicator when `display-fill-column-indicator' is non-nil.
>
>Please also say in the doc string what are the possible values and in
>what column units they are measured.
>
Ok, perfect

>Thanks for working on this.

1E6 Thanks.
Ergus

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Wed, 13 Mar 2019 21:02:25 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> >  Lisp_Object save_object = it->object;
> >  it->object = Qnil;
> >
> >before the call to PRODUCE_GLYPHS, and then restore it->object to its
> >previous value after PRODUCE_GLYPHS.
> >
> I thought that append_stretch_glyph was putting the it->object to Now I
> see it didn't.

append_stretch_glyph only does that for the stretch glyph it creates,
it doesn't change it->object.

> 1E6 Thanks.

My pleasure.

Re: Fill column indicator functionality

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

Here is a patch with Eli's fixes and corrections:

Actually I have 3 more questions:

1) In the graphical mode the character I use now (?\u2502) does not look
like a vertical line (there is a small vertical space between them so
the line now looks like with ?|); in terminal it looks fine. What's the
proper way to change the font size or the character itself to fit the
entire row height in the graphical mode?

2) Are there any extra considerations needed to use the character
?\u2502 ? Is it needed to check (for example) if the actual fonts can
display it properly?

3) Actually there are 3 possible configuration options the column
number, the character, and the font. Should we provide some other
alternative?

The next step is to implement the R2L version of this, but I don't have
used R2L editing ever, so it may take a while.

On Wed, Mar 13, 2019 at 10:09:42PM +0200, Eli Zaretskii wrote:
>> Date: Wed, 13 Mar 2019 21:02:25 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> >  Lisp_Object save_object = it->object;
>> >  it->object = Qnil;
>> >
>> >before the call to PRODUCE_GLYPHS, and then restore it->object to its
>> >previous value after PRODUCE_GLYPHS.
>> >
>> I thought that append_stretch_glyph was putting the it->object to Now I
>> see it didn't.
>
>append_stretch_glyph only does that for the stretch glyph it creates,
>it doesn't change it->object.
>
>> 1E6 Thanks.
>
>My pleasure.
>

[-- Attachment #2: display-fill-column-indicator_wip.patch --]
[-- Type: text/plain, Size: 16093 bytes --]

diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index baa05d0a89..3f58eac63b 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -648,6 +648,11 @@ since it could result in memory overflow and make Emacs crash."
                                   (const :tag "Count lines from beginning of narrowed region"
                                          :value nil))
                                  "26.1")
+
+             (display-fill-column-indicator-column display-fill-column-indicator
+                                 integer "27.1")
+             (display-fill-column-indicator-character display-fill-column-indicator
+                                 character "27.1")
 	     ;; xfaces.c
 	     (scalable-fonts-allowed display boolean "22.1")
 	     ;; xfns.c
diff --git a/lisp/display-fill-column-indicator.el b/lisp/display-fill-column-indicator.el
new file mode 100644
index 0000000000..846466a2c3
--- /dev/null
+++ b/lisp/display-fill-column-indicator.el
@@ -0,0 +1,74 @@
+;;; display-fill-column-indicator.el --- interface for display-fill-column-indicator -*- lexical-binding: t -*-
+
+;; Copyright (C) 2017-2019 Free Software Foundation, Inc.
+
+;; Maintainer: emacs-devel@gnu.org
+;; Keywords: convenience
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; Provides a minor mode interface for `display-fill-column-indicator'.
+;;
+;; Toggle display of line numbers with M-x
+;; display-fill-column-indicator-mode.  To enable line numbering in
+;; all buffers, use M-x global-display-fill-column-indicator-mode.  To
+;; change the default line column
+
+
+;; NOTE: Customization variables for `display-fill-column-indicator'
+;; itself are defined in cus-start.el.
+
+;;; Code:
+
+(defgroup display-fill-column-indicator nil
+  "Display line numbers in the buffer."
+  :group 'convenience
+  :group 'display)
+
+
+;;;###autoload
+(define-minor-mode display-fill-column-indicator-mode
+  "Toggle display fill column indicator.
+This uses `display-fill-column-indicator' internally.
+
+To change the position of the line displayed by default,
+customize `display-fill-column-indicator-column' you can change the
+character for the line setting `display-fill-column-indicator-character'."
+  :lighter nil
+  (if display-fill-column-indicator-mode
+      (progn
+        (setq display-fill-column-indicator t)
+        (unless display-fill-column-indicator-column
+          (setq display-fill-column-indicator-column fill-column))
+        (unless display-fill-column-indicator-character
+          (setq display-fill-column-indicator-character ?\u2502)))
+    (setq display-fill-column-indicator nil)))
+
+(defun display-fill-column-indicator--turn-on ()
+  "Turn on `display-fill-column-indicator-mode'."
+  (unless (or (minibufferp)
+              (and (daemonp) (null (frame-parameter nil 'client))))
+    (display-fill-column-indicator-mode)))
+
+;;;###autoload
+(define-globalized-minor-mode global-display-fill-column-indicator-mode
+  display-fill-column-indicator-mode display-fill-column-indicator--turn-on)
+
+(provide 'display-fill-column-indicator)
+
+;;; display-fill-column-indicator.el ends here
diff --git a/lisp/faces.el b/lisp/faces.el
index ab6c384c80..153e6a208f 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2502,6 +2502,20 @@ unwanted effects."
   :group 'basic-faces
   :group 'display-line-numbers)
 
+;; Definition stolen from linum.el.
+(defface fill-column
+  '((t :inherit (shadow default)))
+  "Face for displaying fill column indicator line.
+This face is used when `display-fill-column-indicator-mode' is
+non-nil.
+
+If you customize the font of this face, make sure it is a
+monospaced font, otherwise the line's characters will not line
+up horizontally."
+  :version "27.1"
+  :group 'basic-faces
+  :group 'display-fill-column-indicator)
+
 (defface escape-glyph
   '((((background dark)) :foreground "cyan")
     ;; See the comment in minibuffer-prompt for
diff --git a/lisp/frame.el b/lisp/frame.el
index dd1d5b030f..03c4d0761b 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -2663,6 +2663,9 @@ See also `toggle-frame-maximized'."
         display-line-numbers-width
         display-line-numbers-current-absolute
         display-line-numbers-widen
+        display-fill-column-indicator
+        display-fill-column-indicator-column
+        display-fill-column-indicator-character
         bidi-paragraph-direction
         bidi-display-reordering))
 
diff --git a/lisp/ldefs-boot.el b/lisp/ldefs-boot.el
index 0e8e5f699b..1227ceb377 100644
--- a/lisp/ldefs-boot.el
+++ b/lisp/ldefs-boot.el
@@ -7734,7 +7734,44 @@ See `display-line-numbers-mode' for more information on Display-Line-Numbers mod
 
 \(fn &optional ARG)" t nil)
 
-(if (fboundp 'register-definition-prefixes) (register-definition-prefixes "display-line-numbers" '("display-line-numbers-")))
+(if (fboundp 'register-definition-prefixes)
+    (register-definition-prefixes "display-line-numbers" '("display-line-numbers-")))
+
+;;;***
+\f
+;;;### (autoloads nil "display-fill-column-indicator" "display-fill-column-indicator.el"
+;;;;;;  (0 0 0 0))
+;;; Generated autoloads from display-fill-column-indicator.el
+
+(autoload 'display-fill-column-indicator-mode "display-fill-column-indicator" "\
+Toggle display fill column indicator.
+This uses `display-fill-column-indicator' internally.
+
+To change the position of the line displayed by default,
+customize `display-fill-column-indicator-column'.
+
+\(fn &optional ARG)" t nil)
+
+(defvar global-display-fill-column-indicator-mode nil "\
+Non-nil if Global Display-fill-column-indicator mode is enabled.
+See the `global-display-fill-column-indicator-mode' command
+for a description of this minor mode.")
+
+(custom-autoload 'global-display-fill-column-indicator-mode
+                 "display-fill-column-indicator" nil)
+
+(autoload 'global-display-fill-column-indicator-mode
+  "display-fill-column-indicator" "\
+Toggle display fill column indicator.
+This uses `display-fill-column-indicator' internally.
+
+To change the position of the line displayed by default,
+customize `display-fill-column-indicator-column'.
+
+\(fn &optional ARG)" t nil)
+
+(if (fboundp 'register-definition-prefixes)
+    (register-definition-prefixes "display-fill-column-indicator" '("display-fill-column-indicator-")))
 
 ;;;***
 \f
diff --git a/src/xdisp.c b/src/xdisp.c
index 6d30afda6d..8ac4be8dc7 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -20135,15 +20135,41 @@ append_space_for_newline (struct it *it, bool default_face_p)
 	  it->what = IT_CHARACTER;
 	  memset (&it->position, 0, sizeof it->position);
 	  it->object = Qnil;
-	  it->c = it->char_to_display = ' ';
 	  it->len = 1;
 
+	  int local_default_face_id = lookup_basic_face (it->w, it->f, DEFAULT_FACE_ID);
+	  struct face* default_face =
+	    FACE_FROM_ID_OR_NULL (it->f, local_default_face_id);
+
+	  /* Corner case for when display-fill-column-indicator-mode
+	     is active and the extra character should be added in the
+	     same place than the line */
+	  if (!NILP (Vdisplay_fill_column_indicator)
+	      && FIXNATP (Vdisplay_fill_column_indicator_column)
+	      && FIXNATP (Vdisplay_fill_column_indicator_character))
+	    {
+	       struct font *font = default_face->font ? default_face->font : FRAME_FONT (it->f);
+	       const int char_width = font->average_width ? font->average_width : font->space_width;
+	       const int fill_column = XFIXNAT (Vdisplay_fill_column_indicator_column);
+	       const int column_x = char_width * fill_column + it->lnum_pixel_width;
+
+	       if (it->current_x == column_x)
+	         {
+	           it->c = it->char_to_display = XFIXNAT(Vdisplay_fill_column_indicator_character);
+	           it->face_id = merge_faces (it->w, Qfill_column, 0, DEFAULT_FACE_ID);
+	           face = FACE_FROM_ID(it->f, it->face_id);
+	           goto produce_glyphs;
+	         }
+	    }
+
+	  it->c = it->char_to_display = ' ';
 	  /* If the default face was remapped, be sure to use the
 	     remapped face for the appended newline.  */
 	  if (default_face_p)
-	    it->face_id = lookup_basic_face (it->w, it->f, DEFAULT_FACE_ID);
+	    it->face_id = local_default_face_id;
 	  else if (it->face_before_selective_p)
 	    it->face_id = it->saved_face_id;
+
 	  face = FACE_FROM_ID (it->f, it->face_id);
 	  it->face_id = FACE_FOR_CHAR (it->f, face, 0, -1, Qnil);
 	  /* In R2L rows, we will prepend a stretch glyph that will
@@ -20152,11 +20178,12 @@ append_space_for_newline (struct it *it, bool default_face_p)
 	     set.  */
 	  if (it->glyph_row->reversed_p
 	      /* But if the appended newline glyph goes all the way to
-		 the end of the row, there will be no stretch glyph,
-		 so leave the box flag set.  */
+	         the end of the row, there will be no stretch glyph,
+	         so leave the box flag set.  */
 	      && saved_x + FRAME_COLUMN_WIDTH (it->f) < it->last_visible_x)
-	    it->end_of_box_run_p = false;
+		  it->end_of_box_run_p = false;
 
+	produce_glyphs:
 	  PRODUCE_GLYPHS (it);
 
 #ifdef HAVE_WINDOW_SYSTEM
@@ -20305,7 +20332,8 @@ extend_face_to_end_of_line (struct it *it)
 #ifdef HAVE_WINDOW_SYSTEM
       && !face->stipple
 #endif
-      && !it->glyph_row->reversed_p)
+      && !it->glyph_row->reversed_p
+      && NILP (Vdisplay_fill_column_indicator))
     return;
 
   /* Set the glyph row flag indicating that the face of the last glyph
@@ -20359,6 +20387,55 @@ extend_face_to_end_of_line (struct it *it)
 	    }
 	}
 #ifdef HAVE_WINDOW_SYSTEM
+
+      if (!NILP (Vdisplay_fill_column_indicator)
+          && FIXNATP (Vdisplay_fill_column_indicator_column)
+          && FIXNATP (Vdisplay_fill_column_indicator_character))
+        {
+
+	  struct font *font = default_face->font ? default_face->font : FRAME_FONT (f);
+	  const int char_width = font->average_width ? font->average_width : font->space_width;
+
+	  const int fill_column = XFIXNAT (Vdisplay_fill_column_indicator_column);
+
+	  const int column_x = char_width * fill_column + it->lnum_pixel_width;
+
+	  if ((it->current_x < column_x)
+	      && (column_x < it->last_visible_x))
+	    {
+	      const char saved_char = it->char_to_display;
+	      const struct text_pos saved_pos = it->position;
+	      const bool saved_avoid_cursor = it->avoid_cursor_p;
+	      const int saved_face_id = it->face_id;
+	      const bool saved_box_start = it->start_of_box_run_p;
+	      Lisp_Object save_object = it->object;
+
+	      /* The stretch width needs to considet the latter added glyph */
+	      const int stretch_width = column_x - it->current_x - char_width;
+
+	      int stretch_ascent = (((it->ascent + it->descent)
+		    * FONT_BASE (font)) / FONT_HEIGHT (font));
+
+	      it->char_to_display = XFIXNAT(Vdisplay_fill_column_indicator_character);
+	      memset (&it->position, 0, sizeof it->position);
+	      it->avoid_cursor_p = true;
+	      it->face_id = merge_faces (it->w, Qfill_column, 0, DEFAULT_FACE_ID);
+	      it->start_of_box_run_p = false;
+	      it->object = Qnil;
+
+	      append_stretch_glyph (it, Qnil, stretch_width,
+	                            it->ascent + it->descent, stretch_ascent);
+
+	      PRODUCE_GLYPHS (it);
+
+	      it->position = saved_pos;
+	      it->avoid_cursor_p = saved_avoid_cursor;
+	      it->face_id = saved_face_id;
+	      it->start_of_box_run_p = saved_box_start;
+	      it->char_to_display = saved_char;
+	      it->object = save_object;
+	    }
+        }
       if (it->glyph_row->reversed_p)
 	{
 	  /* Prepend a stretch glyph to the row, such that the
@@ -20478,10 +20555,34 @@ extend_face_to_end_of_line (struct it *it)
 	it->face_id = default_face->id;
       else
 	it->face_id = face->id;
-      PRODUCE_GLYPHS (it);
 
-      while (it->current_x <= it->last_visible_x)
-	PRODUCE_GLYPHS (it);
+      /* Display fill-column-line if mode is active */
+      if (!NILP (Vdisplay_fill_column_indicator))
+	{
+	  const int fill_column_indicator_line =
+	    XFIXNAT (Vdisplay_fill_column_indicator_column) + it->lnum_pixel_width;
+	  do
+	    {
+	      if (it->current_x == fill_column_indicator_line)
+	        {
+		  const int saved_face = it->face_id;
+		  it->face_id = merge_faces (it->w, Qfill_column, 0, DEFAULT_FACE_ID);
+		  it->c = it->char_to_display = XFIXNAT(Vdisplay_fill_column_indicator_character);
+		  PRODUCE_GLYPHS (it);
+		  it->face_id = saved_face;
+		  it->c = it->char_to_display = ' ';
+	        }
+	      else
+		PRODUCE_GLYPHS (it);
+	    } while (it->current_x < it->last_visible_x);
+	}
+      else
+	{
+          do
+	    {
+	      PRODUCE_GLYPHS (it);
+            } while (it->current_x < it->last_visible_x);
+        }
 
       if (WINDOW_RIGHT_MARGIN_WIDTH (it->w) > 0
 	  && (it->glyph_row->used[RIGHT_MARGIN_AREA]
@@ -20571,14 +20672,16 @@ highlight_trailing_whitespace (struct it *it)
       if (!row->reversed_p)
 	{
 	  while (glyph >= start
-		 && glyph->type == CHAR_GLYPH
+	         && (glyph->type == CHAR_GLYPH
+	             || glyph->type == STRETCH_GLYPH)
 		 && NILP (glyph->object))
 	    --glyph;
 	}
       else
 	{
 	  while (glyph <= start
-		 && glyph->type == CHAR_GLYPH
+		 && (glyph->type == CHAR_GLYPH
+	             || glyph->type == STRETCH_GLYPH)
 		 && NILP (glyph->object))
 	    ++glyph;
 	}
@@ -32645,6 +32748,9 @@ be let-bound around code that needs to disable messages temporarily. */);
   /* Name of a text property which disables line-number display.  */
   DEFSYM (Qdisplay_line_numbers_disable, "display-line-numbers-disable");
 
+  /* Names of the faces used to display fill column indicator character. */
+  DEFSYM (Qfill_column, "fill-column");
+
   /* Name and number of the face used to highlight escape glyphs.  */
   DEFSYM (Qescape_glyph, "escape-glyph");
 
@@ -33213,6 +33319,27 @@ either `relative' or `visual'.  */);
   DEFSYM (Qdisplay_line_numbers_widen, "display-line-numbers-widen");
   Fmake_variable_buffer_local (Qdisplay_line_numbers_widen);
 
+  DEFVAR_LISP ("display-fill-column-indicator", Vdisplay_fill_column_indicator,
+    doc: /* Non-nil means display the fill column indicator.  */);
+  Vdisplay_fill_column_indicator = Qnil;
+  DEFSYM (Qdisplay_fill_column_indicator, "display-fill-column-indicator");
+  Fmake_variable_buffer_local (Qdisplay_fill_column_indicator);
+
+  DEFVAR_LISP ("display-fill-column-indicator-column", Vdisplay_fill_column_indicator_column,
+    doc: /* Column to draw the indicator when `display-fill-column-indicator' is non-nil.
+The default value is the variable `fill-column' if not other value is given. */);
+  Vdisplay_fill_column_indicator_column = Qnil;
+  DEFSYM (Qdisplay_fill_column_indicator_column, "display-fill-column-indicator-column");
+  Fmake_variable_buffer_local (Qdisplay_fill_column_indicator_column);
+
+  DEFVAR_LISP ("display-fill-column-indicator-character", Vdisplay_fill_column_indicator_character,
+    doc: /* Character to draw the indicator when `display-fill-column-indicator' is non-nil.
+The default is ?\u2502 the but a good alternative is (ascii 124) if
+yours font doesn't support unicode characters.  */);
+  Vdisplay_fill_column_indicator_character = Qnil;
+  DEFSYM (Qdisplay_fill_column_indicator_character, "display-fill-column-indicator-character");
+  Fmake_variable_buffer_local (Qdisplay_fill_column_indicator_character);
+
   DEFVAR_BOOL ("inhibit-eval-during-redisplay", inhibit_eval_during_redisplay,
     doc: /* Non-nil means don't eval Lisp during redisplay.  */);
   inhibit_eval_during_redisplay = false;

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Thu, 14 Mar 2019 04:02:24 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> 1) In the graphical mode the character I use now (?\u2502) does not look
> like a vertical line (there is a small vertical space between them so
> the line now looks like with ?|); in terminal it looks fine.

It looks fine with the default font I use here in GUI frames: no
vertical space between lines.  So this obviously depends on the font
used for the indicator character.

> What's the proper way to change the font size or the character
> itself to fit the entire row height in the graphical mode?

I don't recommend changing the size, because that will change the
height of the entire screen line, and will have the unpleasant side
effect of changing the vertical spacing of those lines that don't
exceed the fill-column, while lines that do exceed it will have the
original vertical spacing.  Plus, it won't make the vertical space
between the indicator characters disappear.

Instead, I suggest to change the font used for that character, if your
default font has this problem.

The way to change both the size and the font of the character is by
customizing the face used for the indicator.  And since you already
let users customize that face, you can leave this issue alone, and
rely on users to find a suitable font.

> 2) Are there any extra considerations needed to use the character
> ?\u2502 ? Is it needed to check (for example) if the actual fonts can
> display it properly?

If the user customized the face, you don't need to make sure the font
can display it: it's up to the user to do so.  For the default, you
could perhaps check in the function which turns on this mode that
U+2502 is displayable, and if not, fall back on the ASCII '|'.  See
char-displayable-p.  There's also font-get-glyphs, if you need a more
accurate test (but I don't think you do).

> 3) Actually there are 3 possible configuration options the column
> number, the character, and the font. Should we provide some other
> alternative?

See above: since you already provide a special face, the font
customization is already covered and doesn't need a separate knob.

> The next step is to implement the R2L version of this, but I don't have
> used R2L editing ever, so it may take a while.

Are you sure you need to do anything at all for supporting R2L?  Both
PRODUCE_GLYPHS and append_stretch_glyph DTRT transparently with R2L
screen lines, so I think you don't need anything else.  You can try
using TUTORIAL.he as your playing ground; I don't expect you to see
any problems with this feature in R2L lines.

A couple of comments to the patch you posted:

> +	  int local_default_face_id = lookup_basic_face (it->w, it->f, DEFAULT_FACE_ID);

Please keep the source lines shorter than 78 columns; longer lines
should be broken into several shorter lines (here and elsewhere in
your patch).

> -		 the end of the row, there will be no stretch glyph,
> -		 so leave the box flag set.  */
> +	         the end of the row, there will be no stretch glyph,
> +	         so leave the box flag set.  */
>  	      && saved_x + FRAME_COLUMN_WIDTH (it->f) < it->last_visible_x)
> -	    it->end_of_box_run_p = false;
> +		  it->end_of_box_run_p = false;

This part seems to change only the whitespace, and I don't see any
reason for doing that here.

> +	      it->char_to_display = XFIXNAT(Vdisplay_fill_column_indicator_character);

Please leave one space between the macro name and the opening
parenthesis that follows it.

> -      while (it->current_x <= it->last_visible_x)
> -	PRODUCE_GLYPHS (it);
> +      /* Display fill-column-line if mode is active */
> +      if (!NILP (Vdisplay_fill_column_indicator))
> +	{
> +	  const int fill_column_indicator_line =
> +	    XFIXNAT (Vdisplay_fill_column_indicator_column) + it->lnum_pixel_width;
> +	  do
> +	    {
> +	      if (it->current_x == fill_column_indicator_line)
> +	        {
> +		  const int saved_face = it->face_id;
> +		  it->face_id = merge_faces (it->w, Qfill_column, 0, DEFAULT_FACE_ID);
> +		  it->c = it->char_to_display = XFIXNAT(Vdisplay_fill_column_indicator_character);
> +		  PRODUCE_GLYPHS (it);
> +		  it->face_id = saved_face;
> +		  it->c = it->char_to_display = ' ';
> +	        }
> +	      else
> +		PRODUCE_GLYPHS (it);
> +	    } while (it->current_x < it->last_visible_x);
> +	}
> +      else
> +	{
> +          do
> +	    {
> +	      PRODUCE_GLYPHS (it);
> +            } while (it->current_x < it->last_visible_x);
> +        }

Here you replaced a while loop with a do-while loop, which means you
always produce at least one glyph, where the original code might not
have produced any glyphs.  Did you verify this cannot give us any trouble?
Can this code be entered with it->current_x == it->last_visible_x?

> +  /* Names of the faces used to display fill column indicator character. */
> +  DEFSYM (Qfill_column, "fill-column");

"Name of the face", in singular, right?

Also, please keep 2 spaces after the last sentence of a comment, like
this:

  /* Names of the faces used to display fill column indicator character.  */
                                                                       ^^^

> +  DEFVAR_LISP ("display-fill-column-indicator-character", Vdisplay_fill_column_indicator_character,
> +    doc: /* Character to draw the indicator when `display-fill-column-indicator' is non-nil.
> +The default is ?\u2502 the but a good alternative is (ascii 124) if
> +yours font doesn't support unicode characters.  */);

We use the U+NNNN notation in documentation and comments, not ?\uNNNN.
Also, please capitalize "Unicode".  And "yours font" should be "your
font" (I'd actually reword to refer to the font specified by the
fill-column face).

Thanks.

P.S. Btw, there's no need to post diffs for ldefs-boot.el, that file
is regenerated and committed automatically from time to time, courtesy
of Glenn's scripts.

Re: Fill column indicator functionality

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 3981 bytes --]

On Thu, Mar 14, 2019 at 08:40:27AM +0200, Eli Zaretskii wrote:

>> 3) Actually there are 3 possible configuration options the column
>> number, the character, and the font. Should we provide some other
>> alternative?
>
>See above: since you already provide a special face, the font
>customization is already covered and doesn't need a separate knob.
>
Sorry, I wanted to put face not fonts in fact

>> The next step is to implement the R2L version of this, but I don't have
>> used R2L editing ever, so it may take a while.
>
>Are you sure you need to do anything at all for supporting R2L?  Both
>PRODUCE_GLYPHS and append_stretch_glyph DTRT transparently with R2L
>screen lines, so I think you don't need anything else.  You can try
>using TUTORIAL.he as your playing ground; I don't expect you to see
>any problems with this feature in R2L lines.
>
Now I tried and it works, and passed my tests. 

>A couple of comments to the patch you posted:
>
>> +	  int local_default_face_id = lookup_basic_face (it->w, it->f, DEFAULT_FACE_ID);
>
>Please keep the source lines shorter than 78 columns; longer lines
>should be broken into several shorter lines (here and elsewhere in
>your patch).
>

That's why I needed to implement this functionality ;).

>> -		 the end of the row, there will be no stretch glyph,
>> -		 so leave the box flag set.  */
>> +	         the end of the row, there will be no stretch glyph,
>> +	         so leave the box flag set.  */
>>  	      && saved_x + FRAME_COLUMN_WIDTH (it->f) < it->last_visible_x)
>> -	    it->end_of_box_run_p = false;
>> +		  it->end_of_box_run_p = false;
>
>This part seems to change only the whitespace, and I don't see any
>reason for doing that here.
>
Fixed
>> +	      it->char_to_display = XFIXNAT(Vdisplay_fill_column_indicator_character);
>
>Please leave one space between the macro name and the opening
>parenthesis that follows it.
>
>
>Here you replaced a while loop with a do-while loop, which means you
>always produce at least one glyph, where the original code might not
>have produced any glyphs.  Did you verify this cannot give us any trouble?
>Can this code be entered with it->current_x == it->last_visible_x?
>
In the original code there was a PRODUCE_GLYPHS (it); just before the
while loop, so at least one was always produced, that's why I switched
to a do loop. Checking the patch, a potential issue may come from the
fact that I changes the <= for a < and actually there was a missing
GLYPH at the very end. I fixed that now.

>> +  /* Names of the faces used to display fill column indicator character. */
>> +  DEFSYM (Qfill_column, "fill-column");
>
>"Name of the face", in singular, right?
>
>Also, please keep 2 spaces after the last sentence of a comment, like
>this:
>
>  /* Names of the faces used to display fill column indicator character.  */
>                                                                       ^^^
>
>Thanks.
>
>P.S. Btw, there's no need to post diffs for ldefs-boot.el, that file
>is regenerated and committed automatically from time to time, courtesy
>of Glenn's scripts.

Good to know, then why it is not in the gitignore as loaddefs.el?

More questions:

There is DEFVAR_INT and DEFVAR_BOOL. Does it makes sense to use those to
define display-fill-column-indicator-column and
display-fill-column-indicator; instead of DEFVAR_LISP??

Should we add some code in order to assert that if the user changes
fill-column and it is equal to display-fill-column-indicator-column;
then the second one should be updated too? Because
display-fill-column-indicator-column must be == fill-column except if the
users explicitly sets it to a different value.

Finally, if you think that there is something else missing to consider
this as ready, please tell me, else, tell me how to do a pull request.

Maybe in the future I will consider the alternative to change the
background color, but I don't want to make this too complex or add more
overhead to the display engine.

Best
Ergus

[-- Attachment #2: display-fill-column-indicator.patch --]
[-- Type: text/plain, Size: 16359 bytes --]

diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index baa05d0a89..3f58eac63b 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -648,6 +648,11 @@ since it could result in memory overflow and make Emacs crash."
                                   (const :tag "Count lines from beginning of narrowed region"
                                          :value nil))
                                  "26.1")
+
+             (display-fill-column-indicator-column display-fill-column-indicator
+                                 integer "27.1")
+             (display-fill-column-indicator-character display-fill-column-indicator
+                                 character "27.1")
 	     ;; xfaces.c
 	     (scalable-fonts-allowed display boolean "22.1")
 	     ;; xfns.c
diff --git a/lisp/display-fill-column-indicator.el b/lisp/display-fill-column-indicator.el
new file mode 100644
index 0000000000..6e0990839e
--- /dev/null
+++ b/lisp/display-fill-column-indicator.el
@@ -0,0 +1,78 @@
+;;; display-fill-column-indicator.el --- interface for display-fill-column-indicator -*- lexical-binding: t -*-
+
+;; Copyright (C) 2017-2019 Free Software Foundation, Inc.
+
+;; Maintainer: emacs-devel@gnu.org
+;; Keywords: convenience
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; Provides a minor mode interface for `display-fill-column-indicator'.
+;;
+;; Toggle display of line numbers with M-x
+;; display-fill-column-indicator-mode.  To enable line numbering in
+;; all buffers, use M-x global-display-fill-column-indicator-mode.  To
+;; change the default line column
+
+
+;; NOTE: Customization variables for
+;; `display-fill-column-indicator-column' and
+;; `display-fill-column-indicator-char' itself are defined in
+;; cus-start.el.
+
+;;; Code:
+
+(defgroup display-fill-column-indicator nil
+  "Display line numbers in the buffer."
+  :group 'convenience
+  :group 'display)
+
+
+;;;###autoload
+(define-minor-mode display-fill-column-indicator-mode
+  "Toggle display fill column indicator.
+This uses `display-fill-column-indicator' internally.
+
+To change the position of the line displayed by default,
+customize `display-fill-column-indicator-column' you can change the
+character for the line setting `display-fill-column-indicator-character'."
+  :lighter nil
+  (if display-fill-column-indicator-mode
+      (progn
+        (setq display-fill-column-indicator t)
+        (unless display-fill-column-indicator-column
+          (setq display-fill-column-indicator-column fill-column))
+        (unless display-fill-column-indicator-character
+          (if (char-displayable-p ?\u2502)
+              (setq display-fill-column-indicator-character ?\u2502)
+            (setq display-fill-column-indicator-character ?|))))
+    (setq display-fill-column-indicator nil)))
+
+(defun display-fill-column-indicator--turn-on ()
+  "Turn on `display-fill-column-indicator-mode'."
+  (unless (or (minibufferp)
+              (and (daemonp) (null (frame-parameter nil 'client))))
+    (display-fill-column-indicator-mode)))
+
+;;;###autoload
+(define-globalized-minor-mode global-display-fill-column-indicator-mode
+  display-fill-column-indicator-mode display-fill-column-indicator--turn-on)
+
+(provide 'display-fill-column-indicator)
+
+;;; display-fill-column-indicator.el ends here
diff --git a/lisp/faces.el b/lisp/faces.el
index ab6c384c80..c60f1da6f5 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2502,6 +2502,20 @@ unwanted effects."
   :group 'basic-faces
   :group 'display-line-numbers)
 
+;; Definition stolen from display-line-numbers.
+(defface fill-column
+  '((t :inherit (shadow default)))
+  "Face for displaying fill column indicator line.
+This face is used when `display-fill-column-indicator-mode' is
+non-nil.
+
+If you customize the font of this face, make sure it is a
+monospaced font, otherwise the line's characters will not line
+up horizontally."
+  :version "27.1"
+  :group 'basic-faces
+  :group 'display-fill-column-indicator)
+
 (defface escape-glyph
   '((((background dark)) :foreground "cyan")
     ;; See the comment in minibuffer-prompt for
diff --git a/lisp/frame.el b/lisp/frame.el
index dd1d5b030f..03c4d0761b 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -2663,6 +2663,9 @@ See also `toggle-frame-maximized'."
         display-line-numbers-width
         display-line-numbers-current-absolute
         display-line-numbers-widen
+        display-fill-column-indicator
+        display-fill-column-indicator-column
+        display-fill-column-indicator-character
         bidi-paragraph-direction
         bidi-display-reordering))
 
diff --git a/lisp/ldefs-boot.el b/lisp/ldefs-boot.el
index 0e8e5f699b..1227ceb377 100644
--- a/lisp/ldefs-boot.el
+++ b/lisp/ldefs-boot.el
@@ -7734,7 +7734,44 @@ See `display-line-numbers-mode' for more information on Display-Line-Numbers mod
 
 \(fn &optional ARG)" t nil)
 
-(if (fboundp 'register-definition-prefixes) (register-definition-prefixes "display-line-numbers" '("display-line-numbers-")))
+(if (fboundp 'register-definition-prefixes)
+    (register-definition-prefixes "display-line-numbers" '("display-line-numbers-")))
+
+;;;***
+\f
+;;;### (autoloads nil "display-fill-column-indicator" "display-fill-column-indicator.el"
+;;;;;;  (0 0 0 0))
+;;; Generated autoloads from display-fill-column-indicator.el
+
+(autoload 'display-fill-column-indicator-mode "display-fill-column-indicator" "\
+Toggle display fill column indicator.
+This uses `display-fill-column-indicator' internally.
+
+To change the position of the line displayed by default,
+customize `display-fill-column-indicator-column'.
+
+\(fn &optional ARG)" t nil)
+
+(defvar global-display-fill-column-indicator-mode nil "\
+Non-nil if Global Display-fill-column-indicator mode is enabled.
+See the `global-display-fill-column-indicator-mode' command
+for a description of this minor mode.")
+
+(custom-autoload 'global-display-fill-column-indicator-mode
+                 "display-fill-column-indicator" nil)
+
+(autoload 'global-display-fill-column-indicator-mode
+  "display-fill-column-indicator" "\
+Toggle display fill column indicator.
+This uses `display-fill-column-indicator' internally.
+
+To change the position of the line displayed by default,
+customize `display-fill-column-indicator-column'.
+
+\(fn &optional ARG)" t nil)
+
+(if (fboundp 'register-definition-prefixes)
+    (register-definition-prefixes "display-fill-column-indicator" '("display-fill-column-indicator-")))
 
 ;;;***
 \f
diff --git a/src/xdisp.c b/src/xdisp.c
index 6d30afda6d..1994c9b6a1 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -20135,15 +20135,48 @@ append_space_for_newline (struct it *it, bool default_face_p)
 	  it->what = IT_CHARACTER;
 	  memset (&it->position, 0, sizeof it->position);
 	  it->object = Qnil;
-	  it->c = it->char_to_display = ' ';
 	  it->len = 1;
 
+	  int local_default_face_id =
+	    lookup_basic_face (it->w, it->f, DEFAULT_FACE_ID);
+	  struct face* default_face =
+	    FACE_FROM_ID_OR_NULL (it->f, local_default_face_id);
+
+	  /* Corner case for when display-fill-column-indicator-mode
+	     is active and the extra character should be added in the
+	     same place than the line */
+	  if (!NILP (Vdisplay_fill_column_indicator)
+	      && FIXNATP (Vdisplay_fill_column_indicator_column)
+	      && FIXNATP (Vdisplay_fill_column_indicator_character))
+	    {
+	       struct font *font =
+	         default_face->font ? default_face->font : FRAME_FONT (it->f);
+	       const int char_width =
+	         font->average_width ? font->average_width : font->space_width;
+	       const int fill_column =
+		 XFIXNAT (Vdisplay_fill_column_indicator_column);
+	       const int column_x =
+		 char_width * fill_column + it->lnum_pixel_width;
+
+	       if (it->current_x == column_x)
+	         {
+	           it->c = it->char_to_display =
+		     XFIXNAT (Vdisplay_fill_column_indicator_character);
+	           it->face_id =
+		     merge_faces (it->w, Qfill_column, 0, DEFAULT_FACE_ID);
+	           face = FACE_FROM_ID(it->f, it->face_id);
+	           goto produce_glyphs;
+	         }
+	    }
+
+	  it->c = it->char_to_display = ' ';
 	  /* If the default face was remapped, be sure to use the
 	     remapped face for the appended newline.  */
 	  if (default_face_p)
-	    it->face_id = lookup_basic_face (it->w, it->f, DEFAULT_FACE_ID);
+	    it->face_id = local_default_face_id;
 	  else if (it->face_before_selective_p)
 	    it->face_id = it->saved_face_id;
+
 	  face = FACE_FROM_ID (it->f, it->face_id);
 	  it->face_id = FACE_FOR_CHAR (it->f, face, 0, -1, Qnil);
 	  /* In R2L rows, we will prepend a stretch glyph that will
@@ -20152,11 +20185,12 @@ append_space_for_newline (struct it *it, bool default_face_p)
 	     set.  */
 	  if (it->glyph_row->reversed_p
 	      /* But if the appended newline glyph goes all the way to
-		 the end of the row, there will be no stretch glyph,
-		 so leave the box flag set.  */
+	      the end of the row, there will be no stretch glyph,
+	      so leave the box flag set.  */
 	      && saved_x + FRAME_COLUMN_WIDTH (it->f) < it->last_visible_x)
 	    it->end_of_box_run_p = false;
 
+	produce_glyphs:
 	  PRODUCE_GLYPHS (it);
 
 #ifdef HAVE_WINDOW_SYSTEM
@@ -20305,7 +20339,8 @@ extend_face_to_end_of_line (struct it *it)
 #ifdef HAVE_WINDOW_SYSTEM
       && !face->stipple
 #endif
-      && !it->glyph_row->reversed_p)
+      && !it->glyph_row->reversed_p
+      && NILP (Vdisplay_fill_column_indicator))
     return;
 
   /* Set the glyph row flag indicating that the face of the last glyph
@@ -20359,6 +20394,60 @@ extend_face_to_end_of_line (struct it *it)
 	    }
 	}
 #ifdef HAVE_WINDOW_SYSTEM
+
+      if (!NILP (Vdisplay_fill_column_indicator)
+          && FIXNATP (Vdisplay_fill_column_indicator_column)
+          && FIXNATP (Vdisplay_fill_column_indicator_character))
+        {
+
+	  struct font *font =
+	    default_face->font ? default_face->font : FRAME_FONT (f);
+	  const int char_width =
+	    font->average_width ? font->average_width : font->space_width;
+
+	  const int fill_column =
+	    XFIXNAT (Vdisplay_fill_column_indicator_column);
+
+	  const int column_x = char_width * fill_column + it->lnum_pixel_width;
+
+	  if ((it->current_x < column_x)
+	      && (column_x < it->last_visible_x))
+	    {
+	      const char saved_char = it->char_to_display;
+	      const struct text_pos saved_pos = it->position;
+	      const bool saved_avoid_cursor = it->avoid_cursor_p;
+	      const int saved_face_id = it->face_id;
+	      const bool saved_box_start = it->start_of_box_run_p;
+	      Lisp_Object save_object = it->object;
+
+	      /* The stretch width needs to considet the latter added glyph */
+	      const int stretch_width = column_x - it->current_x - char_width;
+
+	      int stretch_ascent = (((it->ascent + it->descent)
+		    * FONT_BASE (font)) / FONT_HEIGHT (font));
+
+	      it->char_to_display =
+	        XFIXNAT (Vdisplay_fill_column_indicator_character);
+	      memset (&it->position, 0, sizeof it->position);
+	      it->avoid_cursor_p = true;
+	      it->face_id =
+	        merge_faces (it->w, Qfill_column, 0, DEFAULT_FACE_ID);
+	      it->start_of_box_run_p = false;
+	      it->object = Qnil;
+
+	      append_stretch_glyph (it, Qnil, stretch_width,
+	                            it->ascent + it->descent, stretch_ascent);
+
+	      PRODUCE_GLYPHS (it);
+
+	      it->position = saved_pos;
+	      it->avoid_cursor_p = saved_avoid_cursor;
+	      it->face_id = saved_face_id;
+	      it->start_of_box_run_p = saved_box_start;
+	      it->char_to_display = saved_char;
+	      it->object = save_object;
+	    }
+        }
       if (it->glyph_row->reversed_p)
 	{
 	  /* Prepend a stretch glyph to the row, such that the
@@ -20478,10 +20567,37 @@ extend_face_to_end_of_line (struct it *it)
 	it->face_id = default_face->id;
       else
 	it->face_id = face->id;
-      PRODUCE_GLYPHS (it);
 
-      while (it->current_x <= it->last_visible_x)
-	PRODUCE_GLYPHS (it);
+      /* Display fill-column-line if mode is active */
+      if (!NILP (Vdisplay_fill_column_indicator))
+	{
+	  const int fill_column_indicator_line =
+	    XFIXNAT (Vdisplay_fill_column_indicator_column)
+	      + it->lnum_pixel_width;
+	  do
+	    {
+	      if (it->current_x == fill_column_indicator_line)
+	        {
+		  const int saved_face = it->face_id;
+		  it->face_id =
+		    merge_faces (it->w, Qfill_column, 0, DEFAULT_FACE_ID);
+		  it->c = it->char_to_display =
+		    XFIXNAT (Vdisplay_fill_column_indicator_character);
+		  PRODUCE_GLYPHS (it);
+		  it->face_id = saved_face;
+		  it->c = it->char_to_display = ' ';
+	        }
+	      else
+		PRODUCE_GLYPHS (it);
+	    } while (it->current_x <= it->last_visible_x);
+	}
+      else
+	{
+          do
+	    {
+	      PRODUCE_GLYPHS (it);
+            } while (it->current_x <= it->last_visible_x);
+        }
 
       if (WINDOW_RIGHT_MARGIN_WIDTH (it->w) > 0
 	  && (it->glyph_row->used[RIGHT_MARGIN_AREA]
@@ -20571,14 +20687,16 @@ highlight_trailing_whitespace (struct it *it)
       if (!row->reversed_p)
 	{
 	  while (glyph >= start
-		 && glyph->type == CHAR_GLYPH
+	         && (glyph->type == CHAR_GLYPH
+	             || glyph->type == STRETCH_GLYPH)
 		 && NILP (glyph->object))
 	    --glyph;
 	}
       else
 	{
 	  while (glyph <= start
-		 && glyph->type == CHAR_GLYPH
+		 && (glyph->type == CHAR_GLYPH
+	             || glyph->type == STRETCH_GLYPH)
 		 && NILP (glyph->object))
 	    ++glyph;
 	}
@@ -32645,6 +32763,9 @@ be let-bound around code that needs to disable messages temporarily. */);
   /* Name of a text property which disables line-number display.  */
   DEFSYM (Qdisplay_line_numbers_disable, "display-line-numbers-disable");
 
+  /* Names of the face used to display fill column indicator character.  */
+  DEFSYM (Qfill_column, "fill-column");
+
   /* Name and number of the face used to highlight escape glyphs.  */
   DEFSYM (Qescape_glyph, "escape-glyph");
 
@@ -33213,6 +33334,27 @@ either `relative' or `visual'.  */);
   DEFSYM (Qdisplay_line_numbers_widen, "display-line-numbers-widen");
   Fmake_variable_buffer_local (Qdisplay_line_numbers_widen);
 
+  DEFVAR_LISP ("display-fill-column-indicator", Vdisplay_fill_column_indicator,
+    doc: /* Non-nil means display the fill column indicator.  */);
+  Vdisplay_fill_column_indicator = Qnil;
+  DEFSYM (Qdisplay_fill_column_indicator, "display-fill-column-indicator");
+  Fmake_variable_buffer_local (Qdisplay_fill_column_indicator);
+
+  DEFVAR_LISP ("display-fill-column-indicator-column", Vdisplay_fill_column_indicator_column,
+    doc: /* Column to draw the indicator when `display-fill-column-indicator' is non-nil.
+The default value is the variable `fill-column' if not other value is given. */);
+  Vdisplay_fill_column_indicator_column = Qnil;
+  DEFSYM (Qdisplay_fill_column_indicator_column, "display-fill-column-indicator-column");
+  Fmake_variable_buffer_local (Qdisplay_fill_column_indicator_column);
+
+  DEFVAR_LISP ("display-fill-column-indicator-character", Vdisplay_fill_column_indicator_character,
+    doc: /* Character to draw the indicator when `display-fill-column-indicator' is non-nil.
+The default is U+2502 the but a good alternative is (ascii 124) if
+the font in fill-column-face supports Unicode characters.  */);
+  Vdisplay_fill_column_indicator_character = Qnil;
+  DEFSYM (Qdisplay_fill_column_indicator_character, "display-fill-column-indicator-character");
+  Fmake_variable_buffer_local (Qdisplay_fill_column_indicator_character);
+
   DEFVAR_BOOL ("inhibit-eval-during-redisplay", inhibit_eval_during_redisplay,
     doc: /* Non-nil means don't eval Lisp during redisplay.  */);
   inhibit_eval_during_redisplay = false;

Re: Fill column indicator functionality

[Andreas Schwab]

On Mär 14 2019, Ergus <spacibba@aol.com> wrote:

> Good to know, then why it is not in the gitignore as loaddefs.el?

gitignore is irrelevant for tracked files.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Thu, 14 Mar 2019 17:51:49 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> >> The next step is to implement the R2L version of this, but I don't have
> >> used R2L editing ever, so it may take a while.
> >
> >Are you sure you need to do anything at all for supporting R2L?  Both
> >PRODUCE_GLYPHS and append_stretch_glyph DTRT transparently with R2L
> >screen lines, so I think you don't need anything else.  You can try
> >using TUTORIAL.he as your playing ground; I don't expect you to see
> >any problems with this feature in R2L lines.
> >
> Now I tried and it works, and passed my tests. 

As expected.

> >P.S. Btw, there's no need to post diffs for ldefs-boot.el, that file
> >is regenerated and committed automatically from time to time, courtesy
> >of Glenn's scripts.
> 
> Good to know, then why it is not in the gitignore as loaddefs.el?

Because unlike loaddefs.el, ldefs-boot.el is a versioned file.  It
must be in the repository, otherwise people would be unable to build a
fresh checkout.  It just isn't maintained by hand, that's all.

> There is DEFVAR_INT and DEFVAR_BOOL. Does it makes sense to use those to
> define display-fill-column-indicator-column and
> display-fill-column-indicator; instead of DEFVAR_LISP??

Using DEFVAR_INT and DEFVAR_BOOL makes it easier to reference the
variable in C, since you have a normal C integer or boolean.  So, for
example, you can say

  if (emacs_scroll_step > 0)

instead of

  if (XFIXNAT (Vemacs_scroll_step) > 0)

and

  if (!inhibit_message)

instead of

  if (!NILP (Vinhibit_message))

> Should we add some code in order to assert that if the user changes
> fill-column and it is equal to display-fill-column-indicator-column;
> then the second one should be updated too? Because
> display-fill-column-indicator-column must be == fill-column except if the
> users explicitly sets it to a different value.

We could use a special value of t for
display-fill-column-indicator-column to mean the current value of
fill-column.

> Finally, if you think that there is something else missing to consider
> this as ready, please tell me, else, tell me how to do a pull request.

I think the main part that is missing is your copyright assignment.
Did you do your legal paperwork?  If not, now is the time to start it.
This patch is large enough to require a copyright assignment.

The only other missing parts are documentation: NEWS and the user
manual.

Btw, did you test the code when there are variable-size characters in
the buffer?  Good test cases are Info files and also Web pages with
images visited via EWW.

> Maybe in the future I will consider the alternative to change the
> background color, but I don't want to make this too complex or add more
> overhead to the display engine.

Indicating the fill-column with background can use almost the same
code as the one you wrote, but we will need to decide what to do if
the text that exceeds fill-column itself has non-default background.
Also, I think the visual effect will be less pleasant when there are
continued lines, because background color is more prominent than an
indicator by a single character.

Thanks.

Re: Fill column indicator functionality

[Clément Pit-Claudel]

On 14/03/2019 02.40, Eli Zaretskii wrote:
>> Date: Thu, 14 Mar 2019 04:02:24 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> 1) In the graphical mode the character I use now (?\u2502) does not look
>> like a vertical line (there is a small vertical space between them so
>> the line now looks like with ?|); in terminal it looks fine.
>
> It looks fine with the default font I use here in GUI frames: no
> vertical space between lines.  So this obviously depends on the font
> used for the indicator character.

Sorry for jumping in late without having followed the whole discussion.  Here's a naive question: is there any reason to use an actual glyph from a face to draw that line, rather than just a continuous line?

A good analogy might be the way window separators ("vertical borders") are drawn: when I use a non-graphical Emacs it uses a series of '|' characters to draw separations between windows, but when I use a graphical Emacs (with scroll-bars-mode off) it draws a solid black line, or at least that's what I understand from e.g. https://lists.gnu.org/archive/html/help-gnu-emacs/2013-01/msg00257.html.

Sorry if I missed something obvious.
Clément.

Re: Fill column indicator functionality

[Óscar Fuentes]

Ergus <spacibba@aol.com> writes:

> +;;;###autoload
> +(define-minor-mode display-fill-column-indicator-mode
> +  "Toggle display fill column indicator.
> +This uses `display-fill-column-indicator' internally.
> +
> +To change the position of the line displayed by default,
> +customize `display-fill-column-indicator-column' you can change the
> +character for the line setting
> `display-fill-column-indicator-character'."

It seems that you forgot to delete half of that docstring.

> @@ -20571,14 +20687,16 @@ highlight_trailing_whitespace (struct it *it)
>        if (!row->reversed_p)
>  	{
>  	  while (glyph >= start
> -		 && glyph->type == CHAR_GLYPH
> +	         && (glyph->type == CHAR_GLYPH
> +	             || glyph->type == STRETCH_GLYPH)
>  		 && NILP (glyph->object))
>  	    --glyph;
>  	}
>        else
>  	{
>  	  while (glyph <= start
> -		 && glyph->type == CHAR_GLYPH
> +		 && (glyph->type == CHAR_GLYPH
> +	             || glyph->type == STRETCH_GLYPH)
>  		 && NILP (glyph->object))
>  	    ++glyph;
>  	}

This hunk is rejected on `master'. 

> @@ -32645,6 +32763,9 @@ be let-bound around code that needs to disable messages temporarily. */);
>    /* Name of a text property which disables line-number display.  */
>    DEFSYM (Qdisplay_line_numbers_disable, "display-line-numbers-disable");
>  
> +  /* Names of the face used to display fill column indicator character.  */

s/Names/Name

> +  DEFSYM (Qfill_column, "fill-column");
> +

Hmmm... is this right? Copy & pasto?

> +  DEFVAR_LISP ("display-fill-column-indicator-character", Vdisplay_fill_column_indicator_character,
> +    doc: /* Character to draw the indicator when `display-fill-column-indicator' is non-nil.
> +The default is U+2502 the but a good alternative is (ascii 124) if

"the but a good"

> +the font in fill-column-face supports Unicode characters.  */);

supports -> does not support ???


This feature is highly appreciated. Thank you.

Re: Fill column indicator functionality

[Ergus]

On Thu, Mar 14, 2019 at 10:28:24PM +0100, �scar Fuentes wrote:
>Ergus <spacibba@aol.com> writes:
>
>
>This hunk is rejected on `master'.
>
Ohh right, Eli fixed it cause it was related with another bug.

I already rebased and fixed all your correction.

Very thanks.

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 14 Mar 2019 14:58:07 -0400
> 
> Sorry for jumping in late without having followed the whole discussion.  Here's a naive question: is there any reason to use an actual glyph from a face to draw that line, rather than just a continuous line?

That's a good question.  Indeed, it would be possible to implement
this with a single thin line being drawn, but I think such an
implementation would have several disadvantages:

 . It will need to be implemented separately for each window-system
   (X, w32, NS), and for TTY frames.  By contrast, the implementation
   discussed here is in a single place, is independent of the display
   kind, and is very simple and localized.

 . Using a glyph makes it easier to support some fancy customizations.
   For example, suppose that someone would like to have the indicator
   be a dotted line, or to have a more prominent appearance -- all
   they'd need to do is find a suitable character, such as ▍ or ▓, and
   be done.  With the continuous line implementation, we'd need to
   implement the corresponding textures in the code, before it could
   be supported.

 . Using the continuous line would cause complications wrt redisplay
   optimizations.  Redisplay of text is highly optimized in Emacs, and
   frequently needs to update only a small portion of the window.  The
   problem is what to do about the indicator line when only some
   portions are redrawn.  A naïve idea of redrawing the entire line
   would cause it to flicker on each keypress.  (The divider avoids
   this problem because it is drawn where no characters can ever
   overwrite it, so it only needs to be redrawn when the window
   dimensions change, something that is rare and causes a complete
   redrawing of the entire window anyway.)  We could instead arrange
   for redrawing only portions of the line that overlap the glyphs
   which are actually redrawn, but then we'd need to write code for
   detecting those portions.  By contrast, using the glyph-based
   implementation we get this for free, because the redisplay
   optimizations already know how to avoid redrawing glyphs that
   didn't change.  We also get for free support for R2L text,
   something that would again require separate code with the
   continuous line idea.

The continuous line idea does have one advantage: it seamlessly
supports lines of variable height.  But that use case is rare, and I
think we will be able to support them with the glyph-based
implementation as well.

Does this answer your question?

Re: Fill column indicator functionality

[Clément Pit-Claudel]

On 15/03/2019 03.30, Eli Zaretskii wrote:
> Does this answer your question?

It does, thanks. It's a very thorough answer. Thanks for taking the time, Eli!

> The continuous line idea does have one advantage: it seamlessly
> supports lines of variable height.  But that use case is rare, and I
> think we will be able to support them with the glyph-based
> implementation as well.

This was actually going to be my follow-up question :) I see lines of variable height in many of most of my Emacs mode, through a combination of factors:

- Font switches due to symbols picked by prettify-symbols-mode not being available in my main programming font
- Variable-pitch fonts being used by AucTeX for section and paragraph titles 
- Varying font sizes to indicate nesting depth in Org-mode
- Changing line spacing to separate top-level items in org-mode

Is there actually a good way to support all this?  Maybe using a very thin space and a face with a :background on it would do.  Or maybe it will be possible to put a 'display (space …) property on the line character so that it displays as a 1-px wide line?

Also, as a second follow-up question: we already have code to draw boxes around characters; would it be hard to extend that code to allow customization of which sides to draw? Alternatively, would it be hard to add a vertical strike-through face property? (I've used horizontal strike-through as a way to display horizontal lines in the past)

Cheers,
Clément.

Re: Fill column indicator functionality

[Alp Aker]

> That's a good question.  Indeed, it would be possible to implement
> this with a single thin line being drawn, but I think such an
> implementation would have several disadvantages:
>
>   . It will need to be implemented separately for each window-system
>     (X, w32, NS), and for TTY frames.  By contrast, the implementation
>     discussed here is in a single place, is independent of the display
>     kind, and is very simple and localized.

I believe a simpler implementation is possible:  Where Ergus's 
implementation uses a char glyph, it could also use a line-height image 
glyph.  That is, instead of a single window-length element, analogous to 
the window divider, the indicator would consist of many independently 
displayed line segments, one per line.  If we use an image type like XPM 
that's universally supported, this would allow a single implementation 
shared by all window systems, and the implementation for graphical and 
text frames would be the same except for the choice of glyph.  (This is 
the method used by the unfortunate fill-column-indicator package whose 
deficiencies have necessitated the current work.)

>   . Using a glyph makes it easier to support some fancy customizations.
>     For example, suppose that someone would like to have the indicator
>     be a dotted line, or to have a more prominent appearance -- all
>     they'd need to do is find a suitable character, such as ▍ or ▓, and
>     be done.  With the continuous line implementation, we'd need to
>     implement the corresponding textures in the code, before it could
>     be supported.

If we use an image glyph on each line, the customizations would apply 
only to the construction of that XPM image; the display routine that 
positions the image segments doesn't need to know how to construct the 
image.  Users could even supply arbitrary images to use, so long as 
they're of the appropriate height (or they could just be cropped to the 
correct height if necessary).  It's straightforward to define XPM 
bitmaps in code, so this would allow even more flexibility than using 
font characters.

>   . Using the continuous line would cause complications wrt redisplay
>     optimizations.  Redisplay of text is highly optimized in Emacs, and
>     frequently needs to update only a small portion of the window.  The
>     problem is what to do about the indicator line when only some
>     portions are redrawn.

Unless I'm mistaken, the method I'm describing would allow the same 
optimizations that Ergus's current implementation does (since it would, 
as far as display is concerned, be the same except for the choice of 
glyph to use).

Re: Fill column indicator functionality

[Mattias Engdegård]

15 mars 2019 kl. 14.00 skrev Alp Aker <alp.tekin.aker@gmail.com>:
> 
>> That's a good question.  Indeed, it would be possible to implement
>> this with a single thin line being drawn, but I think such an
>> implementation would have several disadvantages:
>> 
>>  . It will need to be implemented separately for each window-system
>>    (X, w32, NS), and for TTY frames.  By contrast, the implementation
>>    discussed here is in a single place, is independent of the display
>>    kind, and is very simple and localized.
> 
> I believe a simpler implementation is possible:  Where Ergus's implementation uses a char glyph, it could also use a line-height image glyph.

Terminal emulators often treat box-drawing characters specially, either drawing the lines themselves or extending parts of the glyphs in case there would be gaps. Even XTerm does this, mainly to supplement missing glyphs.

Being its own terminal emulator, Emacs could do the same to avoid gaps in horizontal and vertical lines that should connect. Box-drawing characters are attractive for use in tables, diagrams and user interfaces, and work in both TTYs and window systems. They are sometimes seen in ASCII+ art in source code comments.

The details are fairly window-system-specific but do not have to be implemented everywhere at once.

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Alp Aker <alp.tekin.aker@gmail.com>
> Date: Fri, 15 Mar 2019 09:00:59 -0400
> 
> > That's a good question.  Indeed, it would be possible to implement
> > this with a single thin line being drawn, but I think such an
> > implementation would have several disadvantages:
> >
> >   . It will need to be implemented separately for each window-system
> >     (X, w32, NS), and for TTY frames.  By contrast, the implementation
> >     discussed here is in a single place, is independent of the display
> >     kind, and is very simple and localized.
> 
> I believe a simpler implementation is possible:  Where Ergus's 
> implementation uses a char glyph, it could also use a line-height image 
> glyph.

How do you produce a line-height tall image glyph?  Maybe I'm missing
something, but I think we can only display image glyphs whose height
is fixed and determined by the image, or by its slice whose dimensions
are determined by a suitable display property, i.e. computed in
advance of redisplay.

But in any case, if such an image with dynamically computed height can
be produced reasonably easily by the display engine itself, what you
propose is a trivial extension of the code presented here: we just
need to replace the character glyph by an image glyph.

> the implementation for graphical and 
> text frames would be the same except for the choice of glyph.

No, the implementation for the text-mode frame will always need to be
(slightly) different , because it doesn't support images and it
implements the stretch glyph as a series of space-character glyphs.

> >   . Using a glyph makes it easier to support some fancy customizations.
> >     For example, suppose that someone would like to have the indicator
> >     be a dotted line, or to have a more prominent appearance -- all
> >     they'd need to do is find a suitable character, such as ▍ or ▓, and
> >     be done.  With the continuous line implementation, we'd need to
> >     implement the corresponding textures in the code, before it could
> >     be supported.
> 
> If we use an image glyph on each line, the customizations would apply 
> only to the construction of that XPM image

Maybe I'm again missing something, but how can a Lisp program
(i.e. user customizations) produce an XPM image of unlimited height?
If the height is fixed, the image will be unable to produce vertical
lines taller than its height, in order to support tall lines.

Btw, I don't think we can assume universal XPM support: Emacs can
support platforms that only provide monochrome bitmapped images, no
XPM.  E.g., if I remove or rename the XPM DLL, Emacs on Windows still
shows the tool-bar icons, albeit ugly monochrome versions of them.

> It's straightforward to define XPM bitmaps in code, so this would
> allow even more flexibility than using font characters.

I'm sure users will find customizing a character much easier than
customizing an image.  In any case, I wouldn't give up on allowing a
character, even if we do support images, because there's no reason to
restrict users to images.  For example, a suitable selection of a
character could produce identical displays on GUI and TTY frames,
something that an image could never do.

> >   . Using the continuous line would cause complications wrt redisplay
> >     optimizations.  Redisplay of text is highly optimized in Emacs, and
> >     frequently needs to update only a small portion of the window.  The
> >     problem is what to do about the indicator line when only some
> >     portions are redrawn.
> 
> Unless I'm mistaken, the method I'm describing would allow the same 
> optimizations

Yes, but I was replying to a completely different idea.  What you
propose is just a trivial extension of the code posted here, so all of
the effort that went into that will still be valid, and most of my
message is not really relevant.

Re: Fill column indicator functionality

[Óscar Fuentes]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> This was actually going to be my follow-up question :) I see lines of
> variable height in many of most of my Emacs mode, through a
> combination of factors:
>
> - Font switches due to symbols picked by prettify-symbols-mode not
> being available in my main programming font
> - Variable-pitch fonts being used by AucTeX for section and paragraph titles 
> - Varying font sizes to indicate nesting depth in Org-mode
> - Changing line spacing to separate top-level items in org-mode

I don't understand how this feature can make sense for lines with
non-monospaced fonts. The purpose is to know two things:

1. How far we are from the limit column.
2. If the limit was surpassed.

For 2 there are some handy packages (column-overflow-mode, for instance)
that should work for non-monospaced fonts. For 1 the system has no way
of knowing where to put the line, because it depends on the text that we
are going to write.

What I'm missing?

Re: Fill column indicator functionality

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 15 Mar 2019 08:44:20 -0400
> 
> On 15/03/2019 03.30, Eli Zaretskii wrote:
> > Does this answer your question?
> 
> It does, thanks. It's a very thorough answer. Thanks for taking the time, Eli!
> 
> > The continuous line idea does have one advantage: it seamlessly
> > supports lines of variable height.  But that use case is rare, and I
> > think we will be able to support them with the glyph-based
> > implementation as well.
> 
> This was actually going to be my follow-up question :) I see lines of variable height in many of most of my Emacs mode, through a combination of factors:
> 
> - Font switches due to symbols picked by prettify-symbols-mode not being available in my main programming font
> - Variable-pitch fonts being used by AucTeX for section and paragraph titles 
> - Varying font sizes to indicate nesting depth in Org-mode
> - Changing line spacing to separate top-level items in org-mode

Does the fci mode support those use cases?

> Is there actually a good way to support all this?  Maybe using a very thin space and a face with a :background on it would do.  Or maybe it will be possible to put a 'display (space …) property on the line character so that it displays as a 1-px wide line?

You are thinking in terms of a Lisp program, but we are talking about
something the display engine itself does.  E.g., setting display
properties from inside the display engine is a non-starter, because
users don't expect such properties to appear without their say-so.

But yes, we have several methods of scaling display elements which
could be used to solve these use cases.  I just don't think we should
block the feature until they are fixed.  However important are the use
cases you enumerated, they are not the majority in Emacs, right?

> Also, as a second follow-up question: we already have code to draw boxes around characters; would it be hard to extend that code to allow customization of which sides to draw? Alternatively, would it be hard to add a vertical strike-through face property? (I've used horizontal strike-through as a way to display horizontal lines in the past)

I'm not sure where are you going with this.  Yes, Emacs is capable of
drawing horizontal and vertical lines of specified pixel-width, but
the issue here is not whether we can do it, the issue is how to do
that in a way that fits as much as possible the current basic design
and implementation of the display engine.  Otherwise, the job becomes
so large that we probably won't have this feature any time soon.

Specifically, drawing a "vertical strike-through" still doesn't solve
the problem with the height of the line, because the glyph we will
"strike through" will still need to have a suitable height, right?

You need to realize that on its highest level, the display engine
manipulates glyphs (and there are several kinds of them).  All the
decorations that are not glyphs can be drawn only in places where
glyphs can never appear.  In a nutshell (and this is admittedly an
over-simplification), the display engine can display and/or lay out
anything that we can present/represent as a glyph, but that's all it
can do.

Re: Fill column indicator functionality

[Alp Aker]

> How do you produce a line-height tall image glyph?  Maybe I'm missing
> something, but I think we can only display image glyphs whose height
> is fixed and determined by the image, or by its slice whose dimensions
> are determined by a suitable display property, i.e. computed in
> advance of redisplay.
>
> But in any case, if such an image with dynamically computed height can
> be produced reasonably easily by the display engine itself, what you
> propose is a trivial extension of the code presented here: we just
> need to replace the character glyph by an image glyph.

I did not have a dynamically sized images in mind, only fixed-height 
images.  They offer a way of achieving the graphical effect that some 
people in this thread have requested that would involve, as you point 
out, only a trivial extension of what Ergus has already done.

Would lack of support for variable line heights be an issue?  I can only 
offer my experience here as the author of fill-column-indicator.  Among 
the many issues that package has, lack of support for variable line 
heights in a window hasn't been one of them.  It just isn't something 
users have requested.

> I'm sure users will find customizing a character much easier than
> customizing an image.  In any case, I wouldn't give up on allowing a
> character, even if we do support images, because there's no reason to
> restrict users to images.  For example, a suitable selection of a
> character could produce identical displays on GUI and TTY frames,
> something that an image could never do.

A choice between image and character was what I had in mind.  (If a 
buffer is displayed on both GUI and TTY frames, you can even use both at 
the same time, which is what fci-mode does.)

I wouldn't expect end users to create their own images.  Again, I can 
only offer my own experience, but the only customization requests I've 
received have been for (a) color, (b) thickness, and (c) dashed vs. 
solid.  Those can be offered as simple customization options.  Arbitrary 
user defined images are possible on this scheme, but wouldn't be the 
basic mode of customization.

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Fri, 15 Mar 2019 14:30:55 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> Terminal emulators often treat box-drawing characters specially, either drawing the lines themselves or extending parts of the glyphs in case there would be gaps. Even XTerm does this, mainly to supplement missing glyphs.
> 
> Being its own terminal emulator, Emacs could do the same to avoid gaps in horizontal and vertical lines that should connect.

Unfortunately, this is not currently possible, not without significant
changes in how the Emacs display engine works internally.  The display
routines are currently called in a way that doesn't allow them to have
a window-global view of the display, not even a way of knowing what's
on the previous and the next screen lines.  In fact, the display
routines need to do their job even if the information about the layout
of adjacent screen lines is not available at all, and redisplay
optimizations frequently make use of this property, by starting a new
redisplay cycle on a specific line, doing part of the layout, then
throwing out the results.  About the only thing the display routines
can rely on is the window-start point and the window pixel
dimensions.  Even the vertical coordinate of a line on which the
display routine was called is frequently unknown. 

> The details are fairly window-system-specific but do not have to be implemented everywhere at once.

I don't think I understand what you are saying here.  My point was
that we have xfns.c/xterm.c for X, w32fns.c/w32term.c for w32, and
nsfns.m/nsterm.m for NS.  Any line drawing that doesn't end up as part
f some glyph must be implemented in each of these back-ends, because
the APIs used for such drawing are different.

Re: Fill column indicator functionality

[Clément Pit-Claudel]

On 15/03/2019 10.12, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> This was actually going to be my follow-up question :) I see lines of variable height in many of most of my Emacs mode, through a combination of factors:
>>
>> - Font switches due to symbols picked by prettify-symbols-mode not being available in my main programming font
>> - Variable-pitch fonts being used by AucTeX for section and paragraph titles 
>> - Varying font sizes to indicate nesting depth in Org-mode
>> - Changing line spacing to separate top-level items in org-mode
> 
> Does the fci mode support those use cases?

Not well, no.  There are discontinuities, and if I use wide characters (like CJK spaces, e.g. '　'), portions of the line are misaligned.

> But yes, we have several methods of scaling display elements which
> could be used to solve these use cases.  I just don't think we should
> block the feature until they are fixed.  However important are the use
> cases you enumerated, they are not the majority in Emacs, right?

No, I don't think they are the majority of Emacs :) 

>> Also, as a second follow-up question: we already have code to draw boxes around characters; would it be hard to extend that code to allow customization of which sides to draw? Alternatively, would it be hard to add a vertical strike-through face property? (I've used horizontal strike-through as a way to display horizontal lines in the past)
> 
> I'm not sure where are you going with this.  Yes, Emacs is capable of
> drawing horizontal and vertical lines of specified pixel-width, but
> the issue here is not whether we can do it, the issue is how to do
> that in a way that fits as much as possible the current basic design
> and implementation of the display engine.  Otherwise, the job becomes
> so large that we probably won't have this feature any time soon.
> 
> Specifically, drawing a "vertical strike-through" still doesn't solve
> the problem with the height of the line, because the glyph we will
> "strike through" will still need to have a suitable height, right?

Maybe? At the moment boxes and backgrounds already span the full line height, so I'm assuming strike-throughs would as well.
All that I was pointing out is that the box display code already draws lines that reliably span the entire line height.

Clément.

Re: Fill column indicator functionality

[Alp Aker]

> I'm sure users will find customizing a character much easier than
> customizing an image.  In any case, I wouldn't give up on allowing a
> character, even if we do support images, because there's no reason to
> restrict users to images.  For example, a suitable selection of a
> character could produce identical displays on GUI and TTY frames,
> something that an image could never do.

I just wanted to expand on this point and clarify my motivations for 
chiming in on this discussion.  I'm very grateful Ergus is doing this 
work, as I've long felt that the functionality of fill-column-indicator 
can only be robustly implemented in the display engine.  I merely want 
to offer my experience as the author of what, until now, has been the 
main package providing this kind of functionality in order to make 
Ergus's work more successful.

When I first implemented fill-column-indicator I used a character-based 
approach and, overwhelmingly, the feedback I received from users 
concerned difficulties in finding and successfully configuring use of a 
font that would provide a seamless visual effect.  When I added the 
option to use XPM images (generated not by the user, but by the package, 
with customization options concerning color, thickness, etc.), users 
only seemed to make use of that.  I've never received a complaint from 
someone wanting to use the package on a system that didn't support XPM 
images.





>
>>>    . Using the continuous line would cause complications wrt redisplay
>>>      optimizations.  Redisplay of text is highly optimized in Emacs, and
>>>      frequently needs to update only a small portion of the window.  The
>>>      problem is what to do about the indicator line when only some
>>>      portions are redrawn.
>> Unless I'm mistaken, the method I'm describing would allow the same
>> optimizations
> Yes, but I was replying to a completely different idea.  What you
> propose is just a trivial extension of the code posted here, so all of
> the effort that went into that will still be valid, and most of my
> message is not really relevant.

Re: Fill column indicator functionality

[Clément Pit-Claudel]

On 15/03/2019 10.07, Óscar Fuentes wrote:
> What I'm missing?

I this I see what caused the confusion.  There are two answers:

- First, at least one of the examples I mentioned involves changes in line height, not in character width; that's the part I worry most about.
- Second, I believe the 80-character limits is usually intended to serve as a bound on the width of the text on display (the assumption being that short lines are easier to read than long ones, and that keeping a limited width makes it easier to show multiple text fragments side by side).  When the text is monospace, it's natural to express the limit in terms of a number of characters.  When the text is displayed in a variable-pitch font, the natural equivalent is to express the limit in pixels or em units.  IOW, a long lines indicator still makes sense even for variable-pitch fonts; you just don't want it to count characters.

Clément.

Re: Fill column indicator functionality

[Clément Pit-Claudel]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On 15/03/2019 10.19, Alp Aker wrote:
> Would lack of support for variable line heights be an issue?  I can
> only offer my experience here as the author of fill-column-indicator.
> Among the many issues that package has, lack of support for variable
> line heights in a window hasn't been one of them.  It just isn't
> something users have requested.

It's the main reason why I don't use fci-mode :) I've attached a screenshot.


[-- Attachment #2: fci.png --]
[-- Type: image/png, Size: 58510 bytes --]

Re: Fill column indicator functionality

[Mattias Engdegård]

fre 2019-03-15 klockan 16:24 +0200 skrev Eli Zaretskii:

> Unfortunately, this is not currently possible, not without
> significant changes in how the Emacs display engine works
> internally.  The display routines are currently called in a way that
> doesn't allow them to have a window-global view of the display, not
> even a way of knowing what's on the previous and the next screen
> lines.

Sorry, I was being unclear. What I meant to say was that if some box-
drawing glyph does not go all the way to the edge of its cell, then
Emacs could attempt to improve on the rendering of that glyph instead
of being bound by the font. It would not need to know anything about
what is drawn elsewhere. It's just a way of fixing the font.

I don't even know how common the problem is with modern fonts, or what
the underlying causes are. I've mostly observed it with scaled pixel
fonts.

Re: Fill column indicator functionality

[Stefan Monnier]

>> Being its own terminal emulator, Emacs could do the same to avoid gaps in
>> horizontal and vertical lines that should connect.
>
> Unfortunately, this is not currently possible, not without significant
> changes in how the Emacs display engine works internally.  The display
> routines are currently called in a way that doesn't allow them to have
> a window-global view of the display, not even a way of knowing what's
> on the previous and the next screen lines.  In fact, the display
> routines need to do their job even if the information about the layout
> of adjacent screen lines is not available at all, and redisplay
> optimizations frequently make use of this property, by starting a new
> redisplay cycle on a specific line, doing part of the layout, then
> throwing out the results.  About the only thing the display routines
> can rely on is the window-start point and the window pixel
> dimensions.  Even the vertical coordinate of a line on which the
> display routine was called is frequently unknown. 

I think what Mattias is referring to is to change the part of the code
where we draw the glyph matrix onto the screen (i.e. the part that's
window-system specific), to add ad-hoc hacks that try to display
box-drawing characters differently to try and fill small gaps
between them.  I don't know how workable that would be, especially when
considering proportional fonts (i.e. the problems with box-drawing
characters aren't limited to gaps between them but also include
misalignment).


        Stefan

Re: Fill column indicator functionality

[Stefan Monnier]

> This was actually going to be my follow-up question :) I see lines of
> variable height in many of most of my Emacs mode, through a combination of
> factors:
>
> - Font switches due to symbols picked by prettify-symbols-mode not being
> available in my main programming font
> - Variable-pitch fonts being used by AucTeX for section and paragraph titles 
> - Varying font sizes to indicate nesting depth in Org-mode
> - Changing line spacing to separate top-level items in org-mode

I also see such variations due to my use of fonts instead of colors
for font-lock highlighting: I use different fonts for the keyword-face
and the doc-face.  I try to choose them such that they take up exactly
the same number of pixels as my default font, but it's a pretty
delicate/brittle business.

So I agree it's a case we should try and handle "correctly".


        Stefan

Re: Fill column indicator functionality

[Óscar Fuentes]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 15/03/2019 10.07, Óscar Fuentes wrote:
>> What I'm missing?
>
> I this I see what caused the confusion.  There are two answers:
>
> - First, at least one of the examples I mentioned involves changes in
> line height, not in character width; that's the part I worry most
> about.

Yes, I've seen this quite often: Emacs chooses a font for some unicode
char and the line height is altered.

> - Second, I believe the 80-character limits is usually intended to
> serve as a bound on the width of the text on display (the assumption
> being that short lines are easier to read than long ones, and that
> keeping a limited width makes it easier to show multiple text
> fragments side by side). When the text is monospace, it's natural to
> express the limit in terms of a number of characters. When the text is
> displayed in a variable-pitch font, the natural equivalent is to
> express the limit in pixels or em units. IOW, a long lines indicator
> still makes sense even for variable-pitch fonts; you just don't want
> it to count characters.

This is more about typesetting than anything else. As long as Emacs has
no real WYSIWYG word-processing capabilities, IMHO the lack of this
feature on that context is not important.

Re: Fill column indicator functionality

[Clément Pit-Claudel]

On 15/03/2019 11.15, Óscar Fuentes wrote:
>> - First, at least one of the examples I mentioned involves changes in
>> line height, not in character width; that's the part I worry most
>> about.

> Yes, I've seen this quite often: Emacs chooses a font for some unicode
> char and the line height is altered.

Right, exactly. It would be great if the new fci implementation handled this smoothly.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Alp Aker <alp.tekin.aker@gmail.com>
> Date: Fri, 15 Mar 2019 10:19:04 -0400
> 
> I did not have a dynamically sized images in mind, only fixed-height 
> images.  They offer a way of achieving the graphical effect that some 
> people in this thread have requested that would involve, as you point 
> out, only a trivial extension of what Ergus has already done.

Right.

> Would lack of support for variable line heights be an issue?

I hope not, at least not initially.  But Clément seems to think
otherwise.

> I can only offer my experience here as the author of
> fill-column-indicator.  Among the many issues that package has, lack
> of support for variable line heights in a window hasn't been one of
> them.  It just isn't something users have requested.

This is Emacs: as soon as you offer a feature that solves N problems
users always wanted solved, someone will come up and argue that
solution for the N+1th problem is an absolute must to have ;-)

> A choice between image and character was what I had in mind.  (If a 
> buffer is displayed on both GUI and TTY frames, you can even use both at 
> the same time, which is what fci-mode does.)
> 
> I wouldn't expect end users to create their own images.  Again, I can 
> only offer my own experience, but the only customization requests I've 
> received have been for (a) color, (b) thickness, and (c) dashed vs. 
> solid.  Those can be offered as simple customization options.  Arbitrary 
> user defined images are possible on this scheme, but wouldn't be the 
> basic mode of customization.

Sounds like we are in violent agreement, then.  Thanks for your
comments, the experience of fci-mode is, of course, something we
should learn from when we design the customization facilities of this
new implementation.

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Cc: alp.tekin.aker@gmail.com, emacs-devel@gnu.org
> Date: Fri, 15 Mar 2019 16:05:33 +0100
> 
> Sorry, I was being unclear. What I meant to say was that if some box-
> drawing glyph does not go all the way to the edge of its cell, then
> Emacs could attempt to improve on the rendering of that glyph instead
> of being bound by the font. It would not need to know anything about
> what is drawn elsewhere. It's just a way of fixing the font.

Emacs never examines the glyphs that the font produces, it just calls
an API that displays text using glyph numbers it receives from the
font back-end.

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 15 Mar 2019 11:09:25 -0400
> 
> I think what Mattias is referring to is to change the part of the code
> where we draw the glyph matrix onto the screen (i.e. the part that's
> window-system specific), to add ad-hoc hacks that try to display
> box-drawing characters differently to try and fill small gaps
> between them.

Emacs has no idea how a glyph will look on the screen, it just tells
the window-system to display it.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 15 Mar 2019 10:35:02 -0400
> 
> > Does the fci mode support those use cases?
> 
> Not well, no.  There are discontinuities, and if I use wide characters (like CJK spaces, e.g. '　'), portions of the line are misaligned.

The misalignment part should disappear with this new implementation,
because it works in pixels.

> > Specifically, drawing a "vertical strike-through" still doesn't solve
> > the problem with the height of the line, because the glyph we will
> > "strike through" will still need to have a suitable height, right?
> 
> Maybe? At the moment boxes and backgrounds already span the full line height, so I'm assuming strike-throughs would as well.

That's again not on the glyph level, it's drawing code specific to
each terminal type.

Re: Fill column indicator functionality

[Drew Adams]

(Caveat: I haven't really been following this thread.
Apologies if I misunderstand the intention or the
scope, e.g., if this is off topic.)

I guess y'all are trying to come up with the ability
to have vertical display lines similar to window
dividers - maybe 1-pixel wide (or configurable as
N pixels wide?).

Keith is apparently working on such a thing for a
fake-cursors implementation.  And this thread is
about using such a thing for indicating the fill
column.

Do I understand that right?  If so, will the approach
to doing this be general, so the same implementation
(in C) can be used for both of these applications?

In that case, could it also be used also for vertical
lines separating table cells and other things.

If so (if we'll have a general feature for such
support) will there be something similar for
horizontal lines?  And will we be able to limit
such lines (start and stop positions), or will
they always be across an entire window?

Re: Fill column indicator functionality

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> This is Emacs: as soon as you offer a feature that solves N problems
> users always wanted solved, someone will come up and argue that
> solution for the N+1th problem is an absolute must to have ;-)

+1

This feature, as implemented, is useful. Furthermore, its implementation
is not problematic on the sense of making it difficult to replace it
with somethin more comprehensive on the future.

Although the improvements suggested are reasonable and well-founded, It
would be a shame if it is delayed as a consequence of the social
dynamics you mention.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 15 Mar 2019 16:59:16 +0000 (UTC)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: esq@lawlist.com
> 
> Keith is apparently working on such a thing for a
> fake-cursors implementation.  And this thread is
> about using such a thing for indicating the fill
> column.
> 
> Do I understand that right?  If so, will the approach
> to doing this be general, so the same implementation
> (in C) can be used for both of these applications?

Asked and answered:

  http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00356.html

Re: Fill column indicator functionality

[Clément Pit-Claudel]

On 15/03/2019 12.13, Eli Zaretskii wrote:
> 
>>> Specifically, drawing a "vertical strike-through" still doesn't solve
>>> the problem with the height of the line, because the glyph we will
>>> "strike through" will still need to have a suitable height, right?

>> Maybe? At the moment boxes and backgrounds already span the full line height, so I'm assuming strike-throughs would as well.

> That's again not on the glyph level, it's drawing code specific to
> each terminal type.

Understood. I was asking how hard it would be to use that code for drawing lines (since it already exists ^^)

Re: Fill column indicator functionality

[Clément Pit-Claudel]

On 15/03/2019 13.24, Óscar Fuentes wrote:
> Although the improvements suggested are reasonable and well-founded, It
> would be a shame if it is delayed as a consequence of the social
> dynamics you mention.

Oh, yes, of course. I don't intend to delay anything ("now is better than never"), just to make sure that we have all use cases in mind so that we don't design something that is needlessly restrictive (or hard to extend in the future).

I am thankful for the cool work that Ergus is doing, and for Eli's dedication and patient mentorship.  

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 15 Mar 2019 14:26:11 -0400
> Cc: emacs-devel@gnu.org
> 
> I was asking how hard it would be to use that code for drawing lines (since it already exists ^^)

Drawing a line is not hard at all, regardless of whether the code to
do that exists or not.  What is missing is a way to tell the
terminal-specific back-end to draw that line.  This would probably
require a new glyph attribute.

RE: Fill column indicator functionality

[Drew Adams]

> Asked and answered:
> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00356.html

I read that at the time.  I don't think that responds
to what I suggested.

I understood that the simple fill-column indicator
feature is not a more general feature, and it is not
waiting for the fake-cursors feature.  My questions
were about further possibilities and (perhaps) basing
them on some common building blocks.

But if that's the response, so be it.  Thanks.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 15 Mar 2019 19:18:11 +0000 (UTC)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: spacibba@aol.com, emacs-devel@gnu.org, esq@lawlist.com
> 
> I understood that the simple fill-column indicator
> feature is not a more general feature, and it is not
> waiting for the fake-cursors feature.  My questions
> were about further possibilities and (perhaps) basing
> them on some common building blocks.

It is not about waiting, it's about the best design for each feature.

One of the features is similar to a cursor: it moves by user commands,
and can in principle be repositioned at every redisplay cycle.  The
other is entirely unlike a cursor: its position is more or less fixed,
and changes very rarely, if at all.  This fundamental difference leads
to 2 different designs and implementations, conflating which is IMO
not a good idea.  Cursor drawing is implemented in Emacs in a way that
is very different from normal glyph display, something that is
justified by its frequently-moving nature and the fact that there's
only one cursor per window.  The indicator discussed here is a very
different creature.

Re: Fill column indicator functionality

[Ergus]

On Fri, Mar 15, 2019 at 04:59:16PM +0000, Drew Adams wrote:

Hi Drew:

>(Caveat: I haven't really been following this thread.
>Apologies if I misunderstand the intention or the
>scope, e.g., if this is off topic.)
>
>I guess y'all are trying to come up with the ability
>to have vertical display lines similar to window
>dividers - maybe 1-pixel wide (or configurable as
>N pixels wide?).
>
>Keith is apparently working on such a thing for a
>fake-cursors implementation.  And this thread is
>about using such a thing for indicating the fill
>column.
>

Not really, this patch is a much much simpler solution for a much much
less complex use case.

The fci functionality is in my opinion a very basic code editor
functionality and the solution already available was going to be
unmaintained and had incompatibilities with show-trailing-whitespace.

Eli replied to this a couple of days ago.

Up to now I implemented this to add 1 single vertical line to a
position, the expansion to multiple lines is something possible, but I
don't find a general enough use case that deserves to do so; but if we
find one we can work on that in the future.

I didn't want to over-specify the functionality or produce excessive
overhead in a key place like the display engine. So being a KISS was
part of the intention.

>Do I understand that right?  If so, will the approach
>to doing this be general, so the same implementation
>(in C) can be used for both of these applications?
>

I don't think so; at least not in an easy way. 

>In that case, could it also be used also for vertical
>lines separating table cells and other things.
>
I think that those use cases must be better implemented in elisp as the
use cases will be very specific.

>If so (if we'll have a general feature for such
>support) will there be something similar for
>horizontal lines?

This one is easy, to implement if it is not already; but I don't think
it even requires to go in the display engine. 

>And will we be able to limit
>such lines (start and stop positions), or will

If there is a real use case we can add that functionality, but now it is
not implemented.

>they always be across an entire window?

For now yes.

I hope this answers all your doubts?

Re: Fill column indicator functionality

[Ergus]

On Fri, Mar 15, 2019 at 09:52:53AM +0200, Eli Zaretskii wrote:
>> Date: Thu, 14 Mar 2019 22:13:15 +0100
>> From: Ergus <spacibba@aol.com>
>>
>Can you solve this problem by using the :height attribute whose value
>is 1.0 (a floating-point number) for the face of the character?  If
>that doesn't work, we might introduce a special feature for this use
>case.
>

I'll try this in a while to see how the experience changes. If we set
that this way the font will autoresize depending of the height of the
current column?

Anyway I think the discussion in progress can give a different answer. I
will wait a bit more to get a recommendation. Or a solution that promise
to be better.

>In any case, I think this use case is rare enough to leave it for
>subsequent improvements.  It doesn't sound as show-stopper to me.
>
>> Or use a different type of glyph in graphical mode... maybe an image as
>> the fci package does? Is that possible?
>
>It should be possible to use an image, yes.  Does the fci package
>solve the use case of lines that are taller than default, as in Info
>or EWW?  If so, what do they do -- use a larger slice of an image
>according to the line height or something?  Because using an image
>still needs to solve the problem of displaying a taller image when the
>line's height is larger than the default.
>

The XPM image seems to be a good enough approach according to Alp's
comment/experience, but it only solves a part of the problem. But I
haven't go in the details of what they do and I don't want to over
specify the functionality or produce too much overhead.

>One more potential issue that I think you should test is when the
>fringes are disabled on GUI frames, and we usurp the last column of
>the text area to display continuation and truncation glyphs there, as
>we do on TTY frames.  If the fill-column is equal to the last column
>of the window, or to one before the last, I think you will need to
>augment your comparison with it->last_visible_x in this case.
>
The code that adds the information looks to run later, so the line is
hidden in that case, which for me is the expected behavior. Otherwise I
didn't understand the issue.

Apart from that there, are some corrections I made in order to fix some
background issues I observed in graphical mode.

In graphical interfaces the space after the line is always filled with
the background color of the face of the last produced glyph, even if I
reset it to the saved value after the generation. The only solution I
found so far was to add an extra glyph after reset the face to the
default (saved) value, but hopefully there is a better way?

Re: Fill column indicator functionality

[Óscar Fuentes]

Ergus <spacibba@aol.com> writes:

> Apart from that there, are some corrections I made in order to fix some
> background issues I observed in graphical mode.

One thing I just noticed:

emacs -Q

A graphical frame is shown with the toolbar. In *scratch*

M-x display-fill-column-indicator-mode

Now the part of the toolbar that is not covered by icons has white
background.

Switch to *Messages*. The toolbar is shown normally. Switch back to
*scratch*. The toolbar is partially white again.

Re: Fill column indicator functionality

[Ergus]

Hi Oscar:

I'm trying to reproduce the issue you describe, but I don't see it in my
system.

I will send the corrected patch soon (any way my changes can't be merged
yet); but I am not sure that my work is related with toolbars
issues. Please if you can give some extra information about your system
it will be usefull. Specially the graphical interface and/or OS, because I
only tested GNU/Linux.

Best,
Ergus

On Fri, Mar 15, 2019 at 11:52:52PM +0100, �scar Fuentes wrote:
>Ergus <spacibba@aol.com> writes:
>
>> Apart from that there, are some corrections I made in order to fix some
>> background issues I observed in graphical mode.
>
>One thing I just noticed:
>
>emacs -Q
>
>A graphical frame is shown with the toolbar. In *scratch*
>
>M-x display-fill-column-indicator-mode
>
>Now the part of the toolbar that is not covered by icons has white
>background.
>
>Switch to *Messages*. The toolbar is shown normally. Switch back to
>*scratch*. The toolbar is partially white again.
>
>

Re: Fill column indicator functionality

[Óscar Fuentes]

Ergus <spacibba@aol.com> writes:

> Hi Oscar:
>
> I'm trying to reproduce the issue you describe, but I don't see it in my
> system.
>
> I will send the corrected patch soon (any way my changes can't be merged
> yet); but I am not sure that my work is related with toolbars
> issues. Please if you can give some extra information about your system
> it will be usefull. Specially the graphical interface and/or OS, because I
> only tested GNU/Linux.
>
> Best,
> Ergus

Following is the information as reported by `report-emacs-bug'. I'll send
you an screenshot off-list.

In GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit)
 of 2019-03-14 built on sky
Repository revision: 020e69d992c98fd852e835c9bd707a8d137090f2
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: Debian GNU/Linux buster/sid

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Display-Fill-Column-Indicator mode enabled in current buffer
You can run the command ‘display-fill-column-indicator-mode’ with M-x di-i RET
Display-Fill-Column-Indicator mode enabled in current buffer

Configured using:
 'configure --without-toolkit-scroll-bars --with-x-toolkit=lucid
 --with-modules'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GSETTINGS GLIB NOTIFY INOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB LUCID X11 XDBE XIM
MODULES THREADS PDUMPER GMP

Important settings:
  value of $LANG: es_ES.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  display-fill-column-indicator-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
easymenu mml-sec password-cache epa derived epg epg-config gnus-util
rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
display-fill-column-indicator elec-pair mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads inotify dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 45167 5012)
 (symbols 48 5846 1)
 (strings 32 15616 1682)
 (string-bytes 1 501739)
 (vectors 16 9468)
 (vector-slots 8 117448 9386)
 (floats 8 19 27)
 (intervals 56 212 0)
 (buffers 992 11))

Re: Fill column indicator functionality

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 4083 bytes --]

Hi Oscar:

I think that I found it. So I will try to correct it in the patch update.



On 16 March 2019 00:47:16 CET, "Óscar Fuentes" <ofv@wanadoo.es> wrote:
>Ergus <spacibba@aol.com> writes:
>
>> Hi Oscar:
>>
>> I'm trying to reproduce the issue you describe, but I don't see it in
>my
>> system.
>>
>> I will send the corrected patch soon (any way my changes can't be
>merged
>> yet); but I am not sure that my work is related with toolbars
>> issues. Please if you can give some extra information about your
>system
>> it will be usefull. Specially the graphical interface and/or OS,
>because I
>> only tested GNU/Linux.
>>
>> Best,
>> Ergus
>
>Following is the information as reported by `report-emacs-bug'. I'll
>send
>you an screenshot off-list.
>
>In GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit)
> of 2019-03-14 built on sky
>Repository revision: 020e69d992c98fd852e835c9bd707a8d137090f2
>Repository branch: master
>Windowing system distributor 'The X.Org Foundation', version
>11.0.12003000
>System Description: Debian GNU/Linux buster/sid
>
>Recent messages:
>For information about GNU Emacs and the GNU system, type C-h C-a.
>Display-Fill-Column-Indicator mode enabled in current buffer
>You can run the command ‘display-fill-column-indicator-mode’ with M-x
>di-i RET
>Display-Fill-Column-Indicator mode enabled in current buffer
>
>Configured using:
> 'configure --without-toolkit-scroll-bars --with-x-toolkit=lucid
> --with-modules'
>
>Configured features:
>XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GSETTINGS GLIB NOTIFY INOTIFY
>LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB LUCID X11 XDBE XIM
>MODULES THREADS PDUMPER GMP
>
>Important settings:
>  value of $LANG: es_ES.UTF-8
>  locale-coding-system: utf-8-unix
>
>Major mode: Lisp Interaction
>
>Minor modes in effect:
>  display-fill-column-indicator-mode: t
>  tooltip-mode: t
>  global-eldoc-mode: t
>  eldoc-mode: t
>  electric-indent-mode: t
>  mouse-wheel-mode: t
>  tool-bar-mode: t
>  menu-bar-mode: t
>  file-name-shadow-mode: t
>  global-font-lock-mode: t
>  font-lock-mode: t
>  blink-cursor-mode: t
>  auto-composition-mode: t
>  auto-encryption-mode: t
>  auto-compression-mode: t
>  line-number-mode: t
>  transient-mark-mode: t
>
>Load-path shadows:
>None found.
>
>Features:
>(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
>bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
>easymenu mml-sec password-cache epa derived epg epg-config gnus-util
>rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode mail-parse
>rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail
>rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
>display-fill-column-indicator elec-pair mule-util tooltip eldoc
>electric
>uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
>term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
>tabulated-list replace newcomment text-mode elisp-mode lisp-mode
>prog-mode register page menu-bar rfn-eshadow isearch timer select
>scroll-bar mouse jit-lock font-lock syntax facemenu font-core
>term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
>vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
>hebrew greek romanian slovak czech european ethiopic indian cyrillic
>chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
>help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
>button faces cus-face macroexp files text-properties overlay sha1 md5
>base64 format env code-pages mule custom widget
>hashtable-print-readable
>backquote threads inotify dynamic-setting system-font-setting
>font-render-setting x-toolkit x multi-tty make-network-process emacs)
>
>Memory information:
>((conses 16 45167 5012)
> (symbols 48 5846 1)
> (strings 32 15616 1682)
> (string-bytes 1 501739)
> (vectors 16 9468)
> (vector-slots 8 117448 9386)
> (floats 8 19 27)
> (intervals 56 212 0)
> (buffers 992 11))

[-- Attachment #2: Type: text/html, Size: 4555 bytes --]

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 15 Mar 2019 23:52:52 +0100
> 
> emacs -Q
> 
> A graphical frame is shown with the toolbar. In *scratch*
> 
> M-x display-fill-column-indicator-mode
> 
> Now the part of the toolbar that is not covered by icons has white
> background.
> 
> Switch to *Messages*. The toolbar is shown normally. Switch back to
> *scratch*. The toolbar is partially white again.

I think the code which displays the indicator should not do that if
it->w->pseudo_window_p is non-zero.  IOW, if it->w->pseudo_window_p is
non-zero, extend_face_to_end_of_line should returns without producing
the glyphs for the stretch and the indicator character.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sat, 16 Mar 2019 00:22:50 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> I am not sure that my work is related with toolbars issues.

In some configuration, where Emacs itself draws the tool bar (as
opposed to the toolkit doing that), the tool bar is a special kind of
window, and redisplay handles that window as well.  Your code should
refrain from producing the indicator in such windows.  I wrote in my
previous message how I propose to do that.

Re: Fill column indicator functionality

[Ergus]

On Fri, Mar 15, 2019 at 09:52:53AM +0200, Eli Zaretskii wrote:

> Can you solve this problem by using the :height attribute whose value
> is 1.0 (a floating-point number) for the face of the character?  If
> that doesn't work, we might introduce a special feature for this use
> case.
> 

Hi:

I tried that solution (setting the :height attribute to 1.0 in the face
declaration) and it didn't work.

```
(defface fill-column-face
 '((t :inherit (shadow default) :height 1.0))
 "Face for displaying fill column indicator line.
This face is used when `display-fill-column-indicator-mode' is
non-nil.

If you customize the font of this face, make sure it is a
monospaced font, otherwise the line's characters will not line
up horizontally."
 :version "27.1"
 :group 'basic-faces
 :group 'display-fill-column-indicator)
```

There is still a small space and for rows with different size fonts it
keeps always the same size.

I see that there is a calc_line_height_property; can we use that to
change the glyph. Maybe it is possible to implement a setter (equivalent
to get_it_property?

We can compare the line height with the it height and change it
temporarily to print the indicator?

Does it makes sense?

Question about documented functions

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 126 bytes --]

Hi. I have a question. The functions/macros to work with lisp variables from C in lisp.h header file are documented somewhere?

[-- Attachment #2: Type: text/html, Size: 126 bytes --]

Re: Question about documented functions

[Eli Zaretskii]

> Date: Sat, 16 Mar 2019 11:18:47 +0100
> From: Ergus <spacibba@aol.com>
> 
> Hi. I have a question. The functions/macros to work with lisp variables from C in lisp.h header file are
> documented somewhere?

Only in lisp.h itself.  If something there is not clear enough, we
could improve the commentary.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 15 Mar 2019 21:56:26 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> Anyway I think the discussion in progress can give a different answer. I
> will wait a bit more to get a recommendation. Or a solution that promise
> to be better.

OK, we are waiting for your legal paperwork anyway.

> >One more potential issue that I think you should test is when the
> >fringes are disabled on GUI frames, and we usurp the last column of
> >the text area to display continuation and truncation glyphs there, as
> >we do on TTY frames.  If the fill-column is equal to the last column
> >of the window, or to one before the last, I think you will need to
> >augment your comparison with it->last_visible_x in this case.
> >
> The code that adds the information looks to run later, so the line is
> hidden in that case, which for me is the expected behavior. Otherwise I
> didn't understand the issue.

My concern was that it->last_visible_x is not the last pixel you can
use for the indicator, because there must be space left for the
continuation and truncation glyphs.  But if you tested that use case
and the code works, I'm happy.

> In graphical interfaces the space after the line is always filled with
> the background color of the face of the last produced glyph, even if I
> reset it to the saved value after the generation. The only solution I
> found so far was to add an extra glyph after reset the face to the
> default (saved) value, but hopefully there is a better way?

I don't think I understand what face is "the face of the last produced
glyph".  is that the face of the indicator character, is that the
default face, or is that something else?  Can you show a screenshot?

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sat, 16 Mar 2019 10:36:10 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> I tried that solution (setting the :height attribute to 1.0 in the face
> declaration) and it didn't work.

Well, I'm not really surprised, it was a long shot.

> I see that there is a calc_line_height_property; can we use that to
> change the glyph. Maybe it is possible to implement a setter (equivalent
> to get_it_property?

I don't think I understand the proposal.  calc_line_height_property is
used to produce line-spacing, but I don't see how it could be used for
enlarging the font, since AFAIK that can only be done via a face
definition.

> We can compare the line height with the it height and change it
> temporarily to print the indicator?

That won't help, because the code we are talking about doesn't draw
anything, it just prepares the data structures for drawing.  the
actual drawing happens later, and it is terminal-dependent (for X, see
xterm.c, the function x_draw_glyph_string_foreground, for example).

I think, unless some clever idea comes up which will allow us to use
an existing feature, we should for now leave this issue alone, because
avoiding the gap between indicators when line height varies will
probably require adding some display features, and the indicator
display shouldn't be held off till we do.

Re: Question about documented functions

[Ergus]

On Sat, Mar 16, 2019 at 02:21:37PM +0200, Eli Zaretskii wrote:
>> Date: Sat, 16 Mar 2019 11:18:47 +0100
>> From: Ergus <spacibba@aol.com>
>>
>> Hi. I have a question. The functions/macros to work with lisp variables from C in lisp.h header file are
>> documented somewhere?
>
>Only in lisp.h itself.  If something there is not clear enough, we
>could improve the commentary.

The problem is that I was trying to figure out the canonical method to
check if a variable was: t from C code (or assign t to a "DEFVAR_LISP"
defined variable). I was looking for something similar to NILP but I
couldn't get it.

For example:

#if DEFINE_KEY_OPS_AS_MACROS
# define XLI(o) lisp_h_XLI (o)
# define XIL(i) lisp_h_XIL (i)
# define XLP(o) lisp_h_XLP (o)
# define XPL(p) lisp_h_XPL (p)
# define CHECK_FIXNUM(x) lisp_h_CHECK_FIXNUM (x)
# define CHECK_SYMBOL(x) lisp_h_CHECK_SYMBOL (x)
# define CHECK_TYPE(ok, predicate, x) lisp_h_CHECK_TYPE (ok, predicate, x)
# define CONSP(x) lisp_h_CONSP (x)
# define EQ(x, y) lisp_h_EQ (x, y)
# define FLOATP(x) lisp_h_FLOATP (x)
# define FIXNUMP(x) lisp_h_FIXNUMP (x)
# define NILP(x) lisp_h_NILP (x)
# define SET_SYMBOL_VAL(sym, v) lisp_h_SET_SYMBOL_VAL (sym, v)
# define SYMBOL_CONSTANT_P(sym) lisp_h_SYMBOL_CONSTANT_P (sym)
# define SYMBOL_TRAPPED_WRITE_P(sym) lisp_h_SYMBOL_TRAPPED_WRITE_P (sym)
# define SYMBOL_VAL(sym) lisp_h_SYMBOL_VAL (sym)
# define SYMBOLP(x) lisp_h_SYMBOLP (x)
# define TAGGEDP(a, tag) lisp_h_TAGGEDP (a, tag)
# define VECTORLIKEP(x) lisp_h_VECTORLIKEP (x)
# define XCAR(c) lisp_h_XCAR (c)
# define XCDR(c) lisp_h_XCDR (c)
# define XCONS(a) lisp_h_XCONS (a)
# define XHASH(a) lisp_h_XHASH (a)
# ifndef GC_CHECK_CONS_LIST
#  define check_cons_list() lisp_h_check_cons_list ()
# endif
# if USE_LSB_TAG
#  define make_fixnum(n) lisp_h_make_fixnum (n)
#  define XFIXNAT(a) lisp_h_XFIXNAT (a)
#  define XFIXNUM(a) lisp_h_XFIXNUM (a)
#  define XSYMBOL(a) lisp_h_XSYMBOL (a)
#  define XTYPE(a) lisp_h_XTYPE (a)
# endif
#endif

It will be helpful for new people (like me), some explanations about
each of them. Expected arguments, and or objectives. And comments like
XFIXNUM can crash so it is needed to protect the code with an if
FIXNUMP. And then what CHECK_FIXNUM is useful for.

I know I need to read more, but it was a bit confusing to figure out the
difference between FIXNUM and FIXNAT.

And functions that are lisp equivalents (CAR CRD) could say that so
newbies can refer to the elisp manual to look for it.

Re: Question about documented functions

[Eli Zaretskii]

> Date: Sat, 16 Mar 2019 14:53:34 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> The problem is that I was trying to figure out the canonical method to
> check if a variable was: t from C code (or assign t to a "DEFVAR_LISP"
> defined variable). I was looking for something similar to NILP but I
> couldn't get it.

Use Qt in C to refer to the symbol t.  Like this:

  Lisp_Object foo = Qt;      /* assignment */
  ...
  if (EQ (some_object, Qt))  /* test for equality to t */
    ...

> It will be helpful for new people (like me), some explanations about
> each of them. Expected arguments, and or objectives. And comments like
> XFIXNUM can crash so it is needed to protect the code with an if
> FIXNUMP. And then what CHECK_FIXNUM is useful for.
> 
> I know I need to read more, but it was a bit confusing to figure out the
> difference between FIXNUM and FIXNAT.
> 
> And functions that are lisp equivalents (CAR CRD) could say that so
> newbies can refer to the elisp manual to look for it.

OK, I will try to add some more commentary when I have time.

Re: Fill column indicator functionality

[Johan Bockgård]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 15/03/2019 10.19, Alp Aker wrote:
>> Would lack of support for variable line heights be an issue?  I can
>> only offer my experience here as the author of fill-column-indicator.
>> Among the many issues that package has, lack of support for variable
>> line heights in a window hasn't been one of them.  It just isn't
>> something users have requested.
>
> It's the main reason why I don't use fci-mode :) I've attached a screenshot.

You can use the "stipple" face feature (on platforms that support it) to
draw a 1 pixel tall repeating bitmap (with some limitations).

##

(require 'fill-column-indicator)

(defface fci-face
  `((t (:foreground
	,(or fci-rule-character-color fci-rule-color)
	:stipple
	(,(frame-char-width) 1
	 ,(string (lsh (1- (expt 2 fci-rule-width))
		       (/ (frame-char-width) 2))
		  0 0 0 0)))))
  "")

(setq fci-always-use-textual-rule t
      fci-rule-character ?\s)

(defadvice fci-make-rule-string (around frob activate)
  (setq ad-return-value
	(propertize (char-to-string fci-rule-character) 'face 'fci-face)))

(fci-mode)

##

Example with big line spacing:


[-- Attachment #2: fci-with-stipple.png --]
[-- Type: image/png, Size: 20960 bytes --]

Re: Fill column indicator functionality

[Clément Pit-Claudel]

On 16/03/2019 11.07, Johan Bockgård wrote:
> Clément Pit-Claudel <cpitclaudel@gmail.com> writes:
> 
>> On 15/03/2019 10.19, Alp Aker wrote:
>>> Would lack of support for variable line heights be an issue?  I can
>>> only offer my experience here as the author of fill-column-indicator.
>>> Among the many issues that package has, lack of support for variable
>>> line heights in a window hasn't been one of them.  It just isn't
>>> something users have requested.
>>
>> It's the main reason why I don't use fci-mode :) I've attached a screenshot.
> 
> You can use the "stipple" face feature (on platforms that support it) to
> draw a 1 pixel tall repeating bitmap (with some limitations).

Very nice :)

Re: Fill column indicator functionality

[Alp Aker]

[-- Attachment #1: Type: text/plain, Size: 4486 bytes --]

>> In graphical interfaces the space after the line is always filled with
>> the background color of the face of the last produced glyph, even if I
>> reset it to the saved value after the generation. The only solution I
>> found so far was to add an extra glyph after reset the face to the
>> default (saved) value, but hopefully there is a better way?
> I don't think I understand what face is "the face of the last produced
> glyph".  is that the face of the indicator character, is that the
> default face, or is that something else?  Can you show a screenshot?
I noticed an issue with non-default backgrounds that span newlines, such 
as happens with region highlighting. I believe I ran into what Ergus is 
describing while working on a fix (see (3) below).  The version of the 
code I looked at was 9dcaa15e5a, from Ergus's Github repo.

You can see the issue with non-default backgrounds in the attached 
screenshots mode-off.png and mode-on.png; activating 
display-fill-column-indicator-mode truncates the highlighting on each 
line.  To fix:

1. The stretch glyph needs to be drawn in the current face, not the 
fill_column face.

2. The default fill-column face should have an unspecified background 
and it should be merged into the current face during display, not into 
the default face.

3. If the fill-column face specifies a background, we need to reset the 
face to the saved face after producing the indicator glyph. Here I found 
it necessary to insert another display element in order for the face 
change to take effect before the background is extended to the end of 
the line. (I used a 0-width stretch glyph.)  Without that, the 
fill-column face is used (see the attached c.png for a screenshot).  I 
believe this need to add another display element at the end of the line 
is what Ergus was asking about.


diff --git a/lisp/faces.el b/lisp/faces.el
index 153e6a208f..6b9980a77f 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2504,7 +2504,7 @@ line-number-current-line

  ;; Definition stolen from linum.el.
  (defface fill-column
-  '((t :inherit (shadow default)))
+  '((t :inherit (shadow)))
    "Face for displaying fill column indicator line.
  This face is used when `display-fill-column-indicator-mode' is
  non-nil.

diff --git a/src/xdisp.c b/src/xdisp.c
index 8ac4be8dc7..7c4f9889eb 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -20416,21 +20416,23 @@ extend_face_to_end_of_line (struct it *it)
            int stretch_ascent = (((it->ascent + it->descent)
              * FONT_BASE (font)) / FONT_HEIGHT (font));

-          it->char_to_display = 
XFIXNAT(Vdisplay_fill_column_indicator_character);
            memset (&it->position, 0, sizeof it->position);
            it->avoid_cursor_p = true;
-          it->face_id = merge_faces (it->w, Qfill_column, 0, 
DEFAULT_FACE_ID);
            it->start_of_box_run_p = false;
            it->object = Qnil;

            append_stretch_glyph (it, Qnil, stretch_width,
                                  it->ascent + it->descent, stretch_ascent);

+          it->char_to_display = 
XFIXNAT(Vdisplay_fill_column_indicator_character);
+          it->face_id = merge_faces (it->w, Qfill_column, 0, 
saved_face_id);
            PRODUCE_GLYPHS (it);

+          it->face_id = saved_face_id;
+          append_stretch_glyph (it, Qnil, 0, it->ascent + it->descent,
+                             stretch_ascent);
            it->position = saved_pos;
            it->avoid_cursor_p = saved_avoid_cursor;
-          it->face_id = saved_face_id;
            it->start_of_box_run_p = saved_box_start;
            it->char_to_display = saved_char;
            it->object = save_object;
@@ -20566,7 +20568,7 @@ extend_face_to_end_of_line (struct it *it)
            if (it->current_x == fill_column_indicator_line)
              {
            const int saved_face = it->face_id;
-          it->face_id = merge_faces (it->w, Qfill_column, 0, 
DEFAULT_FACE_ID);
+          it->face_id = merge_faces (it->w, Qfill_column, 0, saved_face);
            it->c = it->char_to_display = 
XFIXNAT(Vdisplay_fill_column_indicator_character);
            PRODUCE_GLYPHS (it);
            it->face_id = saved_face;


[-- Attachment #2: c.png --]
[-- Type: image/png, Size: 34786 bytes --]

[-- Attachment #3: mode-on.png --]
[-- Type: image/png, Size: 48715 bytes --]

[-- Attachment #4: mode-off.png --]
[-- Type: image/png, Size: 47731 bytes --]

Re: Fill column indicator functionality

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 5087 bytes --]

Hi

The version on github is outdated. I have a workaround for that backgrownd issue in a patch I sent to Eli (in this mailing list) on yesterday. Please try that one and check if you experience the same problems.
I will update the github code latter because i am doing some changes in the lisp interface now.

On 17 March 2019 18:28:22 CET, Alp Aker <alp.tekin.aker@gmail.com> wrote:
>>> In graphical interfaces the space after the line is always filled
>with
>>> the background color of the face of the last produced glyph, even if
>I
>>> reset it to the saved value after the generation. The only solution
>I
>>> found so far was to add an extra glyph after reset the face to the
>>> default (saved) value, but hopefully there is a better way?
>> I don't think I understand what face is "the face of the last
>produced
>> glyph".  is that the face of the indicator character, is that the
>> default face, or is that something else?  Can you show a screenshot?
>I noticed an issue with non-default backgrounds that span newlines,
>such 
>as happens with region highlighting. I believe I ran into what Ergus is
>
>describing while working on a fix (see (3) below).  The version of the 
>code I looked at was 9dcaa15e5a, from Ergus's Github repo.
>
>You can see the issue with non-default backgrounds in the attached 
>screenshots mode-off.png and mode-on.png; activating 
>display-fill-column-indicator-mode truncates the highlighting on each 
>line.  To fix:
>
>1. The stretch glyph needs to be drawn in the current face, not the 
>fill_column face.
>
>2. The default fill-column face should have an unspecified background 
>and it should be merged into the current face during display, not into 
>the default face.
>
>3. If the fill-column face specifies a background, we need to reset the
>
>face to the saved face after producing the indicator glyph. Here I
>found 
>it necessary to insert another display element in order for the face 
>change to take effect before the background is extended to the end of 
>the line. (I used a 0-width stretch glyph.)  Without that, the 
>fill-column face is used (see the attached c.png for a screenshot).  I 
>believe this need to add another display element at the end of the line
>
>is what Ergus was asking about.
>
>
>diff --git a/lisp/faces.el b/lisp/faces.el
>index 153e6a208f..6b9980a77f 100644
>--- a/lisp/faces.el
>+++ b/lisp/faces.el
>@@ -2504,7 +2504,7 @@ line-number-current-line
>
>  ;; Definition stolen from linum.el.
>  (defface fill-column
>-  '((t :inherit (shadow default)))
>+  '((t :inherit (shadow)))
>    "Face for displaying fill column indicator line.
>  This face is used when `display-fill-column-indicator-mode' is
>  non-nil.
>
>diff --git a/src/xdisp.c b/src/xdisp.c
>index 8ac4be8dc7..7c4f9889eb 100644
>--- a/src/xdisp.c
>+++ b/src/xdisp.c
>@@ -20416,21 +20416,23 @@ extend_face_to_end_of_line (struct it *it)
>            int stretch_ascent = (((it->ascent + it->descent)
>              * FONT_BASE (font)) / FONT_HEIGHT (font));
>
>-          it->char_to_display = 
>XFIXNAT(Vdisplay_fill_column_indicator_character);
>            memset (&it->position, 0, sizeof it->position);
>            it->avoid_cursor_p = true;
>-          it->face_id = merge_faces (it->w, Qfill_column, 0, 
>DEFAULT_FACE_ID);
>            it->start_of_box_run_p = false;
>            it->object = Qnil;
>
>            append_stretch_glyph (it, Qnil, stretch_width,
>                                 it->ascent + it->descent,
>stretch_ascent);
>
>+          it->char_to_display = 
>XFIXNAT(Vdisplay_fill_column_indicator_character);
>+          it->face_id = merge_faces (it->w, Qfill_column, 0, 
>saved_face_id);
>            PRODUCE_GLYPHS (it);
>
>+          it->face_id = saved_face_id;
>+          append_stretch_glyph (it, Qnil, 0, it->ascent + it->descent,
>+                             stretch_ascent);
>            it->position = saved_pos;
>            it->avoid_cursor_p = saved_avoid_cursor;
>-          it->face_id = saved_face_id;
>            it->start_of_box_run_p = saved_box_start;
>            it->char_to_display = saved_char;
>            it->object = save_object;
>@@ -20566,7 +20568,7 @@ extend_face_to_end_of_line (struct it *it)
>            if (it->current_x == fill_column_indicator_line)
>              {
>            const int saved_face = it->face_id;
>-          it->face_id = merge_faces (it->w, Qfill_column, 0, 
>DEFAULT_FACE_ID);
>+          it->face_id = merge_faces (it->w, Qfill_column, 0,
>saved_face);
>            it->c = it->char_to_display = 
>XFIXNAT(Vdisplay_fill_column_indicator_character);
>            PRODUCE_GLYPHS (it);
>            it->face_id = saved_face;

[-- Attachment #2: Type: text/html, Size: 7007 bytes --]

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Alp Aker <alp.tekin.aker@gmail.com>
> Date: Sun, 17 Mar 2019 13:28:22 -0400
> 
> I noticed an issue with non-default backgrounds that span newlines, such 
> as happens with region highlighting.

That's known, but in the case in point the non-default background
doesn't span newlines: the first character on the next line doesn't
have the same background as the indicator character.

Re: Fill column indicator functionality

[Ergus]

Hi:

The variable fill-column is defined in the buffer.c file. I should
access it in every display_line when display-fill-column is enabled if I
want to keep the difference between display-fill-column-indicator-column
and fill-column. (when display-fill-column-indicator is t).

Whats the better method to do that?

I think that doing the check every time display_line is called is
something not really needed because a redisplay is triggered when those
variables change, so maybe is better to do a variable update in the
redisplay there and then we can access directly an int variable without
the need to call all the if-&&-else for every line. That must be cleaner
because the checking and comparisons will be just in one part of the
code. But I am wondering if that could have some undesired side effect.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Mon, 18 Mar 2019 02:03:13 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> The variable fill-column is defined in the buffer.c file. I should
> access it in every display_line when display-fill-column is enabled if I
> want to keep the difference between display-fill-column-indicator-column
> and fill-column. (when display-fill-column-indicator is t).
> 
> Whats the better method to do that?

Are you worried about performance?  If so, then don't: accessing a
single variable is not something that would slow down redisplay in any
tangible way.  So I don't recommend any more complex solution that
somehow caches the fill-column value, it isn't justified in this case.

Re: Fill column indicator functionality

[Ergus]

Hi Eli:

The question was actually in 2 parts but I explained bad myself:

1) How to  access a specific buffer variable defined in buffer.c from
xdisp.c Obviously there is a connection throw the 'it' struct, but maybe
it is not the proper way to read it.

(BTW: why there is not a header file for xdisp?) That could reduce the
size of xdisp.c moving all the documentation and comments to the header.
that could ease the generation of some doxygen documentation and graphs
useful new for people who will wants to touch that part.

2) The question about caching that was not only because of performance
concerns, but also for code cleanup; because setting the variables in
the redisplay call will localize the 'if' asserts to one place and
reduce some code repeats (the potential reduce of operations /
display_line is just a good side effect in this case.)

The point is that right now we have code in 4 parts in this file and any
correction requires to touch these 4 parts (add_space_at_end ,
extend_face gui part, extend_face tui part and Lisp variable
declarations). If anyone touches this code apart from me, the workflow
could be very error prone, but also there are like 10-15 lines that are
repeated in the 3 places without a real need because the values only
change from time to time. 

  if (!NILP (Vdisplay_fill_column_indicator)
      && (it->w->pseudo_window_p == 0)
      && (!NILP (Vdisplay_fill_column_indicator_column))
      && FIXNATP (Vdisplay_fill_column_indicator_character))
    {
       int fill_column_indicator_column = -1;

       if (EQ (Vdisplay_fill_column_indicator_column, Qt))
         fill_column_indicator_column = fill_column;
       else if (FIXNATP (Vdisplay_fill_column_indicator_column))
	     fill_column_indicator_column =
	       XFIXNAT (Vdisplay_fill_column_indicator_column);

And so on.

On Mon, Mar 18, 2019 at 05:35:43AM +0200, Eli Zaretskii wrote:
>> Date: Mon, 18 Mar 2019 02:03:13 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> The variable fill-column is defined in the buffer.c file. I should
>> access it in every display_line when display-fill-column is enabled if I
>> want to keep the difference between display-fill-column-indicator-column
>> and fill-column. (when display-fill-column-indicator is t).
>>
>> Whats the better method to do that?
>
>Are you worried about performance?  If so, then don't: accessing a
>single variable is not something that would slow down redisplay in any
>tangible way.  So I don't recommend any more complex solution that
>somehow caches the fill-column value, it isn't justified in this case.
>

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Mon, 18 Mar 2019 12:42:49 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> 1) How to  access a specific buffer variable defined in buffer.c from
> xdisp.c Obviously there is a connection throw the 'it' struct, but maybe
> it is not the proper way to read it.

There's no need to do anything with 'struct it' for this purpose.
Just do something like

   int fc = BVAR (current_buffer, fill_column);

This works for any variable that is actually a field of 'struct
buffer'.  And when the display engine works on displaying some window,
that window's buffer is always stored in current_buffer.

> (BTW: why there is not a header file for xdisp?)

There is: dispextern.h.  The name is not xdisp.h for historical
reasons.

> That could reduce the size of xdisp.c moving all the documentation
> and comments to the header.

This is C, not C++; we don't put code commentary on header files, we
put it near the implementation, i.e. mostly in *.c files (except for
macros and inline functions that are defined in the headers).

> 2) The question about caching that was not only because of performance
> concerns, but also for code cleanup; because setting the variables in
> the redisplay call will localize the 'if' asserts to one place and
> reduce some code repeats (the potential reduce of operations /
> display_line is just a good side effect in this case.)

I don't think I understand the concern here, unless it's about what
you say below:

> The point is that right now we have code in 4 parts in this file and any
> correction requires to touch these 4 parts (add_space_at_end ,
> extend_face gui part, extend_face tui part and Lisp variable
> declarations). If anyone touches this code apart from me, the workflow
> could be very error prone, but also there are like 10-15 lines that are
> repeated in the 3 places without a real need because the values only
> change from time to time. 
> 
>   if (!NILP (Vdisplay_fill_column_indicator)
>       && (it->w->pseudo_window_p == 0)
>       && (!NILP (Vdisplay_fill_column_indicator_column))
>       && FIXNATP (Vdisplay_fill_column_indicator_character))
>     {
>        int fill_column_indicator_column = -1;
> 
>        if (EQ (Vdisplay_fill_column_indicator_column, Qt))
>          fill_column_indicator_column = fill_column;
>        else if (FIXNATP (Vdisplay_fill_column_indicator_column))
> 	     fill_column_indicator_column =
> 	       XFIXNAT (Vdisplay_fill_column_indicator_column);

You can make this a macro or a short function, and thus avoid the
repetition.  We have quite a few macros in xdisp.c, for similar
reasons.

Re: Fill column indicator functionality

[Ergus]

Hi:

I am back with this topic waiting for the membership approval I already
claimed. In the meantime the changes are available on github if anyone
wants to try/test/correct/suggest anything.

I have a design question related to continuation lines.

Right now the indicator is show in all the lines including the
continuation lines.

Conceptually this is not right because a wrapped line is actually a line
that already crossed the fill-column, so the question is if I should add
an extra if to not print the indicator in continuation lines.

Re: Fill column indicator functionality

[Óscar Fuentes]

Ergus <spacibba@aol.com> writes:

> I am back with this topic waiting for the membership approval I already
> claimed. In the meantime the changes are available on github if anyone
> wants to try/test/correct/suggest anything.

To clarify to others, that is https://github.com/Ergus/Emacs on master
branch.

> I have a design question related to continuation lines.
>
> Right now the indicator is show in all the lines including the
> continuation lines.
>
> Conceptually this is not right because a wrapped line is actually a line
> that already crossed the fill-column, so the question is if I should add
> an extra if to not print the indicator in continuation lines.

That's interesting. Showing a continous vertical line is aesthetically
pleasing even when it does not make sense otherwise, but a gap on that
vertical line also is useful because it makes the continuation lines
obvious.

I guess the answer here, as often in Emacs, is "make it configurable"
:-)

Re: Fill column indicator functionality

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> I have a design question related to continuation lines.
>>
>> Right now the indicator is show in all the lines including the
>> continuation lines.

A quick experiment here shows the indicator on the continuation line
only when the last char of the line is in the previous column of the
inticator's.

>> Conceptually this is not right because a wrapped line is actually a line
>> that already crossed the fill-column, so the question is if I should add
>> an extra if to not print the indicator in continuation lines.
>
> That's interesting. Showing a continous vertical line is aesthetically
> pleasing even when it does not make sense otherwise, but a gap on that
> vertical line also is useful because it makes the continuation lines
> obvious.
>
> I guess the answer here, as often in Emacs, is "make it configurable"
> :-)

I retract my opinion. I made some invalid asumptions above wrt how and
when the indicator is shown. IMO displaying the indicator on
continuation lines makes no sense for the reason you explained.

Re: Fill column indicator functionality

[Ergus]

Ok, it is done.

But maybe the "right" to do is to add a special value to the
display-fill-column-indicator var in order to avoid an extra variable
only for this.

Right now it is only t||nil, we can set a value like 'visual right?.

On Tue, Apr 02, 2019 at 03:03:27PM +0200, �scar Fuentes wrote:
>Ergus <spacibba@aol.com> writes:
>
>> I am back with this topic waiting for the membership approval I already
>> claimed. In the meantime the changes are available on github if anyone
>> wants to try/test/correct/suggest anything.
>
>To clarify to others, that is https://github.com/Ergus/Emacs on master
>branch.
>
>> I have a design question related to continuation lines.
>>
>> Right now the indicator is show in all the lines including the
>> continuation lines.
>>
>> Conceptually this is not right because a wrapped line is actually a line
>> that already crossed the fill-column, so the question is if I should add
>> an extra if to not print the indicator in continuation lines.
>
>That's interesting. Showing a continous vertical line is aesthetically
>pleasing even when it does not make sense otherwise, but a gap on that
>vertical line also is useful because it makes the continuation lines
>obvious.
>
>I guess the answer here, as often in Emacs, is "make it configurable"
>:-)
>
>

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Tue, 2 Apr 2019 15:37:18 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> Ok, it is done.
> 
> But maybe the "right" to do is to add a special value to the
> display-fill-column-indicator var in order to avoid an extra variable
> only for this.
> 
> Right now it is only t||nil, we can set a value like 'visual right?.

Only if there is demand for that, IMO.  I think past discussions
indicated people don't want to see the indicator on continuation
lines, and Óscar just confirmed that one more time.

Re: Fill column indicator functionality

[Ergus]

Ok, it is done in the simpler way then, I just added the extra if:

&& (it->continuation_lines_width == 0)               \

and moved everything to a macro. I think this is enough right?, at least
it is working for me.



On Tue, Apr 02, 2019 at 06:07:25PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 2 Apr 2019 15:37:18 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> Ok, it is done.
>>
>> But maybe the "right" to do is to add a special value to the
>> display-fill-column-indicator var in order to avoid an extra variable
>> only for this.
>>
>> Right now it is only t||nil, we can set a value like 'visual right?.
>
>Only if there is demand for that, IMO.  I think past discussions
>indicated people don't want to see the indicator on continuation
>lines, and �scar just confirmed that one more time.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Tue, 2 Apr 2019 17:35:04 +0200
> From: Ergus <spacibba@aol.com>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> Ok, it is done in the simpler way then, I just added the extra if:
> 
> && (it->continuation_lines_width == 0)               \
> 
> and moved everything to a macro. I think this is enough right?

Yes, I think so.

Re: Fill column indicator functionality

[Ergus]

I just pushed a new branch with the fill-column-indicator feature.

I would prefer to rebase before pushing to the master branch. (In my
ideal world I will rebase and then do a merge with -no-ff. But this is
not the workflow you have here)

So, how is decided when to move this to the master branch? (the
equivalent to accept the pull request)

There are changes in the NEWS already but not in the manual. So, just
tell me the following steps. 

Best,
Ergus

On Tue, Apr 02, 2019 at 06:44:17PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 2 Apr 2019 17:35:04 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
>>
>> Ok, it is done in the simpler way then, I just added the extra if:
>>
>> && (it->continuation_lines_width == 0)               \
>>
>> and moved everything to a macro. I think this is enough right?
>
>Yes, I think so.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Tue, 2 Apr 2019 18:36:23 +0200
> From: Ergus <spacibba@aol.com>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> So, how is decided when to move this to the master branch?

We should let people use the branch for at least 2 weeks and provide
feedback, and then decide based on what they report.

> There are changes in the NEWS already but not in the manual. So, just
> tell me the following steps. 

You can work on finishing up the branch (docs and other cleanups) in
parallel with people trying it, you don't have to do it sequentially.

Thanks.

Re: Fill column indicator functionality

[Ergus]

OK.

Please give a look to the NEWS comments I added to check if they are
right.

On Tue, Apr 02, 2019 at 07:48:24PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 2 Apr 2019 18:36:23 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
>>
>> So, how is decided when to move this to the master branch?
>
>We should let people use the branch for at least 2 weeks and provide
>feedback, and then decide based on what they report.
>
>> There are changes in the NEWS already but not in the manual. So, just
>> tell me the following steps.
>
>You can work on finishing up the branch (docs and other cleanups) in
>parallel with people trying it, you don't have to do it sequentially.
>
>Thanks.
>

Re: Fill column indicator functionality

[Robert Pluim]

>>>>> On Tue, 2 Apr 2019 18:36:23 +0200, Ergus <spacibba@aol.com> said:

    Ergus> I just pushed a new branch with the fill-column-indicator
    Ergus> feature.  I would prefer to rebase before pushing to the
    Ergus> master branch. (In my ideal world I will rebase and then do
    Ergus> a merge with -no-ff. But this is not the workflow you have
    Ergus> here)

I took a quick look. Itʼs three commits, including the NEWS
changes. Any reason you donʼt want to squash those into a single
commit?

    Ergus> So, how is decided when to move this to the master branch?
    Ergus> (the equivalent to accept the pull request)

    Ergus> There are changes in the NEWS already but not in the
    Ergus> manual. So, just tell me the following steps.

The NEWS changes have some minor issues (spelling, two spaces after
full stop, spurious whitespace), but the new user variables and modes
need descriptions in the user manual.

Robert

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Tue, 2 Apr 2019 19:00:31 +0200
> From: Ergus <spacibba@aol.com>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> Please give a look to the NEWS comments I added to check if they are
> right.

The NEWS entry is too long, IMO.  It should only describe the new
feature in a few sentences, with all the rest in the manual and doc
strings.

Thanks.

Re: Fill column indicator functionality

[Ergus]

On Tue, Apr 02, 2019 at 07:01:45PM +0200, Robert Pluim wrote:
>>>>>> On Tue, 2 Apr 2019 18:36:23 +0200, Ergus <spacibba@aol.com> said:
>
>    Ergus> I just pushed a new branch with the fill-column-indicator
>    Ergus> feature.  I would prefer to rebase before pushing to the
>    Ergus> master branch. (In my ideal world I will rebase and then do
>    Ergus> a merge with -no-ff. But this is not the workflow you have
>    Ergus> here)
>
>I took a quick look. Itʼs three commits, including the NEWS
>changes. Any reason you donʼt want to squash those into a single
>commit?
>
No, I do the squash when I rebase before merging to master and I do
all the changes and fixes recommended on top of this branch.

I just keep it like this now because recommendations will arrive and I
don't want to overwrite public history constantly if many changes are
suggested before the approval. This is like a develop branch for the
feature, so I'll put things "pretty" in the last moment. and in the mean
time I will just add commits on top of it.

>    Ergus> So, how is decided when to move this to the master branch?
>    Ergus> (the equivalent to accept the pull request)
>
>    Ergus> There are changes in the NEWS already but not in the
>    Ergus> manual. So, just tell me the following steps.
>
>The NEWS changes have some minor issues (spelling, two spaces after
>full stop, spurious whitespace), but the new user variables and modes
>need descriptions in the user manual.
>
>Robert
>
So you mean that the variables descriptions shouldn't be in NEWS?

Re: Fill column indicator functionality

[Ergus]

On Tue, Apr 02, 2019 at 08:26:09PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 2 Apr 2019 19:00:31 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
>>
>> Please give a look to the NEWS comments I added to check if they are
>> right.
>
>The NEWS entry is too long, IMO.  It should only describe the new
>feature in a few sentences, with all the rest in the manual and doc
>strings.
>
>Thanks.
>
OK, where in the manual do you think I should move this? What section/file?

Re: Fill column indicator functionality

[Robert Pluim]

>>>>> On Tue, 2 Apr 2019 19:26:20 +0200, Ergus <spacibba@aol.com> said:

    Ergus> On Tue, Apr 02, 2019 at 07:01:45PM +0200, Robert Pluim wrote:
    >>>>>>> On Tue, 2 Apr 2019 18:36:23 +0200, Ergus
    >>>>>>> <spacibba@aol.com> said:
    >> 
    Ergus> I just pushed a new branch with the fill-column-indicator
    Ergus> feature.  I would prefer to rebase before pushing to the
    Ergus> master branch. (In my ideal world I will rebase and then do
    Ergus> a merge with -no-ff. But this is not the workflow you have
    Ergus> here)
    >> 
    >> I took a quick look. Itʼs three commits, including the NEWS
    >> changes. Any reason you donʼt want to squash those into a
    >> single commit?
    >> 
    Ergus> No, I do the squash when I rebase before merging to master
    Ergus> and I do all the changes and fixes recommended on top of
    Ergus> this branch.

Thatʼs what I meant. One other point: none of your commits have
ChangeLog style entries, see "** Commit messages" in CONTRIBUTE for a
long description of the format (and learn to love "C-x 4 a")

    Ergus> I just keep it like this now because recommendations will
    Ergus> arrive and I don't want to overwrite public history
    Ergus> constantly if many changes are suggested before the
    Ergus> approval. This is like a develop branch for the feature, so
    Ergus> I'll put things "pretty" in the last moment. and in the
    Ergus> mean time I will just add commits on top of it.

Sure.

    Ergus> So, how is decided when to move this to the master branch?
    Ergus> (the equivalent to accept the pull request)
    
When Eli says itʼs ready, which requires some people to try it out and
give feedback.

    >> 
    Ergus> There are changes in the NEWS already but not in the
    Ergus> manual. So, just tell me the following steps.
    >> 
    >> The NEWS changes have some minor issues (spelling, two spaces
    >> after full stop, spurious whitespace), but the new user
    >> variables and modes need descriptions in the user manual.
    >> 
    >> Robert
    >> 
    Ergus> So you mean that the variables descriptions shouldn't be in
    Ergus> NEWS?

What you've put in NEWS now is pretty comprehensive, perhaps too much
so. Iʼd cut down what's in NEWS and move the extensive description to
the manual, probably (info "(emacs)Fill Commands")

Robert

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Tue, 2 Apr 2019 19:48:57 +0200
> From: Ergus <spacibba@aol.com>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> OK, where in the manual do you think I should move this? What section/file?

I think the section "Displaying Boundaries" is a good place, it
currently describes only the fringe indicators of the beginning and
end of the buffer.  Since fill-column indicator is a display feature,
I think this is the right place.  The file to edit is
doc/emacs/display.texi.

Robert suggested to describe this in "Fill Commands", but I think we
should only mention the indicator there, and have a cross-reference to
"Displaying Boundaries", where the full description should live.

An alternative for "Display Boundaries" is "Display Custom", which is
a hodge-podge of display-related customizations.

Re: Fill column indicator functionality

[Ergus]

I just uploaded a commit with a preliminary documentation in the file you
recommended.

I am learning the texinfo format on the way, so I still need to learn
how to do a cross reference and other details (it is not trivial for a
markdown/rst/Latex user like me).

I added the documentation about the indicator on the beginning of the
Node because I think it is somehow more general as it is not restricted
to graphical displays like the boundaries indicator.

Maybe it is possible to add some division in the page to highlight that
there are at least 2 topics there. (Markdown equivalent to #, ##, ###
and so on)

I also removed most of the text in NEWS (As I moved it to the
manual). Please give a look if it is better now.


On Tue, Apr 02, 2019 at 09:28:51PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 2 Apr 2019 19:48:57 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
>>
>> OK, where in the manual do you think I should move this? What section/file?
>
>I think the section "Displaying Boundaries" is a good place, it
>currently describes only the fringe indicators of the beginning and
>end of the buffer.  Since fill-column indicator is a display feature,
>I think this is the right place.  The file to edit is
>doc/emacs/display.texi.
>
>Robert suggested to describe this in "Fill Commands", but I think we
>should only mention the indicator there, and have a cross-reference to
>"Displaying Boundaries", where the full description should live.
>
>An alternative for "Display Boundaries" is "Display Custom", which is
>a hodge-podge of display-related customizations.

Re: Fill column indicator functionality

[Dmitry Gutov]

On 02.04.2019 19:48, Eli Zaretskii wrote:
> We should let people use the branch for at least 2 weeks and provide
> feedback, and then decide based on what they report.

I've tried it out for a bit.

Looks nice, and seems fully compatible with company-mode, FWIW.

I'll probably go back to whitespace-mode (which only shows something if 
a line is too long already), but it'll be a nice option to have and 
recommend to others.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Tue, 2 Apr 2019 23:22:52 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> I just uploaded a commit with a preliminary documentation in the file you
> recommended.

Thanks.

> I am learning the texinfo format on the way, so I still need to learn
> how to do a cross reference and other details (it is not trivial for a
> markdown/rst/Latex user like me).

I suggest to have the Texinfo manual open in your Emacs session at all
times when you are writing docs.  The Texinfo manual is well indexed,
so it's very easy to find how to format each directive.  For example,
"i xref RET" will immediately land you in the section that describes
the @xref directive, which is the main directive for cross-references;
the other ones are @pxref and @ref.

> I added the documentation about the indicator on the beginning of the
> Node because I think it is somehow more general as it is not restricted
> to graphical displays like the boundaries indicator.

This is OK.

> Maybe it is possible to add some division in the page to highlight that
> there are at least 2 topics there. (Markdown equivalent to #, ##, ###
> and so on)

I see no need.  The text can clearly indicate where a new sub-topic
starts.

> I also removed most of the text in NEWS (As I moved it to the
> manual). Please give a look if it is better now.

Comments:

 . Use 2 spaces between sentences, per our conventions.
 . Be sure to remove trailing whitespace (I have
   show-trailing-whitespace turned on in derivatives of Text mode for
   that purpose).
 . Don't use "new" or "old" in the manual -- this is appropriate for
   NEWS, but the manual describes what Emacs does regardless of when
   this became available.
 . The sentence which starts with "Is the" is not correct English.
   Instead, say something like "Specifies the ...".
 . nil and t are symbols, so should be in @code.
 . You have left one symbol quoted 'like this' instead of being in
   @code.
 . I spotted one typo: "throw" instead of "through".
 . For best future-proof results, take long commands in @w{}, as in
   @w{@kbd{M-x global-display-fill-column-indicator-mode}}, to prevent
   makeinfo and TeX from breaking them up between 2 lines at the
   whitespace.

There's also a typo in NEWS: "The indicators is not displayed" --
this mixes singular and plural forms.

The doc string of display-fill-column-indicator-column has a too-long
first sentence, it should fit on a 80-column line.

Thanks.

Re: Fill column indicator functionality

[Ergus]

I just pushed a commit with your corrections to the manual. Hope it is
better now.

I tried to do a rebase of the branch (to keep it synchronized with
master) and I see it was not possible to rebase the public branch.

I am wondering that at the end I will need to do a rebase and the squash
locally and a merge in master in a different patch if I want to keep a
nice history... Now I see the advantages of having forks and pull/merge
requests.

This makes me reconsider the importance of the gitlab discussion from
some days ago.


On Wed, Apr 03, 2019 at 08:20:10AM +0300, Eli Zaretskii wrote:
>> Date: Tue, 2 Apr 2019 23:22:52 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> I just uploaded a commit with a preliminary documentation in the file you
>> recommended.
>
>Thanks.
>
>> I am learning the texinfo format on the way, so I still need to learn
>> how to do a cross reference and other details (it is not trivial for a
>> markdown/rst/Latex user like me).
>
>I suggest to have the Texinfo manual open in your Emacs session at all
>times when you are writing docs.  The Texinfo manual is well indexed,
>so it's very easy to find how to format each directive.  For example,
>"i xref RET" will immediately land you in the section that describes
>the @xref directive, which is the main directive for cross-references;
>the other ones are @pxref and @ref.
>
>> I added the documentation about the indicator on the beginning of the
>> Node because I think it is somehow more general as it is not restricted
>> to graphical displays like the boundaries indicator.
>
>This is OK.
>
>> Maybe it is possible to add some division in the page to highlight that
>> there are at least 2 topics there. (Markdown equivalent to #, ##, ###
>> and so on)
>
>I see no need.  The text can clearly indicate where a new sub-topic
>starts.
>
>> I also removed most of the text in NEWS (As I moved it to the
>> manual). Please give a look if it is better now.
>
>Comments:
>
> . Use 2 spaces between sentences, per our conventions.
> . Be sure to remove trailing whitespace (I have
>   show-trailing-whitespace turned on in derivatives of Text mode for
>   that purpose).
> . Don't use "new" or "old" in the manual -- this is appropriate for
>   NEWS, but the manual describes what Emacs does regardless of when
>   this became available.
> . The sentence which starts with "Is the" is not correct English.
>   Instead, say something like "Specifies the ...".
> . nil and t are symbols, so should be in @code.
> . You have left one symbol quoted 'like this' instead of being in
>   @code.
> . I spotted one typo: "throw" instead of "through".
> . For best future-proof results, take long commands in @w{}, as in
>   @w{@kbd{M-x global-display-fill-column-indicator-mode}}, to prevent
>   makeinfo and TeX from breaking them up between 2 lines at the
>   whitespace.
>
>There's also a typo in NEWS: "The indicators is not displayed" --
>this mixes singular and plural forms.
>
>The doc string of display-fill-column-indicator-column has a too-long
>first sentence, it should fit on a 80-column line.
>
>Thanks.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Wed, 3 Apr 2019 12:22:36 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> I just pushed a commit with your corrections to the manual. Hope it is
> better now.
> 
> I tried to do a rebase of the branch (to keep it synchronized with
> master) and I see it was not possible to rebase the public branch.

You could skip the rebase step and just merge when time comes.  Does
it really matter for you to rebase?  I personally never do, FWIW.

Or you could rebase locally and merge to master, then push, when we
decide to land the feature.

Or you could push a new branch after rebasing.

Either way, there's nothing to worry about too much here.  No
catastrophe happened, not anywhere near a catastrophe.

The changes you made look fine to me.  Let's wait for more people to
try the branch.

Thanks.

Re: Fill column indicator functionality

[Stefan Monnier]

> I tried to do a rebase of the branch (to keep it synchronized with
> master) and I see it was not possible to rebase the public branch.

As Eli said: you can't force-push, but you can delete-then-repush to get
the same effect.

> I am wondering that at the end I will need to do a rebase and the squash
> locally

As a matter of policy we do not require rebasing nor squashing.
It's perfectly OK to just "git merge" into "master".

What we do want, tho is that the commits that are merged come with
proper commit-messages.


        Stefan

Re: Fill column indicator functionality

[Robert Pluim]

>>>>> On Wed, 03 Apr 2019 14:11:00 +0300, Eli Zaretskii <eliz@gnu.org> said:

    Eli> The changes you made look fine to me.  Let's wait for more
    Eli> people to try the branch.

Iʼve just tried it.

- etc/NEWS says:

    Customize the buffer-local variables 'display-fill-column-indicator'

but M-x customize-variable doesnʼt know about
'display-fill-column-indicator'

- the manual talks about 'global-display-fill-column-indicator-mode', but
M-x doesnʼt  know about that function until I
    (require 'display-fill-column-indicator)
(this may be due to the way autoloads work in emacs. Thereʼs an entry
in ldefs-boot.el for it)

- the Commentary section in display-fill-column-indicator.el still
talks about line numbers, and appears truncated.

- when I turn it on, it chooses \u2502, which is not displayable by my
default font, but is displayable by a fallback font. I end up with
empty blocks at the end of each line. I can probably customize
'fill-column-face' to work around this, but Iʼd expect this to work by
default (either by using '|' or using the fallback font).

- in org-mode buffers the indicator is displayed as '['. This may be
related to the previous point (those buffers use yet a third font).

Robert

Re: Fill column indicator functionality

[Ergus]

On Fri, Apr 05, 2019 at 11:10:15AM +0200, Robert Pluim wrote:
>>>>>> On Wed, 03 Apr 2019 14:11:00 +0300, Eli Zaretskii <eliz@gnu.org> said:
>
>    Eli> The changes you made look fine to me.  Let's wait for more
>    Eli> people to try the branch.
>
>Iʼve just tried it.
>
>- etc/NEWS says:
>
>    Customize the buffer-local variables 'display-fill-column-indicator'
>
>but M-x customize-variable doesnʼt know about
>'display-fill-column-indicator'
>
Hi:

Sorry, I forgot to add it to cus-start.el I fixed right now. Ween I set
the variable with set-variable it works for me. (and redisplay is called)

The problem now is that I added it to cus-start.el but when I set it
with the interface, the line does not change at all. Nothing really
happens when I save.

Could anyone tell me what I am missing here please??

>- the manual talks about 'global-display-fill-column-indicator-mode', but
>M-x doesnʼt  know about that function until I
>    (require 'display-fill-column-indicator)
>(this may be due to the way autoloads work in emacs. Thereʼs an entry
>in ldefs-boot.el for it)
>
I have it without the require, so maybe when generating the autoload
(which seems to be an automatic process) it will appear. 

>- the Commentary section in display-fill-column-indicator.el still
>talks about line numbers, and appears truncated.
>
Fixed, thanks!

>- when I turn it on, it chooses \u2502, which is not displayable by my
>default font, but is displayable by a fallback font. I end up with
>empty blocks at the end of each line. I can probably customize
>'fill-column-face' to work around this, but Iʼd expect this to work by
>default (either by using '|' or using the fallback font).
>
I don't really find a right method to fix this because the
char-displayable-p function seems not to be accurate in many
cases. There was a discussion about this before, but there was not a
final agreement I think. And from the char-displayable-p documentation:

```
On a multi-font display, the test is only whether there is an
appropriate font from the selected frame's fontset to display
CHAR's charset in general.  Since fonts may be specified on a
per-character basis, this may not be accurate.
```

Any suggestion here?

>- in org-mode buffers the indicator is displayed as '['. This may be
>related to the previous point (those buffers use yet a third font).
>

>Robert

Ergus

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Ergus <spacibba@aol.com>,  emacs-devel@gnu.org
> Date: Fri, 05 Apr 2019 11:10:15 +0200
> 
> - the manual talks about 'global-display-fill-column-indicator-mode', but
> M-x doesnʼt  know about that function until I
>     (require 'display-fill-column-indicator)

I think your loaddefs.el is outdated, and/or you didn't rebuild Emacs
after updating loaddefs.el.

> (this may be due to the way autoloads work in emacs. Thereʼs an entry
> in ldefs-boot.el for it)

ldefs-boot.el is not used in a non-bootstrap build.

> - when I turn it on, it chooses \u2502, which is not displayable by my
> default font, but is displayable by a fallback font. I end up with
> empty blocks at the end of each line. I can probably customize
> 'fill-column-face' to work around this, but Iʼd expect this to work by
> default (either by using '|' or using the fallback font).

Is this in Emacs -Q or do you have some font or fontset
customizations?  If the latter, please try in "emacs -Q", and if that
works, please tell what customizations defeats that.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 5 Apr 2019 12:36:14 +0200
> From: Ergus <spacibba@aol.com>
> 
> The problem now is that I added it to cus-start.el but when I set it
> with the interface, the line does not change at all. Nothing really
> happens when I save.

Does invoking 'redisplay' (the function) fix that?

> >- when I turn it on, it chooses \u2502, which is not displayable by my
> >default font, but is displayable by a fallback font. I end up with
> >empty blocks at the end of each line. I can probably customize
> >'fill-column-face' to work around this, but Iʼd expect this to work by
> >default (either by using '|' or using the fallback font).
> >
> I don't really find a right method to fix this because the
> char-displayable-p function seems not to be accurate in many
> cases. There was a discussion about this before, but there was not a
> final agreement I think. And from the char-displayable-p documentation:
> 
> ```
> On a multi-font display, the test is only whether there is an
> appropriate font from the selected frame's fontset to display
> CHAR's charset in general.  Since fonts may be specified on a
> per-character basis, this may not be accurate.
> ```
> 
> Any suggestion here?

Once we have the details I requested from Robert.

> >- in org-mode buffers the indicator is displayed as '['. This may be
> >related to the previous point (those buffers use yet a third font).

How come '|' is displayed as '['?  What does Emacs show in *Help* if
you (Robert) go to that character and type "C-u C-x ="?

Re: Fill column indicator functionality

[Robert Pluim]

>>>>> On Fri, 05 Apr 2019 14:44:58 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com> Cc: Ergus
    >> <spacibba@aol.com>, emacs-devel@gnu.org Date: Fri, 05 Apr 2019
    >> 11:10:15 +0200
    >> 
    >> - the manual talks about
    >> 'global-display-fill-column-indicator-mode', but M-x doesnʼt
    >> know about that function until I (require
    >> 'display-fill-column-indicator)

    Eli> I think your loaddefs.el is outdated, and/or you didn't
    Eli> rebuild Emacs after updating loaddefs.el.

    >> (this may be due to the way autoloads work in emacs. Thereʼs an
    >> entry in ldefs-boot.el for it)

    Eli> ldefs-boot.el is not used in a non-bootstrap build.

Indeed, loaddefs.el was outdated, all fine now.

    >> - when I turn it on, it chooses \u2502, which is not
    >> displayable by my default font, but is displayable by a
    >> fallback font. I end up with empty blocks at the end of each
    >> line. I can probably customize 'fill-column-face' to work
    >> around this, but Iʼd expect this to work by default (either by
    >> using '|' or using the fallback font).

    Eli> Is this in Emacs -Q or do you have some font or fontset
    Eli> customizations?  If the latter, please try in "emacs -Q", and
    Eli> if that works, please tell what customizations defeats that.

This is with font customizations, it works in 'emacs -Q', However:

emacs -Q
<set default face to "IBM Plex Mono", which canʼt display \u2502>
M-x global-display-fill-column-indicator-mode => shows boxes at eol
C-x 8 RET 2502 => shows '|' glyph, and 'C-u C-x =' =>

             position: 148 of 148 (99%), column: 0
            character: │ (displayed as │) (codepoint 9474, #o22402, #x2502)
              charset: unicode (Unicode (ISO10646))
code point in charset: 0x2502
               script: symbol
               syntax: _ 	which means: symbol
             category: .:Base, c:Chinese, h:Korean, j:Japanese
             to input: type "C-x 8 RET 2502" or "C-x 8 RET BOX DRAWINGS LIGHT VERTICAL"
          buffer code: #xE2 #x94 #x82
            file code: #xE2 #x94 #x82 (encoded by coding system utf-8-unix)
              display: by this font (glyph code)
    mac-ct:-*-Andale Mono-normal-normal-normal-*-12-*-*-*-m-0-iso10646-1 (#x21C)

So \u2502 is displayable, just not by the default font.

Re: Fill column indicator functionality

[Robert Pluim]

>>>>> On Fri, 05 Apr 2019 14:47:47 +0300, Eli Zaretskii <eliz@gnu.org> said:
    >> >- in org-mode buffers the indicator is displayed as '['. This
    >> may be >related to the previous point (those buffers use yet a
    >> third font).

    Eli> How come '|' is displayed as '['?  What does Emacs show in
    Eli> *Help* if you (Robert) go to that character and type "C-u C-x
    Eli> ="?

I canʼt: itʼs not a real character in the buffer, itʼs a fill-column
indicator. Inserting a real \u2502 works correctly, but that falls
back to a different font than the rest of the buffer text.

Robert

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 05 Apr 2019 14:09:58 +0200
> 
>     Eli> Is this in Emacs -Q or do you have some font or fontset
>     Eli> customizations?  If the latter, please try in "emacs -Q", and
>     Eli> if that works, please tell what customizations defeats that.
> 
> This is with font customizations, it works in 'emacs -Q', However:

Please show the customizations, I still don't understand the issue
100%.

> emacs -Q
> <set default face to "IBM Plex Mono", which canʼt display \u2502>
> M-x global-display-fill-column-indicator-mode => shows boxes at eol
> C-x 8 RET 2502 => shows '|' glyph, and 'C-u C-x =' =>

What Unicode blocks does this font support more-or-less fully?  In
particular, does it have any glyphs in the Box Drawing block?

In general, it is not a good idea to choose as your default a font
that cannot display symbol and punctuation characters, because Emacs
prefers the default fonts for those.  I'm guessing your fontset
customizations somehow disabled that.

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Ergus <spacibba@aol.com>,  emacs-devel@gnu.org
> Date: Fri, 05 Apr 2019 14:13:35 +0200
> 
> >>>>> On Fri, 05 Apr 2019 14:47:47 +0300, Eli Zaretskii <eliz@gnu.org> said:
>     >> >- in org-mode buffers the indicator is displayed as '['. This
>     >> may be >related to the previous point (those buffers use yet a
>     >> third font).
> 
>     Eli> How come '|' is displayed as '['?  What does Emacs show in
>     Eli> *Help* if you (Robert) go to that character and type "C-u C-x
>     Eli> ="?
> 
> I canʼt: itʼs not a real character in the buffer, itʼs a fill-column
> indicator.

Of course you can: invoke Emacs with -fn switch that names the font
used in Org buffers as the default font.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 5 Apr 2019 12:36:14 +0200
> From: Ergus <spacibba@aol.com>
> 
> I don't really find a right method to fix this because the
> char-displayable-p function seems not to be accurate in many
> cases. There was a discussion about this before, but there was not a
> final agreement I think. And from the char-displayable-p documentation:
> 
> ```
> On a multi-font display, the test is only whether there is an
> appropriate font from the selected frame's fontset to display
> CHAR's charset in general.  Since fonts may be specified on a
> per-character basis, this may not be accurate.
> ```
> 
> Any suggestion here?

Can you reproduce the problem, given the information Robert provided
about the font he uses?

Once you can reproduce the problem, I suggest to use the macro
FACE_FOR_CHAR to find the ID of a face suitable for displaying the
indicator character, instead of using DEFAULT_FACE_ID.  You can find
examples of using this macro elsewhere in xdisp.c.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 05 Apr 2019 15:44:42 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Robert Pluim <rpluim@gmail.com>
> > Cc: emacs-devel@gnu.org
> > Date: Fri, 05 Apr 2019 14:09:58 +0200
> > 
> >     Eli> Is this in Emacs -Q or do you have some font or fontset
> >     Eli> customizations?  If the latter, please try in "emacs -Q", and
> >     Eli> if that works, please tell what customizations defeats that.
> > 
> > This is with font customizations, it works in 'emacs -Q', However:
> 
> Please show the customizations, I still don't understand the issue
> 100%.

In particular, this:

> > emacs -Q
> > <set default face to "IBM Plex Mono", which canʼt display \u2502>
> > M-x global-display-fill-column-indicator-mode => shows boxes at eol
> > C-x 8 RET 2502 => shows '|' glyph, and 'C-u C-x =' =>

is already a surprise, as '|' is not U+2502, it's U+007C.  How come?
Did something funky go on when you copied the characters into your
email?

Re: Fill column indicator functionality

[Robert Pluim]

>>>>> On Fri, 05 Apr 2019 16:21:21 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> Date: Fri, 05 Apr 2019 15:44:42 +0300 From: Eli Zaretskii
    >> <eliz@gnu.org> Cc: emacs-devel@gnu.org
    >> 
    >> > From: Robert Pluim <rpluim@gmail.com> > Cc:
    >> emacs-devel@gnu.org > Date: Fri, 05 Apr 2019 14:09:58 +0200
    >> > 
    >> > Eli> Is this in Emacs -Q or do you have some font or fontset
    >> > Eli> customizations?  If the latter, please try in "emacs
    >> -Q", and > Eli> if that works, please tell what customizations
    >> defeats that.
    >> > 
    >> > This is with font customizations, it works in 'emacs -Q',
    >> However:
    >> 
    >> Please show the customizations, I still don't understand the
    >> issue 100%.

As mentioned in my other message: emacs -Q + customizing the default
font is enough.

    Eli> In particular, this:

    >> > emacs -Q > <set default face to "IBM Plex Mono", which canʼt
    >> display \u2502> > M-x global-display-fill-column-indicator-mode
    >> => shows boxes at eol > C-x 8 RET 2502 => shows '|' glyph, and
    >> 'C-u C-x =' =>

    Eli> is already a surprise, as '|' is not U+2502, it's U+007C.
    Eli> How come?  Did something funky go on when you copied the
    Eli> characters into your email?

It shows the correct U+2502 glyph. I was just lazy and typed U+007C in
the email.

Robert

Re: Fill column indicator functionality

[Robert Pluim]

>>>>> On Fri, 05 Apr 2019 15:44:42 +0300, Eli Zaretskii <eliz@gnu.org> said:
    Eli> Please show the customizations, I still don't understand the
    Eli> issue 100%.

Nothing beyond setting the default face.

    >> emacs -Q <set default face to "IBM Plex Mono", which canʼt
    >> display \u2502> M-x global-display-fill-column-indicator-mode
    >> => shows boxes at eol C-x 8 RET 2502 => shows '|' glyph, and
    >> 'C-u C-x =' =>

    Eli> What Unicode blocks does this font support more-or-less
    Eli> fully?  In particular, does it have any glyphs in the Box
    Eli> Drawing block?

I donʼt know, but probably not.

    Eli> In general, it is not a good idea to choose as your default a
    Eli> font that cannot display symbol and punctuation characters,
    Eli> because Emacs prefers the default fonts for those.  I'm
    Eli> guessing your fontset customizations somehow disabled that.

I donʼt have any fontset customizations. But I agree I should probably
choose a better font.

Robert

Re: Fill column indicator functionality

[Robert Pluim]

>>>>> On Fri, 05 Apr 2019 15:46:08 +0300, Eli Zaretskii <eliz@gnu.org> said:
    Eli> Of course you can: invoke Emacs with -fn switch that names
    Eli> the font used in Org buffers as the default font.

If I do that and insert U+2502, itʼs then displayed using the fallback
font (Andale Mono in this case).

Robert

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 05 Apr 2019 16:09:51 +0200
> 
> >>>>> On Fri, 05 Apr 2019 15:46:08 +0300, Eli Zaretskii <eliz@gnu.org> said:
>     Eli> Of course you can: invoke Emacs with -fn switch that names
>     Eli> the font used in Org buffers as the default font.
> 
> If I do that and insert U+2502, itʼs then displayed using the fallback
> font (Andale Mono in this case).

So what font customizations do you have for Org buffers that cause a
different glyph be displayed there?

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 05 Apr 2019 17:13:19 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Robert Pluim <rpluim@gmail.com>
> > Cc: emacs-devel@gnu.org
> > Date: Fri, 05 Apr 2019 16:09:51 +0200
> > 
> > >>>>> On Fri, 05 Apr 2019 15:46:08 +0300, Eli Zaretskii <eliz@gnu.org> said:
> >     Eli> Of course you can: invoke Emacs with -fn switch that names
> >     Eli> the font used in Org buffers as the default font.
> > 
> > If I do that and insert U+2502, itʼs then displayed using the fallback
> > font (Andale Mono in this case).
> 
> So what font customizations do you have for Org buffers that cause a
> different glyph be displayed there?

Also, what does this yield:

  M-: (internal-char-font nil ?│) RET

Please try that in both *scratch* and in an Org buffer.

Re: Fill column indicator functionality

[Ergus]

On Fri, Apr 05, 2019 at 02:47:47PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 5 Apr 2019 12:36:14 +0200
>> From: Ergus <spacibba@aol.com>
>>
>> The problem now is that I added it to cus-start.el but when I set it
>> with the interface, the line does not change at all. Nothing really
>> happens when I save.
>
>Does invoking 'redisplay' (the function) fix that?
>
No

>> >- when I turn it on, it chooses \u2502, which is not displayable by my
>> >default font, but is displayable by a fallback font. I end up with
>> >empty blocks at the end of each line. I can probably customize
>> >'fill-column-face' to work around this, but Iʼd expect this to work by
>> >default (either by using '|' or using the fallback font).
>> >
>> I don't really find a right method to fix this because the
>> char-displayable-p function seems not to be accurate in many
>> cases. There was a discussion about this before, but there was not a
>> final agreement I think. And from the char-displayable-p documentation:
>>
>> ```
>> On a multi-font display, the test is only whether there is an
>> appropriate font from the selected frame's fontset to display
>> CHAR's charset in general.  Since fonts may be specified on a
>> per-character basis, this may not be accurate.
>> ```
>>
>> Any suggestion here?
>
>Once we have the details I requested from Robert.
>
>> >- in org-mode buffers the indicator is displayed as '['. This may be
>> >related to the previous point (those buffers use yet a third font).
>
>How come '|' is displayed as '['?  What does Emacs show in *Help* if
>you (Robert) go to that character and type "C-u C-x ="?

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 5 Apr 2019 17:04:04 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> On Fri, Apr 05, 2019 at 02:47:47PM +0300, Eli Zaretskii wrote:
> >> Date: Fri, 5 Apr 2019 12:36:14 +0200
> >> From: Ergus <spacibba@aol.com>
> >>
> >> The problem now is that I added it to cus-start.el but when I set it
> >> with the interface, the line does not change at all. Nothing really
> >> happens when I save.
> >
> >Does invoking 'redisplay' (the function) fix that?
> >
> No

Maybe I don't understand the situation.  Can you describe what you
did, step by step, that you expected to change the appearance of the
indicator, but didn't?

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 05 Apr 2019 16:06:17 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Once you can reproduce the problem, I suggest to use the macro
> FACE_FOR_CHAR to find the ID of a face suitable for displaying the
> indicator character, instead of using DEFAULT_FACE_ID.  You can find
> examples of using this macro elsewhere in xdisp.c.

On second thought, I think using FACE_FOR_CHAR would produce
unpleasant results.  If the font required to display U+2502 is not the
default font, it could be higher than the default font, which will
cause the line height become larger on those screen lines where the
indicator is displayed.  The result will cause complaints.

So I think we should insist on being able to display the indicator
character by the default face's font.  Whether this is possible could
be tested by comparing the font returned by internal-char-font and the
default face's font returned by face-font.  Like this:

  (if (eq (aref (car (internal-char-font nil ?│)) 0)
          (face-font 'default))
       ;; can use the default font for U+2502

(But we should use the actual value of
display-fill-column-indicator-char instead of the literal character.)

WDYT?

Re: Fill column indicator functionality

[Ergus]

Hi:

If I set a different value to display-fill-column-indicator with
customize-variable and save; the display should be updated to use the
new value right? (display the indicator or hide it)

I have never used customize-variable, so maybe that's not the expected
behavior.

Or it requires to reboot?

It happens when I use set-variable.



On Fri, Apr 05, 2019 at 06:17:36PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 5 Apr 2019 17:04:04 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> On Fri, Apr 05, 2019 at 02:47:47PM +0300, Eli Zaretskii wrote:
>> >> Date: Fri, 5 Apr 2019 12:36:14 +0200
>> >> From: Ergus <spacibba@aol.com>
>> >>
>> >> The problem now is that I added it to cus-start.el but when I set it
>> >> with the interface, the line does not change at all. Nothing really
>> >> happens when I save.
>> >
>> >Does invoking 'redisplay' (the function) fix that?
>> >
>> No
>
>Maybe I don't understand the situation.  Can you describe what you
>did, step by step, that you expected to change the appearance of the
>indicator, but didn't?

Re: Fill column indicator functionality

[Ergus]

Hi Eli:

On Fri, Apr 05, 2019 at 06:28:40PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 05 Apr 2019 16:06:17 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> Once you can reproduce the problem, I suggest to use the macro
>> FACE_FOR_CHAR to find the ID of a face suitable for displaying the
>> indicator character, instead of using DEFAULT_FACE_ID.  You can find
>> examples of using this macro elsewhere in xdisp.c.
>
>On second thought, I think using FACE_FOR_CHAR would produce
>unpleasant results.  If the font required to display U+2502 is not the
>default font, it could be higher than the default font, which will
>cause the line height become larger on those screen lines where the
>indicator is displayed.  The result will cause complaints.
>
I have a version already implemented with this solution and I don't
like it for the reasons you expose.

>So I think we should insist on being able to display the indicator
>character by the default face's font.  Whether this is possible could
>be tested by comparing the font returned by internal-char-font and the
>default face's font returned by face-font.  Like this:
>
>  (if (eq (aref (car (internal-char-font nil ?│)) 0)
>          w(face-font 'default))
>       ;; can use the default font for U+2502
>
>(But we should use the actual value of
>display-fill-column-indicator-char instead of the literal character.)
>
>WDYT?

Actually this is what we have now:

(define-minor-mode display-fill-column-indicator-mode
  "Toggle display fill column indicator.
This uses `display-fill-column-indicator' internally.

To change the position of the column displayed by default,
customize `display-fill-column-indicator-column' you can change the
character for the indicator setting `display-fill-column-indicator-character'."
  :lighter nil
  (if display-fill-column-indicator-mode
      (progn
        (setq display-fill-column-indicator t)
        (unless display-fill-column-indicator-character
          (if (char-displayable-p ?\u2502)
              (setq display-fill-column-indicator-character ?\u2502)
            (setq display-fill-column-indicator-character ?|))))
    (setq display-fill-column-indicator nil)))


I think we only need to extend the inner if with your condition, but I
got an error because (internal-char-font nil ?│) always return nil in a
terminal and aref has issues with that.

Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
  aref(nil 0)
  eval((aref (car (internal-char-font nil 9474)) 0) nil)
  elisp--eval-last-sexp(nil)
  #f(compiled-function (eval-last-sexp-arg-internal) "Evaluate sexp before point; print value in the echo area.\nInteractively, with a non `-' prefix argument, print output into\ncurrent buffer.\n\nNormally, this function truncates long output according to the\nvalue of the variables `eval-expression-print-length' and\n`eval-expression-print-level'.  With a prefix argument of zero,\nhowever, there is no such truncation.\nInteger values are printed in several formats (decimal, octal,\nand hexadecimal).  When the prefix argument is -1 or the value\ndoesn't exceed `eval-expression-print-maximum-character', an\ninteger value is also printed as a character of that codepoint.\n\nIf `eval-expression-debug-on-error' is non-nil, which is the default,\nthis command arranges for all errors to enter t
 he debugger." (interactive "P") #<bytecode 0x1fdfdd428807>)(nil)
  apply(#f(compiled-function (eval-last-sexp-arg-internal) "Evaluate sexp before point; print value in the echo area.\nInteractively, with a non `-' prefix argument, print output into\ncurrent buffer.\n\nNormally, this function truncates long output according to the\nvalue of the variables `eval-expression-print-length' and\n`eval-expression-print-level'.  With a prefix argument of zero,\nhowever, there is no such truncation.\nInteger values are printed in several formats (decimal, octal,\nand hexadecimal).  When the prefix argument is -1 or the value\ndoesn't exceed `eval-expression-print-maximum-character', an\ninteger value is also printed as a character of that codepoint.\n\nIf `eval-expression-debug-on-error' is non-nil, which is the default,\nthis command arranges for all errors to e
 nter the debugger." (interactive "P") #<bytecode 0x1fdfdd428807>) nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

In a gui I get this error:

Debugger entered--Lisp error: (wrong-type-argument arrayp #<font-object "-1ASC-Liberation Mono-normal-normal-normal-*-15-*-*-*-*-0-iso10646-1">)
  aref(#<font-object "-1ASC-Liberation Mono-normal-normal-normal-*-15-*-*-*-*-0-iso10646-1"> 0)
  eval((aref (car (internal-char-font nil 9474)) 0) nil)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

Could we use something else?

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 5 Apr 2019 20:11:33 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> >  (if (eq (aref (car (internal-char-font nil ?│)) 0)
> >          w(face-font 'default))
> >       ;; can use the default font for U+2502
> >
> >(But we should use the actual value of
> >display-fill-column-indicator-char instead of the literal character.)
> >
> >WDYT?
> 
> Actually this is what we have now:
> 
> (define-minor-mode display-fill-column-indicator-mode
>   "Toggle display fill column indicator.
> This uses `display-fill-column-indicator' internally.
> 
> To change the position of the column displayed by default,
> customize `display-fill-column-indicator-column' you can change the
> character for the indicator setting `display-fill-column-indicator-character'."
>   :lighter nil
>   (if display-fill-column-indicator-mode
>       (progn
>         (setq display-fill-column-indicator t)
>         (unless display-fill-column-indicator-character
>           (if (char-displayable-p ?\u2502)
>               (setq display-fill-column-indicator-character ?\u2502)
>             (setq display-fill-column-indicator-character ?|))))
>     (setq display-fill-column-indicator nil)))
> 
> 
> I think we only need to extend the inner if with your condition, but I
> got an error because (internal-char-font nil ?│) always return nil in a
> terminal and aref has issues with that.

For terminal frames, char-displayable-p is okay and should be left
alone as the only test there.  The test I proposed is only needed for
GUI frames.

> In a gui I get this error:
> 
> Debugger entered--Lisp error: (wrong-type-argument arrayp #<font-object "-1ASC-Liberation Mono-normal-normal-normal-*-15-*-*-*-*-0-iso10646-1">)
>   aref(#<font-object "-1ASC-Liberation Mono-normal-normal-normal-*-15-*-*-*-*-0-iso10646-1"> 0)
>   eval((aref (car (internal-char-font nil 9474)) 0) nil)

Oops, sorry, I copied the wrong expression.  This is the correct one:

  (aref (query-font (car (internal-char-font nil ?│))) 0)

Btw, there could be a problem when the mode is turned on on a GUI
frame, where '│' can be displayed OK, and then a TTY frame is created
in the same session, where that character cannot be displayed.  I
wonder how to deal with this issue.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 5 Apr 2019 19:30:10 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> If I set a different value to display-fill-column-indicator with
> customize-variable and save; the display should be updated to use the
> new value right? (display the indicator or hide it)
> 
> I have never used customize-variable, so maybe that's not the expected
> behavior.

After changing the value, you need to click "STATE" and select "Set
for current session".  Did you do that?

> Or it requires to reboot?

No.

Re: Fill column indicator functionality

[Ergus]

On Fri, Apr 05, 2019 at 10:05:53PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 5 Apr 2019 19:30:10 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> If I set a different value to display-fill-column-indicator with
>> customize-variable and save; the display should be updated to use the
>> new value right? (display the indicator or hide it)
>>
>> I have never used customize-variable, so maybe that's not the expected
>> behavior.
>
>After changing the value, you need to click "STATE" and select "Set
>for current session".  Did you do that?
>

Yes, I did, and there is not change.

>> Or it requires to reboot?
>
>No.

Re: Fill column indicator functionality

[Óscar Fuentes]

Ergus <spacibba@aol.com> writes:

> On Fri, Apr 05, 2019 at 10:05:53PM +0300, Eli Zaretskii wrote:
>>> Date: Fri, 5 Apr 2019 19:30:10 +0200
>>> From: Ergus <spacibba@aol.com>
>>> Cc: emacs-devel@gnu.org
>>>
>>> If I set a different value to display-fill-column-indicator with
>>> customize-variable and save; the display should be updated to use the
>>> new value right? (display the indicator or hide it)
>>>
>>> I have never used customize-variable, so maybe that's not the expected
>>> behavior.
>>
>>After changing the value, you need to click "STATE" and select "Set
>>for current session".  Did you do that?
>>
>
> Yes, I did, and there is not change.

I have a patch from some days ago applied here, sorry if this is
outdated, but I see something suspicious. After M-x customize-variable
display-fill-column-indicator-character :


Hide display-fill-column-indicator-character: nil
    State : STANDARD. (mismatch)
   Character to draw the indicator when ‘display-fill-column-indicator’ is non-n


That "nil" and "mismatch" are not right. This is the definition of the
variable in xdisp.c:


  DEFVAR_LISP ("display-fill-column-indicator-character", Vdisplay_fill_column_indicator_character,
    doc: /* Character to draw the indicator when `display-fill-column-indicator' is non-nil.
The default is U+2502 but a good alternative is (ascii 124) if
the font in fill-column-face does not support Unicode characters.  */);
  Vdisplay_fill_column_indicator_character = Qnil;
  DEFSYM (Qdisplay_fill_column_indicator_character, "display-fill-column-indicator-character");
  Fmake_variable_buffer_local (Qdisplay_fill_column_indicator_character);


I know next to nothing about those macros, but look suspicious.

Re: Fill column indicator functionality

[Ergus]

On Fri, Apr 05, 2019 at 10:03:07PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 5 Apr 2019 20:11:33 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> >  (if (eq (aref (car (internal-char-font nil ?│)) 0)
>> >          w(face-font 'default))
>> >       ;; can use the default font for U+2502
>> >
>> >(But we should use the actual value of
>> >display-fill-column-indicator-char instead of the literal character.)
>> >
>> >WDYT?
>>
>> Actually this is what we have now:
>>
>> (define-minor-mode display-fill-column-indicator-mode
>>   "Toggle display fill column indicator.
>> This uses `display-fill-column-indicator' internally.
>>
>> To change the position of the column displayed by default,
>> customize `display-fill-column-indicator-column' you can change the
>> character for the indicator setting `display-fill-column-indicator-character'."
>>   :lighter nil
>>   (if display-fill-column-indicator-mode
>>       (progn
>>         (setq display-fill-column-indicator t)
>>         (unless display-fill-column-indicator-character
>>           (if (char-displayable-p ?\u2502)
>>               (setq display-fill-column-indicator-character ?\u2502)
>>             (setq display-fill-column-indicator-character ?|))))
>>     (setq display-fill-column-indicator nil)))
>>
>>
>> I think we only need to extend the inner if with your condition, but I
>> got an error because (internal-char-font nil ?│) always return nil in a
>> terminal and aref has issues with that.
>
>For terminal frames, char-displayable-p is okay and should be left
>alone as the only test there.  The test I proposed is only needed for
>GUI frames.
>
>> In a gui I get this error:
>>
>> Debugger entered--Lisp error: (wrong-type-argument arrayp #<font-object "-1ASC-Liberation Mono-normal-normal-normal-*-15-*-*-*-*-0-iso10646-1">)
>>   aref(#<font-object "-1ASC-Liberation Mono-normal-normal-normal-*-15-*-*-*-*-0-iso10646-1"> 0)
>>   eval((aref (car (internal-char-font nil 9474)) 0) nil)
>
>Oops, sorry, I copied the wrong expression.  This is the correct one:
>
>  (aref (query-font (car (internal-char-font nil ?│))) 0)
>
>Btw, there could be a problem when the mode is turned on on a GUI
>frame, where '│' can be displayed OK, and then a TTY frame is created
>in the same session, where that character cannot be displayed.  I
>wonder how to deal with this issue.

There is also the problem that the user could activate
display-fill-column-mode and then change the font. 

Re: Fill column indicator functionality

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]

On Fri, Apr 05, 2019 at 11:10:46PM +0200, Óscar Fuentes wrote:
>Ergus <spacibba@aol.com> writes:
>
>> On Fri, Apr 05, 2019 at 10:05:53PM +0300, Eli Zaretskii wrote:
>>>> Date: Fri, 5 Apr 2019 19:30:10 +0200
>>>> From: Ergus <spacibba@aol.com>
>>>> Cc: emacs-devel@gnu.org
>>>>
>>>> If I set a different value to display-fill-column-indicator with
>>>> customize-variable and save; the display should be updated to use the
>>>> new value right? (display the indicator or hide it)
>>>>
>>>> I have never used customize-variable, so maybe that's not the expected
>>>> behavior.
>>>
>>>After changing the value, you need to click "STATE" and select "Set
>>>for current session".  Did you do that?
>>>
>>
>> Yes, I did, and there is not change.
>
>I have a patch from some days ago applied here, sorry if this is
>outdated, but I see something suspicious. After M-x customize-variable
>display-fill-column-indicator-character :
>
>
>Hide display-fill-column-indicator-character: nil
>    State : STANDARD. (mismatch)
>   Character to draw the indicator when ‘display-fill-column-indicator’ is non-n
>
>
>That "nil" and "mismatch" are not right. This is the definition of the
>variable in xdisp.c:
>
>
>  DEFVAR_LISP ("display-fill-column-indicator-character", Vdisplay_fill_column_indicator_character,
>    doc: /* Character to draw the indicator when `display-fill-column-indicator' is non-nil.
>The default is U+2502 but a good alternative is (ascii 124) if
>the font in fill-column-face does not support Unicode characters.  */);
>  Vdisplay_fill_column_indicator_character = Qnil;
>  DEFSYM (Qdisplay_fill_column_indicator_character, "display-fill-column-indicator-character");
>  Fmake_variable_buffer_local (Qdisplay_fill_column_indicator_character);
>
>
>I know next to nothing about those macros, but look suspicious.
>
>

Yes, I observe a similar behavior. Look the attachment. The value is
nil but the indicator is shown.

[-- Attachment #2: Screenshot_2019-04-05_23-50-54.png --]
[-- Type: image/png, Size: 27191 bytes --]

Re: Fill column indicator functionality

[Óscar Fuentes]

Ergus <spacibba@aol.com> writes:

>>>>> If I set a different value to display-fill-column-indicator with
>>>>> customize-variable and save; the display should be updated to use the
>>>>> new value right? (display the indicator or hide it)
>>>>>
>>>>> I have never used customize-variable, so maybe that's not the expected
>>>>> behavior.
>>>>
>>>>After changing the value, you need to click "STATE" and select "Set
>>>>for current session".  Did you do that?
>>>>
>>>
>>> Yes, I did, and there is not change.
>>
>>I have a patch from some days ago applied here, sorry if this is
>>outdated, but I see something suspicious. After M-x customize-variable
>>display-fill-column-indicator-character :
>>
>>
>>Hide display-fill-column-indicator-character: nil
>>    State : STANDARD. (mismatch)
>>   Character to draw the indicator when ‘display-fill-column-indicator’ is non-n
>>
>>
>>That "nil" and "mismatch" are not right. This is the definition of the
>>variable in xdisp.c:
>>
>>
>>  DEFVAR_LISP ("display-fill-column-indicator-character", Vdisplay_fill_column_indicator_character,
>>    doc: /* Character to draw the indicator when `display-fill-column-indicator' is non-nil.
>>The default is U+2502 but a good alternative is (ascii 124) if
>>the font in fill-column-face does not support Unicode characters.  */);
>>  Vdisplay_fill_column_indicator_character = Qnil;
>>  DEFSYM (Qdisplay_fill_column_indicator_character, "display-fill-column-indicator-character");
>>  Fmake_variable_buffer_local (Qdisplay_fill_column_indicator_character);
>>
>>
>>I know next to nothing about those macros, but look suspicious.
>>
>>
>
> Yes, I observe a similar behavior. Look the attachment. The value is
> nil but the indicator is shown.

Oh, you are talking about display-fill-column-indicator and I about
display-fill-column-indicator-character. Sorry for the confusion, but my
observation points to a problem that may be related to what you are
discussing.

BTW, here display-fill-column-indicator is not customizable.

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 05 Apr 2019 23:10:46 +0200
> 
> I have a patch from some days ago applied here, sorry if this is
> outdated, but I see something suspicious. After M-x customize-variable
> display-fill-column-indicator-character :
> 
> 
> Hide display-fill-column-indicator-character: nil
>     State : STANDARD. (mismatch)
>    Character to draw the indicator when ‘display-fill-column-indicator’ is non-n
> 
> 
> That "nil" and "mismatch" are not right. This is the definition of the
> variable in xdisp.c:
> 
> 
>   DEFVAR_LISP ("display-fill-column-indicator-character", Vdisplay_fill_column_indicator_character,
>     doc: /* Character to draw the indicator when `display-fill-column-indicator' is non-nil.
> The default is U+2502 but a good alternative is (ascii 124) if
> the font in fill-column-face does not support Unicode characters.  */);
>   Vdisplay_fill_column_indicator_character = Qnil;
>   DEFSYM (Qdisplay_fill_column_indicator_character, "display-fill-column-indicator-character");
>   Fmake_variable_buffer_local (Qdisplay_fill_column_indicator_character);

Hmm... why do we need those DEFSYMs?  I don't think the Qfoo symbols
are ever used in C, are they?  Do the problems go away if you remove
the DEFSYMS?

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 5 Apr 2019 22:03:21 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> On Fri, Apr 05, 2019 at 10:05:53PM +0300, Eli Zaretskii wrote:
> >> Date: Fri, 5 Apr 2019 19:30:10 +0200
> >> From: Ergus <spacibba@aol.com>
> >> Cc: emacs-devel@gnu.org
> >>
> >> If I set a different value to display-fill-column-indicator with
> >> customize-variable and save; the display should be updated to use the
> >> new value right? (display the indicator or hide it)
> >>
> >> I have never used customize-variable, so maybe that's not the expected
> >> behavior.
> >
> >After changing the value, you need to click "STATE" and select "Set
> >for current session".  Did you do that?
> >
> 
> Yes, I did, and there is not change.

So you are saying that display-fill-column-indicator is nil if you
eval it with M-:, but the indicator is still being displayed?

Re: Fill column indicator functionality

[Robert Pluim]

>>>>> On Fri, 5 Apr 2019 23:15:43 +0200, Ergus <spacibba@aol.com> said:
    >> Btw, there could be a problem when the mode is turned on on a
    >> GUI frame, where '│' can be displayed OK, and then a TTY frame
    >> is created in the same session, where that character cannot be
    >> displayed.  I wonder how to deal with this issue.

    Ergus> There is also the problem that the user could activate
    Ergus> display-fill-column-mode and then change the font.

For both these issues Iʼm tempted to say 'caveat Emacsor'. With
perhaps a note in the manual if weʼre feeling generous :-)

What's the issue with just using '|' (U+7c) unconditionally?

Robert

Re: Fill column indicator functionality

[Ergus]

On Sat, Apr 06, 2019 at 09:49:49AM +0300, Eli Zaretskii wrote:
>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Fri, 05 Apr 2019 23:10:46 +0200
>>
>> I have a patch from some days ago applied here, sorry if this is
>> outdated, but I see something suspicious. After M-x customize-variable
>> display-fill-column-indicator-character :
>>
>>
>> Hide display-fill-column-indicator-character: nil
>>     State : STANDARD. (mismatch)
>>    Character to draw the indicator when ‘display-fill-column-indicator’ is non-n
>>
>>
>> That "nil" and "mismatch" are not right. This is the definition of the
>> variable in xdisp.c:
>>
>>
>>   DEFVAR_LISP ("display-fill-column-indicator-character", Vdisplay_fill_column_indicator_character,
>>     doc: /* Character to draw the indicator when `display-fill-column-indicator' is non-nil.
>> The default is U+2502 but a good alternative is (ascii 124) if
>> the font in fill-column-face does not support Unicode characters.  */);
>>   Vdisplay_fill_column_indicator_character = Qnil;
>>   DEFSYM (Qdisplay_fill_column_indicator_character, "display-fill-column-indicator-character");
>>   Fmake_variable_buffer_local (Qdisplay_fill_column_indicator_character);
>
>Hmm... why do we need those DEFSYMs?  I don't think the Qfoo symbols
>are ever used in C, are they?  Do the problems go away if you remove
>the DEFSYMS?
>
Hi Eli:

I just followed the same schema than the display-line-numbers variables
some lines before. (and many other variables)

What are actually the Qfoo symbols for? I thought they where for make
buffer local variables?

Actually the question is: Why are we not using those?  instead of
 Vdisplay_fill_column_indicator_character?

Maybe these are dumb questions, but now is when the real doubt came out.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sat, 6 Apr 2019 13:06:52 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> >Hmm... why do we need those DEFSYMs?  I don't think the Qfoo symbols
> >are ever used in C, are they?  Do the problems go away if you remove
> >the DEFSYMS?
> >
> Hi Eli:
> 
> I just followed the same schema than the display-line-numbers variables
> some lines before. (and many other variables)

We should only need DEFSYM if we need to reference Qfoo in C code.

> What are actually the Qfoo symbols for? I thought they where for make
> buffer local variables?
> 
> Actually the question is: Why are we not using those?  instead of
>  Vdisplay_fill_column_indicator_character?

The Vfoo is the variable, the Qfoo is its symbol.  You need the latter
if you have to call a function that accepts symbols, like specbind.
It's the same as with foo vs 'foo in Lisp.

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 06 Apr 2019 12:13:30 +0200
> 
> >>>>> On Fri, 5 Apr 2019 23:15:43 +0200, Ergus <spacibba@aol.com> said:
>     >> Btw, there could be a problem when the mode is turned on on a
>     >> GUI frame, where '│' can be displayed OK, and then a TTY frame
>     >> is created in the same session, where that character cannot be
>     >> displayed.  I wonder how to deal with this issue.
> 
>     Ergus> There is also the problem that the user could activate
>     Ergus> display-fill-column-mode and then change the font.
> 
> For both these issues Iʼm tempted to say 'caveat Emacsor'. With
> perhaps a note in the manual if weʼre feeling generous :-)

That's one solution, yes.

> What's the issue with just using '|' (U+7c) unconditionally?

It looks less pretty, at least with my font: the resulting vertical
line is not contiguous.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sat, 06 Apr 2019 09:51:13 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > >After changing the value, you need to click "STATE" and select "Set
> > >for current session".  Did you do that?
> > >
> > 
> > Yes, I did, and there is not change.
> 
> So you are saying that display-fill-column-indicator is nil if you
> eval it with M-:, but the indicator is still being displayed?

I think you should add display-fill-column-indicator (and maybe other
related variables) to the list you see at the end of frame.el.  Please
follow the procedure described in the comment there to find out which
of the new variables need to be added, don't just add them all.

Thanks.

Re: Fill column indicator functionality

[Ergus]

On Sat, Apr 06, 2019 at 04:21:14PM +0300, Eli Zaretskii wrote:
>> Date: Sat, 06 Apr 2019 09:51:13 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> > >After changing the value, you need to click "STATE" and select "Set
>> > >for current session".  Did you do that?
>> > >
>> >
>> > Yes, I did, and there is not change.
>>
>> So you are saying that display-fill-column-indicator is nil if you
>> eval it with M-:, but the indicator is still being displayed?
>
>I think you should add display-fill-column-indicator (and maybe other
>related variables) to the list you see at the end of frame.el.  Please
>follow the procedure described in the comment there to find out which
>of the new variables need to be added, don't just add them all.
>
>Thanks.

Hi:

I just pushed 2 commits that seems to fix (most of) the issues:

In the first one I extended the conditions for the character
selection. It is not perfect for the reasons we have exposed, but in the
mean time it will work for no very fancy conditions until we agree if we
should use | or find a better solution because I don't like that one :(,
it looks too ugly by default.

In the last commit I removed the Qfoo symbols which seems to fix the
customize-variable issue.

I also removed the variables from frame.el because it seems they were
not needed when I followed the procedure.

I am wondering why in display-line-numbers the symbols are needed and
the inclusion in frame.el, but not for display-fill-column-indicator if
they are implemented in a so similar way.

Whats the internal criteria for that? Some code to read?

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sat, 6 Apr 2019 17:20:14 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> In the first one I extended the conditions for the character
> selection. It is not perfect for the reasons we have exposed, but in the
> mean time it will work for no very fancy conditions until we agree if we
> should use | or find a better solution because I don't like that one :(,
> it looks too ugly by default.

I agree.

> In the last commit I removed the Qfoo symbols which seems to fix the
> customize-variable issue.
> 
> I also removed the variables from frame.el because it seems they were
> not needed when I followed the procedure.

Assuming you bound the command to change the variables to a simple
key, like F5, that's fine.  "M-x set-variable", for example, won't do,
because it activates the minibuffer, and that triggers a thorough
redisplay.

> I am wondering why in display-line-numbers the symbols are needed and
> the inclusion in frame.el, but not for display-fill-column-indicator if
> they are implemented in a so similar way.
> 
> Whats the internal criteria for that? Some code to read?

I just followed the procedure described there, AFAIR.

Re: Fill column indicator functionality

[Ergus]

On Sat, Apr 06, 2019 at 07:00:58PM +0300, Eli Zaretskii wrote:
>> Date: Sat, 6 Apr 2019 17:20:14 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> In the first one I extended the conditions for the character
>> selection. It is not perfect for the reasons we have exposed, but in the
>> mean time it will work for no very fancy conditions until we agree if we
>> should use | or find a better solution because I don't like that one :(,
>> it looks too ugly by default.
>
>I agree.
>
>> In the last commit I removed the Qfoo symbols which seems to fix the
>> customize-variable issue.
>>
>> I also removed the variables from frame.el because it seems they were
>> not needed when I followed the procedure.
>
>Assuming you bound the command to change the variables to a simple
>key, like F5, that's fine.  "M-x set-variable", for example, won't do,
>because it activates the minibuffer, and that triggers a thorough
>redisplay.
>

That's right I double check and there was an error in the corrections, I
just fixed.

I am wondering if there is a way to put conditionals there, because the
redisplay needs to be triggered only if one of the variables is already
non-nil and we need to redisplay if we change fill-column only if
display-fill-column-indicator-column is t. Similar thing should happen
for display-line-numbers right?

>> I am wondering why in display-line-numbers the symbols are needed and
>> the inclusion in frame.el, but not for display-fill-column-indicator if
>> they are implemented in a so similar way.
>>
>> Whats the internal criteria for that? Some code to read?
>
>I just followed the procedure described there, AFAIR.
OK.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sat, 6 Apr 2019 20:59:36 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> I am wondering if there is a way to put conditionals there, because the
> redisplay needs to be triggered only if one of the variables is already
> non-nil and we need to redisplay if we change fill-column only if
> display-fill-column-indicator-column is t. Similar thing should happen
> for display-line-numbers right?

I don't see why we should bother.  These variables change only rarely,
so it isn't like they will trigger redisplay frequent enough to be a
problem.

Btw, if you mean you added display-fill-column-indicator-* variables
to the list in frame.el, I don't think I see that.  Did I miss
something?

Re: Fill column indicator functionality

[Ergus]

On Sat, Apr 06, 2019 at 10:07:05PM +0300, Eli Zaretskii wrote:
>> Date: Sat, 6 Apr 2019 20:59:36 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> I am wondering if there is a way to put conditionals there, because the
>> redisplay needs to be triggered only if one of the variables is already
>> non-nil and we need to redisplay if we change fill-column only if
>> display-fill-column-indicator-column is t. Similar thing should happen
>> for display-line-numbers right?
>
>I don't see why we should bother.  These variables change only rarely,
>so it isn't like they will trigger redisplay frequent enough to be a
>problem.
>
>Btw, if you mean you added display-fill-column-indicator-* variables
>to the list in frame.el, I don't think I see that.  Did I miss
>something?

Sorry, I removed and then reinserted, but forgot to push the last commit.

Re: Fill column indicator functionality

[Ergus]

Hi all:

I have been testing all the latest changes with the display-fci-mode and
I have just found that the display-fill-column-indicator variable (and
the others) are not buffer local anymore after the latest changes. So I
cannot enable the mode for some buffers and not for others. 

As in display-line-numbers this works because there are still the
Fmake_variable_buffer_local (Qdisplay_line_numbers); I tested
customize-variable for display-line-numbers variables and it looks like
setting in that way doesn't work as it was happening to
display-fill-column-indicator yesterday.

If I set any of those with set-variable it works. So it is exactly the
same problem I had on yesterday.

So the problem seems to be somewhere else. Any suggestion?

On Sat, Apr 06, 2019 at 10:07:05PM +0300, Eli Zaretskii wrote:
>> Date: Sat, 6 Apr 2019 20:59:36 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> I am wondering if there is a way to put conditionals there, because the
>> redisplay needs to be triggered only if one of the variables is already
>> non-nil and we need to redisplay if we change fill-column only if
>> display-fill-column-indicator-column is t. Similar thing should happen
>> for display-line-numbers right?
>
>I don't see why we should bother.  These variables change only rarely,
>so it isn't like they will trigger redisplay frequent enough to be a
>problem.
>
>Btw, if you mean you added display-fill-column-indicator-* variables
>to the list in frame.el, I don't think I see that.  Did I miss
>something?
>

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sun, 7 Apr 2019 20:19:25 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> I have been testing all the latest changes with the display-fci-mode and
> I have just found that the display-fill-column-indicator variable (and
> the others) are not buffer local anymore after the latest changes. So I
> cannot enable the mode for some buffers and not for others. 
> 
> As in display-line-numbers this works because there are still the
> Fmake_variable_buffer_local (Qdisplay_line_numbers); I tested
> customize-variable for display-line-numbers variables and it looks like
> setting in that way doesn't work as it was happening to
> display-fill-column-indicator yesterday.

Sorry, I don't think I understand what you are saying here.  I see
that the display-fill-column-indicator variables aren't made
buffer-local in xdisp.c; why not?  Would doing that solve the problem?

And what do you mean by "it looks like setting in that way doesn't
work as it was happening to display-fill-column-indicator yesterday"?
What did you try, and what didn't work? and why are you talking about
display-line-numbers and display-fill-column-indicator intermittently?

> If I set any of those with set-variable it works. So it is exactly the
> same problem I had on yesterday.

I thought yesterday's problem was that customize-variable didn't work
at all.

> So the problem seems to be somewhere else. Any suggestion?

What problem are we talking about?  I'm confused.

Re: Fill column indicator functionality

[Ergus]

On Sun, Apr 07, 2019 at 09:31:28PM +0300, Eli Zaretskii wrote:
>> Date: Sun, 7 Apr 2019 20:19:25 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> I have been testing all the latest changes with the display-fci-mode and
>> I have just found that the display-fill-column-indicator variable (and
>> the others) are not buffer local anymore after the latest changes. So I
>> cannot enable the mode for some buffers and not for others.
>>
>> As in display-line-numbers this works because there are still the
>> Fmake_variable_buffer_local (Qdisplay_line_numbers); I tested
>> customize-variable for display-line-numbers variables and it looks like
>> setting in that way doesn't work as it was happening to
>> display-fill-column-indicator yesterday.
>
>Sorry, I don't think I understand what you are saying here.  I see
>that the display-fill-column-indicator variables aren't made
>buffer-local in xdisp.c; why not?  Would doing that solve the problem?
>
>And what do you mean by "it looks like setting in that way doesn't
>work as it was happening to display-fill-column-indicator yesterday"?
>What did you try, and what didn't work? and why are you talking about
>display-line-numbers and display-fill-column-indicator intermittently?
>
>> If I set any of those with set-variable it works. So it is exactly the
>> same problem I had on yesterday.
>
>I thought yesterday's problem was that customize-variable didn't work
>at all.
>
>> So the problem seems to be somewhere else. Any suggestion?
>
>What problem are we talking about?  I'm confused.


Hi Eli:

Try customize-variable RET display-line-numbers-mode RET

And set it for current session. It does nothing, the problem is with
customize-variable. All the rest was fine.

Re: Fill column indicator functionality

[Ergus]

On Sun, Apr 07, 2019 at 09:31:28PM +0300, Eli Zaretskii wrote:
>> Date: Sun, 7 Apr 2019 20:19:25 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> I have been testing all the latest changes with the display-fci-mode and
>> I have just found that the display-fill-column-indicator variable (and
>> the others) are not buffer local anymore after the latest changes. So I
>> cannot enable the mode for some buffers and not for others.
>>
>> As in display-line-numbers this works because there are still the
>> Fmake_variable_buffer_local (Qdisplay_line_numbers); I tested
>> customize-variable for display-line-numbers variables and it looks like
>> setting in that way doesn't work as it was happening to
>> display-fill-column-indicator yesterday.
>
>Sorry, I don't think I understand what you are saying here.  I see
>that the display-fill-column-indicator variables aren't made
>buffer-local in xdisp.c; why not?  Would doing that solve the problem?
>
>And what do you mean by "it looks like setting in that way doesn't
>work as it was happening to display-fill-column-indicator yesterday"?
>What did you try, and what didn't work? and why are you talking about
>display-line-numbers and display-fill-column-indicator intermittently?
>
>> If I set any of those with set-variable it works. So it is exactly the
>> same problem I had on yesterday.
>
>I thought yesterday's problem was that customize-variable didn't work
>at all.
>
>> So the problem seems to be somewhere else. Any suggestion?
>
>What problem are we talking about?  I'm confused.

sorry:

M-x customize-variable RET display-line-numbers

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sun, 7 Apr 2019 20:38:06 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> M-x customize-variable RET display-line-numbers

Works for me as expected.

Re: Fill column indicator functionality

[Ergus]

On Sun, Apr 07, 2019 at 10:02:52PM +0300, Eli Zaretskii wrote:
>> Date: Sun, 7 Apr 2019 20:38:06 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> M-x customize-variable RET display-line-numbers
>
>Works for me as expected.

Well, for me it doesn't work the same way display-fill-column-indicator
didn't on yesterday.

Re: Fill column indicator functionality

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

I send you a pictures that shows how when I open the customize-variable
it shows that Display Line NUmbers is off, but you can see the numbers
enabled.

And another where I changed it to relative, but the values are still
absolute after setting them for current session.



On Sun, Apr 07, 2019 at 10:02:52PM +0300, Eli Zaretskii wrote:
>> Date: Sun, 7 Apr 2019 20:38:06 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> M-x customize-variable RET display-line-numbers
>
>Works for me as expected.
>

[-- Attachment #2: Screenshot_2019-04-07_22-46-31.png --]
[-- Type: image/png, Size: 54668 bytes --]

[-- Attachment #3: Screenshot_2019-04-07_22-49-09.png --]
[-- Type: image/png, Size: 65490 bytes --]

Re: Fill column indicator functionality

[Stefan Monnier]

> I send you a pictures that shows how when I open the customize-variable
> it shows that Display Line NUmbers is off, but you can see the numbers
> enabled.

My guess is that the default value (shown by customize) is different
from the buffer-local value.


        Stefan

Re: Fill column indicator functionality

[Ergus]

On Sun, Apr 07, 2019 at 05:23:46PM -0400, Stefan Monnier wrote:
>> I send you a pictures that shows how when I open the customize-variable
>> it shows that Display Line NUmbers is off, but you can see the numbers
>> enabled.
>
>My guess is that the default value (shown by customize) is different
>from the buffer-local value.
>
>
>        Stefan

Yes, I also think so. But then there shouldn't be the "Set for this
session" option, or something must explain this issue for buffer local
variables in the customize buffer right?

Because I made some changes on yesterday due to someone reported this
behavior as a bug.

Re: Fill column indicator functionality

[Stefan Monnier]

> Yes, I also think so. But then there shouldn't be the "Set for this
> session" option, or something must explain this issue for buffer local
> variables in the customize buffer right?

Customize doesn't know anything about buffer-local, sadly :-(


        Stefan

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sun, 7 Apr 2019 22:05:14 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> On Sun, Apr 07, 2019 at 10:02:52PM +0300, Eli Zaretskii wrote:
> >> Date: Sun, 7 Apr 2019 20:38:06 +0200
> >> From: Ergus <spacibba@aol.com>
> >> Cc: emacs-devel@gnu.org
> >>
> >> M-x customize-variable RET display-line-numbers
> >
> >Works for me as expected.
> 
> Well, for me it doesn't work the same way display-fill-column-indicator
> didn't on yesterday.

Does it work for you on the master branch?

Re: Fill column indicator functionality

[Ergus]

On Mon, Apr 08, 2019 at 05:27:59AM +0300, Eli Zaretskii wrote:
>> Date: Sun, 7 Apr 2019 22:05:14 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> On Sun, Apr 07, 2019 at 10:02:52PM +0300, Eli Zaretskii wrote:
>> >> Date: Sun, 7 Apr 2019 20:38:06 +0200
>> >> From: Ergus <spacibba@aol.com>
>> >> Cc: emacs-devel@gnu.org
>> >>
>> >> M-x customize-variable RET display-line-numbers
>> >
>> >Works for me as expected.
>>
>> Well, for me it doesn't work the same way display-fill-column-indicator
>> didn't on yesterday.
>
>Does it work for you on the master branch?

No, I have exactly the same behavior in the master head and in 26.1
(from my distro).

Actually, after more tests I associate the issue with the global mode
only.

For example, this does not reproduce the issue, but the changes applies
to the "Customize Options" buffer itself only.

emacs -Q

M-x display-line-numbers-mode
M-x customize-variable RET display-line-numbers RET

But this:

emacs -Q

M-x global-display-line-numbers-mode
M-x customize-variable RET display-line-numbers RET

Does reproduce the bug and no changes applies at all.

I think it has to do with what Stefan suggested.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Mon, 8 Apr 2019 10:51:02 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> For example, this does not reproduce the issue, but the changes applies
> to the "Customize Options" buffer itself only.
> 
> emacs -Q
> 
> M-x display-line-numbers-mode
> M-x customize-variable RET display-line-numbers RET
> 
> But this:
> 
> emacs -Q
> 
> M-x global-display-line-numbers-mode
> M-x customize-variable RET display-line-numbers RET
> 
> Does reproduce the bug and no changes applies at all.
> 
> I think it has to do with what Stefan suggested.

Then I think we have nothing to worry about: this is a general issue,
not something specific or new with this new mode.

Re: Fill column indicator functionality

[Ergus]

On Mon, Apr 08, 2019 at 05:57:01PM +0300, Eli Zaretskii wrote:
>> Date: Mon, 8 Apr 2019 10:51:02 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> For example, this does not reproduce the issue, but the changes applies
>> to the "Customize Options" buffer itself only.
>>
>> emacs -Q
>>
>> M-x display-line-numbers-mode
>> M-x customize-variable RET display-line-numbers RET
>>
>> But this:
>>
>> emacs -Q
>>
>> M-x global-display-line-numbers-mode
>> M-x customize-variable RET display-line-numbers RET
>>
>> Does reproduce the bug and no changes applies at all.
>>
>> I think it has to do with what Stefan suggested.
>
>Then I think we have nothing to worry about: this is a general issue,
>not something specific or new with this new mode.

So I will remove the latest commit I added that fixed this, but removed
the buffer local variables.

Re: Fill column indicator functionality

[Ergus]

Hi Eli:

I see some threads about and now I have a question. In case the
fci-branch finally goes into master, should I add it in a 27.? or in a
26.? one. Because the lisp file needs to be updated accordingly.
(Sorry but I don't understand the number sequence we use and when they
end, whats the criteria to make a major or a minor next release?).

BTW, when is planned the next release and it will be a 26.? or a 27.?
one.

Best,
Ergus

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 12 Apr 2019 15:46:33 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> I see some threads about and now I have a question. In case the
> fci-branch finally goes into master, should I add it in a 27.? or in a
> 26.? one. Because the lisp file needs to be updated accordingly.

Emacs 27, definitely.  That's what the master branch develops, while
emacs-26 is the release branch, which is closed to new features.

> (Sorry but I don't understand the number sequence we use and when they
> end, whats the criteria to make a major or a minor next release?).

CONTRIBUTE is supposed to explain that, under "Branches".

> BTW, when is planned the next release

We don't plan releases around here.  Currently, the master branch
still has several features pending/not finished, so Emacs 27.1 will
not enter pretest, let alone be released, before least 6 months from
now, probably a year.

> and it will be a 26.? or a 27.?  one

Emacs 26.3 will be released from the emacs-26 branch if we decide
there are enough bugs in Emacs 26.2 to justify another 26.x release,
or if some critical vulnerability is reported that cannot wait until
27.1.

Re: Fill column indicator functionality

[Ergus]

Hi Eli:

Should we consider to add this functionality already to the master branch??

I have been using it since we implemented it and I haven't have any
issue. Maybe the character to use is still an open discussion, but there
are not new idea. And with the last fixes it works perfectly fine.

So I am waiting for your approve or new
suggestions/comments/corrections. I will need to re-edit most of the
commits messages probably or do a squash to condensate everything in a
single commit... So, at your orders Captain!!.

Best,
Ergus

On Fri, Apr 12, 2019 at 04:54:27PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 12 Apr 2019 15:46:33 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> I see some threads about and now I have a question. In case the
>> fci-branch finally goes into master, should I add it in a 27.? or in a
>> 26.? one. Because the lisp file needs to be updated accordingly.
>
>Emacs 27, definitely.  That's what the master branch develops, while
>emacs-26 is the release branch, which is closed to new features.
>
>> (Sorry but I don't understand the number sequence we use and when they
>> end, whats the criteria to make a major or a minor next release?).
>
>CONTRIBUTE is supposed to explain that, under "Branches".
>
>> BTW, when is planned the next release
>
>We don't plan releases around here.  Currently, the master branch
>still has several features pending/not finished, so Emacs 27.1 will
>not enter pretest, let alone be released, before least 6 months from
>now, probably a year.
>
>> and it will be a 26.? or a 27.?  one
>
>Emacs 26.3 will be released from the emacs-26 branch if we decide
>there are enough bugs in Emacs 26.2 to justify another 26.x release,
>or if some critical vulnerability is reported that cannot wait until
>27.1.
>

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Wed, 1 May 2019 13:08:08 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> Should we consider to add this functionality already to the master branch??

It needs a few final touches, and then it can land.  See my comments
below:

> +initialization tries to set it to U+2502 or '|'.

Please use @samp{|} instead of literal quotes.

> +@item fill-column-face

This face should be indexed, use @vindex for that.

> +Specifies the face used to display the indicator it inherits its
> +default values from shadow and the default face.

These are two sentences, not one.  Please place a period after
"indicator".

> +  Emacs can display an indicator in the @code{fill-column} position
> +using the Display fill column indicator mode 

The mode should be capitalized: "Display Fill Column Indicator mode".

> +---

This should be "+++", to indicate that the manuals have been updated.
"---" means there's no need to document the described feature in the
manuals.

> +There are 2 new buffer local variables and 1 face to customize this
> +mode:
> +
> +*** 'display-fill-column-indicator-column' is the column where the
> +    indicator should be set. It can take positive numerical values for
> +    the column or the special value t. Any other value disables the
> +    indicator. The default value is t.
> +    
> +    When the value is t it means that the variable 'fill-column' will
> +    be used.
> +
> +*** 'display-fill-column-indicator-char' is the character used for the
> +    indicator. This character can be any valid char including unicode
> +    ones if the user's font supports them.
> +    
> +    When the mode is enabled throw the functions
> +    'display-fill-column-indicator-mode' and
> +    'global-display-fill-column-indicator-mode', they check if there
> +    is a value non-nil for this variable, otherwise the initialization
> +    tries to set it to U+2502 or '|'.
> +    
> +*** 'fill-column-face' is the face used to display the indicator it
> +    inherits it default values from shadow and the default faces.

No need to use "***" here.  In fact, I'm not sure we should describe
these new variables in NEWS, just point to the manual instead.

> +;; Copyright (C) 2017-2019 Free Software Foundation, Inc.

This is copy-paste; it should be just 2019.

> +(define-minor-mode display-fill-column-indicator-mode
> +  "Toggle display fill column indicator.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"Toggle display of fill-column indicator.".

> +To change the position of the column displayed by default,
> +customize `display-fill-column-indicator-column' you can change the
> +character for the indicator setting `display-fill-column-indicator-character'."

There are 2 sentences here, not one.

> +;; Definition stolen from display-line-numbers.
> +(defface fill-column-face
> +  '((t :inherit (shadow default)))
> +  "Face for displaying fill column indicator line.
                                                ^^^^
I'd drop the "line" part.  You allude to the shape of the indicator
character, but it doesn't have to look like a line, and using "line"
is confusing here.

> +If you customize the font of this face, make sure it is a
> +monospaced font, otherwise the line's characters will not line
> +up horizontally."

Is this true for the indicator?  I think this comes from the
line-number face, but I'm not sure it is applicable to the fill-column
indicator.

> diff --git a/lisp/ldefs-boot.el b/lisp/ldefs-boot.el
> index cb378ce..45c72ff 100644
> --- a/lisp/ldefs-boot.el
> +++ b/lisp/ldefs-boot.el

You don't need to update ldefs-boot.el, it is done automatically by
Glenn's script.

> +	  /* Corner case for when display-fill-column-indicator-mode
> +	     is active and the extra character should be added in the
> +	     same place than the line */

Here and elsewhere, please use our conventions for writing comments:
they should start with a capital letter and end with a period and 2
spaces before the "*/" comment terminator.

> +	       if (EQ (Vdisplay_fill_column_indicator_column, Qt)
> +	           && FIXNATP (BVAR (current_buffer, fill_column)))
> +	         fill_column_indicator_column =
> +		   XFIXNAT (BVAR (current_buffer, fill_column));
> +	       else if (FIXNATP (Vdisplay_fill_column_indicator_column))
> +		 fill_column_indicator_column =
> +		   XFIXNAT (Vdisplay_fill_column_indicator_column);

There's no 'else' clause here.  What will happen if neither of these
two conditions holds?  What do we want to happen then?

> @@ -20163,11 +20215,12 @@ append_space_for_newline (struct it *it, bool default_face_p)
>  	     set.  */
>  	  if (it->glyph_row->reversed_p
>  	      /* But if the appended newline glyph goes all the way to
> -		 the end of the row, there will be no stretch glyph,
> -		 so leave the box flag set.  */
> +	      the end of the row, there will be no stretch glyph,
> +	      so leave the box flag set.  */

Please don't convert TABs to spaces in C sources.

> +	       if (EQ (Vdisplay_fill_column_indicator_column, Qt)
> +	           && FIXNATP (BVAR (current_buffer, fill_column)))
> +	         fill_column_indicator_column =
> +		   XFIXNAT (BVAR (current_buffer, fill_column));
> +	       else if (FIXNATP (Vdisplay_fill_column_indicator_column))
> +		 fill_column_indicator_column =
> +		   XFIXNAT (Vdisplay_fill_column_indicator_column);

Same here: what if neither of the 2 conditions holds?

> +	          /* Only generate a stretch glysph if there is distance
                                             ^^^^^^
A typo.

> +	          /* Generate the glysph indicator only if
                                  ^^^^^^
And here.  Also, I think you mean "indicator glyph", i.e. transpose
the words.

> +	          /* If there is space after the indicator generate an
                                                          ^
Comma missing there.

> +	             extra empty glysph to restore the face. */
                                 ^^^^^^
Another typo.

I think this problem was only on X?  If so, I suggest to say that in
the comment.

>  #ifdef HAVE_WINDOW_SYSTEM
> +
>        if (it->glyph_row->reversed_p)

IMO, this extra line actually makes the source less readable, not
more.

> +      /* Display fill-column-line if needed.  */

You mean "Display fill-column-line indicator if needed.", yes?

> +	  /* Vdisplay_fill_column_indicator_column accepts the special
> +	     value t to use the default fill-column variable.  */
> +	  if (EQ (Vdisplay_fill_column_indicator_column, Qt)
> +	      && FIXNATP (BVAR (current_buffer, fill_column)))
> +	    fill_column_indicator_column =
> +	      XFIXNAT (BVAR (current_buffer, fill_column)) + it->lnum_pixel_width;
> +	  else if (FIXNATP (Vdisplay_fill_column_indicator_column))
> +	    fill_column_indicator_column =
> +	      XFIXNAT (Vdisplay_fill_column_indicator_column) + it->lnum_pixel_width;

Once again: no 'else'.

> +  /* Names of the face used to display fill column indicator character.  */
        ^^^^^
"Name", in singular.  And I would lose the "character" part, as it
might not be a character, at least in the future.

> +  DEFVAR_LISP ("display-fill-column-indicator-column", Vdisplay_fill_column_indicator_column,
> +    doc: /* Column for indicator when `display-fill-column-indicator' is non-nil.
> +The default value is t which means that the indicator will use the `fill-column' variable.

The last line is too long, please break it into 2.

> +If a numeric value is set, the indicator will be drawn in that column
   ^^^^^^^^^^^^^^^^^^^^^^^^^^
"If a number, ..."

Btw, "number" is not accurate, as it must be an integer, right?  It
cannot be a float.

> +  DEFVAR_LISP ("display-fill-column-indicator-character", Vdisplay_fill_column_indicator_character,
> +    doc: /* Character to draw the indicator when `display-fill-column-indicator' is non-nil.
> +The default is U+2502 but a good alternative is (ascii 124) if
> +the font in fill-column-face does not support Unicode characters.  */);

Please quote fill-column-face `like this', so it will generate a link
in the *Help* buffer.

Finally, there are several places where you have left trailing
whitespace, please remove that.  Also, sometimes you left only 1 space
between sentences, whereas our convention is to leave 2.

Thanks!

Re: Fill column indicator functionality

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 1 May 2019 13:08:08 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>> 
>> +@item fill-column-face
>
> This face should be indexed, use @vindex for that.

[...]

>> +;; Definition stolen from display-line-numbers.
>> +(defface fill-column-face
>> +  '((t :inherit (shadow default)))
>> +  "Face for displaying fill column indicator line.
>                                                 ^^^^
> I'd drop the "line" part.  You allude to the shape of the indicator
> character, but it doesn't have to look like a line, and using "line"
> is confusing here.

I'm not sure how closely this convention is followed in new code, but
FWIW the defface docs under (info "(elisp) Defining Faces") say:

 -- Macro: defface face spec doc [keyword value]...
     This macro declares FACE as a named face whose default face spec is
     given by SPEC.  You should not quote the symbol FACE, and it should
     not end in ‘-face’ (that would be redundant).
     ^^^^^^^^^^^^^^^^^^

Thanks,

-- 
Basil

Re: Fill column indicator functionality

[Basil L. Contovounesios]

Ergus <spacibba@aol.com> writes:

> branch: fill_column_indicator
> commit 780f1efe27a347c7fd92bbbc0b3bc1828749d953
> Author: Jimmy Aguilar Mena <spacibba@aol.com>
> Commit: Jimmy Aguilar Mena <spacibba@aol.com>
>
>     display-fill-column-indicator interface corrections
> ---
>  lisp/cus-start.el                     |  5 +++++
>  lisp/display-fill-column-indicator.el | 13 ++++++-------
>  2 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/lisp/cus-start.el b/lisp/cus-start.el
> index 3f58eac..b935776 100644
> --- a/lisp/cus-start.el
> +++ b/lisp/cus-start.el
> @@ -649,6 +649,11 @@ since it could result in memory overflow and make Emacs crash."
>                                           :value nil))
>                                   "26.1")
>  
> +             (display-fill-column-indicator display-fill-column-indicator
> +                                 (choice
> +                                  (const :tag "Off (nil)" :value nil)
> +                                  (const :tag "On (t)" :value t))
> +                                  "27.1")
>               (display-fill-column-indicator-column display-fill-column-indicator
>                                   integer "27.1")
>               (display-fill-column-indicator-character display-fill-column-indicator

I'm not sure custom :tags should mention nil/t.  Why is :value
needed/useful?  Should this variable be defined as DEFVAR_BOOL for now,
with :type 'boolean?

Thanks,

-- 
Basil

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: Ergus <spacibba@aol.com>,  <emacs-devel@gnu.org>
> Date: Fri, 03 May 2019 15:14:50 +0100
> 
> >> +;; Definition stolen from display-line-numbers.
> >> +(defface fill-column-face
> >> +  '((t :inherit (shadow default)))
> >> +  "Face for displaying fill column indicator line.
> >                                                 ^^^^
> > I'd drop the "line" part.  You allude to the shape of the indicator
> > character, but it doesn't have to look like a line, and using "line"
> > is confusing here.
> 
> I'm not sure how closely this convention is followed in new code, but
> FWIW the defface docs under (info "(elisp) Defining Faces") say:
> 
>  -- Macro: defface face spec doc [keyword value]...
>      This macro declares FACE as a named face whose default face spec is
>      given by SPEC.  You should not quote the symbol FACE, and it should
>      not end in ‘-face’ (that would be redundant).
>      ^^^^^^^^^^^^^^^^^^

If you drop the -face part in this case, you are left with
fill-column, and we already have a variable by that name.  So in this
case following that rule would be detrimental, I'd say.

Also, I think this name follows what fci-mode did.

Re: Fill column indicator functionality

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: Ergus <spacibba@aol.com>,  <emacs-devel@gnu.org>
>> Date: Fri, 03 May 2019 15:14:50 +0100
>> 
>> >> +;; Definition stolen from display-line-numbers.
>> >> +(defface fill-column-face
>> >> +  '((t :inherit (shadow default)))
>> >> +  "Face for displaying fill column indicator line.
>> >                                                 ^^^^
>> > I'd drop the "line" part.  You allude to the shape of the indicator
>> > character, but it doesn't have to look like a line, and using "line"
>> > is confusing here.
>> 
>> I'm not sure how closely this convention is followed in new code, but
>> FWIW the defface docs under (info "(elisp) Defining Faces") say:
>> 
>>  -- Macro: defface face spec doc [keyword value]...
>>      This macro declares FACE as a named face whose default face spec is
>>      given by SPEC.  You should not quote the symbol FACE, and it should
>>      not end in ‘-face’ (that would be redundant).
>>      ^^^^^^^^^^^^^^^^^^
>
> If you drop the -face part in this case, you are left with
> fill-column, and we already have a variable by that name.  So in this
> case following that rule would be detrimental, I'd say.

Well, it could also be called something else,
e.g. fill-column-indicator.  But it's not important.

> Also, I think this name follows what fci-mode did.

FWIW, I don't think fci-mode defines any faces, just user options like
fci-rule-color, fci-rule-width, fci-rule-character-color, etc.

Thanks,

-- 
Basil

Re: Fill column indicator functionality

[Alp Aker]

[-- Attachment #1.1: Type: text/plain, Size: 756 bytes --]

On Wed, May 1, 2019 at 7:09 AM Ergus <spacibba@aol.com> wrote:
>
> Should we consider to add this functionality already to the master
branch??
>
[...]
> So I am waiting for your approve or new suggestions/comments/corrections.

I have an aesthetic suggestion.  In the current implementation the
fill-column char is, by default, always drawn with the background of the
default face, overriding any other background such as region highlighting.
That leads to an effect that I suspect many users will find jarring.  See
the attached screenshot a.png.  You might consider using the same
background for the fill-column char as you do for the preceding stretch
glyph and subsequent fill to end of line.  The attached b.png illustrates
what that would look like.

[-- Attachment #1.2: Type: text/html, Size: 911 bytes --]

[-- Attachment #2: b.png --]
[-- Type: image/png, Size: 63251 bytes --]

[-- Attachment #3: a.png --]
[-- Type: image/png, Size: 62378 bytes --]

Re: Fill column indicator functionality

[Ergus]

I agree, but I added the -face because someone highlighted in another
mail that there was already a symbol called fill-column.

So what should I do then?? Any way there are plenty of symbols ending in
-face... So I thought is was a "relaxed" requirement.

On Fri, May 03, 2019 at 03:14:50PM +0100, Basil L. Contovounesios wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Wed, 1 May 2019 13:08:08 +0200
>>> From: Ergus <spacibba@aol.com>
>>> Cc: emacs-devel@gnu.org
>>>
>>> +@item fill-column-face
>>
>> This face should be indexed, use @vindex for that.
>
>[...]
>
>>> +;; Definition stolen from display-line-numbers.
>>> +(defface fill-column-face
>>> +  '((t :inherit (shadow default)))
>>> +  "Face for displaying fill column indicator line.
>>                                                 ^^^^
>> I'd drop the "line" part.  You allude to the shape of the indicator
>> character, but it doesn't have to look like a line, and using "line"
>> is confusing here.
>
>I'm not sure how closely this convention is followed in new code, but
>FWIW the defface docs under (info "(elisp) Defining Faces") say:
>
> -- Macro: defface face spec doc [keyword value]...
>     This macro declares FACE as a named face whose default face spec is
>     given by SPEC.  You should not quote the symbol FACE, and it should
>     not end in ???-face??? (that would be redundant).
>     ^^^^^^^^^^^^^^^^^^
>
>Thanks,
>
>-- 
>Basil

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: <spacibba@aol.com>,  <emacs-devel@gnu.org>
> Date: Fri, 03 May 2019 16:25:35 +0100
> 
> > If you drop the -face part in this case, you are left with
> > fill-column, and we already have a variable by that name.  So in this
> > case following that rule would be detrimental, I'd say.
> 
> Well, it could also be called something else,
> e.g. fill-column-indicator.  But it's not important.
> 
> > Also, I think this name follows what fci-mode did.
> 
> FWIW, I don't think fci-mode defines any faces, just user options like
> fci-rule-color, fci-rule-width, fci-rule-character-color, etc.

Ah, okay.  then I guess we could indeed go with fill-column-indicator.

Re: Fill column indicator functionality

[Ergus]

Hi I think I fixed everything following your and Basil's suggestions.

>spaces before the "*/" comment terminator.
>
>> +	       if (EQ (Vdisplay_fill_column_indicator_column, Qt)
>> +	           && FIXNATP (BVAR (current_buffer, fill_column)))
>> +	         fill_column_indicator_column =
>> +		   XFIXNAT (BVAR (current_buffer, fill_column));
>> +	       else if (FIXNATP (Vdisplay_fill_column_indicator_column))
>> +		 fill_column_indicator_column =
>> +		   XFIXNAT (Vdisplay_fill_column_indicator_column);
>
>There's no 'else' clause here.  What will happen if neither of these
>two conditions holds?  What do we want to happen then?
>
The variable is initialized to a right value that will no produce
indicator, so I don't actually need the else. But any way I made a small
change I like more.

>Please quote fill-column-face `like this', so it will generate a link
>in the *Help* buffer.
>
>Finally, there are several places where you have left trailing
>whitespace, please remove that.  Also, sometimes you left only 1 space
>between sentences, whereas our convention is to leave 2.
>
>Thanks!

Thanks to you!

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 3 May 2019 19:49:35 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> >> +	       if (EQ (Vdisplay_fill_column_indicator_column, Qt)
> >> +	           && FIXNATP (BVAR (current_buffer, fill_column)))
> >> +	         fill_column_indicator_column =
> >> +		   XFIXNAT (BVAR (current_buffer, fill_column));
> >> +	       else if (FIXNATP (Vdisplay_fill_column_indicator_column))
> >> +		 fill_column_indicator_column =
> >> +		   XFIXNAT (Vdisplay_fill_column_indicator_column);
> >
> >There's no 'else' clause here.  What will happen if neither of these
> >two conditions holds?  What do we want to happen then?
> >
> The variable is initialized to a right value that will no produce
> indicator, so I don't actually need the else. But any way I made a small
> change I like more.

In general, conditions that "cannot happen" should call emacs_abort.
That variable can be set by users to any value, including values you
don't expect.  If the code survives that, then fine; otherwise, the
prudent thing is to disable the feature or abort.

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 3 May 2019 19:49:35 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> Hi I think I fixed everything following your and Basil's suggestions.

Almost.  I spotted at least one occurrence of each of the following:

  . trailing whitespace
  . only one space between sentences in documentation and comments
  . C comment that doesn't end in a period and 2 spaces

Once you fix these, please feel free to merge to master.

Thanks.

Re: Fill column indicator functionality

[Ergus]

Hi Eli:

I was looking the Alp's mail and he is right. Is there a simple way to
fix the background issue when there is selection???

On Fri, May 03, 2019 at 09:39:41PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 3 May 2019 19:49:35 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> Hi I think I fixed everything following your and Basil's suggestions.
>
>Almost.  I spotted at least one occurrence of each of the following:
>
>  . trailing whitespace
>  . only one space between sentences in documentation and comments
>  . C comment that doesn't end in a period and 2 spaces
>
>Once you fix these, please feel free to merge to master.
>
>Thanks.
>

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Fri, 3 May 2019 23:05:08 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> I was looking the Alp's mail and he is right. Is there a simple way to
> fix the background issue when there is selection???

I'm not sure I understand what we want to happen if the region crosses
the indicator.  The 'region' face by default specifies only the
background, but that's just the default.  It could specify any other
attributes of a face, including the foreground color, the font, the
size, the slant, you name it.  So what do we want to do with that,
exactly?  We need a clear understanding of what is being proposed
before we code it.

Re: Fill column indicator functionality

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

It looks like we need only to keep the background colour also for the indicator. It could be by temporally changing the indicator face background or something like that. or adding temporally all the other properties to the region face.

I don't know if there is an easy way to do so and if it worth the effort.

On May 4, 2019 8:54:10 AM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 3 May 2019 23:05:08 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>> 
>> I was looking the Alp's mail and he is right. Is there a simple way
>to
>> fix the background issue when there is selection???
>
>I'm not sure I understand what we want to happen if the region crosses
>the indicator.  The 'region' face by default specifies only the
>background, but that's just the default.  It could specify any other
>attributes of a face, including the foreground color, the font, the
>size, the slant, you name it.  So what do we want to do with that,
>exactly?  We need a clear understanding of what is being proposed
>before we code it.

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

[-- Attachment #2: Type: text/html, Size: 1560 bytes --]

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sat, 04 May 2019 11:37:13 +0200
> From: Ergus <spacibba@aol.com>
> 
> It looks like we need only to keep the background colour also for the indicator.

Are you sure that's all?  And that some users won't want the indicator
face's background to prevail?

> I don't know if there is an easy way to do so and if it worth the effort.

Given a face_id, you can get the face struct with FACE_FROM_ID.  The
face struct has a member named 'lface', which is a vector of the
face's Lisp attributes.  Each attribute in the vector has a known
index.  So doing something like this (untested) should change the
background color of the indicator as requested:

  int region_face_id = lookup_named_face (NULL, it->f, Qregion, false);
  struct face *region_face = FACE_FROM_ID (it->f, region_face_id);
  Lisp_Object bg_color = region_face->lface[LFACE_BACKGROUND_INDEX];
  face->lface[LFACE_BACKGROUND_INDEX] =
    STRINGP (bg_color) : bg_color : Qunspecified);

assuming that 'face' used in the ASET line is the face of the
indicator, as you compute it in your branch.

Re: Fill column indicator functionality

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> It looks like we need only to keep the background colour also for the
>> indicator.
>
> Are you sure that's all?  And that some users won't want the indicator
> face's background to prevail?

This feature is about a vertical line, not a vertical line plus some
colored space around it. Just because the line is emulated by a sequence
of characters does not mean that we must provide char-related
customizations beyond the strictly necessary (i.e. the char used to draw
the line).

Indeed, the background effect when there is an active region is a bit
jarring and it would be nice to fix it, but IMHO it is not a
show-stopper so if there is no easy fix, leave it as it is.

Re: Fill column indicator functionality

[Alp Aker]

[-- Attachment #1.1: Type: text/plain, Size: 2491 bytes --]

>> It looks like we need only to keep the background colour also for the
>> indicator.
>
> Are you sure that's all?  And that some users won't want the indicator
> face's background to prevail?

User customization could be accommodated by something like the below
(naive) patch.  We define fill-column-indicator face to have unspecified
background; when displaying the indicator we merge the indicator face into
the current it->face_id (the same face used for the stretch glyph preceding
the indicator).

This has two advantages: (1) By default, we display the indicator using the
existing background, but the user can still override by explicitly setting
the background attribute of the indicator face.  (2) This handles the
general case of a non-default background, not just region highlighting.
(See the attached screenshot for an example of the issue not involving
region highlighting.)

diff --git a/src/xdisp.c b/src/xdisp.c
index 1782748144..07c5ee0a1c 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -20494,7 +20494,7 @@ extend_face_to_end_of_line (struct it *it)
                        XFIXNAT (Vdisplay_fill_column_indicator_character);
                      it->face_id =
                        merge_faces (it->w, Qfill_column_indicator,
-                                    0, DEFAULT_FACE_ID);
+                                    0, saved_face_id);
                      PRODUCE_GLYPHS (it);
                    }

@@ -20658,7 +20658,7 @@ extend_face_to_end_of_line (struct it *it)
                {
                  const int saved_face = it->face_id;
                  it->face_id =
-                   merge_faces (it->w, Qfill_column_indicator, 0,
DEFAULT_FACE_ID);
+                   merge_faces (it->w, Qfill_column_indicator, 0,
saved_face);
                  it->c = it->char_to_display =
                    XFIXNAT (Vdisplay_fill_column_indicator_character);
                  PRODUCE_GLYPHS (it);
diff --git a/lisp/faces.el b/lisp/faces.el
index b933279064..207b627f25 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2502,7 +2502,9 @@ line-number-current-line

 ;; Definition stolen from display-line-numbers.
 (defface fill-column-indicator
-  '((t :inherit (shadow default)))
+  '((t :inherit shadow :weight normal :slant normal
+       :underline nil :overline nil :strike-through nil
+       :box nil :invert-video nil :stipple nil))
   "Face for displaying fill column indicator.
 This face is used when `display-fill-column-indicator-mode' is
 non-nil."

[-- Attachment #1.2: Type: text/html, Size: 3385 bytes --]

[-- Attachment #2: screenshot.png --]
[-- Type: image/png, Size: 83841 bytes --]

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Alp Aker <alptekin.aker@gmail.com>
> Date: Sat, 4 May 2019 11:44:11 -0400
> Cc: Emacs devel <emacs-devel@gnu.org>
> 
> User customization could be accommodated by something like the below (naive) patch.  We define
> fill-column-indicator face to have unspecified background; when displaying the indicator we merge the
> indicator face into the current it->face_id (the same face used for the stretch glyph preceding the indicator).

What about the case there's no stretch, i.e. the indicator directly
follows the last character of the line?

Re: Fill column indicator functionality

[Eli Zaretskii]

> Date: Sat, 04 May 2019 18:59:37 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> What about the case there's no stretch, i.e. the indicator directly
> follows the last character of the line?

More generally, I think the change you propose will have the indicator
merge the attributes of any face of the last character, not just when
its the region face.  Maybe that is what is wanted, I don't know.

Re: Fill column indicator functionality

[Alp Aker]

[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]

> > User customization could be accommodated by something like the below
(naive) patch.  We define
> > fill-column-indicator face to have unspecified background; when
displaying the indicator we merge the
> > indicator face into the current it->face_id (the same face used for the
stretch glyph preceding the indicator).
>
> What about the case there's no stretch, i.e. the indicator directly
> follows the last character of the line?

Apologies for my poor phrasing, but I think you might misunderstand the
intent.  I meant that we use the background that is in effect before we
draw anything related to the indicator, not that we take the face *from*
the stretch glyph.

I did miss that the indicator is also drawn in append_space_for_newline.
Revised patch below.

diff --git a/lisp/faces.el b/lisp/faces.el
index b933279064..207b627f25 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2502,7 +2502,9 @@ line-number-current-line

 ;; Definition stolen from display-line-numbers.
 (defface fill-column-indicator
-  '((t :inherit (shadow default)))
+  '((t :inherit shadow :weight normal :slant normal
+       :underline nil :overline nil :strike-through nil
+       :box nil :invert-video nil :stipple nil))
   "Face for displaying fill column indicator.
 This face is used when `display-fill-column-indicator-mode' is
 non-nil."
diff --git a/src/xdisp.c b/src/xdisp.c
index 1782748144..61ea050b4a 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -20201,7 +20201,7 @@ append_space_for_newline (struct it *it, bool
default_face_p)
       XFIXNAT (Vdisplay_fill_column_indicator_character);
             it->face_id =
       merge_faces (it->w, Qfill_column_indicator,
-                   0, DEFAULT_FACE_ID);
+                   0, saved_face_id);
             face = FACE_FROM_ID(it->f, it->face_id);
             goto produce_glyphs;
           }
@@ -20494,7 +20494,7 @@ extend_face_to_end_of_line (struct it *it)
                  XFIXNAT (Vdisplay_fill_column_indicator_character);
                it->face_id =
                  merge_faces (it->w, Qfill_column_indicator,
-                              0, DEFAULT_FACE_ID);
+                                    0, saved_face_id);
                PRODUCE_GLYPHS (it);
              }

@@ -20658,7 +20658,7 @@ extend_face_to_end_of_line (struct it *it)
          {
    const int saved_face = it->face_id;
    it->face_id =
-     merge_faces (it->w, Qfill_column_indicator, 0, DEFAULT_FACE_ID);
+     merge_faces (it->w, Qfill_column_indicator, 0, saved_face);
    it->c = it->char_to_display =
      XFIXNAT (Vdisplay_fill_column_indicator_character);
    PRODUCE_GLYPHS (it);

[-- Attachment #2: Type: text/html, Size: 4344 bytes --]

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Alp Aker <alptekin.aker@gmail.com>
> Date: Sat, 4 May 2019 12:32:51 -0400
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
> 	Emacs devel <emacs-devel@gnu.org>
> 
> Apologies for my poor phrasing, but I think you might misunderstand the intent.  I meant that we use the
> background that is in effect before we draw anything related to the indicator, not that we take the face *from*
> the stretch glyph.  

That would mean the indicator will inherit the background color of any
face of the last character on the line.  Is that the intent, and what
users will want?

Re: Fill column indicator functionality

[Alp Aker]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

> That would mean the indicator will inherit the background color of any
> face of the last character on the line.  Is that the intent, and what
> users will want?

That was the behavior of fci-mode, and I never received a request for
different
behavior.

Please note that that's already what this implementation does with the
stretch glyph.  If you think
that behavior is wrong, then the treatment of the stretch glyph should be
changed as well.

[-- Attachment #2: Type: text/html, Size: 577 bytes --]

Re: Fill column indicator functionality

[Eli Zaretskii]

> From: Alp Aker <alptekin.aker@gmail.com>
> Date: Sat, 4 May 2019 12:38:44 -0400
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 
> 	Emacs devel <emacs-devel@gnu.org>
> 
> Please note that that's already what this implementation does with the stretch glyph.  If you think 
> that behavior is wrong, then the treatment of the stretch glyph should be changed as well.

The stretch glyph was there before the indicator, but the indicator is
a new entity.  I have no idea what the users will want, I'm just
pointing out the implications.  This sub-thread started from the use
case of the region, but the proposed solution will change the face in
many other use cases.  If that's what the users will want, fine.

Re: Fill column indicator functionality

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

I tried a similar approach but I didn't finish it yet. The direct vector modification didn't work for me ... Probably because the indicator face is always reset after setting the indicator and I think the real screen update is made after the matrix generation. (If I understood right how the display engine works)

So with this approach the merge really creates a new face dynamically if needed.

Any way if that approach finally works for the general case I can fix also the other case. I will try it tomorrow because today I don't have time.

Thanks Alp specially for the Lisp code :-).

On May 4, 2019 5:59:37 PM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Alp Aker <alptekin.aker@gmail.com>
>> Date: Sat, 4 May 2019 11:44:11 -0400
>> Cc: Emacs devel <emacs-devel@gnu.org>
>> 
>> User customization could be accommodated by something like the below
>(naive) patch.  We define
>> fill-column-indicator face to have unspecified background; when
>displaying the indicator we merge the
>> indicator face into the current it->face_id (the same face used for
>the stretch glyph preceding the indicator).
>
>What about the case there's no stretch, i.e. the indicator directly
>follows the last character of the line?

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

[-- Attachment #2: Type: text/html, Size: 1741 bytes --]

Re: Fill column indicator functionality

[Keith David Bershatsky]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

I understand that the primary goals are lightweight and speed, and I fully appreciate those goals.

I see that the current draft only deals with glyph rows ending _prior_ to the fill-column, and then an extra glyph is added subsequent thereto for the purposes of creating a visible fill column indicator.

I would suggest devising a mechanism that can intersect characters (at any given X coordinate) for glyph rows that extend beyond the fill-column, including, variable pitch and mono-spaced fonts.  Attached is a screenshot of what this would look like in Emacs.

Admittedly, the code used to create the visible fill column indicator in the screenshot (capable of intersecting characters at any given X) is anything but lightweight _and_ it is only for GUI versions of Emacs (NS/W32/X11).  It is, however, pretty darn quick....

Perhaps there is an overlay that can be used that is capable of intersecting characters, or a thin vertical window spanning the window-body-height that is one pixel wide; e.g., all three GUI platforms can create a vertical window as thin or thick as desired (such as a vertical scroll bar).  There are platform options to repaint or suppress repainting when removing windows ....  Emacs already has the ability to redraw the glyphs that fall within a given rectangle using the w->current_matrix after update_window has already done its thing ....

In case anyone is interested in the code used to generate the screenshot below, the latest proof concept patch for feature requests 17684 / 22873 is now at version 19.002:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22873#134


[-- Attachment #2: 17684_22873__19_002.png --]
[-- Type: application/png, Size: 404651 bytes --]

Re: Fill column indicator functionality

[Ergus]

Hi:

I added the Alp's changes and some minor fixes and it works fine. I
tried something similar before but it didn't work fine because I
didn't have the right Lisp code for the face.

Thanks Alp.

On Sat, May 04, 2019 at 07:42:31PM +0300, Eli Zaretskii wrote:
>> From: Alp Aker <alptekin.aker@gmail.com>
>> Date: Sat, 4 May 2019 12:38:44 -0400
>> Cc: ?scar Fuentes <ofv@wanadoo.es>,
>> 	Emacs devel <emacs-devel@gnu.org>
>>
>> Please note that that's already what this implementation does with the stretch glyph.  If you think
>> that behavior is wrong, then the treatment of the stretch glyph should be changed as well.
>
>The stretch glyph was there before the indicator, but the indicator is
>a new entity.  I have no idea what the users will want, I'm just
>pointing out the implications.  This sub-thread started from the use
>case of the region, but the proposed solution will change the face in
>many other use cases.  If that's what the users will want, fine.
>