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.devel Subject: Re: Unicode confusables and reordering characters considered harmful Date: Wed, 03 Nov 2021 19:44:18 +0200 Message-ID: <83mtmlgmml.fsf@gnu.org> References: <875ytag0hb.fsf@yahoo.com> <87zgqmd5np.fsf@mat.ucm.es> <83wnlqk3rn.fsf@gnu.org> <72dd5c2a-42c7-b12e-05ed-e93adbd89727@gmail.com> <83ilxajyhw.fsf@gnu.org> <83fssejxf8.fsf@gnu.org> <835ytajsv2.fsf@gnu.org> <11d5fecb44af1d388b7f@heytings.org> <11d5fecb449846dc0851@heytings.org> <837ddpicbb.fsf@gnu.org> <11d5fecb442f6eb9e9e3@heytings.org> <83v919gv9a.fsf@gnu.org> <11d5fecb4476ff938838@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14062"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, stefan@marxist.se, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 03 18:54:29 2021 Return-path: Envelope-to: ged-emacs-devel@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 1miKSy-0003VL-O9 for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Nov 2021 18:54:28 +0100 Original-Received: from localhost ([::1]:53462 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1miKSx-0007g8-3T for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Nov 2021 13:54:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45524) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1miKJC-0007nR-07 for emacs-devel@gnu.org; Wed, 03 Nov 2021 13:44:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33858) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1miKJA-0008Cy-Qc; Wed, 03 Nov 2021 13:44:21 -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=CLMqthNx5foqkmDKSm2JH9GqWLXKnuph465pO7sT0+s=; b=n8Y5toBx5e9S bvPIeVpJtSQyJVXIb7z0sLx+zNk3HaZk6qcABp50/R0XktlXjSMWijGNuaIfZp5QOr1jW5r50Qbqr xUJBu3OUUcwVgSA9Q1IfvF8rFjfAb4E+c188aIwYtwNFUxC0gYorNDBqqexkUAYvCBKQsAyck+ikr 05Kut34+mtt2/mMUCIUoQxDoHHs8Da3J+E/x42AWCU4yPUeN7e7Pe2SjAUqEMC0wMlnEomiRBXBr8 QJ2iryn8SXTbUnFqVX+PJ/ru4F7T9pbb4ESU5wkjs6/fHoIkkmYlOulFtR8hV3/qu3WQ992t0w64d NzEqfg1T90xHq3dpj1HufA==; Original-Received: from [87.69.77.57] (port=4179 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 1miKJ9-0003BS-SF; Wed, 03 Nov 2021 13:44:20 -0400 In-Reply-To: <11d5fecb4476ff938838@heytings.org> (message from Gregory Heytings on Wed, 03 Nov 2021 16:01:20 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:278594 Archived-At: > Date: Wed, 03 Nov 2021 16:01:20 +0000 > From: Gregory Heytings > cc: stefan@marxist.se, emacs-devel@gnu.org, cpitclaudel@gmail.com, > monnier@iro.umontreal.ca > > > It could, but I don't think we should install such features. > > Why not? Because it doesn't pass my quality-control tests. > Is this not simply an improved (and built-in) version of your > initial suggestion to use glyphless-char-display? glyphless-char-display already exists and is built-in. People who want to have these characters stand out for some reason can use it, that's why it is open to customization. What you propose is "yet another mechanism similar to glyphless-char-display", and I don't see why we should have this for a small group of characters. We already have a small mess because display-tables and glyphless-char-display produce a race; I certainly don't think we should introduce yet another, third mechanism for a similar purpose. I could consider adding an additional METHOD to those we already support there, if someone thinks the existing ones are insufficient. Not sure if this is needed, but it at least makes some sense, assuming the proposal would be reasonable and not limited to a small group of codepoints. > Except that glyphless-char-display is global (whereas > buffer-display-table is buffer-local), and that a tofu is not as > visible as a character highlighted with the font-lock-warning-face. Patches to allow glyphless display to be controlled on a buffer-local basis would be welcome, I think this would be a good enhancement.