Errors aren't highlighted

[gigiigig]

Hi, sorry for my others empty issues opened, i had a connection problem. I've configured vimside and ensime well, it works with sublime text, but in vim ensime start correctly, but errors aren't highlighted , same problem in ubuntu 12.04 ,12.10 and Mac OS x.

[megaannum]

I do not understand what you are asking. What errors?

Vimside uses Vim and Ensime. Ensime was originally created to work with Emacs where communication is via a documented protocol. Vimside uses that same protocol to communicate with the Ensime server. The Vim code that generates the communications with the Ensime server and handles the data and messages returned by it, it is hope, has similar capabilities to what the Emacs code has, but, of course, it is totally different code. Vim and Vimside has nothing to do with sublime text.

If your Scala code has errors and you run a type check on it you ought to get a quickfix window.

On 02/25/2013 01:24 AM, Luigi Antonini wrote:

Hi, sorry for my others empty issues opened, i had a connection problem. I've configured vimside and ensime well, it works with sublime text, but in vim ensime start correctly, but errors aren't highlighted , same problem in ubuntu 12.04 ,12.10 and Mac OS x.

— Reply to this email directly or view it on GitHub https://github.com/megaannum/vimside/issues/14.

Quis custodiet ipsos custodes

[gigiigig]

Ok figured out how to see errors , but isn't possible to see errors marked directly on error lines? For example eclim show typecheck's errors marking error lines in the left with a red symbol, and, pointing the cursor on the line, it describe the error. Something like that would be really useful.

[fayimora]

@megaannum I think @gigiigig is suggesting a feature. Something similar to what syntastic does. In-line errors rather than just a list in the quick-fix window. So maybe a red arrow before the line number.

Or maybe something as brilliant as underlining the exact snippet of code(see image below)

• image from Google Images

FYI, I'm just clarifying so @gigiigig feel free to correct me if this off track :smile:

[rompetroll]

There already are plugins out there for highlighting quickfix errors in the buffer

https://github.com/MarcWeber/vim-addon-signs https://github.com/tomtom/quickfixsigns_vim https://github.com/jceb/vim-hier

I haven't tried them with vimside, but it should work.

MarcWeber's plugin highlights errors (or in this case :grep locations) like this

[gigiigig]

@megaannum i mean exactly what @fayimora said, and it would be very nice have exact errors underlining ,
however @rompetroll suggested plugins are a good solution , maybe they can be referred on documentation

[megaannum]

Currently I am working on the Type Inspector and hope to have something ready to check-in this weekend. Then, I still have the Package Inspector, Running the Application and the Debugger capabilities to code. At that point, at least in terms of features, I will have duplicated what the Emacs-Ensime client has. Vimside will then transition from being in Alpha to being in Beta... So, it will be a while before I look again at how Vimside handles compiler errors.

That said, I designed Vimside so that it was easily (I hope) extensible by others.

There is an Option "swank-event-trigger-scala-notes" whose value is the function that handles Scala compilation event notifications from the Ensime server. The default value of this option is: "vimside#swank#event#scala_notes#Handle". If you go into the source, in the directory autoload/vimside/swank/event and look at the code in scala_notes.vim you will see the above function definition.

If you wish to experiment with creating another implementation, the simple part is to set the value of the Option to the name of your function in your options_user.vim file which will override the Options default value. Writing your own implementation will take some work. I would recommend placing it in a file called, let say, test_scala_notes.vim and place the file in your Vim autoload directory. Then name your implementation of the event handler function test_scala_notes#Handler (which is then the name of the function to set the Option value with and, in addition, Vim's autoload will magically find it). Use the Logger to log entry to the file, start Vimside, do a typecheck and see if your log output appears in the vimside log file (logging has to be enabled). If you see it then you are on your way, you can experiment with creating error handling/correcting code. If you are generous, you can donate to Vimside and it will become another implementation.

Some Vimside capabilities have multiple implementations already that can be selected via an Option value.

Also, when Vimside enters Beta I plan to have a mailing list. Good Luck.

On 02/26/2013 08:01 AM, Luigi Antonini wrote:

@megaannum https://github.com/megaannum i mean exactly what @fayimora https://github.com/fayimora said, and it would be very nice have exact errors underlining ,

however @rompetroll https://github.com/rompetroll suggested plugins are a good solution , maybe they can be referred on documentation

— Reply to this email directly or view it on GitHub https://github.com/megaannum/vimside/issues/14#issuecomment-14122392.

Quis custodiet ipsos custodes

[megaannum]

Question: What is the "semantics" of highlighting the line locations of errors in the source files? When you edit the source file, does the highlighting disappear? If you insert lines, does the highlighting stay on the "correct" lines of do the lines move and the highlighting mark the wrong lines? Can the source file highlights be toggled on/off? The highlighting appears to be done with Vim signs. Are there different highlights for "error" vs "warning" vs "info"?

Thanks. Feedback would be appreciated.

Richard

[rompetroll]

Just some random thoughts on this:

Looking at this particular plugin https://github.com/jceb/vim-hier/blob/master/plugin/hier.vim, there seems to be a QuickFixCmdPost event which is used for updating the highlights. So I guess this means that whenever you feed the quickfix list with updates, external highlighting plugins should be able to pick that up?

So feeding quickfix with a swank-event-trigger-scala-notes handler could be an idea, although i suspect these events occur too often.

As for how things should work, I think https://github.com/scrooloose/syntastic does it quite OK. That is a syntax parsing plugin for a number of languages. The way error feedback works there is that you have to save the source-file in order to get a redraw with updated highlights. As long as you don't save, the highlights stay where they are. Also if you move lines around etc, the highlights don't follow. So it's pretty basic in that regard. But that is perfectly fine I think, especially because the redraw on larger files is quite laggy.

So also for vimside, it would be good to have the redraw on request and not based on events, I assume.

I also some times turn off highlighting (:SyntasticToggleMode in syntasic) if there are too many errors. Important to have that possibility.

https://github.com/mhinz/vim-signify, which gives feedback about which lines have been changed since the last git-commit also requires a :w for updating the signs.

So, redraw highlights on save seems to be a common way to do this. I hope that was kind of what you were asking about :-)

[gigiigig]

That's just how i imagine highlighting could be :

lines containing errors are highlighted or underlined, when the cursor go upon a error line, the relative message is shown errors are highlighted when file is saved, it seems all ensime integrations do that way when you are editing, highlighted lines remain the wrong lines disable highlighting could be a good option

Of course, any way to do that is good, maybe just document how to integrate another plugin will be good.

2013/6/26 Sven Eigenbrodt notifications@github.com

Just some random thoughts on this:

Looking at this particular plugin https://github.com/jceb/vim-hier/blob/master/plugin/hier.vim, there seems to be a QuickFixCmdPost event which is used for updating the highlights. So I guess this means that whenever you feed the quickfix list with updates, external highlighting plugins should be able to pick that up?

So feeding quickfix with a swank-event-trigger-scala-notes handler could be an idea, although i suspect these events occur too often.

As for how things should work, I think https://github.com/scrooloose/syntastic does it quite OK. That is a syntax parsing plugin for a number of languages. The way error feedback works there is that you have to save the source-file in order to get a redraw with updated highlights. As long as you don't save, the highlights stay where they are. Also if you move lines around etc, the highlights don't follow. So it's pretty basic in that regard. But that is perfectly fine I think, especially because the redraw on larger files is quite laggy.

So also for vimside, it would be good to have the redraw on request and not based on events, I assume.

I also some times turn off highlighting (:SyntasticToggleMode in syntasic) if there are too many errors. Important to have that possibility.

https://github.com/mhinz/vim-signify, which gives feedback about which lines have been changed since the last git-commit also requires a :w for updating the signs.

So, redraw highlights on save seems to be a common way to do this. I hope that was kind of what you were asking about :-)

— Reply to this email directly or view it on GitHubhttps://github.com/megaannum/vimside/issues/14#issuecomment-20050502 .

[megaannum]

With the latest checkins I've implemented, as an alternative to the standard Vim quickfix window, the Actwin (Action Window) which is currently the default window for both the uses-of-symbol-at-point and show-errors-and-warning (Ensime compile or SBT compile) commands. (The default values for both tailor-uses-of-symbol-at-point-window tailor-show-errors-and-warning-window is 'actwin' which can be changed (back) to 'quickfix' in an Option file.)

The ActWin is highly tailorable both at a global Vimside level by redefining the Option of the form: tailor-actwin-... and specifically for uses-of-symbol-at-point and/or show-errors-and-warning by defining the Option of the form: tailor-uses-of-symbol-at-point-.... tailor-show-errors-and-warning-.... Here the 'tailor-actwin-...' Options are the parent Options for the child Options 'tailor-uses-of-symbol-at-point-....' and 'tailor-show-errors-and-warning-....' (meaning that if the child Option value is not set, then the parent Option value is used).

For the ActWin, there are 2 types of window: the one or more Scala source code windows (referred to as 'scala') and the singleton ActWin ('actwin'). As well has having no special information/line display, there are three different ways to highlight per-line information in both the scala and actwin windows (the fact that both have 3 ways is a coincidence). The Vim techologies used are ColorColumn, sign, line-pattern based highlighting. and CursorLine (which I think are all of the ways of highlighting Vim text). Multiple ones can be enabled and configured at a time (but sometimes one will simply override another (e.g., CursorLine overrides pattern-based line highlight) so you have to experiment as to which combination you want.

For the scala windows there are the highlight enabling Options:

tailor-actwin-display-scala-color-column-enable tailor-actwin-display-scala-color-line-enable tailor-actwin-display-scala-sign-enable tailor-show-errors-and-warning-actwin-display-scala-color-column-enable tailor-show-errors-and-warning-actwin-display-scala-color-line-enable tailor-show-errors-and-warning-actwin-display-scala-sign-enable tailor-uses-of-symbol-at-point-actwin-display-scala-color-column-enable tailor-uses-of-symbol-at-point-actwin-display-scala-color-line-enable tailor-uses-of-symbol-at-point-actwin-display-scala-sign-enable

where color-column-enable uses ColorColumn to highlight the current line's column number if available color-line-enable uses Vims line-pattern based highlighting current line. sign-enable uses Vims sign capability to highlight all lines.

The actwin highlight enabling the Options are:

tailor-actwin-display-actwin-cursor-line-enable tailor-actwin-display-actwin-highlight-line-enable tailor-actwin-display-actwin-sign-enable tailor-show-errors-and-warning-actwin-display-actwin-cursor-line-enable tailor-show-errors-and-warning-actwin-display-actwin-highlight-line-enable tailor-show-errors-and-warning-actwin-display-actwin-sign-enable tailor-uses-of-symbol-at-point-actwin-display-actwin-cursor-line-enable tailor-uses-of-symbol-at-point-actwin-display-actwin-highlight-line-enable tailor-uses-of-symbol-at-point-actwin-display-actwin-sign-enable

where cursoe-line-enable uses CursorLine to highlight the current line. highlight-line-enable uses Vims line-pattern based highlighting current line. sign-enable uses Vims sign capability to highlight all lines.

For each highlighing type, there are various further Options (see the PROPERTIES file for all options).

There are also commands defined to allow for the navigation of the actwin from within the actwin and from the scala window (with, of course, Options defining the mapping from key(s) to command). Supported are key mappings (:map key commnd), command definition and use of abbreviations to execute a command. You may wish to change some or all of the definitions.

Basically, in the scala windows, some of the quickfix (default) commands are the default: ccl - close window cn - next line cp - previous line cf - first line cl - last line ce - enter (goto corresponding line is scala file).

You will notice that as you traverse the lines in the actwin, the scala window highlighting moves and you jump to a new scala file if needed automatically.

For the actwin window, some of the default commands are:

- help - show actwin map - show scala cmd - show scala map - select current line GG - goto top line G - goto bottom line j - down one line k - up one line dd - delete current line (entry) q - close actwin For each such Option definition, you can define a single, String, mapping or a List of Strings, e.g.: "close": "q" "down": [ "j", ""] To quickly see all of the available Options you run the following command in your shell: grep tailor-actwin PROPERTIES grep tailor-uses-of-symbol-at-point-actwin PROPERTIES grep tailor-show-errors-and-warning-actwin PROPERTIES I wanted to experiment with Vim signs prior to coding up the Vimside debug feature and some folks had stated that they wanted more features in the Vimside quickfix window. I am rather pleased with the actwin code; its pretty flexible and responsive. Also, the actwin code is new and so may be fragile.