Gvim message on XDG textedit URL link

[Andrew Bernard]

I have PDF's with links in them and XDG textedit URLs that can take me from the PDF to the source file (for lilypond music engraving if interested)., The links work and take me to the right line and column corresponding to the link in the PDF. But I am unable to turn off the lengthy and needless long cryptic message displayed at the bottom of the screen despite searching for answers. Having to see this and press enter every time is tedious. This is an example:

Here's the sort of textedit link:

textedit:///home/acb/work/test.ly:4:2:3

What should one do?

[Charles Campbell]

Andrew Bernard wrote:
> I have PDF's with links in them and XDG textedit URLs that can take me
> from the PDF to the source file (for lilypond music engraving if
> interested)., The links work and take me to the right line and column
> corresponding to the link in the PDF. But I am unable to turn off the
> lengthy and needless long cryptic message displayed at the bottom of
> the screen despite searching for answers. Having to see this and press
> enter every time is tedious. This is an example:
>

> gvim message.jpg
>
> Here's the sort of textedit link:
>
> textedit:///home/acb/work/test.ly:4:2:3
>
> What should one do?
>

I am unable to find a "textedit:" string in any of the vim runtime
files. Sounds like you've installed a plugin to handle textedit links --
so I suggest finding out what the plugin name is and contacting its author.

Chip Campbell

[Andrew Bernard]

Perhaps I was not clear. The string 'textedit' has nothing to do with gvim internals or scripts or plugins. It's the URL used by the xdg-open process when running gvim in server mode, so that the file is opened on a given line and column. The textedit string is embedded in the PDFs as a way of linking objects in the PDF to the source code line for them. It's got nothing to do with any plugins. It's a standard and common technique with PDF files.

Gvim works fine in servermode, and the file is opened at the right place. It very inconvenient to see this long message for no good reason - it's not an error, it's not useful information, and to have to press ENTER each time, when you are going back and forth between a music score and its note objects and the Lilypond source code hundreds of times. I can't see any reason for this behaviour from gvim, and it actually makes it pretty much unusable for this use case.

If you set up a handler for the MIME type x-scheme-handler/textedit then xdg-open textedit:///home/acb/work/test.ly:4:2:3 will open the file test.ly in the editor you have set for handling text documents on your system and go to the location. In the same way that clicking a URL in a PDF opens your browser on the page.

I'm not reporting an error, but a usability issue, bad enough to make me have to switch to alternative editor for the task. This used to work int he past where you could set cmdheight to 2, but that no longer suppresses the message ion version 9.0.

Andrew

[Christian Brabandt]

It it still not clear yet, when this happens. So please clarify, what
exactly do you do to make those messages appear, that you'd like to
hide?


Thanks,
Christian
--
Ersparnis der Erfahrung
Sündflut der Erfahrung,
Dinge, wovon man nicht reden würde, wenn man
wüsste, wovon die Rede ist.
-- Goethe, Maximen und Reflektionen, Nr. 1337

[Andrew Bernard]

Can you see the image attachment in my post? That's the message. Also,
it is clear when it happens as I said - on a remote call from xdg-open
textdit style URLs. I don't think my post was totally vague. Maybe I am
wrong!

Andrew

[Christian Brabandt]

On Mi, 07 Sep 2022, Andrew Bernard wrote:

> Can you see the image attachment in my post? That's the message. Also, it is
> clear when it happens as I said - on a remote call from xdg-open textdit
> style URLs. I don't think my post was totally vague. Maybe I am wrong!

We have seen the message. What we do not know yet is, what exactly you
did to make this message appear.

Thanks,
Christian
--
Schau mir in den Auspuff Kleines!

[Andrew Bernard]

Sorry, this is all too hard it would seem. To explain in it in detail
you would have to read how to use point and click with PDFs made by
Lilypond.

The program gvim is producing unwanted messages when invoked with a
remote call and produces a needless pres ENTER, when all one wants is
for the remote call to go to the line and column.

If there is any interest still, here is an example call:

gvim --remote "+3:norm4" test.ly

Apologies if I left this out. I thought people would be familiar with
textedit URLs and how to use them. I suppose that sort of call is not
obvious after all.

[Christian Brabandt]

On Mi, 07 Sep 2022, Andrew Bernard wrote:

> Sorry, this is all too hard it would seem. To explain in it in detail you
> would have to read how to use point and click with PDFs made by Lilypond.
>
> The program gvim is producing unwanted messages when invoked with a remote
> call and produces a needless pres ENTER, when all one wants is for the
> remote call to go to the line and column.
>
> If there is any interest still, here is an example call:
>
> gvim --remote "+3:norm4" test.ly
>
> Apologies if I left this out. I thought people would be familiar with
> textedit URLs and how to use them. I suppose that sort of call is not
> obvious after all.

Ah, so this comes from the --remote call.

Interesting, that the :norm4 works, because there is no pipe after it.
But it looks like Vim builds up the whole string dynamically and adds an
'|' at the end automatically.

However, I think this silently breaks, because the ":norm" sees
everything after it as belonging to it, so in this case the '|' does not
really end the user specified command and therefore you see this
message. I messed around briefly, trying to wrap everything into an :exe
expression (or using :call cursor), but at least, this did not seem to
work on my windows environment.

A possible work-around would be to it build the whole command yourself
by using, e.g. --remote-send "<c-\><c-N>:e +3|norm4| .bashrc<cr>"

or:

--remote-send "<c-\><c-n>:e .bashrc<cr>|:e|norm4|<cr>"

I wonder if this would work better with the following patch, by wrapping everything into an :exe call.

diff --git a/src/clientserver.c b/src/clientserver.c
index bb2108d7d..c4489c953 100644
--- a/src/clientserver.c
+++ b/src/clientserver.c
@@ -654,8 +654,9 @@ build_drop_cmd(
// Can't use <CR> after "inicmd", because a "startinsert" would cause
// the following commands to be inserted as text. Use a "|",
// hopefully "inicmd" does allow this...
+ ga_concat(&ga, (char_u *)":exe \"");
ga_concat(&ga, inicmd);
- ga_concat(&ga, (char_u *)"|");
+ ga_concat(&ga, (char_u *)"\"|");
}
// Bring the window to the foreground, goto Insert mode when 'im' set and
// clear command line.


Thanks,
Christian
--
10E12 Mikrophone = 1 Megaphon
10E-6 Fisch = 1 Mikrofiche
10E21 Picolos = 1 Gigolo
10 Rationen = 1 Dekoration
3 1/3 Tridents = 1 Dekadent
10 Monologe = 5 Dialoge
2 Monogramme = 1 Diagramm

[Bram Moolenaar]

> On Mi, 07 Sep 2022, Andrew Bernard wrote:
>
> > Sorry, this is all too hard it would seem. To explain in it in detail you
> > would have to read how to use point and click with PDFs made by Lilypond.
> >
> > The program gvim is producing unwanted messages when invoked with a remote
> > call and produces a needless pres ENTER, when all one wants is for the
> > remote call to go to the line and column.
> >
> > If there is any interest still, here is an example call:
> >
> > gvim --remote "+3:norm4" test.ly
> >
> > Apologies if I left this out. I thought people would be familiar with
> > textedit URLs and how to use them. I suppose that sort of call is not
> > obvious after all.
>
> Ah, so this comes from the --remote call.

That was the missing info. This leads to the remote server feature,
which builds a sequence of commands and sends it to the server.

For me it already helps to set 'cmdheight' to 2 or more.

The main problem is that on the server this is received as a command and
put in the input buffer, after which it is executed almost as typed.

Instead of building the command on the client, which can end up being a
bit long, we could send the minimal information to the server and
expand it into the right commands there. We already have
runtime/plugin/rrhelper.vim.

--
Shift happens.
-- Doppler

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[aro...@vex.net]

One of the incidental pleasures of this list is the signature tags. I'm
not sure wheter today's winner is Bram's:

> Shift happens.
> -- Doppler

or Christian's:

--
10E12 Mikrophone = 1 Megaphon
10E-6 Fisch = 1 Mikrofiche
10E21 Picolos = 1 Gigolo
10 Rationen = 1 Dekoration
3 1/3 Tridents = 1 Dekadent
10 Monologe = 5 Dialoge
2 Monogramme = 1 Diagramm

--

[Andrew Bernard]

Reviving this after some time, this still happens with textedit calls to gvim 9.0. Setting the cmdheight no longer works. Can anything be done?