[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "
From: |
Drew Adams |
Subject: |
bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters |
Date: |
Thu, 9 May 2019 13:04:24 -0700 (PDT) |
> >> But I'm afraid we'll have to stick to what we have now.
> >
> > Why? Not sure what you mean.
>
> I mean that it won't be easy to convince others that we need a new
> face for propertizing prompts.
Why assume that? Who needs to be convinced?
If we can't have a new face for this then I'd like
to see non-minibuffer prompting have no face at all,
by default.
> > I would prefer that the two be separated. Tooltip text
> > is quite different from prompts in use cases and behavior.
>
> They are similar in the following aspect: Both prompts and tooltips
> are often displayed using toolkit functions.
That sounds like an implementation thing, not a user-level thing.
And as I said, `x-show-tooltip' has no problem with
showing propertized text.
> GTK tooltips are by
> default not propertized because the system doesn't accept any face
> properties for them. If Emacs used balloon tooltips on Windows,
> propertizing them would not be possible either. And both 'y-or-n-p'
> and 'yes-or-no-p', when implemented via dialog popups, don't adopt our
> text properties either.
Oh, so `x-show-tooltip' only supports properties on
some platforms (e.g. MS Windows)? If so, that's
unfortunate.
Yes, I don't expect window-dialogs to respect
propertized text. Again, unfortunate - but livable.
> The question is now whether an application should accept the uniform
> appearance of such objects as prescribed by the toolkit used and as
> such obey the toolkit's look-and-feel or insist to use its own
> implementations. Emacs leaves that choice to its users. Which means
> that users are told things like "if you want this mode to behave as
> intended, you have to customize variables like 'use-dialog-box' or
> 'x-gtk-use-system-tooltips'". Nothing bad with that, but some users
> might be uncertain whether they should agree. In particular when such
> an option affects all sorts of tooltips or prompts.
Got it; thx.
I would like to see Emacs allow, when possible, Emacsy
things as much as possible. But I can understand that
there can be some tradeoffs.
- bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters, Kévin Le Gouguec, 2019/05/04
- bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters, martin rudalics, 2019/05/05
- bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters, Kévin Le Gouguec, 2019/05/06
- bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters, martin rudalics, 2019/05/07
- bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters, Drew Adams, 2019/05/07
- bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters, Kévin Le Gouguec, 2019/05/08
- bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters, Drew Adams, 2019/05/08
- bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters, martin rudalics, 2019/05/09
- bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters, Drew Adams, 2019/05/09
- bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters, martin rudalics, 2019/05/09
- bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters,
Drew Adams <=