help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Trojan Source detection/highlight in Emacs?


From: Eli Zaretskii
Subject: Re: Trojan Source detection/highlight in Emacs?
Date: Tue, 02 Nov 2021 16:09:31 +0200

> Date: Mon, 01 Nov 2021 19:25:55 -0400
> From:  Stefan Monnier via Users list for the GNU Emacs text editor 
> <help-gnu-emacs@gnu.org>
> 
> > if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069}
> > {U+2066}" {
> >
> > ...would be rendered by bidirectional-aware tools as:
> >
> > if access_level != "user" { // Check if admin
> >
> > This would give the reader the mistaken impression that the program is
> > comparing admin_level with the value "user".
> 
> Clearly, Eli will know better, but I suspect that we may be able to
> avoid most of those issues by (conceptually) treating comment delimiters
> as bidi barriers.  Of course, that leaves open the question of what
> I mean by "bidi barrier" and of how to implement it ;-)

It's more than that: bidi reordering happens on a very low level in
the display engine, where there's absolutely no information about
stuff like comment delimiters and PL syntax in general.  In
particular, that code runs before font-lock and similar features
examined the text syntactically and decided what is and what isn't a
comment.

So doing what you propose would be ... how should I say it? ... very
difficult.

We could instead provide an ability to bidi-reorder only certain
stretches of text, marked by some special text property.  Then a Lisp
program could mark only comments and strings with that property, and
the reordering would not happen anywhere else in the buffer.  Doing
something like that is relatively simple, but not too simple, so I'd
say this particular issue doesn't justify the effort.

I would start with detecting such reordered code and flagging it.  We
are almost there; all that's needed is a motivated individual to
implement the user-level feature using infrastructure that already
(almost) exists.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]