[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fill column indicator functionality

From: Eli Zaretskii
Subject: Re: Fill column indicator functionality
Date: Sat, 09 Mar 2019 16:10:11 +0200

> Date: Sat, 9 Mar 2019 14:22:09 +0100
> From: Ergus <address@hidden>
> Cc: address@hidden
> >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)
>    && !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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]