will mason created NETBEANS-638:

             Summary: Second editor window spontaneously changes current line 
                 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 
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

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


* 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 

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

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

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:

Reply via email to