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

Solution to generalize &spelllang use for textidote #1811

Closed
oblitum opened this issue Oct 1, 2020 · 14 comments
Closed

Solution to generalize &spelllang use for textidote #1811

oblitum opened this issue Oct 1, 2020 · 14 comments

Comments

@oblitum
Copy link

oblitum commented Oct 1, 2020

Description
As requested at #1805 (comment): It would be nice with a solution that handles multiple languages specified by &spelllang.

Describe the solution you'd like
An additional setting or as suggested at #1805 (comment).

@lervag
Copy link
Owner

lervag commented Oct 17, 2020

To summarize the current issue: Currently, the grammar compilers like textidote.vim and vlty.vim use the value of &spelllang to specify the spelling language. @oblitum commented in #1805 that this does not handle multiple language selections.

I'm thinking of something like this:

  • First, we should try to parse the preamble to determine the language from there. E.g. from \usepackage[...]{babel}. If this method does identify a language, then it should be used for the compilers.

  • As a fallback, we should rely on &spelllang. I think multiple languages should be handled by asking the user to choose one. This should be pretty straightforward to implement.

I'd appreciate thoughts from @Konfekt and @matze-dd who has contributed code for these things. And for course from anyone else with opinions.

Note: I don't really think a global configuration makes a lot of sense. At least, this should only be used as a mechanism for specifying a "global default" that might be prioritized before &spelllang.

@Konfekt
Copy link
Contributor

Konfekt commented Oct 19, 2020

Note: I don't really think a global configuration makes a lot of sense. At least, this should only be used as a mechanism for specifying a "global default" that might be prioritized before &spelllang.

Agreed.

First, we should try to parse the preamble to determine the language from there. E.g. from \usepackage[...]{babel}. If this method does identify a language, then it should be used for the compilers.

This is perhaps nice to have, but does now the value of babel or spelllang take priority? In the meanwhile, there are already modelines to set &spelllang in the file.

As a fallback, we should rely on &spelllang. I think multiple languages should be handled by asking the user to choose one. This should be pretty straightforward to implement.

Yes, or simply choose that given first. Again, a modeline could set this choice once and for all.

@matze-dd
Copy link
Contributor

matze-dd commented Oct 19, 2020

I'm thinking of something like this:

  • First, we should try to parse the preamble to determine the language from there. E.g. from \usepackage[...]{babel}. If this method does identify a language, then it should be used for the compilers.
  • As a fallback, we should rely on &spelllang. I think multiple languages should be handled by asking the user to choose one. This should be pretty straightforward to implement.

This sounds reasonable to me. Package babel accepts multiple languages in [...], too. One can switch languages with \foreignlanguage and \selectlanguage in the text. So, the user choice might be necessary also in this case.

To be sure, I just checked whether LanguageTool-5.0 accepts multiple languages like -l en-GB,de-DE. It really doesn't. A Web search for languagetool multiple languages doesn't show useful things, either.

EDIT: LT has an option -adl for auto-detection, but this probably is not very useful, here.

@lervag
Copy link
Owner

lervag commented Oct 20, 2020

First, we should try to parse the preamble to determine the language from there. E.g. from \usepackage[...]{babel}. If this method does identify a language, then it should be used for the compilers.

This is perhaps nice to have, but does now the value of babel or spelllang take priority? In the meanwhile, there are already modelines to set &spelllang in the file.

I agree this is not clear cut, and we need to make some decisions.

As a fallback, we should rely on &spelllang. I think multiple languages should be handled by asking the user to choose one. This should be pretty straightforward to implement.

Yes, or simply choose that given first. Again, a modeline could set this choice once and for all.

Good point about the modeline.

This sounds reasonable to me. Package babel accepts multiple languages in [...], too. One can switch languages with \foreignlanguage and \selectlanguage in the text. So, the user choice might be necessary also in this case.

I think it should be relatively easy to make a choice under amgiuity. There is already an API for this. But the use of \selectlanguage is more difficult. I'm tempted to say this should be "ignored".


So, the question is 1) how to do this in practise e.g. wrt. the comments above, and ii) who will do the work. I will probably get to it if noone else does it, but it is not at the top of my list for now. Thus it may take some time before I do it.

Reg. number 1, I'm thinking something like this:

  • Add a new step during vimtex init to parse the document for language selection. This should give something like b:vimtex.language = ['english', 'german', ...].

  • b:vimtex.language could then be used by vlty and other compilers. Ambiguity can be solved with e.g. vimtex#ui#choose(...).

  • In the case where b:vimtex.language is empty (i.e., no language was detected), we fall back to &spelllang (whoose possible amgiuity may again be solved with the chooser as above).

I think a dedicated option is not necessary. If it is not detected with b:vimtex.language, then one can use a &spelllang for instance with a modeline, as proposed by @Konfekt.

@matze-dd
Copy link
Contributor

... But the use of \selectlanguage is more difficult. I'm tempted to say this should be "ignored".

This is probably best. In multi-language documents, people will perhaps switch forth and back in the text.

@lervag
Copy link
Owner

lervag commented Dec 7, 2020

Ok, I have a new proposal:

  • During startup, I'll let Vimtex parse any \usepackage[...]{babel} lines and use it to fill b:vimtex.packages.babel.language. One question for this task: Does babel allow other options than a specific language? How can I (programatically) know if an option is a language choice or an option for babel?

  • When this is done, language compilers can use the parsed value to set the language, if wanted. It should be easy to implement, including the user choice as mentioned before.

What do you think?

@Konfekt
Copy link
Contributor

Konfekt commented Dec 7, 2020

Yes, babel has other options such as math=normal. The language is usually set in the \documentclass[...] options.

@Konfekt
Copy link
Contributor

Konfekt commented Dec 7, 2020

I think that for all practical means modelines are more feasible.

@lervag
Copy link
Owner

lervag commented Dec 7, 2020

I think you may be right on this, @Konfekt. I can see a lot of headaches trying to implement this type of parsing.

So, let's still rely on the spelllang option, but it could possibly be better documented? The option is mentioned in :help vimtex-grammar, but perhaps the suggestion about modelines should be added?

@matze-dd
Copy link
Contributor

matze-dd commented Dec 7, 2020

So, let's still rely on the spelllang option, but it could possibly be better documented? The option is mentioned in :help vimtex-grammar, but perhaps the suggestion about modelines should be added?

This sounds reasonable.

@Konfekt
Copy link
Contributor

Konfekt commented Dec 7, 2020

One could suggest a command :SetSpelllang to append a modeline:

function! Modeline(variable, value)
  let cmd = 'set ' . a:variable . (empty(a:value) ? '' : '=' . a:value)
  execute cmd
  let modeline = substitute(&commentstring, '%s',' vim: ' . cmd . ': ', '')
  call append(line('$'), modeline)
endfunction
command! -nargs=1 SetSpellLang  call Modeline('spelllang', <q-args>)

For example, :SetSpelllang no will append a line

%  vim: set spelllang=no:

lervag added a commit that referenced this issue Dec 7, 2020
@lervag
Copy link
Owner

lervag commented Dec 7, 2020

I've updated the docs and added a chooser UI if there are multiple values in &spelllang now. With that I think we can close this issue.

@lervag lervag closed this as completed Dec 7, 2020
lervag added a commit that referenced this issue Dec 7, 2020

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
refer: #1811
@PatrBal
Copy link
Contributor

PatrBal commented Jan 8, 2022

Hi all,
I have given :compiler textidote | lmake a try. But I felt that it was rather uneasy to decypher the output of TeXtidote in the location-list. Also, I was missing the error highlighting that :set spell provides. Eventually, I thought that it should not be such a big deal to rewrite the plugin vim-LanguageTool, so that it would be based on TeXtidote instead of LanguageTool. I have just obtained a first version of this new plugin vim-textidote and I find it more pleasant to use than :compiler textidote | lmake. If, by any chance, you are interested in trying it, I would be delighted to get issues, comments and suggestions.

PS. Thank you very much for all the work on Vimtex. I find it wonderful to use.

@lervag
Copy link
Owner

lervag commented Jan 8, 2022

Thanks for the kind words! And congrats on building something that looks useful! I welcome it and will probably try it out when I get the time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants