[jira] [Created] (NETBEANS-638) Second editor window spontaneously changes current line context

["will mason (JIRA)" <ji...@apache.org>]

will mason created NETBEANS-638:
-----------------------------------

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


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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: commits-help@netbeans.apache.org

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