search

martineausimon / nvim-lilypond-suite

Neovim plugin for writing LilyPond scores, with asynchronous make, midi/mp3 player, fast syntax highlighting, "hyphenation" function, and support for LaTex and Texinfo files
GNU General Public License v3.0
130 stars 11 forks source link

`E79: Cannot expand wildcards` on `:LilyCmp` and `:LilyPlayer` #19

Closed niveK77pur closed 1 year ago

niveK77pur commented 1 year ago

The issue

Today, I have encountered an issue where :LilyCmp and :LilyPlayer both yield the following error. My <FILENAME>s usually only contain lower and upper case letters, and possibly dashes (-) to separate words.

Both operations do not work on projects which worked in the past. Even the last project I worked on when making my previous issue a few days ago does not work anymore. I am really not sure if the problem is related to the plugin or something else.

I should also mention that opening the PDF using :Viewer works just fine!

The error message

For :LilyCmp

Compiling <FILENAME>.ly...
E79: Cannot expand wildcards

and for :LilyPlayer

[NVLS] Converting <FILENAME>.midi to mp3...
E79: Cannot expand wildcards

Related information

:h 79 shows the following. To my knowledge, there are no wildchars in my filenames though. I am even more certain about this fact, since files that previously compiled just fine cause this issue.

                            *E79*   
  Cannot expand wildcards

A filename contains a strange combination of characters, which causes Vim to
attempt expanding wildcards but this fails.  This does NOT mean that no
matching file names could be found, but that the pattern was illegal.

I can compile the files just fine in the terminal using lilypond <FILENAME>.

niveK77pur commented 1 year ago

I have just noticed something else, right after posting the issue. The score actually compiles after I close the error message. Similarly, the MP3 player is launched after the error is closed.

It seems that things are still working, but there is this error message that appears before doing so; There does not seem to be any other bad side effects at a glance, other than the error being a nuisance.

martineausimon commented 1 year ago

Hi, sorry for this issue ! Can you please check the return of :lua print(nvls_main) ?

niveK77pur commented 1 year ago

No worries at all! And thank you so much for always getting to the issues so quickly!

In my case it returns (which does not seem to contain anything unusual): /home/myuser/Documents/VinLudens-Sheets/QA-014_Sound-and-Vision/Sound-and-Vision.ly

All my sheets have the /home/myuser/Documents/VinLudens-Sheets/ part in common. Also note that myuser is not my actual username, but mine only contains lower case characters like this too.

martineausimon commented 1 year ago

Thanks for this information.

Unfortunately I can't reproduce this issue. I tried with your nvim config with NVIM_APPNAME, but it works normally.

I think it could be en error in the make function, which is used by :LilyCmp and :LilyPlayer, but not by :Viewer.

Can you tell me if this bug persists when the :LilyPlayer command is used a second time, i.e. the midi file is up to date with the ly file and the mp3 has already been created ? In this case the make function is not invoked.

niveK77pur commented 1 year ago

Thank you! This is very strange indeed, thanks for the input despite not being able to reproduce it!

Running :LilyPlayer after the first time like you mentioned makes the error not appear anymore! It would definitely be helpful if nvim also told me which line is causing the error to appear, but if you have no further clues, at least I know where I can start pinpointing the problem.

In case it is relevant and can help, I am using NVIM v0.9.1. I was also using the nightly build but had the same issue (I switched to the stable build in case something in the nightly had caused this)

martineausimon commented 1 year ago

I wonder if it could be a shell issue. Anyway I think the error may come from line 112 in lua/nvls.lua, containing expandcmd. Can you do some tests directly in nvim with this command ? For example :echo expandcmd("$HOME/Documents/") or something more complex ?

niveK77pur commented 1 year ago

Thanks for the hint, I shall investigate! I should note that I recently switched from bash to fish (good catch on that) and the thought that this might be causing issues has faintly crossed my mind as well. However, even using bash now I still get the error so I eliminated this possibility ... maybe something else has changed after I switched the default shell.

I will report back once I have done some troubleshooting using your pointers!

niveK77pur commented 1 year ago

Preliminary

So after looking around I found a few related issues with the same error and similar symptoms, which eventually lead me to confirm that the issue stems from fish after all! It turns out that fish is not very recommended as the shell in neovim!

For one because it allegedly renders neovim slower,

but also simply as a matter of compatibility.

Plenty of vim addons execute fish-incompatible shellscript, so setting it to /bin/sh is typically better, especially if you have no good reason to set it to fish.

So the good news: There is nothing wrong with the plugin! I'll still lay out everything in case another lost soul stumbles upon here; please check out the Solutions below~

Though there is a "fix" that could potentially be introduced into the plugin in this particular case, see the next section.

The actual issue

In this case however, the issue is not with any incompatible shellscripts. After playing around with the expandcmd() function as you suggested, I managed to more consistently summon the error. It appears as though a quoted string within the string, raises the error. Not using quotes also avoids the error, is not a good solution since filenames might contain spaces.

:echo expandcmd("a 'b' c") |"raises error
:echo expandcmd('a "b" c') |"raises NO error

As you can see, nested single quotes cause a problem, whereas nested double quotes appear to be fine. Also accessing environment variables causes issues under certain circumstances, though I have not managed to find a clear pattern here.

I looked around a bit to check where you used that make() function and it appears at a glance that you create strings with nested single quotes. Based on my quick investigation,

I haven't tried it though and I don't think this should be of much concern given all the information in the first section. (I could try making a PR though in case it does end up fixing the issue, and in case you think this could be an important fix nonetheless! Let me know if I should have a go at it or not~)

So with all that~

Solutions

There are 2 solutions, both of which happen on the user side. There is nothing that needs to be changed in the plugin as the issue is not related to the plugin after all! :D

I have both solutions setup for myself so that I don't need to worry about this in the future when it comes to neovim!

Modifying NeoVim

Inspired by this comment, I add the following to my vimrc. It will detect if the current shell is fish, and then sets it to /bin/sh (or /bin/bash would be fine too as suggested by the next solution).

if vim.fs.basename(vim.o.shell) == 'fish' then
    vim.opt.shell = '/bin/sh'
end

This solution will effectively render your neovim config resistant to any such issues if ran inside of fish.

Modifying Fish

Inspired by this issue's solution, I add the following alias into my fish config. I change the SHELL environment variable which neovim picks up and then sets its shell accordingly to /bin/bash (or /bin/sh would be fine too as suggested by the previous solution).

Note that I cannot say SHELL=/bin/bash nvim as the aliased definition because it would lead to a recursion; also the which variant makes it more robust in that you don't need to update the neovim path if it happens to be different.

alias nvim "SHELL=/bin/bash $(which nvim)"

This solution will effectively avoid your fish config from causing troubles to neovim.

martineausimon commented 1 year ago

Hi ! Glad you found the problem ! Can you tell me if this is valid with fish ?

echo expandcmd([[a 'b' c]])

If it works, it shouldn't be complicated to make the modification in the plugin...

niveK77pur commented 1 year ago

That particular command raises some errors:

E121: Undefined variable: a
E116: Invalid arguments for function expandcmd

However if I turn it into a lua print statement, it still raises the E79: Cannot expand wildcards error.

:lua print(vim.fn.expandcmd([[a 'b' c]])) -- E79 error
:lua print(vim.fn.expandcmd([[a "b" c]])) -- works

It seems as though double quotes work in this case as well; fish is probably causing vim's expansion here to hick up in the presence of single quotes (fish is not strictly posix compliant, so this might explain this "unexpected" behaviour).

EDIT: As mentioned in the :h E79, this particular error does not necessarily indicate anything worrisome. The player and compilation commands both still work despite the error, so I suppose it really is nothing more than an inconvenience here.

martineausimon commented 1 year ago

Thank you (of course I forgot it was vimscript sorry !). I just tried swapping the quotes, and it doesn't seem to cause any problems. I will update the plugin soon.

niveK77pur commented 1 year ago

Awesome thanks a lot for always improving this plugin, you're doing an amazing job here! :D