Re: Question about display engine

[Ergus <spacibba@aol.com>]

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 <spacibba@aol.com>
>> Cc: rudalics@gmx.at, emacs-devel@gnu.org
>>
>> >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.