From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode Date: Wed, 24 Jun 2020 18:13:21 +0300 Message-ID: <83a70sts32.fsf@gnu.org> References: <20200622191653.26453.39420@vcs0.savannah.gnu.org> <20200622191656.2D20920A26@vcs0.savannah.gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="46679"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 24 17:14:19 2020 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 1jo76Q-000C2Q-Qo for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Jun 2020 17:14:18 +0200 Original-Received: from localhost ([::1]:48126 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jo76P-0003mo-TQ for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Jun 2020 11:14:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52090) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jo75n-0002q7-8u for emacs-devel@gnu.org; Wed, 24 Jun 2020 11:13:39 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51424) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jo75m-00030O-HU; Wed, 24 Jun 2020 11:13:38 -0400 Original-Received: from [176.228.60.248] (port=3974 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jo75l-0003Fr-ML; Wed, 24 Jun 2020 11:13:38 -0400 In-Reply-To: (message from Ted Zlatanov on Tue, 23 Jun 2020 22:29:50 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:252527 Archived-At: > From: Ted Zlatanov > Date: Tue, 23 Jun 2020 22:29:50 +0000 > Cc: emacs-devel@gnu.org > > On Mon, 22 Jun 2020 17:09:08 -0400 Stefan Monnier wrote: > > SM> Yes, it's needed first: in some modes, enabling `prettify-symbols-mode` > SM> can lead to really undesirable behavior (e.g. in Haskell it can lead to > SM> code being plain wrong since it can affect indentation and indentation > SM> is semantically significant like in Python). So you really can't impose > SM> it on the unsuspecting user. > > Agreed. It was better to start with something cleaner. So, I created a > whole new prettify-text API and reimplemented auth-source-reveal-mode on > top of it. It worked well in my testing. > > The new branch is scratch/tzz/prettify-text-mode (I left > scratch/tzz/auth-source-reveal-mode in place as a reference). > > The new code won't interfere with existing `prettify-symbols-mode' > users. Eventually `prettify-symbols-mode' could be migrated to this new > API to avoid the code duplication in the post-command-hook and > elsewhere. > > If you have suggestions or comments, please let me know. I'll document > the API before I push the branch out. I looked at the branch today, and I'm sorry to say that I wasn't happy with what I saw there. I very much hope I'm missing something. I ask below some questions to make sure I understand the goal and the design; please bear with me. First, the branch seems to include changes that fall into two classes: a feature that allows to hide passwords in auth-related commands, and a "library of text prettification". Is this correct? If so, why are two almost unrelated features being developed on the same branch? Next, how is the "text prettification library" different from the prettify-symbols-mode we already have, and what is the purpose of introducing such a library? It sounds like "text prettification" actually is about the same job as prettify-symbols-mode, but if so, why do we need the additional code? Perhaps the intent is to let other features use the same technique as prettify-symbols-mode for purposes other than prettifying identifiers in programming-language buffers? But then why is, for example, prettify-text-alist talking about "identifiers"? And this actually brings me to the most important point: the use of static compositions. That feature is semi-deprecated: its implementation in the display engine and its Lisp APIs are not very clean, and in particular it doesn't support bidirectional text. Using it in prettify-symbols-mode is semi-okay, since PL symbols rarely if ever use characters from RTL scripts, but the presence of "text" in the additions on the branch makes me think that this is meant for general-purpose text as well. Passwords can definitely (and do) use bidirectional text, for example. So if this is meant to be a general-purpose feature for displaying some text as something else, I don't think we should do this via static compositions. It is unclean, to say the least, for Emacs to have text-processing features that don't support some of the languages and scripts in our repertory. What will we say to people who come complaining that their language doesn't work with this feature? "we didn't think you language was important enough to support it"? So if we want to expand our use of static compositions, let's first fix its support for bidirectional text, and only then add features which depend on that. We shouldn't introduce features with such incomplete support of scripts and languages; we never did that before, AFAIR. Alternatively, if the purpose is to display some text as something else, we already have display properties and overlays that can be (and are) used for implementing such features; why not use them instead? Once again, sorry for a negative commentary; I hope I'm really missing something simple and obvious. And thanks for working on this, Ted.