I would be interested in hearing from people that often refer to the Fortran Standard docs (or their drafts) on how they navigate the documents. I periodically have to search through the Fortran Standard to check how I should implement feature X in the fortls parser and for me it is always a rather painful process.
My workflow is using the PDF version of the draft and:
Opening 2 windows of the PDF with a PDF viewer (I use Okular)
Have one window opened at the Index page looking for definitions (also showing the TOC on the side)
Using the second window to manually go to the definitions and browse the Standard
That does not seem like a very efficient way to navigate the Fortran Standard, but I havenāt thought of anything better. Do others navigate/search through the Standard in a different way? I would be interested to hear about it. This thread could hopefully be of use to people that want to contribute to open source compilers like gfortran and lfortran but do not know where to get started in terms of the missing functionality they want to implement.
Unhappily Okular and evince do not allow regex search.
Maybe we could build a script using pdfgrep with its -n option, and okular with its -p option to open the right page:
$ pdfgrep "cosh\(" 18-007r1.pdf -n
375:10 5 Result Value. The result has a value equal to a processor-dependent approximation to cosh(X). If X is of type
$ okular -p 375 18-007r1.pdf
On a tangential note, let me know what it would take for fortls to use LFortran as the parser. As far as I know we should be able to parse any free-form to AST (ābetaā quality), and a lot of fixed-form (āalphaā quality), all of SciPy for example.
I am happy to add features, make it installable separately so that you could (if you want to) vendor the files into your Python package. It will be more efficient if we can collaborate on the same parser.
We had a few chats about this earlier this summer and I did a little viability study. I identified 2 bottlenecks at the time:
fortls is all Python making it very portable, adding LFortran as a dependency would make it harder to deploy via PyPi and pip/pipx
the fortls parser is designed to be error resilient. If fails to parse certain bits of code it will just skip them and continue parsing the rest of the file. I donāt remember LFortranās parser working like that I might be wrong through. I remember the solution that we came up was to save at least one valid state of the ASR from when the file was valid and revert to that.
We would also need 1 or 2 devs to then write the C++ ā ā Python glue.
I have just tried xpdf 3.04 (in Ubuntu 22.04) but CTRL+F does not seem to offer regex, but just a simple text search like Okular and evince. Have I missed something?
I generally just ctrl+f for the keyword of interest. Itās probably not the most efficient, and sometimes the chosen word provides too many results, but at that point itās kind of like figuring out how to use Google efficiently, pick the right related words. Using the hyperlinks, index and table of contents also work out pretty well most of the time.
The regex will detect strings like ā12.5 blablaā, "ā12.5.1 blablaā, ā12.5.1.2 blablaā, etc. See the README.md for more information, and tell me what you think.
I have added some improvements proposed by @msz59. And in the coming days, I will add some options to the fss command to modify the regex behavior.
I have also discovered that pdfgrep has an option --cache that speeds dramatically the search when the command is used several times. The first time it takes several seconds, and the next times the search is instantaneous .
I thought just using the -A (--after-context) option of pdfgrep could be a simple alternative. With for example -A 30 we could print the 30 lines following the matching line so that we donāt need to open the PDF. But if the result is at the bottom of a page, pdfgrep stops printing at the end of the page. In that example, we therefore miss the interesting information:
$ pdfgrep -A 30 -iP "\d+\s+abs " 18-007r1.pdf
15 16.9.2 ABS (A)
16 1 Description. Absolute value.
17 2 Class. Elemental function.
18 3 Argument. A shall be of type integer, real, or complex.
J3/18-007r1 339
$
Updated the 2022-10-30:
I have tested a simple solution in Kubuntu (KDE):
create a launcher on your desktop that executes the command okular -p 616 18-007r1.pdf (look in the properties of the icon),
When you click on that icon, the Fortran standard is now opened at the beginning of the final index (page 616),
so when you type CTRL+F, the search begins in the index instead of the top of the document,
and if you find what you want in the index, you have just to click on the page number to go to the section. And if it is not in the index, the search continues at the beginning of the document.
Of course the standard PDF is not totally representable as flat text, and the cross-links (somewhat reminscent of GOTOs :>) in the PDF are great for finding definitions of terms; but I find the search capabilitites of vim with text files so useful, I often do something like
pdfgrep . $FILENAME.pdf > $FILENAME.txt
and look through the text version with vim(1) as a supplement for trying to navigate the PDF. I find I
can find what I want much more easily in the text version; or find where I want to look in the PDF far more easily than using just the PDF.
As far as I know we should be able to parse any free-form to AST (ābetaā quality), and a lot of fixed-form (āalphaā quality), all of SciPy for example.
.