all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Carlos Pita <carlosjosepita@gmail.com>
Cc: 37755@debbugs.gnu.org
Subject: 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	[thread overview]
Message-ID: <83y2xf4d00.fsf@gnu.org> (raw)
In-Reply-To: <CAELgYhe6ukckXsqZrmu2Y3Ckg0=vZPy_SFiK5cMmwfUix-Ztng@mail.gmail.com> (message from Carlos Pita on Sun, 20 Oct 2019 12:47:13 -0300)

> From: Carlos Pita <carlosjosepita@gmail.com>
> Date: Sun, 20 Oct 2019 12:47:13 -0300
> Cc: 37755@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.





  reply	other threads:[~2019-10-20 16:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-15  2:30 bug#37755: Logic in init_fringe_bitmap should be moved to backends (maybe rif->define_fringe_bitmap) Carlos Pita
2019-10-15  9:33 ` Eli Zaretskii
2019-10-15 19:04   ` Carlos Pita
2019-10-15 19:45     ` Carlos Pita
2019-10-16 20:18       ` Carlos Pita
2019-10-16 22:07         ` Carlos Pita
2019-10-20 12:21           ` Eli Zaretskii
2019-10-20 15:47             ` Carlos Pita
2019-10-20 16:07               ` Eli Zaretskii [this message]
2019-10-20 16:32                 ` Carlos Pita
2019-10-26 10:39                   ` Eli Zaretskii
2019-10-26 15:46                     ` Carlos Pita
2019-10-26 16:03                       ` Eli Zaretskii
2019-10-26 16:11                         ` Carlos Pita
2019-10-27 14:47                         ` Carlos Pita

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83y2xf4d00.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=37755@debbugs.gnu.org \
    --cc=carlosjosepita@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.