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

will mason updated NETBEANS-638:
--------------------------------
    Description: 
h2. context

* Editing a file in Netbens (e.g. Java file)
* Split the screen Vertically or Horizontally
* Split the screen Horizontally
* Clone the edit tab

*_rationale_*

* The predominate reason to do any of these three actions is to facilitate the 
viewing of different parts of the same (code) file together, at the same time.
* To permit easier code copy, swap, or move of existing code from one area to 
the other.
* To permit referring to two different parts of the same file that can't fit on 
the screen together with some other file or display, etc.
* Contemporaneous editing of two different sections of code together; say 
editing the declaration section along with some implementation code (for 
example).

In summary keeping two (or more) areas of the same file *+In View at the Same 
Time+*.

h2. expected

*  When the editor window is split or when secondary (clone) windows are open 
each display context must remain with, or in the locality of, the lines chosen 
for display by the user.

# Use-case scenario #1
#*   Split window horizontally -- top and bottom
#*  On the top window the cursor is at line 200.
#*  On the bottom window use {{CTRL/G}} and jump to line 1,500
#* Those positions are _known_ internally by the editor
#* The cursor must remain _in situ_.
#* Should insert lines say 10 in the top panel, the the cursor location in the 
bottom panel must adjust to be at the subjective position of line1,510.
# Use-case scenario #2
#*   Split window horizontally -- top and bottom
#*  On the top window the cursor is at line 200.
#*  On the bottom window use {{CTRL/G}} and jump to line 1,500
#*  Scroll bottom window to line 2,000 
#**  These are the visible lines, the current line remains #1,500
#*  If I subsequently edit at line #200 in the top window the lines visible in 
the bottom window must remain around the #2,000 line mark if nothing else has 
changed!
#**  Admittedly the valid behaviour IF I move the cursor (say up-arrow) should 
be to reset the visible lines to the area around #1,499

h2. actual

Use-case scenario #1

* After an edit in the top window the bottom window  often loses context 
(around 80% of cases)
* Sometimes the lines showing in bottom, don't relate to either line 100 or 
line 1,500 but some other location
* Using a key in the bottom window can have consequences such as inserting text 
in the wrong place dire problems happen if an open brace({) is inadvertently 
inserted!
* sometimes edits in the bottom frame cause the top window to move the 
displayed location.
**  Once more the cursor position is not clearly known 

Use-case scenario #2

*   Sometimes the view in the second  bottom window can move to line #1,500
*   Sometimes the view in the second  bottom window can move to line #200
*  It never seems to stay at line #2,000 where the user (_me_) wants to read 
the text/code!

Both situations

*  Sometimes the cursor seems to remain on the appropriate line in the other 
window (sticking with bottom frame for discussion purposes).
* And the lines in view move  (say to line #1,000) -- Leaving the user with an 
unknown or unexpected view of lines that he/she expected to be around line 
#1,500
* Often boilerplate code in one are can resemble code in a different place
* In this example it would be easy to begin editing line #1,000 believing that 
the changes are going into the method on line #1,500 (say).

h2.  Impact

*  Frustration and wasted time having move cursor or display back to where it 
Should Have Remained (Be).
* Code errors, recall the misplaced opening-brace({) -- this kind of typo can 
take hours to unravel
* Missed opportunities because the code you need to view is not visible or not 
what you are looking at (despite having displayed the code you want *_See_*)

A further problem here is the context changes in the Editor windows your are 
Not viewing may not be immediately seen.  I may split file-01 and make some 
change to top, then edit File-03 altar coming back to file-10 believing the top 
and bottom display the Expected code that I had positioned In that frame -- 
when it no longer represents the chosen line / display locations.



  was:
h2. context

* Editing a file in Netbens (e.g. Java file)
* Split the screen Vertically or Horizontally
* Split the screen Horizontally
* Clone the edit tab

*_rationale_*

* The predominate reason to do any of these three actions is to facilitate the 
viewing of different parts of the same (code) file together, at the same time.
* To permit easier code copy, swap, or move of existing code from one area to 
the other.
* To permit referring to two different parts of the same file that can't fit on 
the screen together with some other file or display, etc.
* Contemporaneous editing of two different sections of code together; say 
editing the declaration section along with some implementation code (for 
example).

In summary keeping two (or more) areas of the same file *+In View at the Same 
Time+*.

h2. expected

*  When the editor window is split or when secondary (clone) windows are open 
each display context must remain with, or in the locality of, the lines chosen 
for display by the user.

# Use-case scenario #1
#*   Split window horizontally -- top and bottom
#*  On the top window the cursor is at line 200.
#*  On the bottom window use {{CTRL/G}} and jump to line 1,500
#* Those positions are _known_ internally by the editor
#* The cursor must remain _in situ_.
#* Should insert lines say 10 in the top panel, the the cursor location in the 
bottom panel must adjust to be at the subjective position of line1,510.

# Use-case scenario #2
#*   Split window horizontally -- top and bottom
#*  On the top window the cursor is at line 200.
#*  On the bottom window use {{CTRL/G}} and jump to line 1,500
#*  Scroll bottom window to line 2,000 
#**  These are the visible lines, the current line remains #1,500
#*  If I subsequently edit at line #200 in the top window the lines visible in 
the bottom window must remain around the #2,000 line mark if nothing else has 
changed!
#**  Admittedly the valid behaviour IF I move the cursor (say up-arrow) should 
be to reset the visible lines to the area around #1,499

h2. actual

Use-case scenario #1

* After an edit in the top window the bottom window  often loses context 
(around 80% of cases)
* Sometimes the lines showing in bottom, don't relate to either line 100 or 
line 1,500 but some other location
* Using a key in the bottom window can have consequences such as inserting text 
in the wrong place dire problems happen if an open brace({) is inadvertently 
inserted!
* sometimes edits in the bottom frame cause the top window to move the 
displayed location.
**  Once more the cursor position is not clearly known 

Use-case scenario #2

*   Sometimes the view in the second  bottom window can move to line #1,500
*   Sometimes the view in the second  bottom window can move to line #200
*  It never seems to stay at line #2,000 where the user (_me_) wants to read 
the text/code!

Both situations

*  Sometimes the cursor seems to remain on the appropriate line in the other 
window (sticking with bottom frame for discussion purposes).
* And the lines in view move  (say to line #1,000) -- Leaving the user with an 
unknown or unexpected view of lines that he/she expected to be around line 
#1,500
* Often boilerplate code in one are can resemble code in a different place
* In this example it would be easy to begin editing line #1,000 believing that 
the changes are going into the method on line #1,500 (say).

h2.  Impact

*  Frustration and wasted time having move cursor or display back to where it 
Should Have Remained (Be).
* Code errors, recall the misplaced opening-brace({) -- this kind of typo can 
take hours to unravel
* Missed opportunities because the code you need to view is not visible or not 
what you are looking at (despite having displayed the code you want *_See_*)

A further problem here is the context changes in the Editor windows your are 
Not viewing may not be immediately seen.  I may split file-01 and make some 
change to top, then edit File-03 altar coming back to file-10 believing the top 
and bottom display the Expected code that I had positioned In that frame -- 
when it no longer represents the chosen line / display locations.




> Second editor window spontaneously changes current line context
> ---------------------------------------------------------------
>
>                 Key: NETBEANS-638
>                 URL: https://issues.apache.org/jira/browse/NETBEANS-638
>             Project: NetBeans
>          Issue Type: Bug
>          Components: cnd - Editor
>    Affects Versions: 9.0
>         Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-205-on-20180202)
> Java: 10; Java HotSpot(TM) 64-Bit Server VM 10+46
> Runtime: Java(TM) SE Runtime Environment 10+46
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_AU (nb)
> User directory: Z:\tmp\.other\user\netbeans\v09.00-beta\FourAbs
> Cache directory: Z:\tmp\.other\cache\netbeans\FourAbs-09
>            Reporter: will mason
>            Priority: Major
>
> h2. context
> * Editing a file in Netbens (e.g. Java file)
> * Split the screen Vertically or Horizontally
> * Split the screen Horizontally
> * Clone the edit tab
> *_rationale_*
> * The predominate reason to do any of these three actions is to facilitate 
> the viewing of different parts of the same (code) file together, at the same 
> time.
> * To permit easier code copy, swap, or move of existing code from one area to 
> the other.
> * To permit referring to two different parts of the same file that can't fit 
> on the screen together with some other file or display, etc.
> * Contemporaneous editing of two different sections of code together; say 
> editing the declaration section along with some implementation code (for 
> example).
> In summary keeping two (or more) areas of the same file *+In View at the Same 
> Time+*.
> h2. expected
> *  When the editor window is split or when secondary (clone) windows are open 
> each display context must remain with, or in the locality of, the lines 
> chosen for display by the user.
> # Use-case scenario #1
> #*   Split window horizontally -- top and bottom
> #*  On the top window the cursor is at line 200.
> #*  On the bottom window use {{CTRL/G}} and jump to line 1,500
> #* Those positions are _known_ internally by the editor
> #* The cursor must remain _in situ_.
> #* Should insert lines say 10 in the top panel, the the cursor location in 
> the bottom panel must adjust to be at the subjective position of line1,510.
> # Use-case scenario #2
> #*   Split window horizontally -- top and bottom
> #*  On the top window the cursor is at line 200.
> #*  On the bottom window use {{CTRL/G}} and jump to line 1,500
> #*  Scroll bottom window to line 2,000 
> #**  These are the visible lines, the current line remains #1,500
> #*  If I subsequently edit at line #200 in the top window the lines visible 
> in the bottom window must remain around the #2,000 line mark if nothing else 
> has changed!
> #**  Admittedly the valid behaviour IF I move the cursor (say up-arrow) 
> should be to reset the visible lines to the area around #1,499
> h2. actual
> Use-case scenario #1
> * After an edit in the top window the bottom window  often loses context 
> (around 80% of cases)
> * Sometimes the lines showing in bottom, don't relate to either line 100 or 
> line 1,500 but some other location
> * Using a key in the bottom window can have consequences such as inserting 
> text in the wrong place dire problems happen if an open brace({) is 
> inadvertently inserted!
> * sometimes edits in the bottom frame cause the top window to move the 
> displayed location.
> **  Once more the cursor position is not clearly known 
> Use-case scenario #2
> *   Sometimes the view in the second  bottom window can move to line #1,500
> *   Sometimes the view in the second  bottom window can move to line #200
> *  It never seems to stay at line #2,000 where the user (_me_) wants to read 
> the text/code!
> Both situations
> *  Sometimes the cursor seems to remain on the appropriate line in the other 
> window (sticking with bottom frame for discussion purposes).
> * And the lines in view move  (say to line #1,000) -- Leaving the user with 
> an unknown or unexpected view of lines that he/she expected to be around line 
> #1,500
> * Often boilerplate code in one are can resemble code in a different place
> * In this example it would be easy to begin editing line #1,000 believing 
> that the changes are going into the method on line #1,500 (say).
> h2.  Impact
> *  Frustration and wasted time having move cursor or display back to where it 
> Should Have Remained (Be).
> * Code errors, recall the misplaced opening-brace({) -- this kind of typo can 
> take hours to unravel
> * Missed opportunities because the code you need to view is not visible or 
> not what you are looking at (despite having displayed the code you want 
> *_See_*)
> A further problem here is the context changes in the Editor windows your are 
> Not viewing may not be immediately seen.  I may split file-01 and make some 
> change to top, then edit File-03 altar coming back to file-10 believing the 
> top and bottom display the Expected code that I had positioned In that frame 
> -- when it no longer represents the chosen line / display locations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
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