Latex ac

[mgmillani]

Fixes issue #1000 . Geany now correctly autocompletes LaTeX macros.
The difference in behaviour can be illustrated with the following document:

\newcommand{\macroname}{}
% The following occurrences of \macro are now autocompleted to \macroname
\macro 
\alpha\macro
% The following is no longer autocompleted to macroname
macro
% Example with @
\newcommand{\@anothermacro}{}
% Gets autocompleted
\@another

The tests were updated to accept this behaviour (since macro tags now start with \).
This also identifies macros defined with \let, \newlength and environments defined with \renewenvironment.

Finally, @ can be used sometimes in a macro name and mostly any character can be used in a label. I added :@ to wordchars so that they can be used in autocomplete.

[elextr]

Have you submitted the changes to ctags/latex.c to the upstream ctags project? What was the response?

In general it is better not to hardcode language specific features in Geany (I'm talking about the editor.c changes). Instead a more generic functionality controlled by settings in the filetype file should be used so that other languages that are not C can also benefit.

[mgmillani]

I was not aware of the ctags project. But their tex file does not seem to have anything for macros, and is considerably different from the ctags/latex.c file here. So I don't see how I could submit theses changes there, and I also don't see how it would help Geany.

One way of making this functionality more generic would be to use the lexer to filter which symbols can be used for autocompletion. So if the lexer can tell whether the current word is a macro or not, and if the known symbols are properly typed, the LaTeX specific code could go away. But I don't know if this could break autocompletion for other languages.

[elextr]

...ctags project. But their tex file does not seem to have anything for macros, and is considerably different from the ctags/latex.c file here.

Sigh, looks like in the past "somebody" made significant changes without getting them upstream which will make sharing improvements hard in future. That was why I asked had you tried first. Ok, guess it will have to be local only.

One way of making this functionality more generic would be to use the lexer to filter which symbols can be used for autocompletion. So if the lexer can tell whether the current word is a macro or not, and if the known symbols are properly typed, the LaTeX specific code could go away. But I don't know if this could break autocompletion for other languages.

Just a note on Geany terminology, lexers are the things inside Scintilla that do purely syntax identification for highlighting, the ctags things are parsers since they understand semantics (at least of declarations). Being purely semantics the lexers don't know what a syntactic element (like a name) represents. But they can compare syntactic elements that are names with a list of known names and identify them differently if they are in the list. This list is usually provided by the parsers from the declarations. But be warned, occurrence of a name will allways be identified that way irrespective of its context, so depending on how latex treats names YMMV (works fairly ok in C, but often quite badly in C++).

What sorts of names does latex have? What sorts are identified by the parser? The autocomplete operation is currently really elementary, and only (sort of) works for C/C++ and look alike languages that use . or -> (which is why you will see an occasional "not all languages are C" rant in Geany discussions :).

So a more general mechanism for having autocomplete handle context when offering names would be good.

Or possibly you could look at re-mapping the symbol kinds used in latex so they can be filtered by the C like mechanism already available an so only need a setting for the separator (instead of . and ->).

[mgmillani]

LaTeX has plain text (natural language), macros (always preceded by a \), environments (like macros, but without the \ in the beginning. They only appear as arguments for macros, like in \begin{env}.) and labels (which are not preceded by \ and can contain mostly anything, like spaces. They are also only used as arguments, like in \ref{label name}). The parser identifies each one of these (except plain text) as different kinds. Additionally, it has chapter, section, subsection and subsubsection, but I guess these are only for navigation, so that the user can quickly jump to different parts of the document.

The lexer is capable of identifying a \begin and its argument (that is, its argument is highlighted differently from arguments of other macros), so differentiating between labels and environments should be possible. It also treats macros differently from plain text.
Currently, geany is capable of omitting autocomplete inside strings and comments. So if plain text is treated as a string by this function, autocomplete would be disabled for it. Then it would be possible to remove \ from wordchars in editor.c as well as the LaTeX-specific portion to separate macros.

[elextr]

The parser identifies each one of these (except plain text) as different kinds. Additionally, it has chapter, section, subsection and subsubsection, but I guess these are only for navigation, so that the user can quickly jump to different parts of the document.

Yeah, I guess the programming language model of symbol types is being somewhat stretched here, but hey programming languages don't have free text in them either :)

Currently, geany is capable of omitting autocomplete inside strings and comments. So if plain text is treated as a string by this function, autocomplete would be disabled for it. Then it would be possible to remove \ from wordchars in editor.c as well as the LaTeX-specific portion to separate macros.

Sounds like a plan.

highlighting_is_string_style() does not currently have a latex section, so nothing should be relying on its behaviour, and so changing it should not break stuff.

[mgmillani]

Now plain text is treated as string, so there is no longer any need for LaTeX-specific treatment in editor.c (other than defining wordchar). I had to slightly change the lexer so that @ would be recognized as part of a command. I submitted the changes to the scintilla repository, but haven't received any answer yet.

The main problem now is that there is no autocomplete for labels, since they are treated as plain text by the lexer. Without changing scintilla, I'm afraid it would be complicated to fix this. However, it is common practice in LaTeX to name labels like fig:my_plot, so the user can type fig: and then force autocomplete, which will correctly show the adequate suggestions.

[mgmillani]

I don't plan on changing anything else. I have been testing my changes for the past month and it is working quite well. I never received an answer for the changes on scintilla.

Is there any chance of this getting merged?

[elextr]

Can you provide a link to the Scintilla report?

[mgmillani]

The merge request is here.

[elextr]

Ok, looking at the date it was submitted I think you probably missed getting it before the Scintilla maintainer went away for some months (and still is away). As for the rest, just needs someone who is confident it works to have time to test and commit it.

Latex users are welcome to try the PR and comment.

[elextr]

No point in making changes to LexLatex.cxx in Geany, its updated by script and will be overwritten by the next update. Needs to be made upstream.

Also updates to ctags should be made upstream to universal ctags, although they are not updated so often.

[mgmillani]

I never got a reply to my merge request to the Scintilla project.

I'll try to make a request to universal ctags, let's see if I have more luck there.

[elextr]

You might try pinging your PR to Scintilla in a few weeks when the maintainer is back from holidays.

[masatake]

I extended Tex parser of u-ctags agressively.
universal-ctags/ctags#2424

Commands in \newcommand are captured.

universal-ctags/ctags@3e2c7ce

If you think u-ctags captures more things, please, consider to open an issue at u-ctags repo.
I wrote a very small interpreter to capture language objects appeared in latex macros.
So I hope u-ctags Tex parser can support your request quickly.