Comments (11)
#257 adressed the configurability of how many lines of context should be shown around labels.
from codespan.
For your other point, why don't you just put a (secondary) label on the context that you want to explain?
from codespan.
That is what i did, but i ended up scrapping it because:
The diagnostic references two nodes in a statement, i just want 3 - 5 lines around each label's location to tell the user "this is where the wrong stuff is" without having them have to go to the line. But this gets very cluttered in real world code. For example a try statement in js code (which is what i am doing) is usually decently large. And i reference something in the try {}
block and the finally {}
block, both of which may be large.
Overall, having another colored line adds clutter to the diagnostic, Your eyes should drift straight to the two places which are labelled, and you should instantly know where that code is. Having more things for the user to consider is ugly.
from codespan.
I think i will use the pre-release version for now with the context lines option for now. Then i will just update once it is released 👍
Edit: realized this is for multiline labels only for now, which isnt exactly what i need. hope an option for single labels could be added in the future.
from codespan.
Ah yes, its more of context inside labels. Mistake on my part 😓
from codespan.
@RDambrosio016 Any chance you could post an example (of the output generated) for such a case where either what you're trying to achieve or how it looks using secondary labels?
from codespan.
Sure, this is what it normally looks like . You cant really tell where exactly in the code it is unless you go back and look at the line numbers. This is how it is with a secondary label, i personally dont like it, and if the catch
for example had a ton of stuff in it it would end up looking horrid.
Ideally i would just be able to say "3 lines of context around each label".
from codespan.
If you took the approach with a secondary label, you could adjust how many lines of context within the secondary label are shown (as I mentioned above). This would resolve the case of "if the catch had a ton of stuff in it". Your personal preference aside, I think this is a good alternative. Here is an example of how it would look using the current version:
from this source code
while(true){
try{
foo();
foo();
foo();
foo();
foo();
foo();
foo();
foo();
foo();
foo();
foo();
if(condition()){
continue;
}
}catch{
bar();
bar();
bar();
bar();
bar();
bar();
}finally{
break;
}
}
This example shows me some other problems though:
- Something got lost on the way of resolving #259 with #260 and the locus is at the earliest label again (notice the error is supposedly on line 2 instead of line 25).
- What you mentioned already: The context should also work for secondary labels and single line labels. But I think it would be enough to enable this feature only if the label is inside another multiline label.
- Another thing that might make sense is to add something like tertiary labels which would look better than my "This is the finally block." label. They should not be rendered but just force the specific line to be shown.
from codespan.
Another thing that might make sense is to add something like tertiary labels which would look better than my "This is the finally block." label. They should not be rendered but just force the specific line to be shown.
I disagree with doing it like this, it should be something separate, maybe Context
, a diagnostic would have a Vec<Context>
. A context basically just holds a range and lines in those ranges will be rendered but without a label or coloring.
from codespan.
I found that there already is #29, which is I think more close to what you were trying to get at. In that light I think suggestion № 3 is not necessary.
№ 1 has already been solved in #282.
from codespan.
I'd really love a solution that allows me to both specify a range of lines to display without requiring a label around it (i.e. the proposed "context" field on a diagnostic), as well as allowing me to specify a default amount of lines of context for any label.
That latter option should imo just be part of the config struct, such that one can set
config.context_before = 2
and config.context_after = 2
so specify "show at least 2 lines before and two lines after my label as context.
I'd assume that implementing that latter half at least should be pretty trivial - I might try myself at a PR for that!
from codespan.
Related Issues (20)
- Position is off by 2 characters with some strings HOT 6
- Add the ability to make multiline suggestions/notes HOT 4
- release tracking issue HOT 5
- codespan-reporting::Files not implemented for codespan::Files<String> HOT 3
- Display is broken on some platforms HOT 5
- Should non-`term` rendering backends live here? HOT 1
- Cut codespan release with fix? HOT 5
- Use of moved value: `blue` HOT 4
- Accessor for the location of a diagnostic HOT 3
- Implement `Ord` for `Severity` HOT 3
- Are there C bindings for codespan? HOT 2
- How to report inside `Display` implementation? HOT 3
- The destiny of `codespan` (and `codespan-reporting`)
- Make some functions `const`
- Request a new releases for including context before and after a label HOT 6
- Error when an error spans until EOF
- Wrong outer padding
- Move termcolor behind a feature flag
- Unicode block-drawing support HOT 1
- Trim or wrap line when it does not fit on the screen
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from codespan.