This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Hints language enhancements | ||
---|---|---|---|
Product: | java | Reporter: | Svata Dedic <sdedic> |
Component: | Hints | Assignee: | Svata Dedic <sdedic> |
Status: | NEW --- | ||
Severity: | normal | CC: | jlahoda, markiewb |
Priority: | P3 | ||
Version: | 8.1 | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
Svata Dedic
2015-04-03 05:57:19 UTC
(In reply to Svata Dedic from comment #0) > Hints language/support enhancements > > * conditional hint parts: currently $xxx$; may serve as a placeholder to > absorb one or more statements (parts), but sometimes either the conditional > part is not suitabel for such treatment, or several parts (i.e. start, end) > may be all either present or absent. > I do not understand. > * capture position: consider a match with $var placeholder, which will match > variable declaration or LValue assignment. Then subsequent $var usages in > the match pattern do not provide positional/tree information for the hint, > which makes the hint implementor to search for a Tree the AST. > Would my issue reported at https://netbeans.org/bugzilla/show_bug.cgi?id=244487 > * subtree matches: sometimes it is relevant that a reference to $foo occurs > not directly in the block, but "somewhere" inside, even nested in > if-while-try blocks. > I cannot imagine a usecase yet. Any example? > * negative matches: pattern part, which terminates the search. If subtree > matches are supported, a 'restart mark' could be needed so that only part of > subtree is ignored. > It can already expressed with custom conditions AFAIK. I never used them, but I read about them. https://bitbucket.org/jlahoda/jackpot30/wiki/RulesLanguageAdditionalDocs > * pattern priorities and hint exclusions: if it is possible to order > patterns, the most relevant hint message would suppress the general ones > from the same hint. Also a hint could deliberately suppress more > general/suitable other hints when matched. > Yes that would be useful. Perhaps you do not need to invoke the suppressed hint's activation code too. > Please give your feedback for the above ideas - I'll probably create a Wiki > page for easier collaboration after the initial round. Yes, a Wiki-page or a shared google drive document would be fine. |