emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [BUG] org-insert-link should use DEFAULT in read-string when asking


From: Max Nikulin
Subject: Re: [BUG] org-insert-link should use DEFAULT in read-string when asking for description
Date: Sun, 27 Feb 2022 17:48:45 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

On 26/02/2022 21:16, Visuwesh wrote:
[சனி, பிப்ரவரி 26 2022] Max Nikulin wrote:

Are you suggesting replacing
     (read-string "rs-initial: " "Some initial")
by
     (read-string "rs-default: " nil nil "Some default")
?

Yes, exactly.

However you agreed that it would be regression since empty description use case would be impossible.

I admit that I forgot about this but Emacs can be made to not translate
empty string to the default argument if you DTRT when calling
`read-from-minibuffer' (and `read-shell-command' does this).  If writing
a new function just to get this functionality is too much, then I guess

`read-shell-command' still has INITIAL argument and it is used by various callers (vc, grep). In addition, unlike for link description, I do not see any point in empty shell command (e.g. in vim :! allows to see output of previous shell command). So `read-shell-command' may behave quite differently.

Current way to ask for link description has the following properties:
- Almost no action (just RET) if the user happy with suggested description. Default description is provided with hope that it is the most convenient option.
- It is possible to erase everything and to get a link with no description.
- The user is free to replace default description with arbitrary alternative text.

It is unclear for me how to tame `read-from-minibuffer' to get equally convenient behavior using DEFAULT argument instead of formally deprecated INITIAL one.

I can live with the current behaviour, but this inconsistency is an
annoyance since I end up with garbled link names, which I only notice
_afterwards_.

Sorry, but I have not figured out what particular problem you met.




reply via email to

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