#136 Forward/back file actions for Navigator

closed-accepted
Tom Power
None
5
2012-10-28
2012-04-21
Tom Power
No

Adds actions to go forward or back a whole file in the Navigator history. Keeps track of where in the history the action was called and makes use of that in subsequent calls to the action. Useful when you have alot of history in a single file, and don't want to go through it to get to "that" file you were just working on.

Discussion

1 2 > >> (Page 1 of 2)
  • Tom, please review for the last time whether all is ok, as it is a bit old. I believe no one objects you committing to unmaintained plugins directly, so please do.

     
  • Tom Power
    Tom Power
    2012-05-19

    • status: open --> open-rejected
     
  • Tom Power
    Tom Power
    2012-05-19

    Isn't OK, I still want an action like this but this patch has bugs!

     
    • assigned_to: nobody --> tp21
     
  • Alan Ezust
    Alan Ezust
    2012-05-23

    When fixed, please create a new ticket, and assign your patch to dale anson for review, he is maintainer of Navigator.

     
  • Alan Ezust
    Alan Ezust
    2012-05-23

    • status: open-rejected --> closed-rejected
     
  • Tom Power
    Tom Power
    2012-06-21

    This works well for me now, what do you think Dale, I can commit it if easier?

     
  • Tom Power
    Tom Power
    2012-06-21

    • assigned_to: tp21 --> daleanson
    • status: closed-rejected --> open
     
  • Tom, what would happen if you didn't have fileJump marker? I guess something terrible, but can't imagine what it is. Maybe a comment could enlighten it?

     
  • Dale Anson
    Dale Anson
    2012-06-21

    Tom, thanks, I'll review this morning.

     
  • Tom Power
    Tom Power
    2012-06-21

    Hi, it's used when the user jumps back to a file they've recently jumped from, found it nicer when doing that than putting the user at the first/last history item in the file they're jumping to, added a comment that hopefully makes clearer

     
  • Introducing fileJump marker adds a significant complication to the code. But let's forget about it for a moment and think of very user interface.

    Let's consider the following scenario:
    1. User does goBack several times still being in file A. They think: I'd rather jump fileBack to B.
    2. He does goBackFile
    3. He does goForwardFile hoping to reach the location he started moving from

    Without fileJump marker he would get to the most recent history entry for that file. With marker he lands back several steps. So the questions arise:
    A. Is it desired?
    B. If yes, should they have the possibility to go fileForward once more to land on the top of the history?

    Could you give one scenario where fileJump is really needed and jumping to most recent entry should be avoided?

    I think I have another scenario where the marker might be misleading:
    1. goBackFile to file B (sets marker in file A)
    2. goForwardFile to file A
    3. Travel through file A manually marking new positions
    4. goBack (not file) many times, stop in file B
    5. goForwardFile to land in file A. Landing in position from 1 (not the position after 3) may be a surprise

    And it's a bit harder to explain (in user docs) what is exactly the place fileBack/fileForward jumps to. I think the place where the user lands in should be easily predictable. But maybe I'm wrong. Let Dale decide.

     
  • Dale Anson
    Dale Anson
    2012-06-21

    Actually, I like this patch quite a lot. It provides the functionality of 'group by file' on the fly so you still have the granularity of jumping by caret position or line. Even better than 'group by file', it takes you back to the last position you visited in the file rather than the last position in the history for that file, which is very convenient.

    I agree with Jarek, this is a little hard to explain for the help file documentation, but if you show the Navigator dockable, it's pretty obvious what's going on. I'll try to write up something coherent before committing.

     
  • Tom Power
    Tom Power
    2012-06-21

    Thanks for the comments both of you, with the fileJump marker I was trying to ensure you got back to the location you were most recently, but in the file you'd jumped from, as that seems better to me. I mainly had in mind tying them to keys for flicking between files without thinking too much. For additional scenarios, I'd say whenever you use the actions to exit a file and there are history items between your current location and the file you're going to.

    For your qu's Jarek:

    First scenario: I think I'd be less surprised by returning to where I'd jumped from, than the last/first place I'd been since being in that file.

    So yes I think it'd be desirable and no I think I'd prefer to use goBack/goForward afterwards to get to my starting location.

    Second scenario: I totally agree, hadn't thought about that and it doesn't work there. I think calling removeFileJumps() whenever you left a file by a method other than goFowardFile()/goBackFile() would fix it and happy to try to implement though don't want to cause more probs :¬)

     
  • Dale Anson
    Dale Anson
    2012-06-21

    I applied the patch and checked in the changes. Please test it out. I'm not sure if scenario 2 is a problem. So far, it is working quite nicely and I haven't been surprised where I ended up.

     
  • Alan Ezust
    Alan Ezust
    2012-06-24

    Just wondering, how are these actions supposed to be different from the jEdit built-in actions, from the View menu "go to previous buffer" and "go to next buffer"?

     
  • Alan Ezust
    Alan Ezust
    2012-06-24

    oops. nevermind, I see the built-in actions are just based on the order of buffers n the bufferset, as opposed to the visited order.

     
    • status: open --> closed-accepted
     
  • Tom Power
    Tom Power
    2012-08-11

    Getting NPE's with this due to my thickness, attached a patch for r21994 that fixes

     
  • Tom Power
    Tom Power
    2012-08-11

    • status: closed-accepted --> open-accepted
     
  • Alan Ezust
    Alan Ezust
    2012-08-17

    Committed second patch as rev#22023.

     
  • Alan Ezust
    Alan Ezust
    2012-08-17

    • status: open-accepted --> closed-accepted
     
  • Tom Power
    Tom Power
    2012-10-13

    • status: closed-accepted --> open-accepted
     
1 2 > >> (Page 1 of 2)