unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#27103: Should show-trailing-whitespace highlight specified spaces?
@ 2017-05-27 16:47 Clément Pit--Claudel
  2017-05-27 18:26 ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Clément Pit--Claudel @ 2017-05-27 16:47 UTC (permalink / raw)
  To: 27103


[-- Attachment #1.1: Type: text/plain, Size: 1273 bytes --]

Hi emacs-devel,

I'm trying to display "/// " comment markers as a thin vertical line. At first, I went for something like the following font-lock rule:

  '(face my-vertical-line-face display (space :width 0.5))

This worked fine, until I decided to add a fringe icon, too:

  '(face my-vertical-line-face display [(space :width 0.5) (left-margin left-arrow)])

Now (with show-trailing-whitespace set to t) Emacs highlight lines that just contain "///" in bright red.  Here's a quick way to reproduce this:

  (dotimes (_ 25) (insert (propertize "///" 'display '((space :width 10) (left-fringe left-arrow))) "\n"))

Contrast with this, which doesn't show trailing-whitespace highlights:

  (dotimes (_ 25) (insert (propertize "///" 'display '(space :width 10)) "\n"))

Am I doing something wrong?  Or is this a bug, and if so which behavior is the correct one? Is there a way to disable the trailing whitespace highlighting here?

The best I've managed is to put the left-fringe property on the first "/" character, and the display property on the next two, but this interacts in annoying ways with point motion.  I added cursor-intangible properties to the mix too, but no luck (they interacted badly with insertion/deletion)

Thanks,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-27 16:47 bug#27103: Should show-trailing-whitespace highlight specified spaces? Clément Pit--Claudel
@ 2017-05-27 18:26 ` Eli Zaretskii
  2017-05-27 19:14   ` Clément Pit--Claudel
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2017-05-27 18:26 UTC (permalink / raw)
  To: Clément Pit--Claudel; +Cc: 27103

tags 27103 notabug
thanks

> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sat, 27 May 2017 12:47:40 -0400
> 
> I'm trying to display "/// " comment markers as a thin vertical line. At first, I went for something like the following font-lock rule:
> 
>   '(face my-vertical-line-face display (space :width 0.5))
> 
> This worked fine, until I decided to add a fringe icon, too:
> 
>   '(face my-vertical-line-face display [(space :width 0.5) (left-margin left-arrow)])
> 
> Now (with show-trailing-whitespace set to t) Emacs highlight lines that just contain "///" in bright red.  Here's a quick way to reproduce this:
> 
>   (dotimes (_ 25) (insert (propertize "///" 'display '((space :width 10) (left-fringe left-arrow))) "\n"))
> 
> Contrast with this, which doesn't show trailing-whitespace highlights:
> 
>   (dotimes (_ 25) (insert (propertize "///" 'display '(space :width 10)) "\n"))
> 
> Am I doing something wrong?

I think you are hitting on undefined behavior: mixing different
replacing specs in the same display property is not generally
supported.

> Is there a way to disable the trailing whitespace highlighting here?

You could swap the order of 'space' and 'left-fringe' specs, but the
fact that this works is sheer luck, and I wouldn't recommend relying
on that.

The rule is to use at most one replacing spec in a display property.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-27 18:26 ` Eli Zaretskii
@ 2017-05-27 19:14   ` Clément Pit--Claudel
  2017-05-27 19:42     ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Clément Pit--Claudel @ 2017-05-27 19:14 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 27103


[-- Attachment #1.1: Type: text/plain, Size: 888 bytes --]

On 2017-05-27 14:26, Eli Zaretskii wrote:> I think you are hitting on undefined behavior: mixing different
> replacing specs in the same display property is not generally
> supported.

Thanks for clarifying.

>> Is there a way to disable the trailing whitespace highlighting here?
> 
> You could swap the order of 'space' and 'left-fringe' specs, but the
> fact that this works is sheer luck, and I wouldn't recommend relying
> on that.

It doesn't work here: the fringe remains empty.

> The rule is to use at most one replacing spec in a display property.

Makes sense, thanks. Would it be a reasonable feature request to ask for a non-replacing version of left-fringe and right-fringe?  I've seen other code work around this by putting the left-fringe property on the before-string of an overlay, but I can't do this with pure text properties.

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-27 19:14   ` Clément Pit--Claudel
@ 2017-05-27 19:42     ` Eli Zaretskii
  2017-05-27 19:52       ` Clément Pit--Claudel
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2017-05-27 19:42 UTC (permalink / raw)
  To: Clément Pit--Claudel; +Cc: 27103

> Cc: 27103@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sat, 27 May 2017 15:14:00 -0400
> 
> Would it be a reasonable feature request to ask for a non-replacing version of left-fringe and right-fringe?

I'm not sure.  Non-replacing specs are those which affect the way the
text having the display property is displayed, but you want something
else: a portion of text that is both displayed normally and produces
the fringe bitmap.  That's not how display properties work.

IOW, it looks like implementing something like that will need serious
changes in how the display engine works, because it basically
traverses across a given buffer position only once.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-27 19:42     ` Eli Zaretskii
@ 2017-05-27 19:52       ` Clément Pit--Claudel
  2017-05-28 16:28         ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Clément Pit--Claudel @ 2017-05-27 19:52 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 27103


[-- Attachment #1.1: Type: text/plain, Size: 1085 bytes --]

On 2017-05-27 15:42, Eli Zaretskii wrote:
>> Cc: 27103@debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Sat, 27 May 2017 15:14:00 -0400
>>
>> Would it be a reasonable feature request to ask for a non-replacing version of left-fringe and right-fringe?
> 
> I'm not sure.  Non-replacing specs are those which affect the way the
> text having the display property is displayed, but you want something
> else: a portion of text that is both displayed normally and produces
> the fringe bitmap.  That's not how display properties work.
> 
> IOW, it looks like implementing something like that will need serious
> changes in how the display engine works, because it basically
> traverses across a given buffer position only once.

Makes sense, thanks for the detailed explanation. Would the same caveat apply to the creation of a new 'left-fringe text property, such that instead of (concat "A" (propertize "_" 'display '(left-fringe filled-square))) one could write (propertize "A" 'left-fringe 'filled-square)?

Thanks,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-27 19:52       ` Clément Pit--Claudel
@ 2017-05-28 16:28         ` Eli Zaretskii
  2017-05-28 16:43           ` Clément Pit--Claudel
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2017-05-28 16:28 UTC (permalink / raw)
  To: Clément Pit--Claudel; +Cc: 27103

> Cc: 27103@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sat, 27 May 2017 15:52:27 -0400
> 
> Would the same caveat apply to the creation of a new 'left-fringe text property, such that instead of (concat "A" (propertize "_" 'display '(left-fringe filled-square))) one could write (propertize "A" 'left-fringe 'filled-square)?

I'm not sure I understand why the former uses 'concat', while the
latter doesn't.  So perhaps I'm missing the point, because otherwise
this looks like just "syntactic sugar", is it?





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-28 16:28         ` Eli Zaretskii
@ 2017-05-28 16:43           ` Clément Pit--Claudel
  2017-05-28 17:44             ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Clément Pit--Claudel @ 2017-05-28 16:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 27103


[-- Attachment #1.1: Type: text/plain, Size: 1245 bytes --]

On 2017-05-28 12:28, Eli Zaretskii wrote:
>> Cc: 27103@debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Sat, 27 May 2017 15:52:27 -0400
>>
>> Would the same caveat apply to the creation of a new 'left-fringe text property, such that instead of (concat "A" (propertize "_" 'display '(left-fringe filled-square))) one could write (propertize "A" 'left-fringe 'filled-square)?
> 
> I'm not sure I understand why the former uses 'concat', while the
> latter doesn't.  So perhaps I'm missing the point, because otherwise
> this looks like just "syntactic sugar", is it?

It uses `concat' because the display spec is replacing.  Let me try a better example :) Consider a buffer with contents like this:

  (defun …
    …)

  (defun …
    …)

Suppose I want to highlight each defun with a fringe indicator.  With my proposal, one could use the following font-lock rule:

  ("^(defun" (0 '(face nil left-fringe right-arrow)))

And the contents of the buffer would look like this:

→ (defun …
    …)

→ (defun …
    …)

I don't think such a result is currently achievable without overlays (which are not nearly fast enough for my purposes).

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-28 16:43           ` Clément Pit--Claudel
@ 2017-05-28 17:44             ` Eli Zaretskii
  2017-05-28 17:53               ` Clément Pit--Claudel
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2017-05-28 17:44 UTC (permalink / raw)
  To: Clément Pit--Claudel; +Cc: 27103

> Cc: 27103@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sun, 28 May 2017 12:43:23 -0400
> 
> > I'm not sure I understand why the former uses 'concat', while the
> > latter doesn't.  So perhaps I'm missing the point, because otherwise
> > this looks like just "syntactic sugar", is it?
> 
> It uses `concat' because the display spec is replacing.  Let me try a better example :) Consider a buffer with contents like this:
> 
>   (defun …
>     …)
> 
>   (defun …
>     …)
> 
> Suppose I want to highlight each defun with a fringe indicator.  With my proposal, one could use the following font-lock rule:
> 
>   ("^(defun" (0 '(face nil left-fringe right-arrow)))
> 
> And the contents of the buffer would look like this:
> 
> → (defun …
>     …)
> 
> → (defun …
>     …)

But this again asks that the display engine could produce 2 different
display elements out of the same buffer position, which means it would
need to scan that buffer position twice.  Right?

> I don't think such a result is currently achievable without overlays (which are not nearly fast enough for my purposes).

Are overlays really so slow that you are prepared to jump through such
hoops?





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-28 17:44             ` Eli Zaretskii
@ 2017-05-28 17:53               ` Clément Pit--Claudel
  2017-05-28 18:14                 ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Clément Pit--Claudel @ 2017-05-28 17:53 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 27103


[-- Attachment #1.1: Type: text/plain, Size: 1036 bytes --]

On 2017-05-28 13:44, Eli Zaretskii wrote:
>> And the contents of the buffer would look like this:
>>
>> → (defun …
>>     …)
>>
>> → (defun …
>>     …)
> 
> But this again asks that the display engine could produce 2 different
> display elements out of the same buffer position, which means it would
> need to scan that buffer position twice.  Right?

Possibly — I don't think I understand this part well.  What happens for before-string properties?  Could the same thing happen here?

>> I don't think such a result is currently achievable without overlays (which are not nearly fast enough for my purposes).
> 
> Are overlays really so slow that you are prepared to jump through such
> hoops?

Definitely :) I need these markers for a literate-programming buffer where roughly every other line has a marker.  On a 10k lines file, overlays are entirely impractical.
(I guess I could lazily add an remove the overlays, but I'm not too excited about reimplementing jit-lock's logic :/)

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-28 17:53               ` Clément Pit--Claudel
@ 2017-05-28 18:14                 ` Eli Zaretskii
  2017-05-28 19:43                   ` Clément Pit--Claudel
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2017-05-28 18:14 UTC (permalink / raw)
  To: Clément Pit--Claudel; +Cc: 27103

> Cc: 27103@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sun, 28 May 2017 13:53:09 -0400
> 
> > But this again asks that the display engine could produce 2 different
> > display elements out of the same buffer position, which means it would
> > need to scan that buffer position twice.  Right?
> 
> Possibly — I don't think I understand this part well.  What happens for before-string properties?

There's a string there, so those properties are processed when the
display engine traverses the string characters.

> Could the same thing happen here?

No, because there's no string.  There's just buffer text and nothing
else.

Maybe we could extend the line-prefix property to support left-fringe
and right-fringe specs.

> > Are overlays really so slow that you are prepared to jump through such
> > hoops?
> 
> Definitely :) I need these markers for a literate-programming buffer where roughly every other line has a marker.  On a 10k lines file, overlays are entirely impractical.

Can you show a simple example where having 5K overlays in a buffer
cause significant slowdown?  I mean, just having 5K overlays, without
any additional bells and whistles.  What exactly is slowed down?





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-28 18:14                 ` Eli Zaretskii
@ 2017-05-28 19:43                   ` Clément Pit--Claudel
  2017-05-28 19:51                     ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Clément Pit--Claudel @ 2017-05-28 19:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 27103


[-- Attachment #1.1: Type: text/plain, Size: 1175 bytes --]

On 2017-05-28 14:14, Eli Zaretskii wrote:> There's a string there, so those properties are processed when the
> display engine traverses the string characters.

Thanks. Understood.

>> Could the same thing happen here?
> 
> No, because there's no string.  There's just buffer text and nothing
> else.
> 
> Maybe we could extend the line-prefix property to support left-fringe
> and right-fringe specs.

Hey, it works!

  (insert (propertize "AA" 'line-prefix (propertize "_" 'display '(left-fringe right-arrow))))

:)

Anything bad with this?

>>> Are overlays really so slow that you are prepared to jump through such
>>> hoops?
>>
>> Definitely :) I need these markers for a literate-programming buffer where roughly every other line has a marker.  On a 10k lines file, overlays are entirely impractical.
> 
> Can you show a simple example where having 5K overlays in a buffer
> cause significant slowdown?  I mean, just having 5K overlays, without
> any additional bells and whistles.  What exactly is slowed down?

My mode uses overlays for other purposes, and this slows all of it down.

Thanks for your time and answers :)
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-28 19:43                   ` Clément Pit--Claudel
@ 2017-05-28 19:51                     ` Eli Zaretskii
  2017-05-28 20:18                       ` Clément Pit--Claudel
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2017-05-28 19:51 UTC (permalink / raw)
  To: Clément Pit--Claudel; +Cc: 27103

> Cc: 27103@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sun, 28 May 2017 15:43:52 -0400
> 
> > Maybe we could extend the line-prefix property to support left-fringe
> > and right-fringe specs.
> 
> Hey, it works!
> 
>   (insert (propertize "AA" 'line-prefix (propertize "_" 'display '(left-fringe right-arrow))))

That's not what I meant, but if you are happy, it's fine with me.

> Anything bad with this?

It's just a display property.  Nothing wrong with that, of course.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-28 19:51                     ` Eli Zaretskii
@ 2017-05-28 20:18                       ` Clément Pit--Claudel
  2017-05-29  2:30                         ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Clément Pit--Claudel @ 2017-05-28 20:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 27103


[-- Attachment #1.1: Type: text/plain, Size: 1206 bytes --]

On 2017-05-28 15:51, Eli Zaretskii wrote:
>> Cc: 27103@debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Sun, 28 May 2017 15:43:52 -0400
>>
>>> Maybe we could extend the line-prefix property to support left-fringe
>>> and right-fringe specs.
>>
>> Hey, it works!
>>
>>   (insert (propertize "AA" 'line-prefix (propertize "_" 'display '(left-fringe right-arrow))))
> 
> That's not what I meant, but if you are happy, it's fine with me.

I didn't realize that this was possible. It fits my use case very nicely :) In the (defun example, I can just put the line-prefix property on the defun, and everything works perfectly.

I wonder if we should mention this in the manual. Maybe in the "display specs" section, where (fringe …) is described, we could add this:

  `left-fringe' and `right-fringe' are replacing specs: the span of text that they apply to is made invisible.  To add a fringe to a line without hiding any of its contents, put the fringe property on the before-string of an overlay or on the line-prefix of your text.

>> Anything bad with this?
> 
> It's just a display property.  Nothing wrong with that, of course.

Thanks!



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-28 20:18                       ` Clément Pit--Claudel
@ 2017-05-29  2:30                         ` Eli Zaretskii
  2017-05-29  2:33                           ` Clément Pit--Claudel
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2017-05-29  2:30 UTC (permalink / raw)
  To: Clément Pit--Claudel; +Cc: 27103-done

> Cc: 27103@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sun, 28 May 2017 16:18:02 -0400
> 
> >>   (insert (propertize "AA" 'line-prefix (propertize "_" 'display '(left-fringe right-arrow))))
> > 
> > That's not what I meant, but if you are happy, it's fine with me.
> 
> I didn't realize that this was possible. It fits my use case very nicely :) In the (defun example, I can just put the line-prefix property on the defun, and everything works perfectly.
> 
> I wonder if we should mention this in the manual. Maybe in the "display specs" section, where (fringe …) is described, we could add this:
> 
>   `left-fringe' and `right-fringe' are replacing specs: the span of text that they apply to is made invisible.  To add a fringe to a line without hiding any of its contents, put the fringe property on the before-string of an overlay or on the line-prefix of your text.

That's the kind of "howto" stuff that doesn't really belong to a
manual.

> >> Anything bad with this?
> > 
> > It's just a display property.  Nothing wrong with that, of course.
> 
> Thanks!

OK, closing.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-29  2:30                         ` Eli Zaretskii
@ 2017-05-29  2:33                           ` Clément Pit--Claudel
  2017-05-29 17:28                             ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Clément Pit--Claudel @ 2017-05-29  2:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 27103-done


[-- Attachment #1.1: Type: text/plain, Size: 578 bytes --]

On 2017-05-28 22:30, Eli Zaretskii wrote:>> I wonder if we should mention this in the manual. Maybe in the "display specs" section, where (fringe …) is described, we could add this:
>>
>>   `left-fringe' and `right-fringe' are replacing specs: the span of text that they apply to is made invisible.  To add a fringe to a line without hiding any of its contents, put the fringe property on the before-string of an overlay or on the line-prefix of your text.
> 
> That's the kind of "howto" stuff that doesn't really belong to a
> manual.

Where does it belong, then?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#27103: Should show-trailing-whitespace highlight specified spaces?
  2017-05-29  2:33                           ` Clément Pit--Claudel
@ 2017-05-29 17:28                             ` Eli Zaretskii
  0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2017-05-29 17:28 UTC (permalink / raw)
  To: Clément Pit--Claudel; +Cc: 27103-done

> Cc: 27103-done@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sun, 28 May 2017 22:33:04 -0400
> 
> >>   `left-fringe' and `right-fringe' are replacing specs: the span of text that they apply to is made invisible.  To add a fringe to a line without hiding any of its contents, put the fringe property on the before-string of an overlay or on the line-prefix of your text.
> > 
> > That's the kind of "howto" stuff that doesn't really belong to a
> > manual.
> 
> Where does it belong, then?

Some tutorial, or the wiki, IMO.





^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2017-05-29 17:28 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-27 16:47 bug#27103: Should show-trailing-whitespace highlight specified spaces? Clément Pit--Claudel
2017-05-27 18:26 ` Eli Zaretskii
2017-05-27 19:14   ` Clément Pit--Claudel
2017-05-27 19:42     ` Eli Zaretskii
2017-05-27 19:52       ` Clément Pit--Claudel
2017-05-28 16:28         ` Eli Zaretskii
2017-05-28 16:43           ` Clément Pit--Claudel
2017-05-28 17:44             ` Eli Zaretskii
2017-05-28 17:53               ` Clément Pit--Claudel
2017-05-28 18:14                 ` Eli Zaretskii
2017-05-28 19:43                   ` Clément Pit--Claudel
2017-05-28 19:51                     ` Eli Zaretskii
2017-05-28 20:18                       ` Clément Pit--Claudel
2017-05-29  2:30                         ` Eli Zaretskii
2017-05-29  2:33                           ` Clément Pit--Claudel
2017-05-29 17:28                             ` Eli Zaretskii

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).