bug#35564: [PATCH v5] Tweak dired warning about "wildcard" characters

[Kévin Le Gouguec]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Without having had a look yet - your last version addresses everything
> brought up so far and can be considered final, right?

I think so.  Going over for bug#28969 and bug#35564, here are the
discussion points I could identify:

- y-or-n-p propertizing its prompt rigidly: out of scope, since we use
  read-multiple-choice now.

- The prompt getting too long: it's now much shorter than the
  four(!)-line version I came up with in v4; it concisely spells out the
  issue (some characters will not be substituted) and invites the user
  to ask for more details if needed.

- Asking the user whether they'd like to actually substitute these
  characters: out of scope; not sure it's necessary, since the new
  "details" buffer explains how to work around this for '?' (using
  backquotes).

  (Though no such workaround exists for '*'.  Allowing '*' to be
   isolated with backquotes just like '?' would be a natural thing to do
   IMO, but that's unrelated to fixing this confusing prompt.)

- Ensuring accessibility: users who cannot distinguish the 'warning'
  face are now invited to add optional '^' markers.

- Preventing '`' being linked to the backquote macro in the docstring
  for dired-do-shell-command: still no idea how to fix that, but that
  can be investigated independently.


Here are some remaining issues I can think of:

- The code that toggles the '^' markers does not check that the command
  is not wrapped/truncated (i.e. that the window is wide enough).

- The details window might not be tall enough, in which case maybe I
  should add [f]orward-/[b]ackward-page actions like nsm.el does.

- In dired--no-subst-confirm, I did my best to make the window-popping
  dance as graceful as possible (unwind-protect so that the details
  buffer is killed even after C-g, save-window-excursion to restore the
  window configuration…), but maybe it falls apart in cases I haven't
  considered.

- UI bikeshedding: maybe drop the leading "Warning:", add the underline
  face to the mix…

- Code quality: some of the small functions I wrote exist for no other
  reason than I found the resulting code to be easier to follow; they
  could probably be inlined if others do not share my preferences.