Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> 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 <monnier@iro.umontreal.ca> 
> 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.