Re: scratch/tzz/auth-source-reveal-mode f16a4c8 2/3: Support regular expressions and API for prettify-symbols-mode

Re: scratch/tzz/auth-source-reveal-mode f16a4c8 2/3: Support regular expressions and API for prettify-symbols-mode

[Stefan Monnier]

> +For example: \"abc[123]\" matching \"abc1\", \"abc2\", or
> +\"abc3\" could be mapped to the Unicode WORLD MAP. Note again the
> +IDENTIFIER is an arbitrary Lisp symbol.
> + (my-worldmap \"abc[123]\" 128506)

I think using ?\U0001f5fa might be "natural" for a unicode char.

More importantly, I think we should accommodate cases where the regexp
needs to match some of the context, i.e. where only some submatch needs
to be prettified.
E.g. we could say that the text affected is either submatch 1 or
submatch 0 (where submatch 0 is used if there's (match-end 1) is nil).


        Stefan

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

[Stefan Monnier]

> +(define-minor-mode auth-source-reveal-mode
[...]
> +  (when auth-source-reveal-mode
> +    ;; Install the prettification magic.
> +    (prettify-symbols-add-prettification-rx
> +     'auth-source-reveal-mode-prettify-regexp ; The identifier symbol.
> +     ;; regexp to hide/reveal
> +     (if (apply #'derived-mode-p auth-source-reveal-json-modes)
> +         (format "\"?password\"?[:[:blank:]]+\"\\([^\t\r\n\"]+\\)\"" auth-source-reveal-regex)
> +       (format "\\b%s\\b\\s-+\\([^ \t\r\n]+\\)" auth-source-reveal-regex))
> +     auth-source-reveal-hider)
> +
> +    (setq-local
> +     prettify-symbols-compose-predicate #'auth-source-reveal-compose-p)

This erases any prior configuration of that variable, so it won't "play
ball" with other users.

> +  (prettify-symbols-mode (if auth-source-reveal-mode 1 -1)))

And here we forcefully enable/disable `prettify-symbols-mode` even if
all the user wanted if to hide the passwords.
I think we need to decouple the two user-level features.


        Stefan

Re: scratch/tzz/auth-source-reveal-mode f16a4c8 2/3: Support regular expressions and API for prettify-symbols-mode

[Ted Zlatanov]

On Mon, 22 Jun 2020 16:00:35 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> +For example: \"abc[123]\" matching \"abc1\", \"abc2\", or
>> +\"abc3\" could be mapped to the Unicode WORLD MAP. Note again the
>> +IDENTIFIER is an arbitrary Lisp symbol.
>> + (my-worldmap \"abc[123]\" 128506)

SM> I think using ?\U0001f5fa might be "natural" for a unicode char.

Got it, fixed.

SM> More importantly, I think we should accommodate cases where the regexp
SM> needs to match some of the context, i.e. where only some submatch needs
SM> to be prettified.
SM> E.g. we could say that the text affected is either submatch 1 or
SM> submatch 0 (where submatch 0 is used if there's (match-end 1) is nil).

Got it, adjusted docs and code. Both of the above are in a single commit
on my branch now.

Ted

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

[Ted Zlatanov]

On Mon, 22 Jun 2020 16:03:31 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> +    (setq-local
>> +     prettify-symbols-compose-predicate #'auth-source-reveal-compose-p)

SM> This erases any prior configuration of that variable, so it won't "play
SM> ball" with other users.

Is it better do what tex-mode.el does?

  (add-function :override (local 'prettify-symbols-compose-predicate)
                #'tex--prettify-symbols-compose-p)

>> +  (prettify-symbols-mode (if auth-source-reveal-mode 1 -1)))

SM> And here we forcefully enable/disable `prettify-symbols-mode` even if
SM> all the user wanted if to hide the passwords.
SM> I think we need to decouple the two user-level features.

The plan was to make `prettify-symbols-mode' a library that other modes
like `auth-source-reveal-mode' can use. I went halfway, creating some
API-like functions. Are you suggesting that library is needed now to
avoid the tight coupling? Or something else?

Thanks
Ted

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

[Stefan Monnier]

>>> +    (setq-local
>>> +     prettify-symbols-compose-predicate #'auth-source-reveal-compose-p)
> SM> This erases any prior configuration of that variable, so it won't "play
> SM> ball" with other users.
> Is it better do what tex-mode.el does?
>   (add-function :override (local 'prettify-symbols-compose-predicate)
>                 #'tex--prettify-symbols-compose-p)

Even better is to not :override but do something more respectful of the
old value (which presumably is still useful for all the matches using the
"other" mapping).

>>> +  (prettify-symbols-mode (if auth-source-reveal-mode 1 -1)))
> SM> And here we forcefully enable/disable `prettify-symbols-mode` even if
> SM> all the user wanted if to hide the passwords.
> SM> I think we need to decouple the two user-level features.
> The plan was to make `prettify-symbols-mode' a library that other modes
> like `auth-source-reveal-mode' can use. I went halfway, creating some
> API-like functions. Are you suggesting that library is needed now to
> avoid the tight coupling? Or something else?

Yes, it's needed first: in some modes, enabling `prettify-symbols-mode`
can lead to really undesirable behavior (e.g. in Haskell it can lead to
code being plain wrong since it can affect indentation and indentation
is semantically significant like in Python).  So you really can't impose
it on the unsuspecting user.


        Stefan

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

[Ted Zlatanov]

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.

Ted

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.

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

[Ted Zlatanov]

On Wed, 24 Jun 2020 18:13:21 +0300 Eli Zaretskii <eliz@gnu.org> 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

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>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 24 Jun 2020 18:15:05 +0000
> 
> 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.

I would like first to understand why you thought about using the
prettify-symbols-mode technique for this.  The natural features to use
for displaying some text instead of what's in the buffer are 'display'
text properties and overlay strings, and the natural feature for
hiding some text is the 'invisible' text property.  So why didn't you
use these features to begin with?  What am I missing?

Thanks.

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

[Ted Zlatanov]

On Wed, 24 Jun 2020 21:36:34 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>> Date: Wed, 24 Jun 2020 18:15:05 +0000
>> 
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.

EZ> I would like first to understand why you thought about using the
EZ> prettify-symbols-mode technique for this.

Well, it did exactly what I needed and worked well in my testing.

See thread "Re: questions about correct reveal-mode usage to hide
passwords":

On Thu, 11 Jun 2020 15:51:27 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
> Ted wrote: 
>> Is there an example using jit-lock that behaves like
>> prettify-symbols-mode in the following cases?
>> 
>> * transforms the text when outside it
>> * temporarily shows the original text when inside it or on its right edge
>> * updates when the user makes changes

SM> Maybe if you look at the `csv-align-mode` in GNU ELPA's `csv-mode.el`
SM> (tho it mixes the job of aligning columns and of truncating/hiding the
SM> text of columns that are too wide).

EZ> The natural features to use
EZ> for displaying some text instead of what's in the buffer are 'display'
EZ> text properties and overlay strings, and the natural feature for
EZ> hiding some text is the 'invisible' text property.  So why didn't you
EZ> use these features to begin with?  What am I missing?

I spent several fruitless hours in that direction. Since I didn't have
more hours to spend, I went with the working solution I could
understand. This didn't happen in a vacuum, I posted my questions to
emacs-devel in the thread above.

Ted

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>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 24 Jun 2020 19:04:10 +0000
> 
> EZ> The natural features to use
> EZ> for displaying some text instead of what's in the buffer are 'display'
> EZ> text properties and overlay strings, and the natural feature for
> EZ> hiding some text is the 'invisible' text property.  So why didn't you
> EZ> use these features to begin with?  What am I missing?
> 
> I spent several fruitless hours in that direction. Since I didn't have
> more hours to spend, I went with the working solution I could
> understand. This didn't happen in a vacuum, I posted my questions to
> emacs-devel in the thread above.

I'm very sorry that I couldn't participate in that discussion.  I did
read its beginning, and at the time it looked to me that you were
getting good advice from Stefan and Clément.  I missed the point where
you decided to switch to prettify-symbols-mode as your basis; I should
have chimed in right there and then.

Can you please tell in more detail what caused you problems when you
tried using overlays and invisible text properties?  It surprises me
that you encountered such difficulties, as there are quite a few
features which use those facilities for similar purposes.  As a random
example, hl-line-mode moves an overlay as result of user commands,
which sounds similar to what you need to do.

Perhaps if you describe the difficulties you bumped into in more
detail, we could help you overcome them?  AFAICT, you never actually
described the specific problems you had.

prettify-symbols-mode (and static compositions in general) just aren't
the right tool for such jobs; we have much better tools for that, and
they work well for many other features.  I'd be very surprised if
those tools couldn't support your use cases.

Thanks.

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

[Ted Zlatanov]

On Thu, 25 Jun 2020 16:31:02 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> Perhaps if you describe the difficulties you bumped into in more
EZ> detail, we could help you overcome them?  AFAICT, you never actually
EZ> described the specific problems you had.

No, I didn't. I spent several hours investigating and the lack of
existing code that did this, plus the complexity of Emacs' display
internals, were discouraging. I didn't keep the attempts I made.

EZ> prettify-symbols-mode (and static compositions in general) just aren't
EZ> the right tool for such jobs; we have much better tools for that, and
EZ> they work well for many other features.  I'd be very surprised if
EZ> those tools couldn't support your use cases.

Again, let's consider what I've done as two things:

1) the new minor auth-source-reveal-mode and the prettify-text
library/API: that won't change and has no hard dependency on static
compositions.

2) the internal implementation of the prettify-text library/API: that's
almost exactly like `prettify-symbols-mode', a part of the core. Your
major concern there (accessibility and internationalization) is valid
but it's equally valid against that existing part of the core.

So again, I propose merging as is, and then spending time on a proper
reimplementation for both `prettify-symbols-mode' and the prettify-text
code. I can work on that reimplementation with guidance from this
mailing list. That will help me keep the changes smaller (the branch is
getting hard to maintain) and more targeted.

Thanks
Ted

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>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 26 Jun 2020 13:52:26 +0000
> 
> EZ> Perhaps if you describe the difficulties you bumped into in more
> EZ> detail, we could help you overcome them?  AFAICT, you never actually
> EZ> described the specific problems you had.
> 
> No, I didn't. I spent several hours investigating and the lack of
> existing code that did this, plus the complexity of Emacs' display
> internals, were discouraging.

I'm not sure what is meant by "did this", but if you are talking about
hiding some text and displaying something else in its stead, then
Emacs is fill of examples of that.  So I'm quite sure it should be
possible to do what you want, if you show the code that you tried to
use.

> 1) the new minor auth-source-reveal-mode and the prettify-text
> library/API: that won't change and has no hard dependency on static
> compositions.
> 
> 2) the internal implementation of the prettify-text library/API: that's
> almost exactly like `prettify-symbols-mode', a part of the core. Your
> major concern there (accessibility and internationalization) is valid
> but it's equally valid against that existing part of the core.
> 
> So again, I propose merging as is, and then spending time on a proper
> reimplementation for both `prettify-symbols-mode' and the prettify-text
> code. I can work on that reimplementation with guidance from this
> mailing list. That will help me keep the changes smaller (the branch is
> getting hard to maintain) and more targeted.

I don't mind when will the dependency on static compositions replaced
by more appropriate features, as long as we agree that it should be
replaced.  (OTOH, I don't see why we should rush towards merging.)
Also, let's not call the library "prettify-text" or anything to that
effect, because that's not what it is supposed to do, it's supposed to
hide text by displaying something else in its stead.

Thanks.

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

[Ted Zlatanov]

On Fri, 26 Jun 2020 17:24:26 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> 1) the new minor auth-source-reveal-mode and the prettify-text
>> library/API: that won't change and has no hard dependency on static
>> compositions.
>> 
>> 2) the internal implementation of the prettify-text library/API: that's
>> almost exactly like `prettify-symbols-mode', a part of the core. Your
>> major concern there (accessibility and internationalization) is valid
>> but it's equally valid against that existing part of the core.
>> 
>> So again, I propose merging as is, and then spending time on a proper
>> reimplementation for both `prettify-symbols-mode' and the prettify-text
>> code. I can work on that reimplementation with guidance from this
>> mailing list. That will help me keep the changes smaller (the branch is
>> getting hard to maintain) and more targeted.

EZ> I don't mind when will the dependency on static compositions replaced
EZ> by more appropriate features, as long as we agree that it should be
EZ> replaced.  (OTOH, I don't see why we should rush towards merging.)

OK, terrific. That makes it much easier to manage for me.

Outside of the internal implementation concerns you have, is there
anything else needed? I assume it's too early to modify NEWS and the
manual.

EZ> Also, let's not call the library "prettify-text" or anything to that
EZ> effect, because that's not what it is supposed to do, it's supposed to
EZ> hide text by displaying something else in its stead.

I can s/prettify-text/something/g, sure. I tried to think of a short
expressive name... maybe text-coverup? Let me know what you think.

Ted

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

[Ted Zlatanov]

On Fri, 26 Jun 2020 14:39:01 +0000 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Fri, 26 Jun 2020 17:24:26 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> I don't mind when will the dependency on static compositions replaced
EZ> by more appropriate features, as long as we agree that it should be
EZ> replaced.  (OTOH, I don't see why we should rush towards merging.)

TZ> OK, terrific. That makes it much easier to manage for me.

TZ> Outside of the internal implementation concerns you have, is there
TZ> anything else needed? I assume it's too early to modify NEWS and the
TZ> manual.

EZ> Also, let's not call the library "prettify-text" or anything to that
EZ> effect, because that's not what it is supposed to do, it's supposed to
EZ> hide text by displaying something else in its stead.

TZ> I can s/prettify-text/something/g, sure. I tried to think of a short
TZ> expressive name... maybe text-coverup? Let me know what you think.

Hi Eli and anyone else interested!

I have pushed an update to my branch scratch/tzz/prettify-text-mode:

* rebase against master
* rename prettify-text everywhere to "text-coverup"
* squashed all the code down to 3 commits

I can move the code to a new file, but otherwise I think I've addressed
all the immediate concerns, and after merging this I will work on your
wider concerns about compositions and overlays. Can you advise if you
have any concerns?

Thank you for your help and time!
Ted