Re: Getting point and click going with gvim on Alma Linux
An update with a solution re gvim with point and click. This would also
apply to other Linux distros apart from Alma Linux I think.
It turns out the missing comma for the gvim remote command has been
submitted as a bug report. But the gobbledygook internal message that
gvim prints and requires you to acknowledge by pressing enter - totally
unnecessary to see or do - can be fixed by using a different command to
execute the remote gvim call.
Hence, in libexec/lilypond-invoke-editor the gvim commands line needs to
be changed to use a call to cursor() and not use the norm command. This
fixes the problem, and makes gvim nice to use again in this context.
# "gvim": [("gvim", "--remote", "+:%(line)s:norm%(column)s", "%(file)s")],
=>
"gvim": [("gvim", "--remote", "+call cursor(%(line)s,%(column)s)",
"%(file)s")],
So we go from this situation in the first image attachment to the
correct one in the second attachment, and no 'press ENTER...'.
It took three days full time to figure this out, including having to
read the source code for vim!
I'll submit a patch for this fix.
Since gvim supports a lilypond syntax file, this is a good solution for
Lilypond as an alternative to Frescobaldi. I did look into this a few
years ago when I 'outgrew' Frescobaldi with some really long and complex
scores and Frescobaldi's response time blew out to unusable levels. I
think this is still an issue in Frescobaldi. It may not affect all
users, but gvim can handle files of any length and provides a solution
to this problem.
I have not read anything much about gvim point and click on Linux on the
list. Or maybe people put up with the junk message and keypress and
don't complain about it. How many people use this setup? Maybe one or two!
[Amusingly I am an emacs user but last time I used that there were still
bad defects in the lilypond code that I am not experienced enough to
solve, and I think these have still not been attended to, although I may
be wrong. Hence my interest in gvim for Lilypond.]
Andrew
On 5/09/2022 9:46 am, Andrew Bernard wrote:
In response to the recent thread on alternatives to Frescobaldi on
Alma Linux I have prepared this set of instructions. I have tested
this and there are two points in addition to the notes below.
One, I am unable to get rid of the last line of the extensive status
message gvim shows at the bottom when invoked with a remote call. This
is puzzling - I am working on it.
Second, in 2.23.12 at least, there is an error, strangely only for
gvim, in libexec/lilypond-invoke editor. Line 130 is missing a comma,
and must be updated to:
"gvim": [("gvim", "--remote", "+:%(line)s:norm%(column)s",
"%(file)s")],
I have submitted a bug report request about this.
Re: Getting point and click going with gvim on Alma Linux
Worse, /usr/bin/vim in Alma Linux will not run the --servername option as it is built without it. You'd have to build vim from source. Vim on Arch Linux is built with that option, I checked. Once more, a disadvantage of Alma Linux. Also, having originally said to use the flatpack version of Frescobaldi, for me it is unusable (though it worked once the first time, and not thereafter) as it shows all sorts of strange file paths under /run, and not my home directory. For me on Alma Linux that is also a failure. Do not misinterpret me - I think Alma Linux is really excellent. Just not in the context of the Lilypond application area. Andrew
Re: Getting point and click going with gvim on Alma Linux
This note was to help out with Alma Linux, so I have not tried on other distros as yet, but using vim in server mode is a failure as bad as emacs. It prints a message correctly claiming input is not from a terminal and hangs, and then, weirdly, it hangs evince as well which has to be forced to quit. Not exactly a happy state. That's on vim compiled from the latest source, version 9.0.381. Personally I don't use Alma Linux, was just doing this for the OP of the thread about Frescobaldi alternatives. But I am getting the impression that while Alma Linux is a great enterprise class server system, it may not be the optimal choice for Lilypond. Nevertheless, I will continue to study the matter. Andrew
Re: Getting point and click going with gvim on Alma Linux
On Tue 06 Sep 2022 at 03:27:46 (+1000), Andrew Bernard wrote: > > I'll incorporate your suggestions. Note that this was specifically > about gvim not vim, but I can add in vim as well, since it is so > closely related. There's still stuff here that is not covered in the > NR,. such as window focus with the mouse that I think is useful. > However, looking more closely now at the NR it looks like this file > was a waste of time, as it is all covered the now. [I wonder if some > bits came from my original screed? :-)] I'm guilty of not reading the > current NR closely. Incidentally I use EDITOR for everything, not a > different editor for lilypond, but that's a valid point re LYEDITOR. > My notes reflect my bias. I added the note about vim partly because J Martin Rushton mentioned running it as part of a non-Frescobaldi workflow. BTW I was interpreting your NR to refer, sensu stricto, to notation.pdf, and Usage to refer to usage.pdf. It strikes me that the distinction might not be obvious in the web docs. I omitted to add that the lilypond-invoke-editor.desktop that one creates is a scratch file, which can be deleted once the xdg-* commands have been run. The official LP docs suggest creating it in /tmp but without mentioning that that usually results in it being cleaned out at the next boot. > The gvim annoying error message and press ENTER to continue is still > not resolved even in version 9 but I am determined to find an answer > even it it means patching the source code. Currently it really makes > gvim much less felicitous than it ought to be for this application. > > I don't know if it is worth mentioning but emacs on Alma Linux at > least totally carks it when used in this manner with emacs as as > server. But emacs has the courtesy to print out that this is a known > bug, then promptly dies! I have in my notes (written when Debian was two versions back): $ emacs ESC-x server-start (Don't run emacs --daemon as this seems to provoke an error (or unusual effect) at the present time which is stretch.) As is well-known, without setting emacs to server-mode, every point-and-click will open a new instance. However, you can type ESC-x server-start at any time in any one emacs instance (ie only one server in operation at a time). > But my notes are really redundant since the NR does cover pretty much > all, so I guess the recommendation can be changed to RTNR. :-) The boxed note in Usage (§4.1.1 page 43) should carry a warning that every time, apart from the first, that you try to start a new instance of emacs (eg to reply to an email, edit a file, point-and-click, etc), you'll end up with a split screen and a 4-line warning message—very tedious. ISTR that we had fun with apparmor last time around. I'll have to check whether bullseye has been configured such that you don't notice it, or whether I just haven't set it up to enforce it. There are always wrinkles. Cheers, David.
Re: Getting point and click going with gvim on Alma Linux
Thanks David, I'll incorporate your suggestions. Note that this was specifically about gvim not vim, but I can add in vim as well, since it is so closely related. There's still stuff here that is not covered in the NR,. such as window focus with the mouse that I think is useful. However, looking more closely now at the NR it looks like this file was a waste of time, as it is all covered the now. [I wonder if some bits came from my original screed? :-)] I'm guilty of not reading the current NR closely. Incidentally I use EDITOR for everything, not a different editor for lilypond, but that's a valid point re LYEDITOR. My notes reflect my bias. The gvim annoying error message and press ENTER to continue is still not resolved even in version 9 but I am determined to find an answer even it it means patching the source code. Currently it really makes gvim much less felicitous than it ought to be for this application. I don't know if it is worth mentioning but emacs on Alma Linux at least totally carks it when used in this manner with emacs as as server. But emacs has the courtesy to print out that this is a known bug, then promptly dies! But my notes are really redundant since the NR does cover pretty much all, so I guess the recommendation can be changed to RTNR. :-) Andrew
Re: Getting point and click going with gvim on Alma Linux
Just some jottings for your consideration.
On Mon 05 Sep 2022 at 09:46:44 (+1000), Andrew Bernard wrote:
> In response to the recent thread on alternatives to Frescobaldi on
> Alma Linux I have prepared this set of instructions. I have tested
> this and there are two points in addition to the notes below.
>
> One, I am unable to get rid of the last line of the extensive status
> message gvim shows at the bottom when invoked with a remote call. This
> is puzzling - I am working on it.
Yes, I usually see one line of that message. It seems to be less
frequent if the first click takes you a reasonable distance down
the source file, and virtually always seen if the top of the
source is showing. Not being a vi-person, I have no idea how to
eliminated it. (I do have your .vimrc fragment below included.)
> Second, in 2.23.12 at least, there is an error, strangely only for
> gvim, in libexec/lilypond-invoke editor. Line 130 is missing a comma,
> and must be updated to:
>
> "gvim": [("gvim", "--remote", "+:%(line)s:norm%(column)s",
> "%(file)s")],
>
> I have submitted a bug report request about this.
It looks as if this has always been in the new Python version,
so perhaps we can surmise that the developer wasn't a vim-person.
[ … ]
> The Guide to getting Point and Click going with Gvim under Alma Linux 9
> ---
>
> The NR has no detailed information about Lilypond point and click with
> gvim for
> Alma Linux. This note attempts to remedy that. Some information from
> the NR is
> copied here for ease of reference.
I think point-and-click was covered in Usage since 2.14.
[ … ]
> Setting the EDITOR variable
> ---
>
> Lilypond uses the environment variable EDITOR to select which editor
> to use to
> display point and click links. For gvim, simply use the value 'gvim':
>
> export EDITOR=gvim
>
> Setting LYEDITOR is not required.
For the new, Python, version of lilypond-invoke editor,
the preferred choice of variable is, in order of preference,
LYEDITOR, XEDITOR and EDITOR. Using LYEDITOR is specific to
point-and-click, and so you don't interfere with the usual
system-wide effects of EDITOR (eg with crontab, mutt, less,
more, midnight commander, etc. to name but a few).
> Running Gvim and Evince
> ---
>
> Run gvim in server mode by doing - exactly nothing! Simply running gvim will
> start the process in a new window. From the terminal this suffixes:
>
> $ gvim
>
> By default gvim will respond to remote requests such as from
> lilypond-invoke-editor. There is no need to use the --servername
> option as the
> name defaults to GVIM (and you can see this in the title bar). By default
> lilypond sends point and click requests to the gvim server named GVIM.
If you prefer running a text version of vim (eg, in xterm/terminal/…),
you still need to add --servername gvim when you start vi/vim,
so that it captures the point-and-clicks.
This is because the servername "gvim" is hard-coded into
lilypond-invoke-editor as server to seek, but the server's name
defaults to the name by which it was invoked: ie, vi or vim.
Cheers,
David.
Getting point and click going with gvim on Alma Linux
In response to the recent thread on alternatives to Frescobaldi on Alma
Linux I have prepared this set of instructions. I have tested this and
there are two points in addition to the notes below.
One, I am unable to get rid of the last line of the extensive status
message gvim shows at the bottom when invoked with a remote call. This
is puzzling - I am working on it.
Second, in 2.23.12 at least, there is an error, strangely only for gvim,
in libexec/lilypond-invoke editor. Line 130 is missing a comma, and must
be updated to:
"gvim": [("gvim", "--remote", "+:%(line)s:norm%(column)s",
"%(file)s")],
I have submitted a bug report request about this.
This is a variant of the document 'The Guide to getting Point and Click
going with Gvim under Ubuntu 18' I submitted to the list some years ago,
and the comments members made there may be useful to read still.
https://mail.gnu.org/archive/html/lilypond-user/2019-02/msg00536.html
These instructions are readily adaptable to other text editors that are
supported in libexec/lilypond-invoke-editor. I used Alma Linux 9.0 to
develop these notes.
Andrew
The Guide to getting Point and Click going with Gvim under Alma Linux 9
---
The NR has no detailed information about Lilypond point and click with
gvim for
Alma Linux. This note attempts to remedy that. Some information from the
NR is
copied here for ease of reference.
Requirements
Alma Linux 9.0
Document Viewer (evince)
Lilypond
gvim version 8.2 (vim-X11 package)
[assumes bash shell]
Setting the EDITOR variable
---
Lilypond uses the environment variable EDITOR to select which editor to
use to
display point and click links. For gvim, simply use the value 'gvim':
export EDITOR=gvim
Setting LYEDITOR is not required.
You can start evince from a terminal command to view a PDF. But if you
want to
click on a PDF in GNOME Nautilus to view it then just exporting this
variable
from the various bash startup files is inadequate. Gnome is started by
Xsession
in X11 before terminals and shells. Therefore it is unable to see
environment
variables set in .bashrc (or .bash_profile, etc). To resolve this matter,
recall that Xsession uses the startup file $HOME/.xsessionrc. For
environment
variables that are to be shared between GNOME applications and terminal
shells,
do the following. Create a file for variable declarations, of arbitrary
name.
Add the EDITOR setting to that file:
$ echo 'export EDITOR=gvim' > ~/.my_env_vars
Then edit ~/.xsessionrc to contain:
if [ -f ~/.my_env_vars ]; then
. ~/.my_env_vars
fi
Now also add these same lines to ~/.bashrc. Some like to use
.bash_profile or
other mechanisms, but the principle is the same. Manage any shared variables
that Nautilus and a bash shell both need in this third file. To make
this take
effect, logout and login again so that a new Xsession is started.
Installing Gvim
---
Gvim is in the following package, not a package called gvim.
# dnf install vim-X11
Configuring the GNOME 3 Desktop
---
Create the file 'lilypond-invoke-editor.desktop':
[Desktop Entry]
Version=1.0
Name=lilypond-invoke-editor
GenericName=Textedit URI handler
Comment=URI handler for textedit:
Exec=lilypond-invoke-editor %u
Terminal=false
Type=Application
MimeType=x-scheme-handler/textedit;
Categories=Editor
NoDisplay=true
Run:
$ xdg-desktop-menu install ./lilypond-invoke-editor.desktop
$ xdg-mime default lilypond-invoke-editor.desktop x-scheme-handler/textedit
Check that this works. Install the xdg-open program:
# dnf install xdg-utils
Then:
$ xdg-open textedit:///etc/os-release:1:0:0
If all is correct lilypond-invoke-editor will run and display the file.
Configuring Gvim
Not all users see this problem, but if you do, it is hard to solve if
you don't
know. On a plain new gvim install, every time you click on a lilypond grob
under the setup described here, a rather daunting status message is
shown, and
you have to press ENTER to continue, each time. This is just an example:
:if !exists('+acd')||!&acd|if haslocaldir()|cd -|lcd -|elseif getcwd()
==# '/home/andro'|cd -|endif|endif
::1898:norm3|cal foreground()|if &im|star|en|redr|f
And also 'Press ENTER or type command to continue'.
The solution to this is to change the size of the message display in
gvim. Add
the following to ~/.gvimrc:
if exists('+cmdheight') && (&ch < 2)
set ch=2
endif
You may need to set the height to 3, depending on various sizes.
[As for why some people do not see this issue, I am unclear.]
[n.b. this is from the previous issue of this document for Ubuntu 18 but the
messsage in Alma Linux persists despite this fix. I am currently working on
it.]
A Personal Preference
-
Because gvim comes by default with mouse enabled, and this is a useful
feature,
if you click i
