From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Trojan Source detection/highlight in Emacs? Date: Tue, 02 Nov 2021 16:09:31 +0200 Message-ID: <8335oelkdg.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2829"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 02 15:29:50 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mhunO-0000Vz-EF for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 02 Nov 2021 15:29:50 +0100 Original-Received: from localhost ([::1]:56184 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mhunN-0004yZ-9k for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 02 Nov 2021 10:29:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41434) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhuTo-0005kk-2M for help-gnu-emacs@gnu.org; Tue, 02 Nov 2021 10:09:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40320) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhuTn-0004Zy-Pi for help-gnu-emacs@gnu.org; Tue, 02 Nov 2021 10:09:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BBXIcv8HI9bciimzgXTk32w9463lROTH4swNsJ2mYQE=; b=V0mh6UMUMJtQ D7HpqOtUwL8Xu0B7bOfuWC+fVn8v/jvbuTww5AHKrfrkwgetptkaRxVxWwj0bEvqDuPRJyo3K/tiv +GxchYwn8HaL2cleJ3h5inzO/uwg/h42DB6FxtMrOAd9QkiNc9TEkmz/6AgGd7i6c8MOU9pz7v2o9 kgJDe3fz04okmUBT36JmDIbdS/I0N8CmtONCHVI/iNwsfQ4YGuRmKA/l2pLBcXs75ekbpb1tMn2si ojpYP250T8AwfuR+RHRt2Eu9vppUaRX/+ZsQ/4J+MVCfICerKQtTeyzIjDTx8MWJdd31JXCbfHFWr K5ZK+M2/wQDhuH/rSHGxYA==; Original-Received: from [87.69.77.57] (port=2121 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhuTn-0004vn-9u for help-gnu-emacs@gnu.org; Tue, 02 Nov 2021 10:09:35 -0400 In-Reply-To: (message from Stefan Monnier via Users list for the GNU Emacs text editor on Mon, 01 Nov 2021 19:25:55 -0400) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:134306 Archived-At: > Date: Mon, 01 Nov 2021 19:25:55 -0400 > From: Stefan Monnier via Users list for the GNU Emacs text editor > > > 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.