Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#165 Sessions plugin discards buffer order

closed-accepted
Alan Ezust
None
5
2015-02-21
2013-06-13
kevin.canadian
No

If buffer sorting is disabled, when saving a session using the Sessions plugin the manual buffer order set by the user gets lost, and on reopen the buffers are in what amounts to random order. I'm attaching a patch which uses a LinkedHashMap to store the current edit pane's buffers, which are in the proper order as set by the user. There may be a better way to solve this (perhaps while addressing bug 2698271), but this seems to work for now.

Discussion

  • kevin.canadian
    kevin.canadian
    2013-06-13

    Patch allowing buffer order to be remembered.

     
    Attachments
  • Alan Ezust
    Alan Ezust
    2014-11-30

    Ticket moved from /p/jedit/plugin-bugs/1719/

     
  • Alan Ezust
    Alan Ezust
    2014-12-01

    I would have seen this sooner (I think) if it had been posted to the correct tracker, plugin-patches, rather than plugin-bugs.
    Committed Rev# 23747 to sessions plugin trunk. This will be in Sessions 1.6.2

     
  • Alan Ezust
    Alan Ezust
    2014-12-01

    • status: open --> closed-accepted
    • assigned_to: Alan Ezust
    • Group: --> 4.3
     
  • kevin.canadian
    kevin.canadian
    2015-02-17

    Thanks for accepting this. Unfortunately changes in the core jEdit have broken my previous patch, and the changes I proposed are no longer enough to fix the problem. I'm attaching a new patch (against today's trunk) which adds a few lines to work around this "new" problem.

    If I can find some time I'll be filing a patch against the core jEdit to address the underlying problem. Basically I see no reason for view.getBuffers() not to default to "presentation order" if no other sorting is requested. Either way, this new patch should work whether they accept my change or not.

    (For the record, the description of the plugin-bugs tracker seemed to fit, since I was reporting a bug in a plugin, and that is what the plugin-bugs tracker says it is for. I'm unfamiliar with the jEdit project in general, and as an "outsider" I can say that the project documentation is a bit of a mess, especially documentation regarding development...)

     
    Attachments
  • kevin.canadian
    kevin.canadian
    2015-02-17

    (Just noticed that the comment in this patch should read "directly", not "direction". Here is the update. Sorry about that.)

     
    Attachments
  • Alan Ezust
    Alan Ezust
    2015-02-21

    Submitting a patch to an already closed ticket is a bad idea, almost a guarantee that it will never be seen and handled properly. Each patch should have a new ticket in the patches tracker.

    The plugin-bugs tracker is where you report bugs, and if you have a patch, it is better to submit a separate ticket on the plugin-patches trcker with each patch. Then you can link to it from the bug afterwards, and we have a proper ticket for your patch which is separate from the bug report.

    I am lazy so I sometimes move bugs with patches into the patches tracker, so they will be noticed and closed more quickly than if they were just bugs without patches.

    Also, if you want to be maintainer of the Sessions plugin, that would be much appreciated. I can even (try to) give you commit permissions to it.

     
    Last edit: Alan Ezust 2015-02-21
  • kevin.canadian
    kevin.canadian
    2015-02-21

    Thanks for the reply. Some projects prefer not opening a new ticket for the same issue, I wasn't sure what was preferred here. The bug/patch separation as you described it makes sense.

    I'll open a new patch with an improved version of this (although it may not be needed for long if we merge the other patch I submitted to the jEdit core).

    I'm not sure what it entails to be a plugin maintainer, and I'm not up to speed on jedit procedures (releases, testing, etc.). But I don't mind being involved, if you can get me commit permission.

    To be honest if I were to do anything more than a few patches here and there I would much rather use git (I've noticed some things are there already).