file window navigation out of order

[v_user]

I'm using 12.0.0 and when I switch between open files (I believe that's the next_window command) it seems the software picks some random order to jump around in.  The GUI shows the filename tabs in alphabetical order, which is fine, and I don't really care what order they sit in - I just want to be able to move right or left down this list in order, instead of hopping around who knows where.  There must be an option somewhere I'm missing, can someone send me in the right direction?  thanks much.

[Graeme]

I'm using 12.0.0 and when I switch between open files (I believe that's the next_window command) it seems the software picks some random order to jump around in.  The GUI shows the filename tabs in alphabetical order, which is fine, and I don't really care what order they sit in - I just want to be able to move right or left down this list in order, instead of hopping around who knows where.  There must be an option somewhere I'm missing, can someone send me in the right direction?  thanks much.

See the help topic "navigation" -> between buffers/windows.  You'll see next_buff_tab, prev_buff_tab mentioned.  Using the keybindings dialog you can bind shortcut keys to these.  I thought there was also a way to scroll through the file tabs by "pages" but I can't find it.

You can find a detailed explanation of how next_buffer, prev-buffer work (and a lot of other things) in the book "Professional Slickedit" available on Amazon.

I've also written my own buffer navigation code (and posted it here somewhere) that allows me to step through buffers in the order that I've visited them  - hence I can cycle between the current buffer and the previous buffer visited or between the current and previous two buffers etc.  Not sure if SE has the equivalent of this - last I checked, next-buffer and prev-buffer didn't quite do what I wanted.

Graeme

[jbhurst]

Hi Graeme!

Nice to see you on the forums again ...

On the "More" tab of the General Options dialog (Tools > Options > General) there is an unlabeled combo box with options that control the next-window and prev-window commands. Choose "Smart next window" (I think it's the default anyway), and you should get the behavior you described. I.e., next-window cycles through windows in order of most recent use, and prev-window in the reverse order. This usually works pretty well. It can get messed up if you are not using the "One file per window" setting ("General" tab). Also, if you load multiple files at the same time, I believe all but the last loaded of them actually go to the bottom of the MRU list, the opposite of what I'd expect.

The other window/buffer switching commands are:

next-buff-tab/prev-buff-tab, which cycle alphabetically. I don't think this is usually very useful, although at least it is predictable and matches the file tabs you see on the screen.

next-buffer (Ctrl+N)/prev-buffer (Ctrl+P), which cycle in order of the "ring", a circular list of your buffers. When you load a file, it is placed into the ring after the current buffer. This can be quite useful if you like to load a set of files with a known order and navigate quickly among them.

These days I find next-window/prev-window the most useful by far.

Regards

John Hurst
Wellington, New Zealand

[Graeme]

On the "More" tab of the General Options dialog (Tools > Options > General) there is an unlabeled combo box with options that control the next-window and prev-window commands. Choose "Smart next window" (I think it's the default anyway), and you should get the behavior you described. I.e., next-window cycles through windows in order of most recent use, and prev-window in the reverse order. This usually works pretty well. It can get messed up if you are not using the "One file per window" setting ("General" tab). Also, if you load multiple files at the same time, I believe all but the last loaded of them actually go to the bottom of the MRU list, the opposite of what I'd expect.

Hi John

Thanks for your comments.  Smart next window and next-window / prev-window were recommended to me by SE support a while ago but they don't do exactly what I want because they are two separate commands and you have to remember which direction to go in.  I want a single command (call it AB2) that alternates indefinitely between the last two (or three etc) buffers I've visited regardless of how I got to where I currently am.  e,g, if I'm currently looking at buffer 1 and the last buffer I was looking at was buffer 2, then AB2 alternates between buffers 1 and 2  - whereas with smart next window, if I'm looking at buffer 1 and want to go back to buffer 2 I have to remember whether to do prev-window or next-window.  I wrote my own macro for this using _switchbuf "callback" to remember the order buffers are visited.  For some reason, when bookmarks are used to switch buffers, the _switchbuf callback doesn't occur so I had to wrap the bookmark commands to get that working.  Also I suspect the "one file per window" setting has a performance cost but I don't know if it's significant.

Graeme

[hs2]

@Graeme: I'm also using a static 'old_buffer_name' with '_switchbuf' and my own 'hs2_toggle_buffer' command to achieve that.
I started with it a long time ago b/c it's indispensable for me especially when not using the '1 file/window' setup as I do.
I can't remember why I don't use the 'old_buffer_name' argument of the '_switchbuf' callback - maybe it wasn't always set as expected. So in fact I'm using the current buffer props and handle the 'old_buffer_name' myself. At the beginning I was only looking at the behaviour of next/prev-buffer where the new buffer is already activated when '_switchbuf' is invoked so I've written the macro stuff in a way relying on that.
Unfortunately 'goto/pop_bookmark' behave differently. I applied this (compatible) patches to these functions and everything is fine since that time
IMHO the _switchbuf callback should be invoked AFTER the new buffer is activated by default. Given that it's much more useful.
HS2
patches (v12.0.3 r31):
pushtag.e

Code: [Select]

   ...
   // HS2-CHG: now switch_buffer is called AFTER begin_select() so the (new) buffer is already activated
   switch_buffer(old_buffer_name,'',swold_pos,swold_buf_id);
   return(status);
bookmark.e

Code: [Select]

      ...
      // HS2-CHG: now switch_buffer is called AFTER begin_select() so the (new) buffer is already activated
      switch_buffer(old_buffer_name,'',swold_pos,swold_buf_id);
      message(nls('At Bookmark %s',bm_id));
In addition I changed set_switch_buffer_args() a bit:

Code: [Select]

      old_buffer_name=(p_DocumentName!="")?p_DocumentName:p_buf_name;
      // HS2-ADD: also handle 'Untitled<NN>' buffers
      if (old_buffer_name == '') {
         old_buffer_name="Untitled<"p_buf_id">";
      }
resp. (below):

Code: [Select]

         old_buffer_name=(wid.p_DocumentName!="")?wid.p_DocumentName:wid.p_buf_name;
         // HS2-ADD: also handle 'Untitled<NN>' buffers
         if (old_buffer_name == '') {
            old_buffer_name="Untitled<"wid.p_buf_id">";
         }


[jbhurst]

@Graeme:

I don't get it. This is exactly the behavior I have with smart next-window. If I'm looking at buffer 1 and the last buffer I was looking at was buffer 2, I press Ctrl+Tab (next-window) and I get buffer 2. If I then press Ctrl+Tab again, I'm back in buffer 1.

Note: I release the Ctrl key between invocations. If I hold down Ctrl, then repeat presses of Tab take me through the list of windows, in order of most recent use. It's pretty much the same as the way Alt-Tab cycles through most recently used applications in Windows.

The only time I tend to use prev-window is for the odd case I mentioned where I open more than one file at the same time using the File Open dialog -- in that case SlickEdit for some reason puts most of the newly open files at the end of the MRU list, and prev-window is the quickest way to get to them.

However, usually if I want to get to a buffer and I'm not sure where it is in the MRU list, I simply use list-buffers instead.

Regards

John Hurst
Wellington, New Zealand

[hs2]

Right John, smart next-window is fine but only when using mult. windows i.e. 'One file per window' checked'.
Unfortunately there is no corresponding functionality in single window mode.
HS2

[jbhurst]

Hi hs2,

OK sorry, I should have realised you guys were talking about single window mode.

One of the things I never could figure out was how to get a command to move the focus between two buffers in the top and bottom "windows" when I have the screen split with hsplit-window.  As I understand it, the problem is that it's an illusion that there is a top and bottom window. Just as when working with "one file per window" it actually looks like there is only one window (if you do as I do and maximize the MDI child window).

John Hurst

[Graeme]

OK sorry, I should have realised you guys were talking about single window mode.

One of the things I never could figure out was how to get a command to move the focus between two buffers in the top and bottom "windows" when I have the screen split with hsplit-window.  As I understand it, the problem is that it's an illusion that there is a top and bottom window. Just as when working with "one file per window" it actually looks like there is only one window (if you do as I do and maximize the MDI child window).

HS2, thanks.


John

Thanks for the info about Ctrl-tab.  It never occurred to me that holding down the Ctrl key would make any difference so when I originally tried the smart next window thing I probably held the Ctrl key down, (as I did last night when testing this again).  I see it's mentioned in the help under smart next window config option but I probably never read that.

Regarding split screen - I'm not sure why you think it's an illusion that there's a top and bottom window.  With one file per window turned off and smart next window enabled, next-window does alternate the focus between the two windows (as you would like)  - don't know what happens wiht one file per window turned on.  With one file per window turned off, when I use split screen, slick does actually create a second window, so you get two windows in the window list and you have to use the Window -> one window command to get back to one window.  I think I'll stick with one file per window mode turned off for now.

Graeme