Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kpse file search #1440

Merged
merged 13 commits into from
Nov 9, 2019
Merged

Conversation

rpspringuel
Copy link
Contributor

When looking for files, GregorioTeX will now employ kpse.find_file if it does not find the file is not in the expected location. This allows for TEXINPUTS to specify paths to scores and addresses the bug part of #1395.

The one thing I'm not sure about is that I make no attempt to strip off directories before doing the kpse based search. Should I?

When looking for files, GregorioTeX will now employ kpse.find_file if it does not find the file is not in the expected location.  This allows for TEXINPUTS to specify paths to scores and addresses the bug part of gregorio-project#1395.
@rpspringuel
Copy link
Contributor Author

Note, I have not yet run a complete battery of tests.

There's no need to do the exact same thing on both branches of the if statement.  Instead we just need the one line after the if statement is completed.
gregorio has trouble writing gtex files to arbitrary locations when security is `openout_any = p` (a problem we've encountered before in relation to snippets).  This solves the problem, but only for files found with kpse, by relocating the gtex and glog files to the project directory, rather than the directory where the gabc file is located.
@rpspringuel
Copy link
Contributor Author

I've done some further testing and have things working a bit better. However, I'm running into #1393. I've included a patch here for that issue when kpse is used to find the file, but it would probably be better to figure out a more general solution.

@rpspringuel
Copy link
Contributor Author

Just discovered an interesting quirk: kpse.find_file appears capable of traversing directories with spaces in the name while the \input statement which actually reads in the gtex file is not. This results in an interesting bug where the code finds a gtex file which is ready for importing, but cannot actually read it in. Not sure if this is simply something that needs documenting or some sort of code fix.

@henryso
Copy link
Contributor

henryso commented Mar 31, 2019

Is there a way to read a file in a la \input which does work with spaces? If so, then I vote we use it; if not, it's a TeX quirk, and we document it.

@rpspringuel
Copy link
Contributor Author

The best that I can think of is to read in the file in lua using io.open and then tex.sprint line by line.

@henryso
Copy link
Contributor

henryso commented Apr 5, 2019

That seems a bit too much. My vote is we document it and if there are enough requests for this, then we consider alternatives.

@eroux
Copy link
Contributor

eroux commented Apr 5, 2019

I agree with @henryso , let's not "fix TeX"...

`kpse.find_file` can find files along paths which have a space in their name, but `\input` cannot load them.  This doesn't matter if the file found in this manner is a gabc file (as its gtex file will be put in the current working directory, which `\input` has no problem with) but if a gtex file is found like this, then TeX will complain about being unable to find the file when it tries to input it.  To help indicate the problem, we check for a space in the path and issue a warning if we see one.  We only warn because gabc files will still work.
This allows the user to use `\gresetgregpath` to set additional paths which will be searched for scores.  The order of search is: current working directory, the paths specified by this new command, and finally the kpse search path.
The default compilation mode has changed so the example code there needed to be changed to reflect that.
@rpspringuel
Copy link
Contributor Author

Okay, this now appears to be complete and behaving the way I want it to. Please check it carefully as I cannot currently check the kpse search in the test repository.

@henryso
Copy link
Contributor

henryso commented Jun 27, 2019

I don't think my review is good enough to fully accept this, but it looks OK to me.

@henryso
Copy link
Contributor

henryso commented Nov 9, 2019

This has been sitting here for a while with no comments to the contrary, so let's merge.

@henryso henryso merged commit 857972d into gregorio-project:ctan Nov 9, 2019
@rpspringuel rpspringuel deleted the kpsewhich_search branch November 12, 2019 00:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants