[ 
https://issues.apache.org/jira/browse/NETBEANS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Lenz updated NETBEANS-116:
------------------------------------
    Description: 
We need a consistent behaviour in the each editor for "select next/previous 
element". It is so inconsistent and it is only working well in the java editor.

I will create subtickets for each editor. Next element selection should be 
separated for those characters in strings: `$-,.;:SPACE{}()[]\/'"*+#` and maybe 
some others but I don't know.

Examples:
"This is my string"; So is the cursor in "my" and I hit the "Select next 
element action", it should select "my" after hitting it again, it should select 
the whole string w/o quotes. After hitting again, it should select the string 
with quotes.

"test \-r test"; Cursor is before "-" and hitting the action, it should select 
the whole string, or -r I don't now. In IntelliJ it selecets the whole string. 
If the cursor is before the "r" it selects "r" first, aftert hitting again, it 
selects the whole string.

"^3.0.0"; Cursor is before "3", after hitting the action, it should select "3". 
After hitting again, it should select the whole string.

It is a bit complicated to describe but for strings it should be consistent in 
Java, JS, CSS, SCSS, LESS, HTML, C/C++, PHP, JSON and so on. As I said I will 
create sub tickets for the editors.

The next thing is that there is more than strings. So the next consistency is 
needed for blocks like if, for, functions, classes etc. All of this alreday 
exists more or less for Java and JS but not that good. Please have a look into 
IntelliJ or WebStorm and hit ctrl + w for this feature. It works like a charm 
on each editor.

So "Select previous element" should work the other way around to unselect the 
last selection.

So there we have HTML, XHTML and XML, where it should work too. It is only 
working ok in HTML but not perfect.


Regards

Chris

  was:
We need a consistent behaviour in the each editor for "select next element". It 
is so inconsistent and it is only working well in the java editor.

I will create subtickets for each editor. Next element selection should be 
separated for those characters in strings: `$-,.;:SPACE{}()[]\/'"*+#` and maybe 
some others but I don't know.

Examples:
"This is my string"; So is the cursor in "my" and I hit the "Select next 
element action", it should select "my" after hitting it again, it should select 
the whole string w/o quotes. After hitting again, it should select the string 
with quotes.

"test \-r test"; Cursor is before "-" and hitting the action, it should select 
the whole string, or -r I don't now. In IntelliJ it selecets the whole string. 
If the cursor is before the "r" it selects "r" first, aftert hitting again, it 
selects the whole string.

"^3.0.0"; Cursor is before "3", after hitting the action, it should select "3". 
After hitting again, it should select the whole string.

It is a bit complicated to describe but for strings it should be consistent in 
Java, JS, CSS, SCSS, LESS, HTML, C/C++, PHP, JSON and so on. As I said I will 
create sub tickets for the editors.

The next thing is that there is more than strings. So the next consistency is 
needed for blocks like if, for, functions, classes etc. All of this alreday 
exists more or less for Java and JS but not that good. Please have a look into 
IntelliJ or WebStorm and hit ctrl + w for this feature. It works like a charm 
on each editor.

So there we have HTML, XHTML and XML, where it should work too. It is only 
working ok in HTML but not perfect.


Regards

Chris


> Consistent behaviour of select next/previous element in each editor
> -------------------------------------------------------------------
>
>                 Key: NETBEANS-116
>                 URL: https://issues.apache.org/jira/browse/NETBEANS-116
>             Project: NetBeans
>          Issue Type: Improvement
>          Components: cnd - Editor, db - SQL Editor, java - Editor, javascript 
> - Editor, javascript - JSON, php - Editor, web - CSS Editor, web - CSS 
> Preprocessors (SASS, LESS, ...), web - HTML Editor
>    Affects Versions: Next
>            Reporter: Christian Lenz
>            Priority: Major
>
> We need a consistent behaviour in the each editor for "select next/previous 
> element". It is so inconsistent and it is only working well in the java 
> editor.
> I will create subtickets for each editor. Next element selection should be 
> separated for those characters in strings: `$-,.;:SPACE{}()[]\/'"*+#` and 
> maybe some others but I don't know.
> Examples:
> "This is my string"; So is the cursor in "my" and I hit the "Select next 
> element action", it should select "my" after hitting it again, it should 
> select the whole string w/o quotes. After hitting again, it should select the 
> string with quotes.
> "test \-r test"; Cursor is before "-" and hitting the action, it should 
> select the whole string, or -r I don't now. In IntelliJ it selecets the whole 
> string. If the cursor is before the "r" it selects "r" first, aftert hitting 
> again, it selects the whole string.
> "^3.0.0"; Cursor is before "3", after hitting the action, it should select 
> "3". After hitting again, it should select the whole string.
> It is a bit complicated to describe but for strings it should be consistent 
> in Java, JS, CSS, SCSS, LESS, HTML, C/C++, PHP, JSON and so on. As I said I 
> will create sub tickets for the editors.
> The next thing is that there is more than strings. So the next consistency is 
> needed for blocks like if, for, functions, classes etc. All of this alreday 
> exists more or less for Java and JS but not that good. Please have a look 
> into IntelliJ or WebStorm and hit ctrl + w for this feature. It works like a 
> charm on each editor.
> So "Select previous element" should work the other way around to unselect the 
> last selection.
> So there we have HTML, XHTML and XML, where it should work too. It is only 
> working ok in HTML but not perfect.
> Regards
> Chris



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to