* Re: scratch/tzz/auth-source-reveal-mode f16a4c8 2/3: Support regular expressions and API for prettify-symbols-mode [not found] ` <20200622191655.E1C4E20A26@vcs0.savannah.gnu.org> @ 2020-06-22 20:00 ` Stefan Monnier 2020-06-22 20:32 ` Ted Zlatanov 0 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2020-06-22 20:00 UTC (permalink / raw) To: emacs-devel; +Cc: Ted Zlatanov > +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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode f16a4c8 2/3: Support regular expressions and API for prettify-symbols-mode 2020-06-22 20:00 ` scratch/tzz/auth-source-reveal-mode f16a4c8 2/3: Support regular expressions and API for prettify-symbols-mode Stefan Monnier @ 2020-06-22 20:32 ` Ted Zlatanov 0 siblings, 0 replies; 15+ messages in thread From: Ted Zlatanov @ 2020-06-22 20:32 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20200622191656.2D20920A26@vcs0.savannah.gnu.org>]
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode [not found] ` <20200622191656.2D20920A26@vcs0.savannah.gnu.org> @ 2020-06-22 20:03 ` Stefan Monnier 2020-06-22 20:39 ` Ted Zlatanov 0 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2020-06-22 20:03 UTC (permalink / raw) To: emacs-devel; +Cc: Ted Zlatanov > +(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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-22 20:03 ` scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode Stefan Monnier @ 2020-06-22 20:39 ` Ted Zlatanov 2020-06-22 21:09 ` Stefan Monnier 0 siblings, 1 reply; 15+ messages in thread From: Ted Zlatanov @ 2020-06-22 20:39 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-22 20:39 ` Ted Zlatanov @ 2020-06-22 21:09 ` Stefan Monnier 2020-06-23 22:29 ` Ted Zlatanov 0 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2020-06-22 21:09 UTC (permalink / raw) To: emacs-devel >>> + (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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-22 21:09 ` Stefan Monnier @ 2020-06-23 22:29 ` Ted Zlatanov 2020-06-24 15:13 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Ted Zlatanov @ 2020-06-23 22:29 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-23 22:29 ` Ted Zlatanov @ 2020-06-24 15:13 ` Eli Zaretskii 2020-06-24 18:15 ` Ted Zlatanov 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2020-06-24 15:13 UTC (permalink / raw) To: Ted Zlatanov; +Cc: monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-24 15:13 ` Eli Zaretskii @ 2020-06-24 18:15 ` Ted Zlatanov 2020-06-24 18:36 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Ted Zlatanov @ 2020-06-24 18:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-24 18:15 ` Ted Zlatanov @ 2020-06-24 18:36 ` Eli Zaretskii 2020-06-24 19:04 ` Ted Zlatanov 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2020-06-24 18:36 UTC (permalink / raw) To: Ted Zlatanov; +Cc: monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-24 18:36 ` Eli Zaretskii @ 2020-06-24 19:04 ` Ted Zlatanov 2020-06-25 13:31 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Ted Zlatanov @ 2020-06-24 19:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-24 19:04 ` Ted Zlatanov @ 2020-06-25 13:31 ` Eli Zaretskii 2020-06-26 13:52 ` Ted Zlatanov 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2020-06-25 13:31 UTC (permalink / raw) To: Ted Zlatanov; +Cc: monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-25 13:31 ` Eli Zaretskii @ 2020-06-26 13:52 ` Ted Zlatanov 2020-06-26 14:24 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Ted Zlatanov @ 2020-06-26 13:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-26 13:52 ` Ted Zlatanov @ 2020-06-26 14:24 ` Eli Zaretskii 2020-06-26 14:39 ` Ted Zlatanov 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2020-06-26 14:24 UTC (permalink / raw) To: Ted Zlatanov; +Cc: monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-26 14:24 ` Eli Zaretskii @ 2020-06-26 14:39 ` Ted Zlatanov 2020-07-12 20:49 ` Ted Zlatanov 0 siblings, 1 reply; 15+ messages in thread From: Ted Zlatanov @ 2020-06-26 14:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode 2020-06-26 14:39 ` Ted Zlatanov @ 2020-07-12 20:49 ` Ted Zlatanov 0 siblings, 0 replies; 15+ messages in thread From: Ted Zlatanov @ 2020-07-12 20:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-07-12 20:49 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20200622191653.26453.39420@vcs0.savannah.gnu.org> [not found] ` <20200622191655.E1C4E20A26@vcs0.savannah.gnu.org> 2020-06-22 20:00 ` scratch/tzz/auth-source-reveal-mode f16a4c8 2/3: Support regular expressions and API for prettify-symbols-mode Stefan Monnier 2020-06-22 20:32 ` Ted Zlatanov [not found] ` <20200622191656.2D20920A26@vcs0.savannah.gnu.org> 2020-06-22 20:03 ` scratch/tzz/auth-source-reveal-mode 4a7c98d 3/3: Create and document auth-source-reveal-mode Stefan Monnier 2020-06-22 20:39 ` Ted Zlatanov 2020-06-22 21:09 ` Stefan Monnier 2020-06-23 22:29 ` Ted Zlatanov 2020-06-24 15:13 ` Eli Zaretskii 2020-06-24 18:15 ` Ted Zlatanov 2020-06-24 18:36 ` Eli Zaretskii 2020-06-24 19:04 ` Ted Zlatanov 2020-06-25 13:31 ` Eli Zaretskii 2020-06-26 13:52 ` Ted Zlatanov 2020-06-26 14:24 ` Eli Zaretskii 2020-06-26 14:39 ` Ted Zlatanov 2020-07-12 20:49 ` Ted Zlatanov
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.