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

[David Wright]

On Mon 02 Nov 2020 at 09:59:45 (+0100), Martín Rincón Botero wrote:

> […] Out of curiosity, do Mac and Windows users have to stick to Frescobaldi 
> for Point & Click? They’re not even mentioned in the Usage Manual.

The code in the footnote of my reply to Andrew implies that, in the
absence of a *EDITOR environment variable, the Windows platform
chooses lilypad, and any other platform chooses emacs. That would
suggest that P&C works on them too.

> > 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
> 
> Wow, that’s old hardware! In my Asus laptop from 2017, Atom takes a while to 
> open the first time. After that, each click takes around 0.5 secs or less I 
> would say. It’s not something of great concern to me, but it’s noticeable, 
> especially after being used to Frescobaldi’s immediate reposition of the 
> cursor. Perhaps it has to do with Atom (not the lightest editor around). Were 
> Atom not so pleasing to the eye, I would probably try with another one to 
> compare speed ;-).

I'm guessing that there are three places where a delay could occur,
and on linux it should be easy to distinguish them. With two xterms,
I started gvim on one (and you'd use atom):

$ strace -f gvim

and on the other I started Xpdf:

$ LYEDITOR=gvim strace -f xpdf my-grand-opera.pdf

When the dust settles, you should see an outpouring of text on
each xterm when the moused is moved over either window.

So hold the mouse steady over a note, then click the button slowly,
and you should see more text appear with ButtonDown and more again
with ButtonUp. As far as P&C is concerned, it's ButtonUp that's
important, so the first delay is in how fast your finger twitches.¹

So to see where the delay is occurring, move the xterms close
together, then hold the button down over a note and, when all
activitiy has ceased, release it. You can see roughly how long
the communication takes by how quickly atom's xterm reacts
after xpdf's xterm.

Similarly, you can move atom and its xterm close together, and
observe the time difference between atom's xterm reacting and
its cursor moving. With 0.5 secs delay, you should be able to
resolve that somewhere in the chain.

If the delay is between the two xterms' output, I would guess
that changing editor won't make much difference.

¹ I can cheat here, as I have the PrintScreen key defined as a
  25 msec left button press, which is faster than I can click
  with the mouse.

Cheers,
David.