[Top][All Lists]

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

Re: [Emacs-diffs] master cd06d17: Fix bug with face-id after restoring f

From: Daniel Colascione
Subject: Re: [Emacs-diffs] master cd06d17: Fix bug with face-id after restoring from pdump
Date: Mon, 28 Jan 2019 11:37:07 -0800
User-agent: SquirrelMail/1.4.23 [SVN]

>> From: Daniel Colascione <address@hidden>
>> Date: Mon, 28 Jan 2019 08:05:13 -0800
>> On 1/28/19 7:25 AM, Eli Zaretskii wrote:
>> > branch: master
>> > commit cd06d173a602bf0aa8a227ff1626dc70013fe480
>> > Author: Eli Zaretskii <address@hidden>
>> > Commit: Eli Zaretskii <address@hidden>
>> >
>> >      Fix bug with face-id after restoring from pdump
>> I was going to fix this problem by just turning lface_id_to_name into a
>> normal Lisp vector and using its size as the next face ID. Why use this
>> more complicated approach?
> Based on previous discussion regarding frames and faces, I was under
> the impression that you prefer moving stuff to the startup of emacs.
> I'm not wed to my solution, feel free to change if you think it's
> better.

The default approach to pretty much anything should be to use the first
entry in this implementation strategy that will work for a particular

1) Write it in Lisp
2) Write it in C using Lisp data structures
3) Use custom data structures in C, but allocated from the Lisp heap
4) malloc some random stuff for a pure-C approach

Right now, the face stuff is #3, but I think we could move it to #2 using
the approach in my previous message (just using an ordinary staticprod
Lisp_Object instead of a Lisp_Object* with a size field). Approaches #3
and #4 need special code for pdumper to work, but #1 and #2 Just Work, and
to the greatest extent possible, we should use #1 or #2 for new feature
work too. It'll reduce the total amount of code we need.

reply via email to

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