emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ted Zlatanov
Subject: Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode
Date: Fri, 26 Jun 2020 13:52:26 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]