[ 
https://issues.apache.org/jira/browse/NETBEANS-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108176#comment-17108176
 ] 

Pier Luigi edited comment on NETBEANS-2082 at 5/15/20, 11:17 AM:
-----------------------------------------------------------------

My post (and intention) was not a criticism but a simple observation: the code 
folding of NB behave "strange" since the first Apache version thus I'm 
expecting that a large part of the users base complains about it. In addition 
the "jump" could be only a part of the problem.

To go forward and in order to "investigate it by myself and/or motivate others" 
this is a visual comparison of the code folding behavior of NB 11.3 compared 
side by side to the old 8.2:

#1: 
[http://download.e-link.it/netbeans/NB_Code_Folding_comparision-Blocks_Identification.mp4]

The first video show that code blocks that are "foldable" are identified 
differently and often in a wrong way: as you can see with NB11.3 the editor 
fail to identify as "foldable" even the main class block and many methods.
 Please note that at 0:22 I cut and re-paste the same block of code (so the 
source remain the same) and the editor seems to correct its foldable blocks 
identification criteria (the main class and some methods become marked as 
foldable), but if I save the file, then close and reopen NB the behavior back 
to the wrong one. 

 

#2 
[http://download.e-link.it/netbeans/NB_Code_Folding_comparision-Jump_to_caret_1.mp4]

The video show the problem highlighted with this thread. Please note that the 
click a 0:26 fold the code correctly with no jump even if the caret is at the 
end of the document, but the following clicks that expand and collapse the same 
block into the same situation exhibit the problematic jump.

 

#3 
[http://download.e-link.it/netbeans/NB_Code_Folding_comparision-Jump_to_caret_2.mp4]

As you can see (0:33), with NB11.3 if you fold a block of code AND the caret is 
inside it, when you scroll the document using the mouse wheel or the scroll 
bar, the document scroll position keep returning automatically to the folded 
code after about a second.

I think that the fold and unfold actions should not deal with scroll and should 
ignore the actual caret position if it is outside the affected block, otherwise 
set the caret position to the begin of the folded block.

 


was (Author: picov):
My post (and intention) was not a criticism but a simple observation: the code 
folding of NB behave "strange" since the first Apache version thus I'm 
expecting that a large part of the users base complains about it. In addition 
the "jump" could be only a part of the problem.

To go forward and in order to "investigate it by myself and/or motivate others" 
this is a visual comparison of the code folding behavior of NB 11.3 compared 
side by side to the old 8.2:

#1: 
[http://download.e-link.it/netbeans/NB_Code_Folding_comparision-Blocks_Identification.mp4]

The first video show that code blocks that are "foldable" are identified 
differently and often in a wrong way: as you can see with NB11.3 the editor 
fail to identify as "foldable" even the main class block and many methods.
Please note that at 0:32 I cut and re-paste the same block of code (so the 
source remain the same) and the editor seems to correct its foldable blocks 
identification criteria (the main class and some methods become marked as 
foldable), but if I save the file, then close and reopen NB the behavior back 
to the wrong one. 

 

#2 
[http://download.e-link.it/netbeans/NB_Code_Folding_comparision-Jump_to_caret_1.mp4]

The video show the problem highlighted with this thread. Please note that the 
click a 0:26 fold the code correctly with no jump even if the caret is at the 
end of the document, but the following clicks that expand and collapse the same 
block into the same situation exhibit the problematic jump.

 

#3 
[http://download.e-link.it/netbeans/NB_Code_Folding_comparision-Jump_to_caret_2.mp4]

As you can see (0:33), with NB11.3 if you fold a block of code AND the caret is 
inside it, when you scroll the document using the mouse wheel or the scroll 
bar, the document scroll position keep returning automatically to the folded 
code after about a second.


I think that the fold and unfold actions should not deal with scroll and should 
ignore the actual caret position if it is outside the affected block, otherwise 
set the caret position to the begin of the folded block.

 

> Scroll to the caret position when code fold feature is run
> ----------------------------------------------------------
>
>                 Key: NETBEANS-2082
>                 URL: https://issues.apache.org/jira/browse/NETBEANS-2082
>             Project: NetBeans
>          Issue Type: Bug
>          Components: editor - Code folding
>    Affects Versions: 10.0, 11.0, 11.1, 11.2
>         Environment: Netbeans 11 with OpenJDK 12. 
> Darwin MacBook-Pro-2.local 18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11 
> 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64
> Netbeans 10 with OpenJDK 11.
> Darwin MacBook-Pro-2.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 
> 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64
>            Reporter: Pier Luigi
>            Assignee: Svatopluk Dedic
>            Priority: Critical
>         Attachments: DemoPHPCodeFoldingProblem_NB11.php, NETBEANS-2082.zip, 
> netbeans-2082.gif
>
>
> Collapsing a block often results in a jump of the editor to an incorrect 
> editing position (and scrolling the page cause a rejump to that position 
> after a second of scroll inactivity).
> The same sources works perfectly with Netbeans 8.2.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Reply via email to