Re: Fill column indicator functionality

[Ergus <spacibba@aol.com>]

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.
>