bug#37755: Logic in init_fringe_bitmap should be moved to backends (maybe rif->define_fringe_bitmap)

[Carlos Pita <carlosjosepita@gmail.com>]

Hi Eli,

thank you for the review.

>It looks like you removed
> the call to init_fringe_bitmap during dumping, and left its equivalent
> only in define-fringe-bitmap, is that right? >

> What did I miss?

The call to gui_init_fringe I guess. Also, notice that
define_fringe_bitmap is quite different than Fdefine_fringe_bitmap.

I suggest you take a look at the modified pseudo code I posted quite a
few message above.

> Emacs needs to have the standard fringe
> bitmaps (for line truncation, continuation, etc.) be defined even
> without a call to define-fringe-bitmap.

This is indeed the case after applying the patch. Some bit shuffling
has been postponed from init_fringe_once to gui_init_fringe, but
that's all.

Now, regarding the dumping stuff you mention, TBH I'm completely
ignorant. So maybe this innocent looking delay of bit shuffling could
have some effect, I don't now, but it's a very different thing from
not initializing standard bitmaps until define-fringe-bitmap is first
called from elisp world.

Besides, whatever is missing after the C static initialization part is
just this *platform dependent* bit shuffling, which I seriously doubt
emacs could make sense of without the appropriate rif at hand, so
quite late in the initialization sequence. I even suggested to avoid
this destructive manipulation of platform independent bitmaps from the
part of the rifs, although I've only followed my suggestion in the
case of cairo, which was quite natural and convenient.

Best regards
--
Carlos