"File tabs"'s order

[coolhair]

In SE2007 and SE2008,  opened file names in "File tabs" toolbar is always in alphabetical order. Some times, it is not convenience to me.
Is there anyone could tell me how to change the order by hand?
Thank you!

[Graeme]

In SE2007 and SE2008,  opened file names in "File tabs" toolbar is always in alphabetical order. Some times, it is not convenience to me.
Is there anyone could tell me how to change the order by hand?
Thank you!

You would have to change the function below (from bufftabs.e).  The call to _sort sorts filenames - the fpos_case is set to "i" for a case insensitive file system, otherwise to empty string.  If you wanted to sort the tabs in the order the files were opened (for example) you would probably need to use _switchbuf and _buffer_add "callbacks" to keep your own ordered list (I already have some code that could be adapted for this).  Similarly you could have the buffer tabs to be in order of how recently the buffer was accessed or how recently the file was modified  or in order of path/filename or some permanently fixed order that you set using a listbox with up/down mechanism, or a combination of all.

Graeme

Code: [Select]

static void maybe_sort_tabs()
{
   _str temp_data[] = null;
   int x;
   for (x=0;x<glist.tab_order._length();x++) {
      temp_data[x] = glist.buffid_order[glist.tab_order[x]].caption:+"\1":+glist.tab_order[x];
   }
   temp_data._sort('F'_fpos_case);
   typeless buf_name;
   typeless buf_id;
   for (x=0;x<glist.tab_order._length();x++) {
      parse temp_data[x] with buf_name "\1" buf_id;
      glist.buffid_order[buf_id].tabid = x;
      glist.tab_order[x] = buf_id;
   }
}


[chrisant]

I want the File Tabs to be in the order that next_buffer()/prev_buffer() will cycle through them.  That way I can see exactly how many times to press Ctrl-N or Ctrl-P to get to the buffer I want to get to.  I am one of those people who has def_one_file=''.

Thanks for the pointer to the code to modify, it's on my list of things to get around to, and if I happen to get to it before anyone else I'll certainly post what I come up with.

[Ryan]

I might be missing something, but it seems like what you want is to use next_buff_tab and prev_buff_tab instead of next_buffer/prev_buffer.  Then you don't have to worry about modifying anything.

Let me know if this helps.

- Ryan

[Dennis]

We have future plans to improve the file tabs, however, that being said, there is a very good reason that they are simply sorted alphabetically and not by buffer ring order.

Alphabetical order makes it possible to quickly find a file in the file tabs visually.  If the files were in buffer ring order you would pretty much have to scan through the file tabs linearly to locate the file you wanted.  We prototyped this many years ago when we developed the file tabs toolbar, and quickly determined that any non-alphabetical order was so inefficient and inconvenient that we just threw out the option entirely.

This has been a highly requested feature -- apparently everyone wants to try File tabs with buffer ring (aka MRU) order -- but I can guarrantee the number of people who would actually use it in that order would be very, very, very few -- seems like nobody believes me, but yes, MRU is that bad.

Our future plans for the file tabs target a much more reasonable compromise, having a very small (configurable) MRU/favorites list as well as a full list of buffers in alphabetical order as they are now.  We do not yet have a target release for these changes.

[chrisant]

@Ryan:  Thanks, I didn't realize those commands existed.
But I don't want to cycle alphabetically, I like the order that next_buffer/prev_buffer use, so I really want the tabs to reflect the same order.
When I have 20 files open and the current file is "foo", I like that no matter if the next file I open is "fpp" or "wux", prev_buffer and next_buffer will go back and forth between these two files.  Using next_buff_tab/prev_buff_tab, I do gain the ability to see how many times to press Ctrl-N or Ctrl-P, but it has the side effect of also significantly altering how many times I need to.  

@Dennis:  Visual Studio's file tabs are in MRU order.  A lot of people are probably used to that.  Personally, if I want to see the list of open buffers in alphabetical order I use the Files toolbar (activate-files-files).  I'm quite certain I want the File Tabs in MRU order.    I can see the argument for having them alphabetical, but I know from years of experience in both Visual Studio and the other editor I was using prior to SlickEdit, that as far as my personal preference goes, it is definitely strongly tilted in favor of the tabs being in MRU order.

Thanks for having this on the wish list, I think in the meantime I'll code up a function to sort it in MRU order (hopefully in the next week or so) and post it.

[Dennis]

Visual Studio keeps a working set of file tabs in MRU order, but they are more like a "top 10", because they are not re-ordered when you click on a file tab, so they do not precisely reflect the buffer ring (aka MRU) order.  Note, you really wouldn't want it to re-order the file tabs to match the strict buffer ring order whenever you switched files, that would quickly get visually annoying.  For one, your current file would always be moved to the first tab.  Nevertheless, what Visual Studio is doing is not wildly different from the redesign I had described.

[chrisant]

Good point about VS, Dennis.  I actually don't want the buffer ring reordered when I click on a file tab, though, it's another thing I'll be looking to tweak.  For 21 years I used an editor that never reordered the buffer ring unless explicitly told to.  I like the ability to reorder when I chose to, but I don't like auto-reordering as it means the keystrokes needed to get to a file are constantly changing; it confuses my fragile mental feng shui.    Perhaps this weekend I'll find time to see if I can hook up that behavior in SE.

I'm very much a def_one_file='' sort of person, and it was actually exciting for me to read this explanation in the SE docs:

• 2. Multiple files share window - With this approach, you determine how many editor windows you want and you select the buffer to display in each. You have to manually create a new editor window (typically by splitting or duplicating an existing window). All buffers are available to all windows. You can use the file tabs to select the buffer to edit, which will place the buffer in the currently active editor window. You can also use Document > List Buffers (list_buffers command) to view a list of the buffers and select one. This approach appeals to users who like a particular arrangement of windows and use editor windows for specific tasks.

I had never found the words to express why I like that behavior and why most MDI apps frustrate me, but that last sentence nails it perfectly -- and for me that extends to the ordering of the buffer ring, too.  It's great to be understood, and to see it expressed so simply and clearly! 

P.S.  You're right, by the way, I don't want the current file to always be moved to the first tab.  I intend to do processing to avoid rotating the file tabs offset into the buffer ring.  I.e. if the tabs were Xyz, Def, Abc, Mno and Abc becomes the current file, I expect Xyz to still be the first tab.  I think it shouldn't be hard to have the file tabs remain pretty much static, the only part I wonder about is whether I'll be able to block the auto-reordering behavior.  I noticed that only certain buffer activation actions cause reordering, so I think I have some leads to help me figure that out.

[hs2]

I'm really curious which editor you've used chrisant - can you tell it ?
HS2

[Graeme]

My GFileman toolbar has several sort orders, including "most recently accessed" order  - which is in order the buffers have actually been visited.  It's not visually annoying at all but it's a vertical list like the files toolbar, whereas the file tabs might be annoying because they're all different sizes and you can't see very many at once.  In GFileman, the first item in the list is always the buffer you're currently looking at if the sort order is "most recently accessed" but I can also sort alphanumerically or with path/filename/ext ordering.  Sometime I have two GFileman toolbars active, with different sort order.  I use the _switchbuf thing to keep track of the order buffers are visited.  It would be nice to have some built in support for determining the order buffers are visited because _switchbuf is not guaranteed to be reliable, though it's important to be able to switch off the re-ordering when I need to.  

I wrote my own buffer list ordering tracker because I wanted to be able to get back to the previous window visited without knowing how I got to where I am  - this was discussed here http://community.slickedit.com/index.php?topic=2573.msg10639#msg10639  - where I learnt that Ctrl-tab (with one file per window enabled) does alternate as I want as long as you remember to release the Ctrl key in between.

I guess if the file tabs displayed in true MRU order (say A B C D E) and the first tab was always the current file (A) you wouldn't be able to determine from looking at the file tabs, how many times you need to use prev-buffer to get to file E firstly because they're not in buffer ring order and secondly because the buffer ring order changes each time.  For this, you need a new command that steps along the file tabs without changing ordering, and when you've got to the buffer you want, you exit "step mode" and the buffer you're now on jumps to the front of the list (this is why I say it's important to be able to stop the re-ordering when you need to and why I have my own buffer list "ring").  

With current slickedit, using next-buff-tab is always going to change the buffer ring order (internally), so if the file tabs were displayed in buffer ring order, they would have to change when next-buff-tab was used  - but this would make next-buff-tab prev-buff-tab useless if the tabs change every time you used the command.  

I usually have too many buffers open to make stepping along file tabs a viable way of getting to a different buffer.  I use "alternate last two buffers" intensively. I also use the "step mode" I described above to step through the last few (3 or 4) buffers I've been to, otherwise the mouse (GFileman is multi-column and lets me see about 50 filenames in a single column) or partial filename entry.

It would be nice if slickedit had a way of alternating between the last two buffers visited without having to select one file per window and also be able to step through the last x buffers visited and pick one, as in "step mode".

Graeme

[coolhair]

Hi, Dennis:
  Thank you for your post!

I am a c++ programmer and I used visual studio 2003 before.
In my opinion the biggest problem of the "file tabs" order is when I open several files have similar filenames but different filetypes.
For example, a1.cpp a2.cpp a1.xml a2.xml from one project and a1.cpp a1.xml from anther, the "file tabs" is looks like this : "a1.cpp a1.cpp a1.xml a1.xml a2.cpp a2.xml". Is it the best way to show? I think it will be more comfortable if it shows like "a1.cpp a2.cpp a1.xml a2.xml a1.cpp a1.xml". By the "project order" and the "file types order". I don't require SE to do this for me, but why not just give me a chance to change the orders by myselft, just like VS2003.

Coolhair

[chrisant]

@Graeme: It should be pretty easy to hook the bufswitch/etc events and remember the previous buffer.  I had a macro that did exactly that in my other editor (i.e. to enable goto-last-buffer), but haven't gotten around to porting that one yet tho.

[hs2]

I've extracted my 'switch-last-buffer' macro I'm (heavily) using and added the 'doCenter' parameter b/c this might not be desired by other users.

Code: [Select]

/**
 * switch to the last (used) buffer
 *
 * @param doCenter   if 'true' the buffer is centered<br>
 *                   This could be useful when quick or visually comparing code snippets in 2 files.
 */
_command void switch_last_buffer ( boolean doCenter = false )
Tested with v12.0.3 and v13.0.0.

There is a problem when using 'goto-bookmark' in v12.0.3 resp. 'old-goto-bookmark' in v13.0.0.
An additional patch to 'bookmark.e' would be needed to solve it (same for v12.0.3 and v13.0.0).

bookmark.e - (old_)goto_bookmark():

Code: [Select]

   if ( bm_data != '' ) {  /* a valid bookmark was selected */
      // HS2-CHG: see below
      // switch_buffer(old_buffer_name,'',swold_pos,swold_buf_id);
      parse bm_data with bm_id mark_id .;
      status=_BookmarkGetInfo(_BookmarkFind(bm_id),
                              bm_id,mark_id,vsbmflags,buf_id,
                              0,RealLineNumber,col,BeginLineROffset,
                              LineData,filename,DocumentName
                             );
      if (status==TEXT_NOT_SELECTED_RC) {
         status=_restore_bookmark(filename,RealLineNumber);
         if (status) {
            return (status);
         }
      }
      begin_select(mark_id,true,true);
      if (p_window_state=='I') {
         p_window_state='N';
      }
      // HS2-CHG: switch_buffer should be 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));

Have fun,
HS2

[davea]

My strong personal preference would be to have both:

1) An option to display the file tabs in the order that the files were opened (i.e. with newer file tabs always appearing on the right)
2) The ability to drag the file tabs to manually reorder them

My previous favorite editor worked like #1 and allows #2. Visual Studio seems to do this as well.

I really, really miss both of these features when using SlickEdit. 

Any chance of getting these in a future release? Please... 

  -Dave A.