unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Clément Pit-Claudel" <cpitclaudel@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Escaping a string for substitute-command-keys
Date: Fri, 4 Oct 2019 09:56:56 -0400	[thread overview]
Message-ID: <ab411bb8-9d72-b285-2c3f-68682a083d1f@gmail.com> (raw)
In-Reply-To: <837e5l7j8n.fsf@gnu.org>

On 2019-10-03 14:54, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 3 Oct 2019 14:28:43 -0400
>>
>>> Is the problem only with quotes?  Or also with other characters?
>>
>> Any characters: for example, \\[ should not trigger a replacement.  The use case (displaying warnings and errors as overlays on code) does not require any string transformation, just to display what a tool (such as gcc or python) produced.
> 
> Then why do you use APIs that are meant for keys and quoted strings?
> Why not format the message yourself?

Sorry, I do not understand what you mean.  I want to display information when the mouse hovers on a portion of the buffer.  Isn't the proper way to do that to set a help-echo property on the corresponding text?

The manual says nothing about command-key substitutions, it just says "If text has a string as its help-echo property, then when you move the mouse onto that text, Emacs displays that string in the echo area, or in the tooltip window (see Tooltips)."

Really, all that I'm complaining about is this bit of code in keyboard.c:

  if (STRINGP (help) || NILP (help))
    {
      if (!NILP (Vshow_help_function))
	call1 (Vshow_help_function, Fsubstitute_command_keys (help));
      help_echo_showing_p = STRINGP (help);
    }

My question is why Vshow_help_function is called with its arguments passed through Fsubstitute_command_keys.

>> Ideally, it would be best to be able to turn off that translation entirely, I think.  I see why it is convenient, but it seems wasteful to mangle a string with escapes only for these escapes to be promptly removed right after.
> 
> Format it yourself, and you have that, no?  Or what am I missing?

I think I've been miscommunication :/ Sorry for wasting your time. My text is already formatted exactly how it should look.  My problem is that once I apply it using a help-echo property, it's displayed differently in the echo area and when I hover with the mouse: the pop-up from the mouse runs the contents of help-echo through substitute-command-keys, but help-at-point doesn't.

>> Should all uses of help-echo be fixed to call substitute-command-keys, and should all code that sets help-echo and doesn't want substitutions changed to escape quotes and backlashes?
> 
> I think you are using the wrong APIs for the job you need to do.
> These APIs perform the substitutions for a reason: they were all
> written for displaying documentation, not arbitrary strings.

I'm saying that these APIs are inconsistent: sometimes they do substitution, sometimes they don't.  Tooltips have substitution applied, and help-at-point doesn't perform substitutions.  And at least two clients of that API seem to be using it wrong (both Flycheck and Flymake).

> Then don't use help-echo, use child frames instead.

Are you saying that flymake should grow its own implementation of tooltips, just to work around the fact that help-echo strings are passed through substitute-command-keys?

Thanks for your help,
Clément.



  reply	other threads:[~2019-10-04 13:56 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03 13:52 Escaping a string for substitute-command-keys Clément Pit-Claudel
2019-10-03 16:31 ` Eli Zaretskii
2019-10-03 16:46   ` Clément Pit-Claudel
2019-10-03 17:21     ` Eli Zaretskii
2019-10-03 18:28       ` Clément Pit-Claudel
2019-10-03 18:54         ` Eli Zaretskii
2019-10-04 13:56           ` Clément Pit-Claudel [this message]
2019-10-04 14:17             ` Eli Zaretskii
2019-10-05  4:03               ` Clément Pit-Claudel
2019-10-05  7:33                 ` Eli Zaretskii
2019-10-05 15:05                   ` Stefan Monnier
2019-10-05 15:59                     ` Eli Zaretskii
2019-10-05  4:06               ` Clément Pit-Claudel
2019-10-05  7:12                 ` Eli Zaretskii
2019-10-05  8:04                   ` Clément Pit-Claudel
2019-10-05  8:13                     ` Eli Zaretskii
2019-10-05  8:24                       ` Clément Pit-Claudel
2019-10-05  9:20                         ` Eli Zaretskii
2019-10-04 19:19         ` Stefan Monnier
2019-10-05 15:40           ` Basil L. Contovounesios
2019-10-05 16:06             ` Eli Zaretskii
2019-10-05 19:53               ` Basil L. Contovounesios
2019-10-06  2:57                 ` Clément Pit-Claudel
2019-10-06 17:21                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ab411bb8-9d72-b285-2c3f-68682a083d1f@gmail.com \
    --to=cpitclaudel@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).