Re: Question about display engine

[Ergus]

Hi Eli:

Could you answer please the questions about the modifications in other
functions (face_at_string and so on)?

And could you tell me which are the faces that are supposed to be
:extend t by default.

I made a couple of changes in the interface to avoid passing the values
by reference. And other small fixed in the branch. Please give a look
and tell me what do you think.

It will be nice if you could tell me where in the manual I am supposed
to documents this as this actually enables 2 different functionalities:

1) Extend a face.
2) Change the region looking (whole screen width or "fixed to text" as a
side effect).

And fixes the issues with fill-column-indicator in org and the other
issue that martin indicated.

I will push tomorrow a fix for the extra space in term mode.

So after that; your comments and the documentations I think I will
rename the branch to a feature one in order to suggest people to test it
your recommended two weeks.

Is it fine?


On Tue, Sep 10, 2019 at 05:27:39AM +0300, Eli Zaretskii wrote:
> > Date: Mon, 9 Sep 2019 21:29:34 +0200
> > From: Ergus <address@hidden>
> > Cc: address@hidden, address@hidden
> >
> > >I don't think I agree.  Given the complexity of the face-related
> > >functionalities -- face remapping, the need to recompute all the faces
> > >when some basic face changes, the various sources of face-related
> > >information for each buffer/string position, etc. -- I find the design
> > >and implementation of face code quite elegant and easy to understand,
> > >maintain and change.
> > >
> > I am talking about efficiency.
>
> Efficiency is secondary to clean design and correct implementation.
>
> > It is just not standard. If there is no difference why are there
> > different methods to select with if/else?
>
> History, I guess.
>
> > To add one field to the faces it required many modifications.
>
> That isn't a problem in my eyes.
>
> > But then why when the GC fails the lagging is so intense? I
> > thought that the main part of the display engine related with GC was the
> > faces part.
>
> No, faces code cannot GC.  What causes GC is the calls to Lisp, which
> is JIT font-lock and other Lisp hooks.
>
> > >Which interfaces would you like to unify?  I don't think I understand.
> > >
> > Most of the code conditioned with: if (FRAME_WINDOW_P (f)) could be
> > simplified. But I understand that this could be a lot of work and I
> > don't know enough about this.
>
> This work is being done, and most of it has been done already.  Some
> display features are only possible on GUI frames (multiple fonts, for
> example), so such conditions are necessary, at least to some extent.