emacs-devel
[Top][All Lists]
Advanced

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

Re: Fill column indicator functionality


From: Ergus
Subject: Re: Fill column indicator functionality
Date: Mon, 11 Mar 2019 11:48:14 +0100
User-agent: NeoMutt/20180716

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




reply via email to

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