GNU bug report logs - #59243
28.2.50; Larger Fringe Bitmaps

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 59243 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: bug#59243: 28.2.50; Larger Fringe Bitmaps
Date: Sun, 13 Nov 2022 15:48:54 +0200

> Date: Sun, 13 Nov 2022 14:08:06 +0100
> Cc: 59243 <at> debbugs.gnu.org, dgutov <at> yandex.ru
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> 
> On 11/13/22 12:47, Eli Zaretskii wrote:
> > Thanks, but is the intent of bigger-fringe.el to have the user load it
> > manually?  If so, this is sub-optimal: Emacs should switch to larger
> > fringe bitmaps automatically based on the screen DPI, or perhaps scale
> > them.
> 
> My idea here would be to just replace the existing bitmaps with the ones
> proposed in bigger-fringe.el. They have the same width, but are a little
> bit higher.

They seem too large to me, but I wonder what do others think.

In any case, if we accept the bigger defaults, the built-in bitmaps in
fringe.c should be updated.

> Another alternative could be to provide an alternative larger fringe
> bitmap set which is used at larger resolution, if the
> left/right-fringe-width is larger than 8. Would you prefer that?

Yes, but the problem is how to do that automatically.  I think people
have tried in the past but bumped into difficulties.

> If we indeed want to go the route to auto scale the bitmaps, then I
> would go the route via characters or via svg, since scaling the bitmaps
> will probably not give great results in contrast to hand-crafted bitmaps.

Probably.  Indeed, supporting SVG icons on the fringes would be a
useful feature.

Previous Next

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