Naturally, one does not want to block the main UI thread and obstruct the user workflow while doing some lenghty operations. Lengthy operations are
are quite ubiquitous in development environments and as a matter of fact a lot of processing has to be done in background with or without user awareness
in order to bring the best experience. As Vim did not really have native support for asynchronous processing (only recently some async support has been added?),
a custom solution had to been brought in.
Therefore, to ease the development and integration of any kind of lengthy operations this framework has been developed. In the context of this framework
lenghty operations are encapsulated in units called services. Each service:
- Has its own unique ID
- Is dispatched to its own background process
- Can be started and shut down on request
- Can be triggered at any moment during its runtime
- Can notify the main thread about its events and queue the actions to be executed on the UI side
To make the communication between the UI and background services seamless, YavideServer on the server side and Y_Server...() API
on the client side is taking care of that. YavideServer is a thin proxy layer which controls and handles all the services.
Important aspect of this framework is that it provides a generic service development platform and enables service developer to fully focus on the
implementation details of particular service. See existing services to see an example how implementation may look like.
Compared to the limited Vim syntax highlighting mechanism, this service brings more complete syntax highlighting including support for the following symbols:
- Namespaces
- Namespace aliases
- Classes
- Structures
- Enums
- Enum values
- Unions
- Local variables
- Class/struct/union data members
- Class/struct/union function members
- Functions
- Function parameters
- Template type parameters
- Template non type parameters
- Template template parameters
- Macro definitions
- Macro instantiations
- Typedefs
- Using directives
- Using declarations
| Before | After |
|---|---|
 |
 |
Initially, syntax highlighting service was using ctags as a back-end for tokenizing the source code. However, ctags, being based on
heuristics and not being a full-featured C++ parser, was falling short in some cases and especially with modern C++ codebases.
Now, ctags back-end has been replaced with clang-based one and that gives us much more complete and correct results. Not only that
new back-end is going to be used for syntax highlighting only, but it can/will be reused for many other purposes. I.e. implementing other services
such as class browsers, indexers, refactoring, fix-its, comments, etc.
In order to see the full effect of syntax highlighting one will need to have a colorscheme which supports additional highlight groups. Standard Vim
colorschemes, if not modified, do not contain these. See this file for a list of new
highlight groups which you will need to add to your colorscheme of choice should you want to make a full use of syntax highlighting service.
There is an example colorscheme that I have made and which Yavide uses by default. One may have a look there to see how things might look like.
Disclaimer: I am really not good at colors so feel free contribute back.
As we are now using a full C++ back-end, in order to get the best results, we need to feed it in with compiler flags which are actually used to compile that specific project.
As of now, user is able to provide those flags (as a whitespace separated list) through g:project_compiler_args variable which can be found at .yavide_proj
(a file at project root directory; generated by Yavide upon creation of a new project).
Future plan is to automate this step further requiring no user intervention (i.e. support for CMake/Makefile projects).
Example how configuration might look like is:
let g:project_compiler_args = '-Ilib -Iinclude -DFEATURE_XX -DEFATURE_YY -Wall -Werror'
If you don't see what you expected, then there are certainly some errors (semantic, parsing, ...) for which you can get a hint if you have look at the QuickFix buffer.
You need to have Diagnostic service enabled.
For bigger files, scrolling will become really really slow if cursorline variable is set (in my env set by default). This is a very old and very annoying Vim issue which is even mentioned in vim-help.
See :help 'cursorline' for more details.
For bigger files one might set nocursorline (it can be even scripted) or turn it off permanently by putting it in .editor.vimrc file.
However, not always this will be enough. See next section.
Vim crawls down because there are thousands of syntax rules being applied to the buffer, and I suspect that by each scroll event these are being reapplied. On a N-thousand lines of code big file applying such a large number of syntax rules will cause rendering issues. To circumvent this issue, either Vim needs to be patched or we have to solve this issue by our own within the framework by introducing a new syntax applying strategy.
A new strategy wouldn't apply all the syntax rules which have been generated for the given file but it would apply syntax rules only for the visible parts (±N lines) of a buffer. This will hopefully fix the issue but for this to be a complete working solution we have to be able to catch all the buffer scrolling events. This is unfortunatelly not exposed by Vim in a seamless way so we will have to apply some workarounds which will make this happen (very soon I hope).
Clang is known for its expressive diagnostics and fix-it hints that it can provide as a feedback without going to the compilation stage.
This feature is now made available and integrated into the Vim QuickFix buffer which will be continuously displaying such information for current buffer.
If you find it too intrusive or redundant you can always turn it off. See How to enable/disable service.
TBD
ctags + cscope combination is used. Shall be replaced with clang-based approach.
TBD
Create .clang-format config file in the project root directory. Auto-formatting is being triggered upon each SaveFile action.
In future this will be a matter of configuration. Currently it is hard-coded in this way.
TBD
Set g:project_env_build_command to the build command specific to the project. I.e. after loading/importing the project do the following:
let g:project_env_build_command='make all'
Once this variable has been successfully set, one is able to use YavideBuildRun command or F7 to trigger the build.
Upon completion quickfix window will be populated with build output where in case of any warnings/errors one is able
to jump to the given warning/error double-clicking/pressing-enter-key on the particular entry from the list. Once the project has
been saved build command will be persisted in project settings and therefore re-loaded on the next project start-up.
Current progress of the build cannot be tracked directly from Yavide but one can use tail -f /tmp/yavide<random_string>build from the terminal.
Possibility to stream the build directly on-the-fly to the Yavide environment (i.e. quickfix window) needs to be evaluated and will be considered.
Set enabled property to 0 or 1 corresponding to the service which you want to enable/disable. Property can be found as
part of the g:project_service_<service_name> variable which is defined in <yavide_install_dir>/core/.globals.vimrc.