GNU bug report logs -
#43941
HTML+ mode: dangerous apostrophe after fullwidth parenthesis
Previous Next
Reported by: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Date: Mon, 12 Oct 2020 05:12:01 UTC
Severity: minor
Tags: confirmed, patch
Merged with 40844,
46312
Found in versions 26.3, 27.0.91
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43941 in the body.
You can then email your comments to 43941 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 12 Oct 2020 05:12:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
積丹尼 Dan Jacobson <jidanni <at> jidanni.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 12 Oct 2020 05:12:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
$ 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>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 12 Oct 2020 14:49:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 43941 <at> debbugs.gnu.org (full text, mbox):
> From: 積丹尼 Dan Jacobson
> <jidanni <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 12 Oct 2020 14:53:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 43941 <at> debbugs.gnu.org (full text, mbox):
>>>>> "EZ" == Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 12 Oct 2020 15:12:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 43941 <at> debbugs.gnu.org (full text, mbox):
On Mon, 12 Oct 2020 17:48:52 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: 積丹尼 Dan Jacobson
>> <jidanni <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 12 Oct 2020 15:22:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 43941 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
> 43941 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 12 Oct 2020 16:19:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 43941 <at> debbugs.gnu.org (full text, mbox):
On Mon, 12 Oct 2020 18:20:58 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
>> 43941 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 12 Oct 2020 16:30:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 43941 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Stephen Berman <stephen.berman <at> gmx.net>, jidanni <at> jidanni.org,
> 43941 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 12 Oct 2020 17:22:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 43941 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, 12 Oct 2020 19:29:07 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Stephen Berman <stephen.berman <at> gmx.net>, jidanni <at> jidanni.org,
>> 43941 <at> 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:
[Message part 2 (text/x-patch, inline)]
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.
[Message part 3 (text/plain, inline)]
If this is the right approach, then all such characters would have to be
added, or is there a better alternative?
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 12 Oct 2020 17:39:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 43941 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Stephen Berman <stephen.berman <at> gmx.net>, jidanni <at> jidanni.org,
> 43941 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 12 Oct 2020 21:27:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 43941 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, 12 Oct 2020 20:38:15 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Stephen Berman <stephen.berman <at> gmx.net>, jidanni <at> jidanni.org,
>> 43941 <at> 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:
[Message part 2 (text/x-patch, inline)]
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.
[Message part 3 (text/plain, inline)]
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Tue, 13 Oct 2020 10:38:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 43941 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, 12 Oct 2020 23:26:15 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> On Mon, 12 Oct 2020 20:38:15 +0300 Eli Zaretskii <eliz <at> 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:
[Message part 2 (text/x-patch, inline)]
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.
[Message part 3 (text/plain, inline)]
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
Forcibly Merged 43941.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 05 Feb 2021 09:42:02 GMT)
Full text and
rfc822 format available.
Forcibly Merged 40844 43941.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 05 Feb 2021 09:42:03 GMT)
Full text and
rfc822 format available.
Forcibly Merged 40844 43941 46312.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 05 Feb 2021 09:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Sun, 13 Jun 2021 12:22:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 43941 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> 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
Added tag(s) patch.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sun, 13 Jun 2021 12:22:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Sun, 13 Jun 2021 18:15:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 43941 <at> debbugs.gnu.org (full text, mbox):
On Sun, 13 Jun 2021 14:21:36 +0200 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Stephen Berman <stephen.berman <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 14 Jun 2021 13:01:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 43941 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> 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
bug marked as fixed in version 28.1, send any further explanations to
46312 <at> debbugs.gnu.org and 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 14 Jun 2021 13:01:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 14 Jun 2021 13:03:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 43941 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 46312 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
> 40844 <at> debbugs.gnu.org, 43941 <at> debbugs.gnu.org, jidanni <at> jidanni.org
> Date: Mon, 14 Jun 2021 15:00:16 +0200
>
> Stephen Berman <stephen.berman <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 14 Jun 2021 13:53:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 43941 <at> debbugs.gnu.org (full text, mbox):
On Mon, 14 Jun 2021 15:00:16 +0200 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Stephen Berman <stephen.berman <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43941; Package
emacs.
(Mon, 14 Jun 2021 13:59:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 43941 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 13 Jul 2021 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 281 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.