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

Previous Next

Full log

Message #31 received at 37755 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Carlos Pita <carlosjosepita <at> gmail.com>
Cc: 37755 <at> debbugs.gnu.org
Subject: Re: bug#37755: Logic in init_fringe_bitmap should be moved to
 backends (maybe rif->define_fringe_bitmap)
Date: Sun, 20 Oct 2019 19:07:11 +0300

> From: Carlos Pita <carlosjosepita <at> gmail.com>
> Date: Sun, 20 Oct 2019 12:47:13 -0300
> Cc: 37755 <at> debbugs.gnu.org
> 
> > What did I miss?
> 
> The call to gui_init_fringe I guess.

I don't see that call in the patch, nor any changes in gui_init_fringe
that would modify its current effect.

If you mean the existing calls, then they are only made at run time,
which would mean Emacs is dumped without the standard bitmaps?  Why is
that?

> Also, notice that define_fringe_bitmap is quite different than
> Fdefine_fringe_bitmap.

Sure, but I said define-fringe-bitmap, which is the Lisp name of
Fdefine_fringe_bitmap.

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

I will, but I'd like to see the full patch as well.

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

If RIF is the problem, we could make each terminal backend do this
initialization unconditionally at dump time.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.