* bug#26959: Feature request: bold underlines @ 2017-05-17 4:16 Clément Pit--Claudel 2017-05-17 4:21 ` Drew Adams 2017-05-17 15:39 ` Eli Zaretskii 0 siblings, 2 replies; 15+ messages in thread From: Clément Pit--Claudel @ 2017-05-17 4:16 UTC (permalink / raw To: 26959 Hi bug-gnu-emacs, Could underline thickness be made configurable? It would be nice to be able to pick between regular and thick/bold underlines (the later would be obtained by doubling the usual underline thickness, I imagine). Thanks, Clément. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 4:16 bug#26959: Feature request: bold underlines Clément Pit--Claudel @ 2017-05-17 4:21 ` Drew Adams 2017-05-17 4:39 ` Clément Pit--Claudel 2017-05-17 15:39 ` Eli Zaretskii 1 sibling, 1 reply; 15+ messages in thread From: Drew Adams @ 2017-05-17 4:21 UTC (permalink / raw To: Clément Pit--Claudel, 26959 > Could underline thickness be made configurable? It would be nice to be able > to pick between regular and thick/bold underlines (the later would be > obtained by doubling the usual underline thickness, I imagine). See my reply to bug #26958. Should we have two requests: 1. Wavy (and plain) underline to follow text scaling (#26958). 2. Be able to configure underline line-width (#26959). Is #2 enough? If we could customize the :line-width for :underline (and :overline? and :strike-through?), would that be sufficient, or is there also a need for such lines to be sensitive to text scaling? ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 4:21 ` Drew Adams @ 2017-05-17 4:39 ` Clément Pit--Claudel 2017-05-17 14:04 ` Drew Adams 0 siblings, 1 reply; 15+ messages in thread From: Clément Pit--Claudel @ 2017-05-17 4:39 UTC (permalink / raw To: Drew Adams, 26959 [-- Attachment #1.1: Type: text/plain, Size: 1127 bytes --] On 2017-05-17 00:21, Drew Adams wrote: >> Could underline thickness be made configurable? It would be nice to be able >> to pick between regular and thick/bold underlines (the later would be >> obtained by doubling the usual underline thickness, I imagine). > > See my reply to bug #26958. Should we have two requests: Thanks for your replies :) > 1. Wavy (and plain) underline to follow text scaling (#26958). > 2. Be able to configure underline line-width (#26959). Yes, that's a great summary. > Is #2 enough? If we could customize the :line-width for :underline > (and :overline? and :strike-through?), would that be sufficient, or > is there also a need for such lines to be sensitive to text scaling? I don't think so — sensitivity to text scaling would be a useful, distinct feature. Otherwise Lisp code will have to inspect font sizes and adjust thickness based on it, which will cause inconsistencies. Additionally, the amount of space between the text and the underline needs to be adjusted when the font size changes — and this is currently done on GNU/Linux already. Clément. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 4:39 ` Clément Pit--Claudel @ 2017-05-17 14:04 ` Drew Adams 2017-05-17 15:06 ` Clément Pit--Claudel 0 siblings, 1 reply; 15+ messages in thread From: Drew Adams @ 2017-05-17 14:04 UTC (permalink / raw To: Clément Pit--Claudel, 26959 > > See my reply to bug #26958. Should we have two requests: > > 1. Wavy (and plain) underline to follow text scaling (#26958). > > 2. Be able to configure underline line-width (#26959). > > Yes, that's a great summary. > > > Is #2 enough? If we could customize the :line-width for :underline > > (and :overline? and :strike-through?), would that be sufficient, or > > is there also a need for such lines to be sensitive to text scaling? > > I don't think so — sensitivity to text scaling would be a useful, distinct > feature. Otherwise Lisp code will have to inspect font sizes and adjust > thickness based on it, which will cause inconsistencies. Additionally, the > amount of space between the text and the underline needs to be adjusted when > the font size changes — and this is currently done on GNU/Linux already. Whatever decision is made about what the most appropriate behavior is, should we make it optional, e.g., give users a way to _not_ scale such lines, boxes, etc.? ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 14:04 ` Drew Adams @ 2017-05-17 15:06 ` Clément Pit--Claudel 2017-05-17 16:06 ` Drew Adams 0 siblings, 1 reply; 15+ messages in thread From: Clément Pit--Claudel @ 2017-05-17 15:06 UTC (permalink / raw To: Drew Adams, 26959 [-- Attachment #1.1: Type: text/plain, Size: 1241 bytes --] On 2017-05-17 10:04, Drew Adams wrote: >>> See my reply to bug #26958. Should we have two requests: >>> 1. Wavy (and plain) underline to follow text scaling (#26958). >>> 2. Be able to configure underline line-width (#26959). >> >> Yes, that's a great summary. >> >>> Is #2 enough? If we could customize the :line-width for :underline >>> (and :overline? and :strike-through?), would that be sufficient, or >>> is there also a need for such lines to be sensitive to text scaling? >> >> I don't think so — sensitivity to text scaling would be a useful, distinct >> feature. Otherwise Lisp code will have to inspect font sizes and adjust >> thickness based on it, which will cause inconsistencies. Additionally, the >> amount of space between the text and the underline needs to be adjusted when >> the font size changes — and this is currently done on GNU/Linux already. > > Whatever decision is made about what the most appropriate behavior > is, should we make it optional, e.g., give users a way to _not_ > scale such lines, boxes, etc.? I think we should wait for an explicit request before introducing such an option: I have not seen complaints about the behavior as currently implemented in GNU/Linux. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 15:06 ` Clément Pit--Claudel @ 2017-05-17 16:06 ` Drew Adams 2017-05-17 18:48 ` Clément Pit--Claudel 0 siblings, 1 reply; 15+ messages in thread From: Drew Adams @ 2017-05-17 16:06 UTC (permalink / raw To: Clément Pit--Claudel, 26959 > > Whatever decision is made about what the most appropriate behavior > > is, should we make it optional, e.g., give users a way to _not_ > > scale such lines, boxes, etc.? > > I think we should wait for an explicit request before introducing such an > option: I have not seen complaints about the behavior as currently > implemented in GNU/Linux. So you are suggesting not only a change in the _default_ behavior but a change in the behavior altogether. Why is that the right approach? Don't you expect that there are some users or libraries that currently expect or depend on the current behavior? Just because someone thinks a change in behavior is a good idea (and I have no opinion on this one, so far), it doesn't follow that Emacs should make that change by default or (especially) as the only possible behavior. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 16:06 ` Drew Adams @ 2017-05-17 18:48 ` Clément Pit--Claudel 2017-05-17 19:48 ` Drew Adams 0 siblings, 1 reply; 15+ messages in thread From: Clément Pit--Claudel @ 2017-05-17 18:48 UTC (permalink / raw To: Drew Adams, 26959 [-- Attachment #1.1: Type: text/plain, Size: 1394 bytes --] On 2017-05-17 12:06, Drew Adams wrote: >>> Whatever decision is made about what the most appropriate behavior >>> is, should we make it optional, e.g., give users a way to _not_ >>> scale such lines, boxes, etc.? >> >> I think we should wait for an explicit request before introducing such an >> option: I have not seen complaints about the behavior as currently >> implemented in GNU/Linux. > > So you are suggesting not only a change in the _default_ behavior > but a change in the behavior altogether. My OP (in the other thread) was about underlines. With my proposal, the behavior would not change on Linux for straight underlines. > Why is that the right > approach? Don't you expect that there are some users or libraries > that currently expect or depend on the current behavior? How would a library depend on this, given that it isn't consistent across platforms, and not observable from ELisp? > Just because someone thinks a change in behavior is a good idea > (and I have no opinion on this one, so far), it doesn't follow > that Emacs should make that change by default or (especially) > as the only possible behavior. Sure. But until someone voices support for what others consider as a bug, it might not make sense to expend resources adding a flag to revert to the old behavior. In any case, maybe we should move this discussion to #26958? [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 18:48 ` Clément Pit--Claudel @ 2017-05-17 19:48 ` Drew Adams 2017-05-17 20:11 ` Clément Pit--Claudel 0 siblings, 1 reply; 15+ messages in thread From: Drew Adams @ 2017-05-17 19:48 UTC (permalink / raw To: Clément Pit--Claudel, 26959 > >>> Whatever decision is made about what the most appropriate behavior > >>> is, should we make it optional, e.g., give users a way to _not_ > >>> scale such lines, boxes, etc.? > >> > >> I think we should wait for an explicit request before introducing such an > >> option: I have not seen complaints about the behavior as currently > >> implemented in GNU/Linux. Have we seen complaints by MS Windows users that underlines (straight, curly) do not scale with the text? > > So you are suggesting not only a change in the _default_ behavior > > but a change in the behavior altogether. > > My OP (in the other thread) was about underlines. With my proposal, > the behavior would not change on Linux for straight underlines. But it would change for wavy underlines, no? And it would likely change for underlines more generally on some non-[GNU]Linux platforms, no? > > Why is that the right > > approach? Don't you expect that there are some users or libraries > > that currently expect or depend on the current behavior? > > How would a library depend on this, given that it isn't consistent across > platforms, and not observable from ELisp? A user may be on only one platform. A user's code (including a library) might expect particular behavior on this or that platform. Like it or not, people get used to existing behaviors, and people write code that expects that behavior. It's possible for Emacs to change the behavior, but it's unusual to change not only the default behavior but the only possible one. Is there a reason why we would have to do that? Why not offer a choice? Why not let a user set her preference? Why not let a program control whether such line-scaling occurs? > > Just because someone thinks a change in behavior is a good idea > > (and I have no opinion on this one, so far), it doesn't follow > > that Emacs should make that change by default or (especially) > > as the only possible behavior. > > Sure. But until someone voices support for what others consider as a bug, it > might not make sense to expend resources adding a flag to revert to the old > behavior. If it is decided that the current behavior is just a bug then yes, it could be changed unconditionally. Is it that clear that this is only a bug? Is there a reason to suppose that no one would want the current behavior or no one would want to choose whether to scale such lines? > In any case, maybe we should move this discussion to #26958? Yes. This one (#26959) already takes the point of view of allowing users a choice. (That's a good thing.) ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 19:48 ` Drew Adams @ 2017-05-17 20:11 ` Clément Pit--Claudel 2017-05-17 21:09 ` Drew Adams 0 siblings, 1 reply; 15+ messages in thread From: Clément Pit--Claudel @ 2017-05-17 20:11 UTC (permalink / raw To: Drew Adams, 26959 [-- Attachment #1.1: Type: text/plain, Size: 235 bytes --] On 2017-05-17 15:48, Drew Adams wrote: > Like it or not, people get used to existing behaviors, and people > write code that expects that behavior. I don't understand how Lisp code can depend on this behavior. Can you clarify? [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 20:11 ` Clément Pit--Claudel @ 2017-05-17 21:09 ` Drew Adams 2017-05-17 21:22 ` Clément Pit--Claudel 0 siblings, 1 reply; 15+ messages in thread From: Drew Adams @ 2017-05-17 21:09 UTC (permalink / raw To: Clément Pit--Claudel, 26959 > > Like it or not, people get used to existing behaviors, and people > > write code that expects that behavior. > > I don't understand how Lisp code can depend on this behavior. > Can you clarify? Is it clearer if I say that people write code to do something, and they can expect it to do what it did previously. The point is that it is not only about a user option. You might have written code that had a given behavior, and now that behavior changes without your having changed the code. Whether you are a user of that code or its maintainer, you might not appreciate the change. Giving users and code a way to choose the behavior usually makes sense. Is there some special reason it would not make sense in this case? What is the imperative to change from A as the only possible behavior to B as the only possible behavior, unless it is agreed that A is a bug and B is the right fix for it? This is all hypothetical. I don't have a horse in this race. I have no idea which behavior is better in general, or which would be preferred by most users most of the time. Maybe you can point to a UI guideline somewhere or some doc that speaks about this? Why does it make sense, a priori, that an underline thickness would scale along with the text? Not to mention the nuances that Eli tried to point out. It is already tricky to deal with Emacs box line-widths and such together with things like interline spacing. I think that before we even get to the question of whether this should be changed unilaterally or offered as a new possibility the behavior should be well specified or demonstrated. FWIW, I just checked in a non-Emacs application (Arbortext editor) on MS Windows, and non-wavy underlining does not seem to zoom along with the text. Now maybe that's because the particular use of that wavy underlining, in this application, is to highlight spelling errors. One could imagine that in one use case it is used for something like that, and it is deemed better not to scale it, but in another use case, where the underlining is considered part of the text itself, it is deemed better to scale the underlining too. I kind of expected that in the Arbortext case, expecting to see that a normal (straight) underline would zoom along with its text. But no, at least for Arbortext that is not the case. Still, I think it makes sense, a priori, to let Emacs code decide in any given context: is the underlining to be treated as in a sense part of the text, i.e., do you want it to scale with the text, or is it to be treated separately? (Clearly it needs to zoom horizontally along with the text.) I tried the same test with MS Word. There, the wavy underline to show spelling problems likewise does not scale with the text, but a straight underline does scale with the text. (That's what I was expecting for Arbortext too.) In terms of use cases I think it mostly comes down to whether a given user or application wants to consider the particular underlining style to be, in a sense, part of the text itself, or to belong to some other level (e.g. content annotation/metadata). (And we are still writing about bug #26959 in the bug #26958 thread...) ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 21:09 ` Drew Adams @ 2017-05-17 21:22 ` Clément Pit--Claudel 2017-05-17 21:37 ` Drew Adams 0 siblings, 1 reply; 15+ messages in thread From: Clément Pit--Claudel @ 2017-05-17 21:22 UTC (permalink / raw To: Drew Adams, 26959 On 2017-05-17 17:09, Drew Adams wrote: > I tried the same test with MS Word. There, the wavy underline > to show spelling problems likewise does not scale with the text Thanks for testing. Did you check whether it scaled with pixel density, though? LibreOffice does that. Clément. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 21:22 ` Clément Pit--Claudel @ 2017-05-17 21:37 ` Drew Adams 0 siblings, 0 replies; 15+ messages in thread From: Drew Adams @ 2017-05-17 21:37 UTC (permalink / raw To: Clément Pit--Claudel, 26959 > > I tried the same test with MS Word. There, the wavy underline > > to show spelling problems likewise does not scale with the text > > Thanks for testing. Did you check whether it scaled with pixel density, > though? LibreOffice does that. Dunno what that means. I took screenshots and checked the number of pixels in the screenshots (zooming in on them in an image editor). HTH. Please don't count on me to test or debug this. I've already spent more time on this than I wanted to. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 4:16 bug#26959: Feature request: bold underlines Clément Pit--Claudel 2017-05-17 4:21 ` Drew Adams @ 2017-05-17 15:39 ` Eli Zaretskii 2017-05-17 18:59 ` Clément Pit--Claudel 1 sibling, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2017-05-17 15:39 UTC (permalink / raw To: Clément Pit--Claudel; +Cc: 26959 > From: Clément Pit--Claudel <clement.pitclaudel@live.com> > Date: Wed, 17 May 2017 00:16:47 -0400 > > Could underline thickness be made configurable? It would be nice to be able to pick between regular and thick/bold underlines (the later would be obtained by doubling the usual underline thickness, I imagine). You need to be aware of some subtleties with underlines as currently implemented, and we should consider all of that when we decide what kind of configurability we want and what should it do. See below. > > FWIW, on Windows I see neither straight nor wavy underline thicken. > > They both continue to have the same line width (thickness) when > > text-scaled. > > > > Should they not stay the same? Should they thicken? Why? > > Thanks for the reply! They do scale in GNU/Linux; the code in xftfont says: > > font->underline_position = -ft_face->underline_position * size / upEM; > font->underline_thickness = ft_face->underline_thickness * size / upEM; > > The corresponding code in w32font says: > > font->underline_thickness = metrics->otmsUnderscoreSize; > font->underline_position = -metrics->otmsUnderscorePosition; > > which might be missing the scaling? Not all font back-ends support this scaling, and not with every font. E.g., xfont.c doesn't support this at all, AFAICS. And while we could probably add this feature to MS-Windows, it will only be available with OTF and TTF fonts (I believe it's the same on Unix and GNU systems). Moreover, if you mix fonts of different sizes on the same line in the same run of consecutive underlined characters, you will see that Emacs defines the thickness and the position of the underline at the first character, and then reuses those values for the entire run, even if the size of the font changes -- it doesn't recompute the values when the font changes. We do this because anything else will look uglier than what we have now. What all this means is that currently the exact visual effect of the underline attribute is deliberately not well-defined: about the only thing you can rely on is that you will get a horizontal line somewhere in the lower portion of the characters. Implementing your suggestion would require that we define the behavior much better, which is not easy given the different font drivers and fonts, on which the user has almost no control. E.g., we will need to decide whether thickness customization overrides the font-dependent scaling, and if not, how these two play together. And if we want to allow customization of the underline position (why not?), we will have to decide what to do with it when the font size changes. And then we will need to decide what to do if the font doesn't support scaling. Bottom line: I think the hard part here is to describe the new behavior, and do that in way that makes sense. Implementing that (assuming the fonts and font backends support the requirements) should be relatively easy, once all of these hidden issues are figured out. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 15:39 ` Eli Zaretskii @ 2017-05-17 18:59 ` Clément Pit--Claudel 2017-05-18 4:10 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Clément Pit--Claudel @ 2017-05-17 18:59 UTC (permalink / raw To: Eli Zaretskii; +Cc: 26959 [-- Attachment #1.1: Type: text/plain, Size: 3630 bytes --] On 2017-05-17 11:39, Eli Zaretskii wrote: >> From: Clément Pit--Claudel <clement.pitclaudel@live.com> >> Date: Wed, 17 May 2017 00:16:47 -0400 >> >> Could underline thickness be made configurable? It would be nice to be able to pick between regular and thick/bold underlines (the later would be obtained by doubling the usual underline thickness, I imagine). > > You need to be aware of some subtleties with underlines as currently > implemented, and we should consider all of that when we decide what > kind of configurability we want and what should it do. See below. > >>> FWIW, on Windows I see neither straight nor wavy underline thicken. >>> They both continue to have the same line width (thickness) when >>> text-scaled. >>> >>> Should they not stay the same? Should they thicken? Why? >> >> Thanks for the reply! They do scale in GNU/Linux; the code in xftfont says: >> >> font->underline_position = -ft_face->underline_position * size / upEM; >> font->underline_thickness = ft_face->underline_thickness * size / upEM; >> >> The corresponding code in w32font says: >> >> font->underline_thickness = metrics->otmsUnderscoreSize; >> font->underline_position = -metrics->otmsUnderscorePosition; >> >> which might be missing the scaling? > > Not all font back-ends support this scaling, and not with every font. > E.g., xfont.c doesn't support this at all, AFAICS. And while we could > probably add this feature to MS-Windows, it will only be available > with OTF and TTF fonts (I believe it's the same on Unix and GNU > systems). Makes sense. And, of course, the scaling is outside of Emacs' control on TTYs. > Moreover, if you mix fonts of different sizes on the same line in the > same run of consecutive underlined characters, you will see that Emacs > defines the thickness and the position of the underline at the first > character, and then reuses those values for the entire run, even if > the size of the font changes -- it doesn't recompute the values when > the font changes. We do this because anything else will look uglier > than what we have now. I saw this, indeed. > What all this means is that currently the exact visual effect of the > underline attribute is deliberately not well-defined: about the only > thing you can rely on is that you will get a horizontal line somewhere > in the lower portion of the characters. > > Implementing your suggestion would require that we define the behavior > much better, which is not easy given the different font drivers and > fonts, on which the user has almost no control. E.g., we will need to > decide whether thickness customization overrides the font-dependent > scaling, and if not, how these two play together. And if we want to > allow customization of the underline position (why not?), we will have > to decide what to do with it when the font size changes. And then we > will need to decide what to do if the font doesn't support scaling. That makes sense, but I'm not sure all of this is needed. I agree that it would be nice, but is it really necessary? In terms of code, my suggestion would translate into multiplying the `thickness' variable in xftfont by 2 when :bold t is specified in the underline's property list. > Bottom line: I think the hard part here is to describe the new > behavior, and do that in way that makes sense. Implementing that > (assuming the fonts and font backends support the requirements) should > be relatively easy, once all of these hidden issues are figured out. Thanks for the explanation. Clément. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#26959: Feature request: bold underlines 2017-05-17 18:59 ` Clément Pit--Claudel @ 2017-05-18 4:10 ` Eli Zaretskii 0 siblings, 0 replies; 15+ messages in thread From: Eli Zaretskii @ 2017-05-18 4:10 UTC (permalink / raw To: Clément Pit--Claudel; +Cc: 26959 > Cc: 26959@debbugs.gnu.org > From: Clément Pit--Claudel <clement.pitclaudel@live.com> > Date: Wed, 17 May 2017 14:59:56 -0400 > > > What all this means is that currently the exact visual effect of the > > underline attribute is deliberately not well-defined: about the only > > thing you can rely on is that you will get a horizontal line somewhere > > in the lower portion of the characters. > > > > Implementing your suggestion would require that we define the behavior > > much better, which is not easy given the different font drivers and > > fonts, on which the user has almost no control. E.g., we will need to > > decide whether thickness customization overrides the font-dependent > > scaling, and if not, how these two play together. And if we want to > > allow customization of the underline position (why not?), we will have > > to decide what to do with it when the font size changes. And then we > > will need to decide what to do if the font doesn't support scaling. > > That makes sense, but I'm not sure all of this is needed. I agree that it would be nice, but is it really necessary? Perhaps not. But any subset of this we choose to implement should be consistent and should make sense to users. > In terms of code, my suggestion would translate into multiplying the `thickness' variable in xftfont by 2 when :bold t is specified in the underline's property list. Even if the bold attribute starts in the middle of a consecutive run of underlined characters? IOW, should this override the current behavior of computing the thickness only once per such run? ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2017-05-18 4:10 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-05-17 4:16 bug#26959: Feature request: bold underlines Clément Pit--Claudel 2017-05-17 4:21 ` Drew Adams 2017-05-17 4:39 ` Clément Pit--Claudel 2017-05-17 14:04 ` Drew Adams 2017-05-17 15:06 ` Clément Pit--Claudel 2017-05-17 16:06 ` Drew Adams 2017-05-17 18:48 ` Clément Pit--Claudel 2017-05-17 19:48 ` Drew Adams 2017-05-17 20:11 ` Clément Pit--Claudel 2017-05-17 21:09 ` Drew Adams 2017-05-17 21:22 ` Clément Pit--Claudel 2017-05-17 21:37 ` Drew Adams 2017-05-17 15:39 ` Eli Zaretskii 2017-05-17 18:59 ` Clément Pit--Claudel 2017-05-18 4:10 ` Eli Zaretskii
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.