Prettier location list

[Kannan]

Eric,

  We use the location list to display results of compilation errors, checkstyle warnings, code references, breakpoints, etc. For any decent sized project, the file paths tend to be fairly long as the package hierarchy is deep. The location list is useful from a pure functionality perspective. But I don't find the UI to be pleasing. It is a flat list instead of hierarchies (see example given below). I was wondering if we can do something about it. I want to get your thoughts on this problem, to see if it makes sense and is possible.

---------------------------------------------------------------

VIM support that is lacking

1. Multiple location list per window, each identified by a name.

When you save a file, the errors are loaded into location list. But then, if I do a code reference, then the contents are overwritten and even the signs are lost. I need to save the file again to regenerate the errors.

2. Ability to store information about a location list without displaying it.

With this support, I can show just the file name instead of path, but use the path when user presses Enter.

---------------------------------------------------------------

Since these features are not yet available in VIM, what if we create our own location list equivalent for some use cases like code reference and use that for displaying Eclim results? It could be a simple temp window with necessary mapping to get to the file. If you look at how Eclipse shows the results in its windows, they are nested. Here is an example.

org.eclim.package1

  Class1.java

  Class2.java

org.eclim.package2

  Class3.java

The way we show is a flat list that is hard to read. We often want to focus on specific packages. So a nested structure is helpful.

org.eclim.package1.Class1.java

org.eclim.package1.Class2.java

org.eclim.package2.Class3.java

org.eclim.package2.Class4.java

  

 

-- 

Kannan

[Kannan]

Another use case I forgot to mention was to differentiate warning messages from errors. Large existing projects tend to have lot of warnings because people don't always follow code conventions. In those cases, its helpful to fix compilation errors rather than wading through warnings introduced by others. If we had nesting support, then we can display it like this and can quickly get to errors.

Errors

  - file1  : error1

  - file 2 : error2

Warnings

  - file1  : warn1

  - file 2 : warn2

 

-- 

Kannan

--
You received this message because you are subscribed to the Google Groups "eclim-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
To post to this group, send email to ecli...@googlegroups.com.
Visit this group at http://groups.google.com/group/eclim-dev.
For more options, visit https://groups.google.com/d/optout.

[Eric Van Dewoestine]

On 2014-10-06 18:01:08, Kannan wrote:
> Another use case I forgot to mention was to differentiate warning messages from errors. Large existing projects tend to have lot of warnings because people don't always follow code conventions. In those cases, its helpful to fix compilation errors rather than wading through warnings introduced by others. If we had nesting support, then we can display it like this and can quickly get to errors.
>
> Errors
> - file1 : error1
> - file 2 : error2
>
> Warnings
> - file1 : warn1
> - file 2 : warn2
>

You can kind of of accomplish this using:

let g:EclimValidateSortResults = 'severity'

> --
> Kannan
>
>
> On Monday, October 6, 2014 5:56 PM, Kannan <rkan...@gmail.com> wrote:
>
>
>
> Eric,
> We use the location list to display results of compilation errors, checkstyle warnings, code references, breakpoints, etc. For any decent sized project, the file paths tend to be fairly long as the package hierarchy is deep. The location list is useful from a pure functionality perspective. But I don't find the UI to be pleasing. It is a flat list instead of hierarchies (see example given below). I was wondering if we can do something about it. I want to get your thoughts on this problem, to see if it makes sense and is possible.
>
> ---------------------------------------------------------------
>
> VIM support that is lacking
> 1. Multiple location list per window, each identified by a name.
> When you save a file, the errors are loaded into location list. But then, if I do a code reference, then the contents are overwritten and even the signs are lost. I need to save the file again to regenerate the errors.

This is why I've wanted to put search results into the quickfix list
(now committed), since searches aren't local to the current file, so
they should have never have been treated as though they were.

> 2. Ability to store information about a location list without displaying it.
> With this support, I can show just the file name instead of path, but use the path when user presses Enter.
> ---------------------------------------------------------------
>
> Since these features are not yet available in VIM, what if we create our own location list equivalent for some use cases like code reference and use that for displaying Eclim results? It could be a simple temp window with necessary mapping to get to the file. If you look at how Eclipse shows the results in its windows, they are nested. Here is an example.
>
> org.eclim.package1
> Class1.java
> Class2.java
>
> org.eclim.package2
> Class3.java
>
> The way we show is a flat list that is hard to read. We often want to focus on specific packages. So a nested structure is helpful.
> org.eclim.package1.Class1.java
> org.eclim.package1.Class2.java
>
> org.eclim.package2.Class3.java
>
> org.eclim.package2.Class4.java

The new FileList utility function now gets us most of that ability
with a lot more room for improvement. However, I don't want to start
pushing all eclim features into the FileList since using the standard
quickfix/location list has a lot of advantages, especially for long
time vim users that have the quickfix command firmly engrained in
their muscle memory. For very specific features (debug breakpoints),
the FileList makes a lot of sense though.

--
eric