From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Ted Zlatanov 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:15:05 +0000 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: References: <20200622191653.26453.39420@vcs0.savannah.gnu.org> <20200622191656.2D20920A26@vcs0.savannah.gnu.org> <83a70sts32.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="83952"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 24 20:16:07 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 1jo9wM-000Li9-Nl for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Jun 2020 20:16:06 +0200 Original-Received: from localhost ([::1]:44394 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jo9wL-0005Te-IA for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Jun 2020 14:16:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jo9vU-00041l-2p for emacs-devel@gnu.org; Wed, 24 Jun 2020 14:15:12 -0400 Original-Received: from mail-qt1-x82a.google.com ([2607:f8b0:4864:20::82a]:37135) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jo9vS-0004c6-4i for emacs-devel@gnu.org; Wed, 24 Jun 2020 14:15:11 -0400 Original-Received: by mail-qt1-x82a.google.com with SMTP id d27so2471069qtg.4 for ; Wed, 24 Jun 2020 11:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifelogs.com; s=google; h=from:to:cc:subject:organization:references:mail-copies-to:date :in-reply-to:message-id:user-agent:mime-version; bh=S5lcPxhSwr5Vyz41N03+9yx1C0biVFmpaO4kLzLkYcA=; b=aKNeNejQ/pBhL3G+HK4oPzTYlzVtaTRmzIJodfXJ4WoNPMeu2q51Jwwx1ykYsVlcYZ spQbJZvhe74VovstixkghvCd2tZoT45oplqARzqY6ul39QltHkyCISjVnofURB8s/DOu qDmz1cBzGTxUeKzumRhNj6AF9spPSbj8rPvfI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:organization:references :mail-copies-to:date:in-reply-to:message-id:user-agent:mime-version; bh=S5lcPxhSwr5Vyz41N03+9yx1C0biVFmpaO4kLzLkYcA=; b=uaDF2PCbjqKhqoPpkkk99QPzPNN6l21USDaRhfWGFRDkjir+U/b9Y8l5cA8QNbyGsm qceiLZrWIKtvxWa/0t240BE0fSB6UIg5lHzluayNDWhzuKKJosNQApb+jwekRvVRYLcG A6qxtoWZvxTSbgloWmvbQerMpjiCE+uj2TMNtUSXkDP5KBDXyfwjvH4wlNZkWsqAr/XN dRGy7blsUOyG7kbfA3h/G273JcFAwhjatd+ZK45GNCm/6/OJCXjCuFI97F8AUF4tkHKZ LHHulZR4jJRs05PS+b/1isc14rhirU5ikGucSxdmCzVVtAzFfm0RF65DsqVKyApn/2wB PdjQ== X-Gm-Message-State: AOAM5332c9ODAgGRPxXxnUhCfjiJw5k3Je0nz+emYO9/3IMWrmUNwygq THGkGpxRH8b0Mfj4GHdT0EQ7UyBul10+Zg== X-Google-Smtp-Source: ABdhPJy95TXNV/YPqpw0pOUI73gxRDfxCRYpyJe6lO5eahIL8XQNDTjqywFdTgChbDuixcLZqXAVkQ== X-Received: by 2002:aed:26e1:: with SMTP id q88mr12627931qtd.354.1593022508497; Wed, 24 Jun 2020 11:15:08 -0700 (PDT) Original-Received: from flea (c-76-28-41-155.hsd1.ma.comcast.net. [76.28.41.155]) by smtp.gmail.com with ESMTPSA id z4sm3647242qkj.131.2020.06.24.11.15.06 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Jun 2020 11:15:06 -0700 (PDT) X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never In-Reply-To: <83a70sts32.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 24 Jun 2020 18:13:21 +0300") Received-SPF: none client-ip=2607:f8b0:4864:20::82a; envelope-from=tzz@lifelogs.com; helo=mail-qt1-x82a.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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:252529 Archived-At: On Wed, 24 Jun 2020 18:13:21 +0300 Eli Zaretskii wrote: EZ> First, the branch seems to include changes that fall into two classes: EZ> a feature that allows to hide passwords in auth-related commands, and EZ> a "library of text prettification". Is this correct? If so, why are EZ> two almost unrelated features being developed on the same branch? (For reference, the branch is scratch/tzz/prettify-text-mode) Hi Eli. The two features will be separate commits so their coexistence in the branch is just to make reviews and testing easier. But they are very much related: the prettification functions are in prettify-text-* and then `auth-source-reveal-mode' uses those functions. EZ> Next, how is the "text prettification library" different from the EZ> prettify-symbols-mode we already have, and what is the purpose of EZ> introducing such a library? It sounds like "text prettification" EZ> actually is about the same job as prettify-symbols-mode, but if so, EZ> why do we need the additional code? Perhaps the intent is to let EZ> other features use the same technique as prettify-symbols-mode for EZ> purposes other than prettifying identifiers in programming-language EZ> buffers? Earlier in scratch/tzz/auth-source-reveal-mode I implemented `auth-source-reveal-mode' on top of `prettify-symbols-mode' but Stefan commented and I agreed that it would be better refactored as a library. So as of now, the prettify-text-* functions are a way to implement text prettifications that works like `prettify-symbols-mode' but doesn't interfere with it. The prettify-text-* functions also support regular expressions, unlike `prettify-symbols-mode'. That's the major new feature because without it, `auth-source-reveal-mode' could not work. In addition, prettifications based on regular expressions have been requested many times in external forums, so I think this is a valid use case beyond `auth-source-reveal-mode'. EZ> But then why is, for example, prettify-text-alist talking EZ> about "identifiers"? The identifiers in `prettify-text-alist' are symbols that identify each entry's origin. For `auth-source-reveal-mode' the identifier is 'auth-source-reveal-regexp. That allows the prettify-text-* functions to list and remove related prettifications instead of anonymously mashing them together like `prettify-symbols-mode' does. EZ> And this actually brings me to the most important point: the use of EZ> static compositions. That feature is semi-deprecated: its EZ> implementation in the display engine and its Lisp APIs are not very EZ> clean, and in particular it doesn't support bidirectional text. Let's separate the library functions named prettify-text-* from the underlying implementation. 1) The library functions. Currently prettify-text-* functions can add or remove prettifications of a regexp to a single character or a composition list. That prettification can be hidden or revealed when point is inside or on the right edge of the prettification. (That's the functionality of `prettify-symbols-mode' as well, except it doesn't support regular expressions and users manipulate the alist directly.) The major problem you raise here is the limitation to a single character or a composition list, which in the prettify-text-* functions gets exposed in exactly one place: the docstring of `prettify-text-alist', which should not be directly manipulated by library users anyway. file:lisp/progmodes/prog-mode.el::95 In ~prettify-text-alist~: #+BEGIN_SRC emacs-lisp (defvar-local prettify-text-alist nil "Alist of text regexp prettifications. Each element must look like (IDENTIFIER REGEXP CHARACTER) ... CHARACTER can be a character, or it can be a list or vector, in which case it will be used to compose the new symbol as per the third argument of `compose-region'. #+END_SRC So I think we can easily move away from static compositions in the prettify-text-* library functions. 2) The underlying implementation. This is almost exactly like `prettify-symbols-mode' in its dependence on static compositions. I agree we should change it, the question is when (before merge or in a followup code fix) and to what, so the behavior is preserved. EZ> Alternatively, if the purpose is to display some text as something EZ> else, we already have display properties and overlays that can be (and EZ> are) used for implementing such features; why not use them instead? I would welcome help in implementing the prettify-text-* internals better (supporting bidirectional script and anything else you would consider required) and asked for help with it earlier. I'll need a hand from someone knowledgeable, or at least a pointer to code that provides the same functionality as `prettify-symbols-mode' in a way that's acceptable. I listed the functionality in (1) above. Ted