Bigger fringe bitmaps

Bigger fringe bitmaps

[Yuri D'Elia]

I recently switched to a higher-resolution screen to basque in all the
hidpi glory.

And all is good. Pretty darn amazing for text rendering, in fact.

Except for the fringe.

Even at 16x16, these bitmaps are now indistinguishable from specks of
dust. At least on lucid the bitmaps do not get upscaled by setting a
larger fringe size.

I suspect upscaling with nearest-neighbor would be a possibility for the
moment, but it's the API surrounding the fixed bitmap sizes that doesn't
look future-proof to me.

I didn't think much of it at first, but it's while debugging with `gud'
that I'm really struggling and realizing how useful the fringe is.

Shouldn't we allow the fringe to be a single character instead of being
a bitmap? With it's own family on graphical displays?

Using a font for the fringe would allow character displays to
potentially show something useful by either using basic ascii symbols
like "-+" or using stuff from the drawing block.

On graphical displays we could use a separated dedicated family.
Font-awesome? **gasp**

Re: Bigger fringe bitmaps

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Date: Wed, 16 Mar 2022 18:57:30 +0100
> 
> I recently switched to a higher-resolution screen to basque in all the
> hidpi glory.
> 
> And all is good. Pretty darn amazing for text rendering, in fact.
> 
> Except for the fringe.
> 
> Even at 16x16, these bitmaps are now indistinguishable from specks of
> dust. At least on lucid the bitmaps do not get upscaled by setting a
> larger fringe size.
> 
> I suspect upscaling with nearest-neighbor would be a possibility for the
> moment, but it's the API surrounding the fixed bitmap sizes that doesn't
> look future-proof to me.
> 
> I didn't think much of it at first, but it's while debugging with `gud'
> that I'm really struggling and realizing how useful the fringe is.
> 
> Shouldn't we allow the fringe to be a single character instead of being
> a bitmap? With it's own family on graphical displays?

It could be a separate feature, but I don't think it should be the
solution for the problem you describe (which is a known problem).  We
should be able to produce a decent display of fringe bitmaps on hidpi
terminals.

Re: Bigger fringe bitmaps

[Po Lu]

Yuri D'Elia <wavexx@thregr.org> writes:

> I recently switched to a higher-resolution screen to basque in all the
> hidpi glory.
>
> And all is good. Pretty darn amazing for text rendering, in fact.
>
> Except for the fringe.
>
> Even at 16x16, these bitmaps are now indistinguishable from specks of
> dust. At least on lucid the bitmaps do not get upscaled by setting a
> larger fringe size.
>
> I suspect upscaling with nearest-neighbor would be a possibility for the
> moment, but it's the API surrounding the fixed bitmap sizes that doesn't
> look future-proof to me.

It should be reasonably future-proof, since we can always add
higher-resolution fringe bitmaps later.

Scaling of display elements (such as face boxes, tool-bar margins and
bitmaps, and fringes) is something I'm working on, but progress is
limited since I don't have any HiDPI hardware to test on.

Re: Bigger fringe bitmaps

[Yuri D'Elia]

On Thu, Mar 17 2022, Po Lu wrote:
>> I suspect upscaling with nearest-neighbor would be a possibility for the
>> moment, but it's the API surrounding the fixed bitmap sizes that doesn't
>> look future-proof to me.
>
> It should be reasonably future-proof, since we can always add
> higher-resolution fringe bitmaps later.
>
> Scaling of display elements (such as face boxes, tool-bar margins and
> bitmaps, and fringes) is something I'm working on, but progress is
> limited since I don't have any HiDPI hardware to test on.

No comment on the idea of potentially using characters in the fringe?

I find the idea appealing somehow, even ignoring hidpi issues, simply
because "it's just more text".

I like the idea of using 🢱 (or ⤶⤷) for wrapped text, 🮗 as a
end-of-buffer, and so on. Easily scaled, and nicely antialiased.

Especially the fact that this would potentially mean an usable fringe
mode on character displays that can be toggled, so that you don't need
to provide an alternate signaling mechanism if you rely on the fringe to
show makers (like gud).

Just to throw ideas on the ground, what if we accepted 3 alternatives
when setting a fringe symbol:

- a bitmap
- a character symbol for character displays (where the font family has
  to be the same throughout the display and thus can be more limited in
  choice)
- a character for graphical displays (where the fringe face can be set
  to a different family entirely)

Re: Bigger fringe bitmaps

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Date: Thu, 17 Mar 2022 08:43:44 +0100
> 
> No comment on the idea of potentially using characters in the fringe?

I did comment on that.  To repeat: it could be a useful new feature,
but I don't think it should be _the_ solution for showing stuff on the
fringes on hidpi terminals; we should be able to produce legible
display of the bitmaps on those terminals.

> I find the idea appealing somehow, even ignoring hidpi issues, simply
> because "it's just more text".

Yes, it could be a good feature.  Patches are welcome.

> I like the idea of using 🢱 (or ⤶⤷) for wrapped text, 🮗 as a
> end-of-buffer, and so on. Easily scaled, and nicely antialiased.

You disregard the issue of which fonts support what characters in the
relevant Unicode blocks.  E.g., on my system, 🢱 is shown as "tofu", as
I evidently don't have a font for that codepoint.  Solving this in the
limited fringe screen estate will need some non-trivial ideas.  And
what about 'half-width' or 'minimal' fringe-styles?

I don't want to discourage someone who wants to work on this new
feature, but my point is that adding it will need some non-trivial
design and implementation decisions, and that's even before we talk
about the details in internals (fringe bitmaps are a special kind of
image in the Emacs display code).  Like I said, patches are welcome,
but let's not pretend that adding this is a trivial job.

> Especially the fact that this would potentially mean an usable fringe
> mode on character displays that can be toggled, so that you don't need
> to provide an alternate signaling mechanism if you rely on the fringe to
> show makers (like gud).

I don't think I follow.  Emacs doesn't support fringes on TTY
displays, so what do you mean by "usable fringe mode on character
displays"?

> - a bitmap
> - a character symbol for character displays (where the font family has
>   to be the same throughout the display and thus can be more limited in
>   choice)

This is already supported, see overlay-arrow-string.  Or do you mean
something else?

Re: Bigger fringe bitmaps

[Yuri D'Elia]

On Thu, Mar 17 2022, Eli Zaretskii wrote:
> I did comment on that.  To repeat: it could be a useful new feature,
> but I don't think it should be _the_ solution for showing stuff on the
> fringes on hidpi terminals; we should be able to produce legible
> display of the bitmaps on those terminals.

Seen it, I was just prompting for more feedback on the idea and discuss
if this could be a good and/or bad idea.

>> I like the idea of using 🢱 (or ⤶⤷) for wrapped text, 🮗 as a
>> end-of-buffer, and so on. Easily scaled, and nicely antialiased.
>
> You disregard the issue of which fonts support what characters in the
> relevant Unicode blocks.

Definitely.

> Solving this in the limited fringe screen estate will need some
> non-trivial ideas. And what about 'half-width' or 'minimal'
> fringe-styles?

I mentally imagine this as just scaling the font smaller to fit the
fringe width, centering each character vertically.

>> Especially the fact that this would potentially mean an usable fringe
>> mode on character displays that can be toggled, so that you don't need
>> to provide an alternate signaling mechanism if you rely on the fringe to
>> show makers (like gud).
>
> I don't think I follow.  Emacs doesn't support fringes on TTY
> displays, so what do you mean by "usable fringe mode on character
> displays"?

That would be part of the advantage of allowing a character to be used
in lieu of a bitmap (either as a feature or as a fallback).

On a TTY we could just reserve the first/last column for the "fringe"
and display the lowest-common-denominator format available.

> This is already supported, see overlay-arrow-string. Or do you mean
> something else?

Yes, but it doesn't behave exactly in the same way as the fringe does.

(and I also as I just discovered, if I disable the fringe on a graphical
display I do not get the overlay arrows as a fallback -- or did I miss
some variable to control this behavior?)

Re: Bigger fringe bitmaps

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 17 Mar 2022 09:34:08 +0100
> 
> On Thu, Mar 17 2022, Eli Zaretskii wrote:
> > I did comment on that.  To repeat: it could be a useful new feature,
> > but I don't think it should be _the_ solution for showing stuff on the
> > fringes on hidpi terminals; we should be able to produce legible
> > display of the bitmaps on those terminals.
> 
> Seen it, I was just prompting for more feedback on the idea and discuss
> if this could be a good and/or bad idea.

I think it's a good idea.  It "just" needs to be implemented...

> > Solving this in the limited fringe screen estate will need some
> > non-trivial ideas. And what about 'half-width' or 'minimal'
> > fringe-styles?
> 
> I mentally imagine this as just scaling the font smaller to fit the
> fringe width, centering each character vertically.

Emacs doesn't know how to scale a font at display time.  The font is
"scaled" (or, rather, selected) when the face using the font is
defined.  So dynamically changing the font of a face when the user
plays with fringe-style would be another complication that needs to be
taken care of.

> >> Especially the fact that this would potentially mean an usable fringe
> >> mode on character displays that can be toggled, so that you don't need
> >> to provide an alternate signaling mechanism if you rely on the fringe to
> >> show makers (like gud).
> >
> > I don't think I follow.  Emacs doesn't support fringes on TTY
> > displays, so what do you mean by "usable fringe mode on character
> > displays"?
> 
> That would be part of the advantage of allowing a character to be used
> in lieu of a bitmap (either as a feature or as a fallback).
> 
> On a TTY we could just reserve the first/last column for the "fringe"
> and display the lowest-common-denominator format available.

How is this different from what overlay-arrow already does?  It is
even more flexible, as it is not limited to a single column.

> > This is already supported, see overlay-arrow-string. Or do you mean
> > something else?
> 
> Yes, but it doesn't behave exactly in the same way as the fringe does.

In what way does it not behave the same?

> (and I also as I just discovered, if I disable the fringe on a graphical
> display I do not get the overlay arrows as a fallback -- or did I miss
> some variable to control this behavior?)

What did you try?  See the "Overlay Arrow" node in the ELisp manual
for what is available.

Re: Bigger fringe bitmaps

[Yuri D'Elia]

On Thu, Mar 17 2022, Eli Zaretskii wrote:
>> Seen it, I was just prompting for more feedback on the idea and discuss
>> if this could be a good and/or bad idea.
>
> I think it's a good idea.  It "just" needs to be implemented...

That's why I'd like to know all possible pitfalls before attempting to
do it ;)

> Emacs doesn't know how to scale a font at display time.  The font is
> "scaled" (or, rather, selected) when the face using the font is
> defined.  So dynamically changing the font of a face when the user
> plays with fringe-style would be another complication that needs to be
> taken care of.

Mhh, I'm not sure if we added some sort of connection between the fringe
sizes and fringe face, which one would prevail? Setting the fringe size
(which right now is just a fixed pixel size) could implicitly set the
fringe face size being used, and/or vice-versa.

> How is this different from what overlay-arrow already does?  It is
> even more flexible, as it is not limited to a single column.
<...>
> In what way does it not behave the same?

I agree it's more powerful, but the overlay-arrow shares the same space
with the buffer, so it can hide existing information. I like the fact
that the fringe is a minimal, non-shared, space.

(ironically it has been a while since I last used it, thanks to the
fringe)

> What did you try?  See the "Overlay Arrow" node in the ELisp manual
> for what is available.

Ok, I just realized I instinctively tried (fringe-mode -1) which creates
some weird artifacts instead of using 0.

The node does say:

  On a graphical display the contents of the string are ignored; instead
a glyph is displayed in the fringe area to the left of the display area.

Maybe it should be:

  On a graphical display, or when the left fringe is disabled, the
contents of the string are ignored; instead a glyph is displayed in the
fringe area to the left of the display area.

Re: Bigger fringe bitmaps

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 17 Mar 2022 10:44:54 +0100
> 
> > Emacs doesn't know how to scale a font at display time.  The font is
> > "scaled" (or, rather, selected) when the face using the font is
> > defined.  So dynamically changing the font of a face when the user
> > plays with fringe-style would be another complication that needs to be
> > taken care of.
> 
> Mhh, I'm not sure if we added some sort of connection between the fringe
> sizes and fringe face, which one would prevail? Setting the fringe size
> (which right now is just a fixed pixel size) could implicitly set the
> fringe face size being used, and/or vice-versa.

I didn't say it's impossible, I said it needed to be taken care of.
Changing a face means recomputing all the faces on the frame as well,
and currently setting a fringe style does nothing of the kind.

> > How is this different from what overlay-arrow already does?  It is
> > even more flexible, as it is not limited to a single column.
> <...>
> > In what way does it not behave the same?
> 
> I agree it's more powerful, but the overlay-arrow shares the same space
> with the buffer, so it can hide existing information. I like the fact
> that the fringe is a minimal, non-shared, space.

How would you go about not sharing the screen space with the buffer,
when the display is a TTY?  What else is there that we could use
instead?

> The node does say:
> 
>   On a graphical display the contents of the string are ignored; instead
> a glyph is displayed in the fringe area to the left of the display area.
> 
> Maybe it should be:
> 
>   On a graphical display, or when the left fringe is disabled, the
> contents of the string are ignored; instead a glyph is displayed in the
> fringe area to the left of the display area.

You mean, when left fringe is enabled, right?

I made the text there more accurate, thanks.

Re: Bigger fringe bitmaps

[Yuri D'Elia]

On Thu, Mar 17 2022, Eli Zaretskii wrote:
>> I agree it's more powerful, but the overlay-arrow shares the same space
>> with the buffer, so it can hide existing information. I like the fact
>> that the fringe is a minimal, non-shared, space.
>
> How would you go about not sharing the screen space with the buffer,
> when the display is a TTY?  What else is there that we could use
> instead?

First/last column reserved when the "tty fringe" is on. On one hand,
potentially more wasteful than the overlay-arrow. On the other, it would
be guaranteed to be a single-character only (and any character there
wouldn't overlap - making it clearly distinct).

I tried to copy/paste some buffers to see how it would "play". As a
first impression, it's a tradeoff I'd take over the overlay-arrow while
debugging for sure.

All modes.. mmh. It looks "different". But if I try to keep only the
right-side fringe, I undoubtedly like it and wouldn't mind the loss of
the column at all times.

I definitely need to try to mock an X11 screenshot to see how _that_
would look as well.

> You mean, when left fringe is enabled, right?
>
> I made the text there more accurate, thanks.

Yes. Thanks, very appreciated!

Re: Bigger fringe bitmaps

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 17 Mar 2022 22:21:14 +0100
> 
> On Thu, Mar 17 2022, Eli Zaretskii wrote:
> >> I agree it's more powerful, but the overlay-arrow shares the same space
> >> with the buffer, so it can hide existing information. I like the fact
> >> that the fringe is a minimal, non-shared, space.
> >
> > How would you go about not sharing the screen space with the buffer,
> > when the display is a TTY?  What else is there that we could use
> > instead?
> 
> First/last column reserved when the "tty fringe" is on. On one hand,
> potentially more wasteful than the overlay-arrow. On the other, it would
> be guaranteed to be a single-character only (and any character there
> wouldn't overlap - making it clearly distinct).

How many hours will pass before someone requests a capability to use
more than just a single column?  We already use two with "=>", so
going down to one with something like ">" will probably be considered
a regression by some.

So I think the current situation is better on balance.

Re: Bigger fringe bitmaps

[Yuri D'Elia]

On Fri, Mar 18 2022, Eli Zaretskii wrote:
>> First/last column reserved when the "tty fringe" is on. On one hand,
>> potentially more wasteful than the overlay-arrow. On the other, it
>> would
>> be guaranteed to be a single-character only (and any character there
>> wouldn't overlap - making it clearly distinct).
>
> How many hours will pass before someone requests a capability to use
> more than just a single column?  We already use two with "=>", so
> going down to one with something like ">" will probably be considered
> a regression by some.
>
> So I think the current situation is better on balance.

I don't expect so. While searching randomly online for bigger fringe
bitmaps I've seen several people asking whether it would be possible to
put a character in there instead of hardcoding some pixels.

It is undoubtedly restrictive when you consider ascii, but unicode
expands that space massively. That 2-character arrow can fit in a single
glyph and look actually like a double-arrow. That's certainly my
reasoning: for most of the bullet/arrow requirements, we would be pretty
much set.

What I would expect to happen with such a feature on graphical displays
instead is the possibility to use an independent family for just one
symbol. Because we already have plenty of families designed for
iconography, such as fontawesome, but those families are not intended to
be interchangeable/generic. They're just repositories of glyphs.

RE: [External] : Re: Bigger fringe bitmaps

[Drew Adams]

> How many hours will pass before someone requests a
> capability to use more than just a single column?

Indeed.  To get the ball rolling, let me be the first
to request the capability to use an irrational number
of columns - PI columns, for instance.  PI seems like
a nice round number...

;-)

  - Sorry.  4 days late for PI Day, at least by the
            most common calendar in use around here.

Re: [External] : Re: Bigger fringe bitmaps

[tomas]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

On Fri, Mar 18, 2022 at 02:52:57PM +0000, Drew Adams wrote:
> > How many hours will pass before someone requests a
> > capability to use more than just a single column?
> 
> Indeed.  To get the ball rolling, let me be the first
> to request the capability to use an irrational number
> of columns - PI columns, for instance.  PI seems like
> a nice round number...

Why not go straight to a Chaitin [1] number? There should
be plenty of those!

Cheers

[1] https://en.wikipedia.org/wiki/Chaitin%27s_constant
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

RE: [External] : Re: Bigger fringe bitmaps

[Drew Adams]

> > > How many hours will pass before someone requests a
> > > capability to use more than just a single column?
> >
> > Indeed.  To get the ball rolling, let me be the first
> > to request the capability to use an irrational number
> > of columns - PI columns, for instance.  PI seems like
> > a nice round number...
> 
> Why not go straight to a Chaitin number? There should
> be plenty of those!
> https://en.wikipedia.org/wiki/Chaitin%27s_constant

Can't explain my preference rationally; it's irrational.

Re: [External] : Re: Bigger fringe bitmaps

[tomas]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

On Fri, Mar 18, 2022 at 04:08:33PM +0000, Drew Adams wrote:
> > > > How many hours will pass before someone requests a
> > > > capability to use more than just a single column?
> > >
> > > Indeed.  To get the ball rolling, let me be the first
> > > to request the capability to use an irrational number
> > > of columns - PI columns, for instance.  PI seems like
> > > a nice round number...
> > 
> > Why not go straight to a Chaitin number? There should
> > be plenty of those!
> > https://en.wikipedia.org/wiki/Chaitin%27s_constant
> 
> Can't explain my preference rationally; it's irrational.

OTOH it might take me too long to explain my preference.
But then, it might not.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [External] : Re: Bigger fringe bitmaps

[Po Lu]

Drew Adams <drew.adams@oracle.com> writes:

>> > > How many hours will pass before someone requests a
>> > > capability to use more than just a single column?
>> >
>> > Indeed.  To get the ball rolling, let me be the first
>> > to request the capability to use an irrational number
>> > of columns - PI columns, for instance.  PI seems like
>> > a nice round number...
>> 
>> Why not go straight to a Chaitin number? There should
>> be plenty of those!
>> https://en.wikipedia.org/wiki/Chaitin%27s_constant
>
> Can't explain my preference rationally; it's irrational.

DEVEL.HUMOR candidate?