* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
@ 2013-06-12 3:18 Juanma Barranquero
2013-06-15 8:21 ` Ted Zlatanov
0 siblings, 1 reply; 16+ messages in thread
From: Juanma Barranquero @ 2013-06-12 3:18 UTC (permalink / raw)
To: 14595
[-- Attachment #1: Type: text/plain, Size: 3776 bytes --]
Package: emacs
Version: 24.3.50
With a test file lambda.el which contains 1000 identical lines:
(lambda (x) x)
emacs -Q --eval "(setq-default prog-prettify-symbols t)" lambda.el
In most cases, lambda is correctly composed to λ; in a few, it is
composed (apparently) like a supperposition of the characters in
"lambda" (attached image included).
If I visit lambda.el as in the example above, and scroll down the
buffer, I get 26 such failures, always at the same lines (168, 280,
364, 432, 489, 538, 581, 619, 654, 686, 715, 742, 767, 791, 813, 834,
854, 873, 891, 908, 924, 940, 955, 970, 984 and 998); however, if upon
visiting the file I go to the end of the buffer and scroll up, I get
many more failures (about 60) at diferent lines, but also consistently
the same lines.
describe-char for a correct composition:
position: 2492 of 15000 (17%), column: 1
character: l (displayed as l) (codepoint 108, #o154, #x6c)
preferred charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x6C
script: latin
syntax: w which means: word
category: .:Base, L:Left-to-right (strong), a:ASCII,
l:Latin, r:Roman
to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
buffer code: #x6C
file code: #x6C (encoded by coding system utf-8-dos)
display: composed to form "lambda" (see below)
Composed with the following character(s) "ambda" by the rule:
(?λ)
The component character(s) are displayed by these fonts (glyph codes):
λ: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso10646-1 (#x21C)
See the variable `reference-point-alist' for the meaning of the rule.
Character code properties: customize what to show
name: LATIN SMALL LETTER L
general-category: Ll (Letter, Lowercase)
decomposition: (108) ('l')
There are text properties here:
composition [Show]
face font-lock-keyword-face
fontified t
describe-char for a wrong one:
position: 2507 of 15000 (17%), column: 1
character: l (displayed as l) (codepoint 108, #o154, #x6c)
preferred charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x6C
script: latin
syntax: w which means: word
category: .:Base, L:Left-to-right (strong), a:ASCII,
l:Latin, r:Roman
to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
buffer code: #x6C
file code: #x6C (encoded by coding system utf-8-dos)
display: composed to form "lambda" (see below)
Composed with the following character(s) "ambda" by the rule:
(?l ?a ?m ?b ?d ?a)
The component character(s) are displayed by these fonts (glyph codes):
l: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x4F)
a: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x44)
m: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x50)
b: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x45)
d: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x47)
a: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x44)
See the variable `reference-point-alist' for the meaning of the rule.
Character code properties: customize what to show
name: LATIN SMALL LETTER L
general-category: Ll (Letter, Lowercase)
decomposition: (108) ('l')
There are text properties here:
composition [Show]
face font-lock-keyword-face
fontified t
[-- Attachment #2: bug.png --]
[-- Type: image/png, Size: 1926 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-12 3:18 bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled Juanma Barranquero
@ 2013-06-15 8:21 ` Ted Zlatanov
2013-06-15 9:00 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Ted Zlatanov @ 2013-06-15 8:21 UTC (permalink / raw)
To: 14595
On Wed, 12 Jun 2013 05:18:59 +0200 Juanma Barranquero <lekktu@gmail.com> wrote:
JB> If I visit lambda.el as in the example above, and scroll down the
JB> buffer, I get 26 such failures, always at the same lines (168, 280,
JB> 364, 432, 489, 538, 581, 619, 654, 686, 715, 742, 767, 791, 813, 834,
JB> 854, 873, 891, 908, 924, 940, 955, 970, 984 and 998); however, if upon
JB> visiting the file I go to the end of the buffer and scroll up, I get
JB> many more failures (about 60) at diferent lines, but also consistently
JB> the same lines.
Ouch. I don't think I'm doing anything strange in the fontification
keywords that implement the new prettification functionality, but why
wasn't this seen before? The scroll behavior probably indicates a
display engine issue.
Ted
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-15 8:21 ` Ted Zlatanov
@ 2013-06-15 9:00 ` Eli Zaretskii
2013-06-15 9:12 ` Eli Zaretskii
2013-06-16 0:17 ` Ted Zlatanov
0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2013-06-15 9:00 UTC (permalink / raw)
To: 14595
> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sat, 15 Jun 2013 04:21:44 -0400
>
> On Wed, 12 Jun 2013 05:18:59 +0200 Juanma Barranquero <lekktu@gmail.com> wrote:
>
> JB> If I visit lambda.el as in the example above, and scroll down the
> JB> buffer, I get 26 such failures, always at the same lines (168, 280,
> JB> 364, 432, 489, 538, 581, 619, 654, 686, 715, 742, 767, 791, 813, 834,
> JB> 854, 873, 891, 908, 924, 940, 955, 970, 984 and 998); however, if upon
> JB> visiting the file I go to the end of the buffer and scroll up, I get
> JB> many more failures (about 60) at diferent lines, but also consistently
> JB> the same lines.
>
> Ouch. I don't think I'm doing anything strange in the fontification
> keywords that implement the new prettification functionality, but why
> wasn't this seen before? The scroll behavior probably indicates a
> display engine issue.
What issue would that be?
The problem here is that the composition rule is generated
incorrectly.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-15 9:00 ` Eli Zaretskii
@ 2013-06-15 9:12 ` Eli Zaretskii
2013-06-15 17:35 ` Juanma Barranquero
2013-06-16 0:17 ` Ted Zlatanov
1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2013-06-15 9:12 UTC (permalink / raw)
To: 14595; +Cc: Juanma Barranquero
> Date: Sat, 15 Jun 2013 12:00:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Ted Zlatanov <tzz@lifelogs.com>
> > Date: Sat, 15 Jun 2013 04:21:44 -0400
> >
> > On Wed, 12 Jun 2013 05:18:59 +0200 Juanma Barranquero <lekktu@gmail.com> wrote:
> >
> > JB> If I visit lambda.el as in the example above, and scroll down the
> > JB> buffer, I get 26 such failures, always at the same lines (168, 280,
> > JB> 364, 432, 489, 538, 581, 619, 654, 686, 715, 742, 767, 791, 813, 834,
> > JB> 854, 873, 891, 908, 924, 940, 955, 970, 984 and 998); however, if upon
> > JB> visiting the file I go to the end of the buffer and scroll up, I get
> > JB> many more failures (about 60) at diferent lines, but also consistently
> > JB> the same lines.
> >
> > Ouch. I don't think I'm doing anything strange in the fontification
> > keywords that implement the new prettification functionality, but why
> > wasn't this seen before? The scroll behavior probably indicates a
> > display engine issue.
>
> What issue would that be?
>
> The problem here is that the composition rule is generated
> incorrectly.
And here's why:
The incorrect display happens when the underlined part below
(compose-region start end (cdr (assoc (match-string 0) alist)))))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
is nil. When that happens, (match-string 0) is "(", the left
parenthesis, not the expected "lambda".
I hope fontification gurus will be able to tell us why this could
happen.
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-15 9:12 ` Eli Zaretskii
@ 2013-06-15 17:35 ` Juanma Barranquero
2013-06-15 17:49 ` Juanma Barranquero
0 siblings, 1 reply; 16+ messages in thread
From: Juanma Barranquero @ 2013-06-15 17:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14595
On Sat, Jun 15, 2013 at 11:12 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> The incorrect display happens when the underlined part below
>
> (compose-region start end (cdr (assoc (match-string 0) alist)))))
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> is nil. When that happens, (match-string 0) is "(", the left
> parenthesis, not the expected "lambda".
The call to syntax-ppss inside prog--prettify-font-lock-compose-symbol
is altering the match-string data. I saved (match-string 0) in the
let* as ms0, and then for the erroneous lines I get this log:
start = 2507 / end = 2513 / (match-string 0) = #("(" 0 1 (fontified
t)) / ms0 = #("lambda" 0 6 (fontified t)) / alist = (("lambda" . 955))
so it was correct when the function was called. Then I wrapped the
syntax-ppss call inside save-match-data and the bug disappears.
> I hope fontification gurus will be able to tell us why this could
> happen.
Yep.
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-15 17:35 ` Juanma Barranquero
@ 2013-06-15 17:49 ` Juanma Barranquero
2013-06-15 20:51 ` Juanma Barranquero
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Juanma Barranquero @ 2013-06-15 17:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14595
In other words, this simple patch fixes the problem:
=== modified file 'lisp/progmodes/prog-mode.el'
--- lisp/progmodes/prog-mode.el 2013-06-06 21:32:13 +0000
+++ lisp/progmodes/prog-mode.el 2013-06-15 17:47:50 +0000
@@ -77,7 +77,7 @@
'(?w) '(?. ?\\))))
(if (or (memq (char-syntax (or (char-before start) ?\ )) syntaxes)
(memq (char-syntax (or (char-after end) ?\ )) syntaxes)
- (nth 8 (syntax-ppss)))
+ (nth 8 (save-match-data (syntax-ppss))))
;; No composition for you. Let's actually remove any composition
;; we may have added earlier and which is now incorrect.
(remove-text-properties start end '(composition))
but, it would still be nice to know why syntax-ppss destroys
(match-data 0) in some lines and not all of them.
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-15 17:49 ` Juanma Barranquero
@ 2013-06-15 20:51 ` Juanma Barranquero
2013-06-16 0:13 ` Ted Zlatanov
2013-06-16 0:53 ` Stefan Monnier
2 siblings, 0 replies; 16+ messages in thread
From: Juanma Barranquero @ 2013-06-15 20:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14595
On Sat, Jun 15, 2013 at 7:49 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> In other words, this simple patch fixes the problem:
This one is presumably cheaper:
=== modified file 'lisp/progmodes/prog-mode.el'
--- lisp/progmodes/prog-mode.el 2013-06-06 21:32:13 +0000
+++ lisp/progmodes/prog-mode.el 2013-06-15 20:50:09 +0000
@@ -74,15 +74,17 @@
(let* ((start (match-beginning 0))
(end (match-end 0))
(syntaxes (if (eq (char-syntax (char-after start)) ?w)
- '(?w) '(?. ?\\))))
+ '(?w) '(?. ?\\)))
+ match)
(if (or (memq (char-syntax (or (char-before start) ?\ )) syntaxes)
(memq (char-syntax (or (char-after end) ?\ )) syntaxes)
- (nth 8 (syntax-ppss)))
+ ;; syntax-ppss can modify the match data
+ (progn (setq match (match-string 0)) (nth 8 (syntax-ppss))))
;; No composition for you. Let's actually remove any composition
;; we may have added earlier and which is now incorrect.
(remove-text-properties start end '(composition))
;; That's a symbol alright, so add the composition.
- (compose-region start end (cdr (assoc (match-string 0) alist)))))
+ (compose-region start end (cdr (assoc match alist)))))
;; Return nil because we're not adding any face property.
nil)
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-15 17:49 ` Juanma Barranquero
2013-06-15 20:51 ` Juanma Barranquero
@ 2013-06-16 0:13 ` Ted Zlatanov
2013-06-16 0:53 ` Stefan Monnier
2 siblings, 0 replies; 16+ messages in thread
From: Ted Zlatanov @ 2013-06-16 0:13 UTC (permalink / raw)
To: 14595
On Sat, 15 Jun 2013 19:49:10 +0200 Juanma Barranquero <lekktu@gmail.com> wrote:
JB> In other words, this simple patch fixes the problem:
JB> === modified file 'lisp/progmodes/prog-mode.el'
JB> --- lisp/progmodes/prog-mode.el 2013-06-06 21:32:13 +0000
JB> +++ lisp/progmodes/prog-mode.el 2013-06-15 17:47:50 +0000
JB> @@ -77,7 +77,7 @@
JB> '(?w) '(?. ?\\))))
JB> (if (or (memq (char-syntax (or (char-before start) ?\ )) syntaxes)
JB> (memq (char-syntax (or (char-after end) ?\ )) syntaxes)
JB> - (nth 8 (syntax-ppss)))
JB> + (nth 8 (save-match-data (syntax-ppss))))
JB> ;; No composition for you. Let's actually remove any composition
JB> ;; we may have added earlier and which is now incorrect.
JB> (remove-text-properties start end '(composition))
Nice catch.
JB> but, it would still be nice to know why syntax-ppss destroys
JB> (match-data 0) in some lines and not all of them.
I took this code out of `perl-mode' but didn't write it. I hope someone
else can answer.
Ted
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-15 17:49 ` Juanma Barranquero
2013-06-15 20:51 ` Juanma Barranquero
2013-06-16 0:13 ` Ted Zlatanov
@ 2013-06-16 0:53 ` Stefan Monnier
2013-06-16 1:19 ` Juanma Barranquero
2 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2013-06-16 0:53 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 14595
> but, it would still be nice to know why syntax-ppss destroys
> (match-data 0) in some lines and not all of them.
syntax-ppss does many different things in different cases (e.g. it may
run syntax-propertize), so it's no wonder.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-15 9:00 ` Eli Zaretskii
2013-06-15 9:12 ` Eli Zaretskii
@ 2013-06-16 0:17 ` Ted Zlatanov
2013-06-16 2:50 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Ted Zlatanov @ 2013-06-16 0:17 UTC (permalink / raw)
To: 14595
On Sat, 15 Jun 2013 12:00:04 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Sat, 15 Jun 2013 04:21:44 -0400
>>
>> On Wed, 12 Jun 2013 05:18:59 +0200 Juanma Barranquero <lekktu@gmail.com> wrote:
>>
JB> If I visit lambda.el as in the example above, and scroll down the
JB> buffer, I get 26 such failures, always at the same lines (168, 280,
JB> 364, 432, 489, 538, 581, 619, 654, 686, 715, 742, 767, 791, 813, 834,
JB> 854, 873, 891, 908, 924, 940, 955, 970, 984 and 998); however, if upon
JB> visiting the file I go to the end of the buffer and scroll up, I get
JB> many more failures (about 60) at diferent lines, but also consistently
JB> the same lines.
>>
>> Ouch. I don't think I'm doing anything strange in the fontification
>> keywords that implement the new prettification functionality, but why
>> wasn't this seen before? The scroll behavior probably indicates a
>> display engine issue.
EZ> What issue would that be?
EZ> The problem here is that the composition rule is generated
EZ> incorrectly.
I understand that part and Juanma posted a patch that looks helpful.
The scroll behavior he described is strangely inconsistent. If you
think it's OK to display inconsistent data with bad input data (which
IIUC is what's happening), then there's no issue. I don't know if it's
OK to display inconsistent lines like that, so I leave it to you and Juanma.
Ted
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-16 0:17 ` Ted Zlatanov
@ 2013-06-16 2:50 ` Eli Zaretskii
2013-06-16 3:01 ` Juanma Barranquero
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2013-06-16 2:50 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 14595
> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sat, 15 Jun 2013 20:17:20 -0400
>
> The scroll behavior [Juanma] described is strangely inconsistent. If you
> think it's OK to display inconsistent data with bad input data (which
> IIUC is what's happening), then there's no issue. I don't know if it's
> OK to display inconsistent lines like that, so I leave it to you and Juanma.
I wasn't aware of any inconsistent display or scrolling behavior in
his description. Juanma, can you repeat that description, which I
probably missed?
Thanks.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-16 2:50 ` Eli Zaretskii
@ 2013-06-16 3:01 ` Juanma Barranquero
2013-06-16 9:27 ` Ted Zlatanov
0 siblings, 1 reply; 16+ messages in thread
From: Juanma Barranquero @ 2013-06-16 3:01 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14595
On Sun, Jun 16, 2013 at 4:50 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> I wasn't aware of any inconsistent display or scrolling behavior in
> his description. Juanma, can you repeat that description, which I
> probably missed?
With a file containing 1000 identical lines "(lambda (x) x)", the
lambdas that were incorrectly composed depend on the direction you
scroll the buffer. Scrolling from the beginning towards the end (page
by page), I got about 30 errors, always in the same positions
(distributed non-uniformly). If you repeat the experiment, but go
immediately to the end and scroll up, you got a different number of
errors (double or so) at different possitions, also consistents from
one run to the next.
I suppose that's what Ted is talking about.
J
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-16 3:01 ` Juanma Barranquero
@ 2013-06-16 9:27 ` Ted Zlatanov
2013-06-16 16:17 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Ted Zlatanov @ 2013-06-16 9:27 UTC (permalink / raw)
To: 14595
On Sun, 16 Jun 2013 05:01:48 +0200 Juanma Barranquero <lekktu@gmail.com> wrote:
JB> On Sun, Jun 16, 2013 at 4:50 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> I wasn't aware of any inconsistent display or scrolling behavior in
>> his description. Juanma, can you repeat that description, which I
>> probably missed?
JB> With a file containing 1000 identical lines "(lambda (x) x)", the
JB> lambdas that were incorrectly composed depend on the direction you
JB> scroll the buffer. Scrolling from the beginning towards the end (page
JB> by page), I got about 30 errors, always in the same positions
JB> (distributed non-uniformly). If you repeat the experiment, but go
JB> immediately to the end and scroll up, you got a different number of
JB> errors (double or so) at different possitions, also consistents from
JB> one run to the next.
JB> I suppose that's what Ted is talking about.
Yes. Again, I don't know if this is a problem worth fixing, I was just
clarifying how it's inconsistent depending on the scroll direction.
Ted
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled
2013-06-16 9:27 ` Ted Zlatanov
@ 2013-06-16 16:17 ` Eli Zaretskii
0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2013-06-16 16:17 UTC (permalink / raw)
To: 14595
> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sun, 16 Jun 2013 05:27:50 -0400
>
> On Sun, 16 Jun 2013 05:01:48 +0200 Juanma Barranquero <lekktu@gmail.com> wrote:
>
> JB> On Sun, Jun 16, 2013 at 4:50 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> I wasn't aware of any inconsistent display or scrolling behavior in
> >> his description. Juanma, can you repeat that description, which I
> >> probably missed?
>
> JB> With a file containing 1000 identical lines "(lambda (x) x)", the
> JB> lambdas that were incorrectly composed depend on the direction you
> JB> scroll the buffer. Scrolling from the beginning towards the end (page
> JB> by page), I got about 30 errors, always in the same positions
> JB> (distributed non-uniformly). If you repeat the experiment, but go
> JB> immediately to the end and scroll up, you got a different number of
> JB> errors (double or so) at different possitions, also consistents from
> JB> one run to the next.
>
> JB> I suppose that's what Ted is talking about.
>
> Yes. Again, I don't know if this is a problem worth fixing, I was just
> clarifying how it's inconsistent depending on the scroll direction.
It's not a problem. There's no symmetry in how the display engine
handles scrolling up and down, so it exposes portions of the buffer to
font-lock differently depending on the direction of the scroll.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-06-16 16:17 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-12 3:18 bug#14595: Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled Juanma Barranquero
2013-06-15 8:21 ` Ted Zlatanov
2013-06-15 9:00 ` Eli Zaretskii
2013-06-15 9:12 ` Eli Zaretskii
2013-06-15 17:35 ` Juanma Barranquero
2013-06-15 17:49 ` Juanma Barranquero
2013-06-15 20:51 ` Juanma Barranquero
2013-06-16 0:13 ` Ted Zlatanov
2013-06-16 0:53 ` Stefan Monnier
2013-06-16 1:19 ` Juanma Barranquero
2013-06-16 1:32 ` Juanma Barranquero
2013-06-16 0:17 ` Ted Zlatanov
2013-06-16 2:50 ` Eli Zaretskii
2013-06-16 3:01 ` Juanma Barranquero
2013-06-16 9:27 ` Ted Zlatanov
2013-06-16 16:17 ` 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).