#136 Forward/back file actions for Navigator

closed-accepted
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)
  • Jarek Czekalski

    Jarek Czekalski - 2012-05-19

    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!

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-05-19
    • 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
     
  • Jarek Czekalski

    Jarek Czekalski - 2012-06-21

    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

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-06-21

    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.

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-08-05
    • 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)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks