* Bigger fringe bitmaps @ 2022-03-16 17:57 Yuri D'Elia 2022-03-16 18:23 ` Eli Zaretskii 2022-03-17 0:31 ` Po Lu 0 siblings, 2 replies; 17+ messages in thread From: Yuri D'Elia @ 2022-03-16 17:57 UTC (permalink / raw) To: emacs-devel 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** ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bigger fringe bitmaps 2022-03-16 17:57 Bigger fringe bitmaps Yuri D'Elia @ 2022-03-16 18:23 ` Eli Zaretskii 2022-03-17 0:31 ` Po Lu 1 sibling, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2022-03-16 18:23 UTC (permalink / raw) To: Yuri D'Elia; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bigger fringe bitmaps 2022-03-16 17:57 Bigger fringe bitmaps Yuri D'Elia 2022-03-16 18:23 ` Eli Zaretskii @ 2022-03-17 0:31 ` Po Lu 2022-03-17 7:43 ` Yuri D'Elia 1 sibling, 1 reply; 17+ messages in thread From: Po Lu @ 2022-03-17 0:31 UTC (permalink / raw) To: Yuri D'Elia; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bigger fringe bitmaps 2022-03-17 0:31 ` Po Lu @ 2022-03-17 7:43 ` Yuri D'Elia 2022-03-17 8:21 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Yuri D'Elia @ 2022-03-17 7:43 UTC (permalink / raw) To: emacs-devel 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) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bigger fringe bitmaps 2022-03-17 7:43 ` Yuri D'Elia @ 2022-03-17 8:21 ` Eli Zaretskii 2022-03-17 8:34 ` Yuri D'Elia 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2022-03-17 8:21 UTC (permalink / raw) To: Yuri D'Elia; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bigger fringe bitmaps 2022-03-17 8:21 ` Eli Zaretskii @ 2022-03-17 8:34 ` Yuri D'Elia 2022-03-17 9:30 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Yuri D'Elia @ 2022-03-17 8:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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?) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bigger fringe bitmaps 2022-03-17 8:34 ` Yuri D'Elia @ 2022-03-17 9:30 ` Eli Zaretskii 2022-03-17 9:44 ` Yuri D'Elia 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2022-03-17 9:30 UTC (permalink / raw) To: Yuri D'Elia; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bigger fringe bitmaps 2022-03-17 9:30 ` Eli Zaretskii @ 2022-03-17 9:44 ` Yuri D'Elia 2022-03-17 12:57 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Yuri D'Elia @ 2022-03-17 9:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bigger fringe bitmaps 2022-03-17 9:44 ` Yuri D'Elia @ 2022-03-17 12:57 ` Eli Zaretskii 2022-03-17 21:21 ` Yuri D'Elia 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2022-03-17 12:57 UTC (permalink / raw) To: Yuri D'Elia; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bigger fringe bitmaps 2022-03-17 12:57 ` Eli Zaretskii @ 2022-03-17 21:21 ` Yuri D'Elia 2022-03-18 6:22 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Yuri D'Elia @ 2022-03-17 21:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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! ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bigger fringe bitmaps 2022-03-17 21:21 ` Yuri D'Elia @ 2022-03-18 6:22 ` Eli Zaretskii 2022-03-18 9:29 ` Yuri D'Elia 2022-03-18 14:52 ` [External] : " Drew Adams 0 siblings, 2 replies; 17+ messages in thread From: Eli Zaretskii @ 2022-03-18 6:22 UTC (permalink / raw) To: Yuri D'Elia; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bigger fringe bitmaps 2022-03-18 6:22 ` Eli Zaretskii @ 2022-03-18 9:29 ` Yuri D'Elia 2022-03-18 14:52 ` [External] : " Drew Adams 1 sibling, 0 replies; 17+ messages in thread From: Yuri D'Elia @ 2022-03-18 9:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [External] : Re: Bigger fringe bitmaps 2022-03-18 6:22 ` Eli Zaretskii 2022-03-18 9:29 ` Yuri D'Elia @ 2022-03-18 14:52 ` Drew Adams 2022-03-18 15:31 ` tomas 1 sibling, 1 reply; 17+ messages in thread From: Drew Adams @ 2022-03-18 14:52 UTC (permalink / raw) To: Eli Zaretskii, Yuri D'Elia; +Cc: emacs-devel@gnu.org > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [External] : Re: Bigger fringe bitmaps 2022-03-18 14:52 ` [External] : " Drew Adams @ 2022-03-18 15:31 ` tomas 2022-03-18 16:08 ` Drew Adams 0 siblings, 1 reply; 17+ messages in thread From: tomas @ 2022-03-18 15:31 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [External] : Re: Bigger fringe bitmaps 2022-03-18 15:31 ` tomas @ 2022-03-18 16:08 ` Drew Adams 2022-03-18 17:19 ` tomas 2022-03-18 23:14 ` Po Lu 0 siblings, 2 replies; 17+ messages in thread From: Drew Adams @ 2022-03-18 16:08 UTC (permalink / raw) To: tomas@tuxteam.de, emacs-devel@gnu.org > > > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [External] : Re: Bigger fringe bitmaps 2022-03-18 16:08 ` Drew Adams @ 2022-03-18 17:19 ` tomas 2022-03-18 23:14 ` Po Lu 1 sibling, 0 replies; 17+ messages in thread From: tomas @ 2022-03-18 17:19 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel@gnu.org [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [External] : Re: Bigger fringe bitmaps 2022-03-18 16:08 ` Drew Adams 2022-03-18 17:19 ` tomas @ 2022-03-18 23:14 ` Po Lu 1 sibling, 0 replies; 17+ messages in thread From: Po Lu @ 2022-03-18 23:14 UTC (permalink / raw) To: Drew Adams; +Cc: tomas@tuxteam.de, emacs-devel@gnu.org 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-03-18 23:14 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-03-16 17:57 Bigger fringe bitmaps Yuri D'Elia 2022-03-16 18:23 ` Eli Zaretskii 2022-03-17 0:31 ` Po Lu 2022-03-17 7:43 ` Yuri D'Elia 2022-03-17 8:21 ` Eli Zaretskii 2022-03-17 8:34 ` Yuri D'Elia 2022-03-17 9:30 ` Eli Zaretskii 2022-03-17 9:44 ` Yuri D'Elia 2022-03-17 12:57 ` Eli Zaretskii 2022-03-17 21:21 ` Yuri D'Elia 2022-03-18 6:22 ` Eli Zaretskii 2022-03-18 9:29 ` Yuri D'Elia 2022-03-18 14:52 ` [External] : " Drew Adams 2022-03-18 15:31 ` tomas 2022-03-18 16:08 ` Drew Adams 2022-03-18 17:19 ` tomas 2022-03-18 23:14 ` Po Lu
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).