* bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis
@ 2020-10-11 14:30 積丹尼 Dan Jacobson
2020-10-12 14:48 ` Eli Zaretskii
0 siblings, 1 reply; 19+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-10-11 14:30 UTC (permalink / raw)
To: 43941
$ emacs -q x.html # emacs-version "26.3"
The humble APOSTROPHE becomes a color change point, due to having a
FULLWIDTH LEFT PARENTHESIS before it.
$ cat x.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>TEST</title>
</head>
<body>
<p>（當然… Sure, you could say
what does this matter to me? It's the <strong>farthest</strong>
thing from my mind.）</p>
<p>計算您對蹠點極為容易： 只不過是經度轉一八○度， 緯度的南北互換。 Computing your antipode is so
simple. Just rotate your longitude 180 degrees and flip your
latitude's north vs. south.</p>
</body>
</html>
^ permalink raw reply [flat|nested] 19+ messages in thread* bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis
2020-10-11 14:30 bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis 積丹尼 Dan Jacobson
@ 2020-10-12 14:48 ` Eli Zaretskii
2020-10-12 14:52 ` 積丹尼 Dan Jacobson
2020-10-12 15:11 ` Stephen Berman
0 siblings, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2020-10-12 14:48 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: 43941
> From: 積丹尼 Dan Jacobson
> <jidanni@jidanni.org>
> Date: Sun, 11 Oct 2020 22:30:16 +0800
>
> $ emacs -q x.html # emacs-version "26.3"
> The humble APOSTROPHE becomes a color change point, due to having a
> FULLWIDTH LEFT PARENTHESIS before it.
I don't think it has anything to do with FULLWIDTH LEFT PARENTHESIS, I
think the apostrophe invokes the string face here.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis
2020-10-12 14:48 ` Eli Zaretskii
@ 2020-10-12 14:52 ` 積丹尼 Dan Jacobson
2020-10-12 15:11 ` Stephen Berman
1 sibling, 0 replies; 19+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-10-12 14:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 43941
>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
EZ> I don't think it has anything to do with FULLWIDTH LEFT PARENTHESIS, I
EZ> think the apostrophe invokes the string face here.
Well I have to use <!-- ' --> to turn it back off.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis
2020-10-12 14:48 ` Eli Zaretskii
2020-10-12 14:52 ` 積丹尼 Dan Jacobson
@ 2020-10-12 15:11 ` Stephen Berman
2020-10-12 15:20 ` Eli Zaretskii
1 sibling, 1 reply; 19+ messages in thread
From: Stephen Berman @ 2020-10-12 15:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 43941, 積丹尼 Dan Jacobson
On Mon, 12 Oct 2020 17:48:52 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: 積丹尼 Dan Jacobson
>> <jidanni@jidanni.org>
>> Date: Sun, 11 Oct 2020 22:30:16 +0800
>>
>> $ emacs -q x.html # emacs-version "26.3"
>> The humble APOSTROPHE becomes a color change point, due to having a
>> FULLWIDTH LEFT PARENTHESIS before it.
>
> I don't think it has anything to do with FULLWIDTH LEFT PARENTHESIS, I
> think the apostrophe invokes the string face here.
But the face does not change if `(' is used instead of `（', e.g. copy
the following two lines into a buffer and type `M-x html-mode' (or `M-x
mhtml-mode', the face change appears in both):
<p>('s</p>
<p>（'s</p>
Steve Berman
^ permalink raw reply [flat|nested] 19+ messages in thread* bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis
2020-10-12 15:11 ` Stephen Berman
@ 2020-10-12 15:20 ` Eli Zaretskii
2020-10-12 16:17 ` Stephen Berman
0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2020-10-12 15:20 UTC (permalink / raw)
To: Stephen Berman; +Cc: 43941, jidanni
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 積丹尼 Dan Jacobson <jidanni@jidanni.org>,
> 43941@debbugs.gnu.org
> Date: Mon, 12 Oct 2020 17:11:01 +0200
>
> >> The humble APOSTROPHE becomes a color change point, due to having a
> >> FULLWIDTH LEFT PARENTHESIS before it.
> >
> > I don't think it has anything to do with FULLWIDTH LEFT PARENTHESIS, I
> > think the apostrophe invokes the string face here.
>
> But the face does not change if `(' is used instead of `（', e.g. copy
> the following two lines into a buffer and type `M-x html-mode' (or `M-x
> mhtml-mode', the face change appears in both):
So which of them is a bug?
^ permalink raw reply [flat|nested] 19+ messages in thread* bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis
2020-10-12 15:20 ` Eli Zaretskii
@ 2020-10-12 16:17 ` Stephen Berman
2020-10-12 16:29 ` Eli Zaretskii
0 siblings, 1 reply; 19+ messages in thread
From: Stephen Berman @ 2020-10-12 16:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stephen Berman, 43941, jidanni
On Mon, 12 Oct 2020 18:20:58 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 積丹尼 Dan Jacobson <jidanni@jidanni.org>,
>> 43941@debbugs.gnu.org
>> Date: Mon, 12 Oct 2020 17:11:01 +0200
>>
>> >> The humble APOSTROPHE becomes a color change point, due to having a
>> >> FULLWIDTH LEFT PARENTHESIS before it.
>> >
>> > I don't think it has anything to do with FULLWIDTH LEFT PARENTHESIS, I
>> > think the apostrophe invokes the string face here.
>>
>> But the face does not change if `(' is used instead of `（', e.g. copy
>> the following two lines into a buffer and type `M-x html-mode' (or `M-x
>> mhtml-mode', the face change appears in both):
>
> So which of them is a bug?
In the context of the OP it seems clear that string face is wrong. So
in my simpler example, that means the display of the second line
containing FULLWIDTH LEFT PARENTHESIS is buggy.
Steve Berman
^ permalink raw reply [flat|nested] 19+ messages in thread* bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis
2020-10-12 16:17 ` Stephen Berman
@ 2020-10-12 16:29 ` Eli Zaretskii
2020-10-12 17:21 ` Stephen Berman
0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2020-10-12 16:29 UTC (permalink / raw)
To: Stephen Berman; +Cc: 43941, jidanni
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Stephen Berman <stephen.berman@gmx.net>, jidanni@jidanni.org,
> 43941@debbugs.gnu.org
> Date: Mon, 12 Oct 2020 18:17:41 +0200
>
> >> But the face does not change if `(' is used instead of `（', e.g. copy
> >> the following two lines into a buffer and type `M-x html-mode' (or `M-x
> >> mhtml-mode', the face change appears in both):
> >
> > So which of them is a bug?
>
> In the context of the OP it seems clear that string face is wrong. So
> in my simpler example, that means the display of the second line
> containing FULLWIDTH LEFT PARENTHESIS is buggy.
Do the ASCII parentheses have some syntactic significance in this
context, then? If not, why do the parentheses affect the meaning of
the apostrophe?
^ permalink raw reply [flat|nested] 19+ messages in thread* bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis
2020-10-12 16:29 ` Eli Zaretskii
@ 2020-10-12 17:21 ` Stephen Berman
2020-10-12 17:38 ` Eli Zaretskii
0 siblings, 1 reply; 19+ messages in thread
From: Stephen Berman @ 2020-10-12 17:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stephen Berman, 43941, jidanni
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]
On Mon, 12 Oct 2020 19:29:07 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Stephen Berman <stephen.berman@gmx.net>, jidanni@jidanni.org,
>> 43941@debbugs.gnu.org
>> Date: Mon, 12 Oct 2020 18:17:41 +0200
>>
>> >> But the face does not change if `(' is used instead of `（', e.g. copy
>> >> the following two lines into a buffer and type `M-x html-mode' (or `M-x
>> >> mhtml-mode', the face change appears in both):
>> >
>> > So which of them is a bug?
>>
>> In the context of the OP it seems clear that string face is wrong. So
>> in my simpler example, that means the display of the second line
>> containing FULLWIDTH LEFT PARENTHESIS is buggy.
>
> Do the ASCII parentheses have some syntactic significance in this
> context, then? If not, why do the parentheses affect the meaning of
> the apostrophe?
It seems they do have some syntactic significance, since the following
patch prevents string face in the examples with FULLWIDTH LEFT
PARENTHESIS:
[-- Attachment #2: sgml-mode.el patch --]
[-- Type: text/x-patch, Size: 614 bytes --]
diff --git a/lisp/textmodes/sgml-mode.el b/lisp/textmodes/sgml-mode.el
index f3d8695e24..92a2215ed7 100644
--- a/lisp/textmodes/sgml-mode.el
+++ b/lisp/textmodes/sgml-mode.el
@@ -193,7 +193,7 @@ sgml-mode-syntax-table
(defconst sgml-tag-syntax-table
(let ((table (sgml-make-syntax-table sgml-specials)))
- (dolist (char '(?\( ?\) ?\{ ?\} ?\[ ?\] ?$ ?% ?& ?* ?+ ?/))
+ (dolist (char '(?\( ?\) ?\{ ?\} ?\[ ?\] ?$ ?% ?& ?* ?+ ?/ ?（))
(modify-syntax-entry char "." table))
(unless (memq ?' sgml-specials)
;; Avoid that skipping a tag backwards skips any "'" prefixing it.
[-- Attachment #3: Type: text/plain, Size: 129 bytes --]
If this is the right approach, then all such characters would have to be
added, or is there a better alternative?
Steve Berman
^ permalink raw reply related [flat|nested] 19+ messages in thread* bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis
2020-10-12 17:21 ` Stephen Berman
@ 2020-10-12 17:38 ` Eli Zaretskii
2020-10-12 21:26 ` Stephen Berman
0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2020-10-12 17:38 UTC (permalink / raw)
To: Stephen Berman; +Cc: 43941, jidanni
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Stephen Berman <stephen.berman@gmx.net>, jidanni@jidanni.org,
> 43941@debbugs.gnu.org
> Date: Mon, 12 Oct 2020 19:21:08 +0200
>
> diff --git a/lisp/textmodes/sgml-mode.el b/lisp/textmodes/sgml-mode.el
> index f3d8695e24..92a2215ed7 100644
> --- a/lisp/textmodes/sgml-mode.el
> +++ b/lisp/textmodes/sgml-mode.el
> @@ -193,7 +193,7 @@ sgml-mode-syntax-table
>
> (defconst sgml-tag-syntax-table
> (let ((table (sgml-make-syntax-table sgml-specials)))
> - (dolist (char '(?\( ?\) ?\{ ?\} ?\[ ?\] ?$ ?% ?& ?* ?+ ?/))
> + (dolist (char '(?\( ?\) ?\{ ?\} ?\[ ?\] ?$ ?% ?& ?* ?+ ?/ ?（))
> (modify-syntax-entry char "." table))
> (unless (memq ?' sgml-specials)
> ;; Avoid that skipping a tag backwards skips any "'" prefixing it.
>
> If this is the right approach, then all such characters would have to be
> added, or is there a better alternative?
It shouldn't be hard to add to the list some of the characters that
have the paired bracket semantics, see uni-brackets.el. But some
SGML/HTML expert should say if that is TRT, indeed.
^ permalink raw reply [flat|nested] 19+ messages in thread* bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis
2020-10-12 17:38 ` Eli Zaretskii
@ 2020-10-12 21:26 ` Stephen Berman
2020-10-13 10:37 ` Stephen Berman
0 siblings, 1 reply; 19+ messages in thread
From: Stephen Berman @ 2020-10-12 21:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 43941, jidanni
[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]
On Mon, 12 Oct 2020 20:38:15 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Stephen Berman <stephen.berman@gmx.net>, jidanni@jidanni.org,
>> 43941@debbugs.gnu.org
>> Date: Mon, 12 Oct 2020 19:21:08 +0200
>>
>> diff --git a/lisp/textmodes/sgml-mode.el b/lisp/textmodes/sgml-mode.el
>> index f3d8695e24..92a2215ed7 100644
>> --- a/lisp/textmodes/sgml-mode.el
>> +++ b/lisp/textmodes/sgml-mode.el
>> @@ -193,7 +193,7 @@ sgml-mode-syntax-table
>>
>> (defconst sgml-tag-syntax-table
>> (let ((table (sgml-make-syntax-table sgml-specials)))
>> - (dolist (char '(?\( ?\) ?\{ ?\} ?\[ ?\] ?$ ?% ?& ?* ?+ ?/))
>> + (dolist (char '(?\( ?\) ?\{ ?\} ?\[ ?\] ?$ ?% ?& ?* ?+ ?/ ?（))
>> (modify-syntax-entry char "." table))
>> (unless (memq ?' sgml-specials)
>> ;; Avoid that skipping a tag backwards skips any "'" prefixing it.
>>
>> If this is the right approach, then all such characters would have to be
>> added, or is there a better alternative?
>
> It shouldn't be hard to add to the list some of the characters that
> have the paired bracket semantics, see uni-brackets.el.
Some, but which? I used the following the code to add all the
paired-bracket characters listed in that file:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sgml-mode-syntax-table patch --]
[-- Type: text/x-patch, Size: 1115 bytes --]
diff --git a/lisp/textmodes/sgml-mode.el b/lisp/textmodes/sgml-mode.el
index f3d8695e24..c2c3f61e3d 100644
--- a/lisp/textmodes/sgml-mode.el
+++ b/lisp/textmodes/sgml-mode.el
@@ -192,8 +192,20 @@ sgml-mode-syntax-table
"Syntax table used in SGML mode. See also `sgml-specials'.")
(defconst sgml-tag-syntax-table
- (let ((table (sgml-make-syntax-table sgml-specials)))
- (dolist (char '(?\( ?\) ?\{ ?\} ?\[ ?\] ?$ ?% ?& ?* ?+ ?/))
+ (let ((table (sgml-make-syntax-table sgml-specials))
+ brackets)
+ (setq brackets (delete-dups
+ (flatten-tree
+ (map-char-table
+ (lambda (key value)
+ (setq brackets (cons (list
+ (if (consp key)
+ (list (car key) (cdr key))
+ key)
+ value)
+ brackets)))
+ (unicode-property-table-internal 'paired-bracket)))))
+ (dolist (char (append brackets (list ?$ ?% ?& ?* ?+ ?/)))
(modify-syntax-entry char "." table))
(unless (memq ?' sgml-specials)
;; Avoid that skipping a tag backwards skips any "'" prefixing it.
[-- Attachment #3: Type: text/plain, Size: 429 bytes --]
But this fails to prevent the unwanted string face fontification.
According to the above code, there are 120 different paired-bracket
characters, so it will be time-consuming to isolate just the ones that
work.
> But some
> SGML/HTML expert should say if that is TRT, indeed.
Yes, hopefully before Someone™ toils through the 120 characters.
Steve Berman
^ permalink raw reply related [flat|nested] 19+ messages in thread* bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis
2020-10-12 21:26 ` Stephen Berman
@ 2020-10-13 10:37 ` Stephen Berman
2021-06-13 12:21 ` bug#43941: bug#40844: html mode sometimes fooled by apostrophe Lars Ingebrigtsen
0 siblings, 1 reply; 19+ messages in thread
From: Stephen Berman @ 2020-10-13 10:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 43941, jidanni
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
On Mon, 12 Oct 2020 23:26:15 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:
> On Mon, 12 Oct 2020 20:38:15 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>
[...]
>> It shouldn't be hard to add to the list some of the characters that
>> have the paired bracket semantics, see uni-brackets.el.
>
> Some, but which? I used the following the code to add all the
> paired-bracket characters listed in that file:
[...]
> But this fails to prevent the unwanted string face fontification.
I made a silly mistake (it was late and I was tired). Here is a
corrected version:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sgml-mode-syntax-table patch --]
[-- Type: text/x-patch, Size: 1061 bytes --]
diff --git a/lisp/textmodes/sgml-mode.el b/lisp/textmodes/sgml-mode.el
index f3d8695e24..26ca536004 100644
--- a/lisp/textmodes/sgml-mode.el
+++ b/lisp/textmodes/sgml-mode.el
@@ -192,8 +192,19 @@ sgml-mode-syntax-table
"Syntax table used in SGML mode. See also `sgml-specials'.")
(defconst sgml-tag-syntax-table
- (let ((table (sgml-make-syntax-table sgml-specials)))
- (dolist (char '(?\( ?\) ?\{ ?\} ?\[ ?\] ?$ ?% ?& ?* ?+ ?/))
+ (let ((table (sgml-make-syntax-table sgml-specials))
+ brackets)
+ (map-char-table
+ (lambda (key value)
+ (setq brackets (cons (list
+ (if (consp key)
+ (list (car key) (cdr key))
+ key)
+ value)
+ brackets)))
+ (unicode-property-table-internal 'paired-bracket))
+ (setq brackets (delete-dups (flatten-tree brackets)))
+ (dolist (char (append brackets (list ?$ ?% ?& ?* ?+ ?/)))
(modify-syntax-entry char "." table))
(unless (memq ?' sgml-specials)
;; Avoid that skipping a tag backwards skips any "'" prefixing it.
[-- Attachment #3: Type: text/plain, Size: 1738 bytes --]
With this patch, when any of the paired-bracket characters is followed
by `'' in html-mode, there is indeed no string face fontification on the
latter (and following characters). The following function demonstrates
this:
(defun sgml-test-brackets ()
"Test fontification of apostrophe preceded by paired-bracket character."
(interactive)
(let ((buf (get-buffer-create "*sgml-test*"))
brackets results)
(map-char-table
(lambda (key value)
(setq brackets (cons (list
(if (consp key)
(list (car key) (cdr key))
key)
value)
brackets)))
(unicode-property-table-internal 'paired-bracket))
(setq brackets (delete-dups (flatten-tree brackets)))
(setq brackets (append brackets (list ?$ ?% ?& ?* ?+ ?/)))
(while brackets
(let ((char (string (pop brackets)))
(face "default"))
(with-current-buffer buf
;; (erase-buffer)
(fundamental-mode)
(insert (concat "<p>" char "'s</p>\n"))
(html-mode)
;; (let ((val (get-text-property 5 'face)))
;; (when val (setq face (symbol-name val))))
;; (push (concat char " : " face "\n") results)
)))
;; (with-current-buffer buf
;; (newline)
;; (while results
;; (insert (pop results))))
(switch-to-buffer buf)))
I wanted to turn this function into a test, and that's what the
commented out lines are supposed to do. But when I uncomment these
lines and call this function with the unpatched (i.e. current) version
of sgml-mode-syntax-table, it still shows default face for `'' with all
the paired-bracket characters. Yet when I step through the function
with Ediff, I do see some cases with font-lock-string-face. I don't
understand what's going on here.
Steve Berman
^ permalink raw reply related [flat|nested] 19+ messages in thread* bug#43941: bug#40844: html mode sometimes fooled by apostrophe
2020-10-13 10:37 ` Stephen Berman
@ 2021-06-13 12:21 ` Lars Ingebrigtsen
2021-06-13 18:14 ` Stephen Berman
0 siblings, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-13 12:21 UTC (permalink / raw)
To: Stephen Berman; +Cc: 40844, 43941, jidanni
Stephen Berman <stephen.berman@gmx.net> writes:
> I made a silly mistake (it was late and I was tired). Here is a
> corrected version:
I can confirm that this patch solves the test cases here.
> With this patch, when any of the paired-bracket characters is followed
> by `'' in html-mode, there is indeed no string face fontification on the
> latter (and following characters). The following function demonstrates
> this:
[...]
> I wanted to turn this function into a test, and that's what the
> commented out lines are supposed to do. But when I uncomment these
> lines and call this function with the unpatched (i.e. current) version
> of sgml-mode-syntax-table, it still shows default face for `'' with all
> the paired-bracket characters. Yet when I step through the function
> with Ediff, I do see some cases with font-lock-string-face. I don't
> understand what's going on here.
Might be a timing issue, perhaps?
In any case, the patch is an improvement, so perhaps that should be
pushed anyway?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#40844: html mode sometimes fooled by apostrophe
2021-06-13 12:21 ` bug#43941: bug#40844: html mode sometimes fooled by apostrophe Lars Ingebrigtsen
@ 2021-06-13 18:14 ` Stephen Berman
2021-06-14 13:00 ` bug#43941: bug#46312: HTML+ mode vs. quotes Lars Ingebrigtsen
0 siblings, 1 reply; 19+ messages in thread
From: Stephen Berman @ 2021-06-13 18:14 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 40844, 43941, jidanni
On Sun, 13 Jun 2021 14:21:36 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> I made a silly mistake (it was late and I was tired). Here is a
>> corrected version:
>
> I can confirm that this patch solves the test cases here.
Thanks for checking.
>> With this patch, when any of the paired-bracket characters is followed
>> by `'' in html-mode, there is indeed no string face fontification on the
>> latter (and following characters). The following function demonstrates
>> this:
>
> [...]
>
>> I wanted to turn this function into a test, and that's what the
>> commented out lines are supposed to do. But when I uncomment these
>> lines and call this function with the unpatched (i.e. current) version
>> of sgml-mode-syntax-table, it still shows default face for `'' with all
>> the paired-bracket characters. Yet when I step through the function
>> with Ediff, I do see some cases with font-lock-string-face. I don't
>> understand what's going on here.
>
> Might be a timing issue, perhaps?
I tried adding sit-for at different points but it made no difference.
> In any case, the patch is an improvement, so perhaps that should be
> pushed anyway?
Upthread Eli said "some SGML/HTML expert should say if that is TRT".
I'm no such expert so I can't make that decision. FWIW, I rewrote the
test using ert, and the result is as above: it passes with the patch, as
expected, but also without the patch, even though in the latter case the
test buffer clearly contains characters fontified with
font-lock-string-face. And just as I wrote above, when stepping through
the ert-deftest using the unpatched sgml-tag-syntax-table, the test does
fail as expected. Here's the test, in case someone else wants to see if
they can figure it out; I haven't succeeded:
(ert-deftest sgml-test-brackets ()
"Test fontification of apostrophe preceded by paired-bracket character."
(let ((buf (get-buffer-create "*sgml-test*"))
brackets results)
(map-char-table
(lambda (key value)
(setq brackets (cons (list
(if (consp key)
(list (car key) (cdr key))
key)
value)
brackets)))
(unicode-property-table-internal 'paired-bracket))
(setq brackets (delete-dups (flatten-tree brackets)))
(setq brackets (append brackets (list ?$ ?% ?& ?* ?+ ?/)))
(with-current-buffer buf
(erase-buffer)
(fundamental-mode)
(while brackets
(let ((char (string (pop brackets))))
(insert (concat "<p>" char "'s</p>\n"))))
(html-mode)
(goto-char (point-min))
(while (not (eobp))
(goto-char (next-single-char-property-change (point) 'face))
(let ((val (get-text-property (point) 'face)))
(when val
(should-not (eq val 'font-lock-string-face))))))))
Steve Berman
^ permalink raw reply [flat|nested] 19+ messages in thread* bug#43941: bug#46312: HTML+ mode vs. quotes
2021-06-13 18:14 ` Stephen Berman
@ 2021-06-14 13:00 ` Lars Ingebrigtsen
2021-06-14 13:02 ` bug#40844: " Eli Zaretskii
2021-06-14 13:52 ` Stephen Berman
0 siblings, 2 replies; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-14 13:00 UTC (permalink / raw)
To: Stephen Berman; +Cc: 46312, 40844, 43941, jidanni
Stephen Berman <stephen.berman@gmx.net> writes:
> Upthread Eli said "some SGML/HTML expert should say if that is TRT".
> I'm no such expert so I can't make that decision.
I'm not either, but at this point I'd rather apply the patch and then we
can see whether some SGML expert pipes up...
> Here's the test, in case someone else wants to see if
> they can figure it out; I haven't succeeded:
Just needs a `font-lock-ensure' after `html-mode'. :-) Then the test
fails without your patch, and passes with your patch.
So I went ahead and pushed your patch (and the test) to Emacs 28 (with
some minor changes to the test).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#40844: bug#46312: HTML+ mode vs. quotes
2021-06-14 13:00 ` bug#43941: bug#46312: HTML+ mode vs. quotes Lars Ingebrigtsen
@ 2021-06-14 13:02 ` Eli Zaretskii
2021-06-14 13:52 ` Stephen Berman
1 sibling, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2021-06-14 13:02 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 46312, 40844, stephen.berman, 43941, jidanni
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 46312@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
> 40844@debbugs.gnu.org, 43941@debbugs.gnu.org, jidanni@jidanni.org
> Date: Mon, 14 Jun 2021 15:00:16 +0200
>
> Stephen Berman <stephen.berman@gmx.net> writes:
>
> > Upthread Eli said "some SGML/HTML expert should say if that is TRT".
> > I'm no such expert so I can't make that decision.
>
> I'm not either, but at this point I'd rather apply the patch and then we
> can see whether some SGML expert pipes up...
Fine with me.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#46312: HTML+ mode vs. quotes
2021-06-14 13:00 ` bug#43941: bug#46312: HTML+ mode vs. quotes Lars Ingebrigtsen
2021-06-14 13:02 ` bug#40844: " Eli Zaretskii
@ 2021-06-14 13:52 ` Stephen Berman
2021-06-14 13:58 ` bug#43941: " Lars Ingebrigtsen
1 sibling, 1 reply; 19+ messages in thread
From: Stephen Berman @ 2021-06-14 13:52 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 46312, 40844, 43941, jidanni
On Mon, 14 Jun 2021 15:00:16 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Upthread Eli said "some SGML/HTML expert should say if that is TRT".
>> I'm no such expert so I can't make that decision.
>
> I'm not either, but at this point I'd rather apply the patch and then we
> can see whether some SGML expert pipes up...
Sounds good.
>> Here's the test, in case someone else wants to see if
>> they can figure it out; I haven't succeeded:
>
> Just needs a `font-lock-ensure' after `html-mode'. :-) Then the test
> fails without your patch, and passes with your patch.
Ah, thanks. The ways of font lock are unfathomable to me.
> So I went ahead and pushed your patch (and the test) to Emacs 28 (with
> some minor changes to the test).
Thanks. I noticed, unfortunately only just now, that the ert test
includes the unused let-bound variable `results' which I inadvertantly
left behind from the previous version, and which will probably make the
byte-compiler complain.
Steve Berman
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#43941: bug#46312: HTML+ mode vs. quotes
2021-06-14 13:52 ` Stephen Berman
@ 2021-06-14 13:58 ` Lars Ingebrigtsen
0 siblings, 0 replies; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-14 13:58 UTC (permalink / raw)
To: Stephen Berman; +Cc: 46312, 40844, 43941, jidanni
Stephen Berman <stephen.berman@gmx.net> writes:
> Thanks. I noticed, unfortunately only just now, that the ert test
> includes the unused let-bound variable `results' which I inadvertantly
> left behind from the previous version, and which will probably make the
> byte-compiler complain.
Yup; now removed.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#40844: html mode sometimes fooled by apostrophe
@ 2020-04-25 11:26 積丹尼 Dan Jacobson
2020-04-25 14:09 ` Noam Postavsky
0 siblings, 1 reply; 19+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-04-25 11:26 UTC (permalink / raw)
To: 40844
$ wget https://www.jidanni.org/lang/pinyin/older.html
$ emacs -q older.html
You will see that by mid-file, emacs has already got confused by
U+0027 APOSTROPHE
causing it to turn on and off font-lock-string-face!
So there is something in this file that causes it to screw up.
emacs-version "26.3"
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-06-14 13:58 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-11 14:30 bug#43941: HTML+ mode: dangerous apostrophe after fullwidth parenthesis 積丹尼 Dan Jacobson
2020-10-12 14:48 ` Eli Zaretskii
2020-10-12 14:52 ` 積丹尼 Dan Jacobson
2020-10-12 15:11 ` Stephen Berman
2020-10-12 15:20 ` Eli Zaretskii
2020-10-12 16:17 ` Stephen Berman
2020-10-12 16:29 ` Eli Zaretskii
2020-10-12 17:21 ` Stephen Berman
2020-10-12 17:38 ` Eli Zaretskii
2020-10-12 21:26 ` Stephen Berman
2020-10-13 10:37 ` Stephen Berman
2021-06-13 12:21 ` bug#43941: bug#40844: html mode sometimes fooled by apostrophe Lars Ingebrigtsen
2021-06-13 18:14 ` Stephen Berman
2021-06-14 13:00 ` bug#43941: bug#46312: HTML+ mode vs. quotes Lars Ingebrigtsen
2021-06-14 13:02 ` bug#40844: " Eli Zaretskii
2021-06-14 13:52 ` Stephen Berman
2021-06-14 13:58 ` bug#43941: " Lars Ingebrigtsen
-- strict thread matches above, loose matches on Subject: below --
2020-04-25 11:26 bug#40844: html mode sometimes fooled by apostrophe 積丹尼 Dan Jacobson
2020-04-25 14:09 ` Noam Postavsky
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).