Re: The Guide to getting Point and Click going with Gvim under Ubuntu 18

[David Wright]

On Sun 01 Nov 2020 at 14:25:07 (+0100), Martín Rincón Botero wrote:
> Thank you very much, Andrew, for this guide! It works! My pdf viewer is
> Foxit Reader so after installing the gnome-open program and checking it
> works, I didn't have to follow any other steps. I wish this guide can be
> merged with the current guide in the Usage Manual. Just one small
> suggestion to make this guide even more idiot-proof (at least for the steps
> I did) would be to make this step a bit more verbose: "Create the file
> 'lilypond-invoke-editor.desktop' *f. ex. in your home folder*". The next
> command assumes that you created the file via terminal and you moved to
> that location with the terminal. In the case that you created that file
> using GEdit (like I did) and followed the instructions in the Usage Manual
> (where it mentions /tmp as folder), the next command won't really work
> unless you're already there in the terminal (where I wasn't, since a
> terminal opens by default with the home directory). This might be obvious
> for people who do everything via terminal, but not for people who prefer
> using graphical applications like GEdit.

I see the problem, but I think that solution is unwise as it leaves
a redundant file in the user's home directory, which they may fear
removing. Better would be to improve the Usage manual in a way such as:

--✄------
  and then execute the commands

    xdg-desktop-menu install /tmp/lilypond-invoke-editor.desktop
    xdg-mime default lilypond-invoke-editor.desktop x-scheme-handler/textedit

  where /tmp is the directory that was chosen for the file.
--✄------

At present, the Usage manual switches from /tmp/ to ./ without
explanation. The idea of using /tmp for the scratch file is of course
that it's automatically emptied when you reboot.

> Is it maybe possible to create a
> script that automates all this? Perhaps the Gvim and Evince parts can be
> left out of it, but I have the feeling that what I just had to do can be
> made into a script. I already can do some scripting in Python, but such a
> script would need the user to have Python installed. So a Bash script from
> someone acquainted with Bash would be very welcome.

This script then has to be maintained, and it also makes it less obvious
how to adjust the process for any differences between systems. I think
the process is mysterious enough without hiding it any more.

> Atom works very well even with large files, however there's a small lag
> with point & click (even with small files). Since Frescobaldi doesn't have
> this Point & Click problem even with large files, I assume this small lag
> has more to do with the fact that there are two applications involved (Atom
> and Foxit) rather than one (Frescobaldi). Am I right? This Point & Click
> penalty is something that I'm willing to trade for the moment: it's less
> than Frescobaldi hanging while trying to move the cursor, let alone for
> trying to edit a large file. I hope this performance issue can be fixed in
> Frescobaldi eventually (although Atom has other advantages like Column
> Selection...).

So what sort of lag are you talking about? And is it different on the
first click (ie when the source file has to be opened)? You must be
running on reasonable hardware, so a noticeable lag does not seem
at all reasonable. A data point for you:

Debian 10/buster with Xpdf and emacs running on a 2000-vintage
Pentium III at 650MHz in 512MB memory took less than a second to
open the source at the first click, and thereafter serviced each
click in 0.5 secs, just so long as the new target position is in
the displayed window. (Obviously this machine takes at least a
second or two to scroll any distance in the editor, and at least
a second just to turn a page in a simple image-free PDF file.)

Cheers,
David.