Tsuquyomi pays no attention to any mistakes when opening

Question

Tsuquyomi pays no attention to any mistakes when opening

I have integrated Tsuquyomi as a Syntastic plugin for TypeScript error checking in Vim. However, I am facing an issue where only ESLint errors are displayed when I open a file, and Tsuquyomi errors are only visible when I save the file or manually run the checker.

In my configuration in the .vimrc, I have set up Syntastic to check with Tsuquyomi on file open:

" Configure syntax management
let g:syntastic_error_symbol = "✗"
let g:syntastic_warning_symbol = "⚠"
let g:syntastic_javascript_checkers = ['eslint', 'standard']
let g:syntastic_cs_checkers = ['syntax', 'semantic', 'issues']
...

Despite this setup, when I create a file with errors, Tsuquyomi does not display these errors when the file is opened. However, manually running :SyntasticCheck shows the errors correctly.

The issue seems to be related to Tsuquyomi not detecting errors on file open, causing a delay in error notification. How can I ensure that Tsuquyomi displays TypeScript errors promptly when the file is opened?

typescript vim vim-plugin syntastic vim-syntastic

Answer 1

Answer №1

You have the following line in your code:

let g:tsuquyomi_disable_quickfix = 1

This setting prevents the syntax/semantic check from running.

Despite this setting, it appears that saving and manual triggering still work, but the immediate check is disabled, as you have noticed.

References:

https://github.com/Quramy/tsuquyomi/issues/183

Edit:

If that doesn't work, consider following the documentation:

Integrating with syntastic

If you are using syntastic, you can use it to display syntax and semantics errors instead of Vim's default quickfix window. To integrate syntastic, add the following settings to your .vimrc file.

let g:tsuquyomi_disable_quickfix = 1
let g:syntastic_typescript_checkers = ['tsuquyomi'] " You shouldn't use the 'tsc' checker.

syntastic has a default TypeScript checker named 'tsc'. Avoid using it with Tusuquyomi as they do not share compile options. Tusuquyomi's checker, 'tsuquyomi', uses tsserver and your tsconfig.json.

You have this line in your code:

let g:syntastic_typescript_checkers = ['eslint', 'tsuquyomi']

Try removing 'eslint' to see if it helps. If you want to use both, we may need to find another way to configure them.

References:

https://github.com/Quramy/tsuquyomi

Edit2:

[..], each checker will be called, in order, as long as the previous checkers don’t return an error. Consider listing checkers from fastest to slowest, or from looser to stricter.

Do the eslint errors actually prevent tsuquyomi from displaying its own errors? It might be worth changing their order to see if that helps.

References:

Answer 2

You have the following line in your code:

let g:tsuquyomi_disable_quickfix = 1

This setting prevents the syntax/semantic check from running.

Despite this setting, it appears that saving and manual triggering still work, but the immediate check is disabled, as you have noticed.

References:

https://github.com/Quramy/tsuquyomi/issues/183

Edit:

If that doesn't work, consider following the documentation:

Integrating with syntastic

If you are using syntastic, you can use it to display syntax and semantics errors instead of Vim's default quickfix window. To integrate syntastic, add the following settings to your .vimrc file.

let g:tsuquyomi_disable_quickfix = 1
let g:syntastic_typescript_checkers = ['tsuquyomi'] " You shouldn't use the 'tsc' checker.

syntastic has a default TypeScript checker named 'tsc'. Avoid using it with Tusuquyomi as they do not share compile options. Tusuquyomi's checker, 'tsuquyomi', uses tsserver and your tsconfig.json.

You have this line in your code:

let g:syntastic_typescript_checkers = ['eslint', 'tsuquyomi']

Try removing 'eslint' to see if it helps. If you want to use both, we may need to find another way to configure them.

References:

https://github.com/Quramy/tsuquyomi

Edit2:

[..], each checker will be called, in order, as long as the previous checkers don’t return an error. Consider listing checkers from fastest to slowest, or from looser to stricter.

Do the eslint errors actually prevent tsuquyomi from displaying its own errors? It might be worth changing their order to see if that helps.

References:

Tsuquyomi pays no attention to any mistakes when opening

Answer №1

Similar questions

The use of findDOMNode has been marked as outdated in StrictMode. Specifically, findDOMNode was utilized with an instance of Transition (generated by MUI Backdrop) that is contained

How can certain properties be mandated while still permitting additional ones?

Having trouble with TypeScript error in React with Material-UI when trying to set up tabs?

Convert image file to a React TypeScript module for export

Struggling with Primeng's KeyFilter functionality?

Loading and unloading an Angular 6 component

Using Visual Studio Code, the next app created with nx now supports relative imports

Angular is throwing an error stating that the type '{ }[]' cannot be assigned to the type '[{ }]'

Tips for dynamically implementing a pipe in Angular 5

Step-by-step guide on setting up cosmosDB databases and containers in azure functions with the node sdk

What is the proper way to specify the type for the `clean-element` higher-order-component in React?

Ensuring that a service is completely initialized before Angular injects it into the system

Error in AWS Lambda: Module 'index' not found

Issues have been encountered with Angular 5 when trying to make required form fields work properly

Challenges encountered when sending an HTTP post request in Ionic 2 with Angular 2

Refreshing Components upon updates to session storage - Angular

Sorting arrays in Typescript

Unable to locate the module name loaded using require() function

What is the correct way to handle Vue props that include a dash in their name?

When using a typescript subscription to collect data from an API, the information is stored in an array. However, only one piece of data can be