Author Topic: Easier File Navigation  (Read 11451 times)

dfrobison

  • Community Member
  • Posts: 6
  • Hero Points: 0
Easier File Navigation
« on: October 18, 2006, 03:05:31 pm »
I have a solution file that consists of 100+ projects and 6000+ files spread over a large number of folders. In VS2005, I'm using a plugin called Whole Tomato that makes finding files and bring them into the editor simple and easy. I've been a slickedit user for years and still struggle with easily finding a file. Is there an easy way to find files? Navigating with the project/file tab is time consuming. What I'm looking for is a location where I can type in parts of a file name that exist in a solution and dynamically have a list displayed of those files that match. I can then choose the file from the list for editing. Today, does SlickEdit have a similar capability?

alex

  • Community Member
  • Posts: 64
  • Hero Points: 6
Re: Easier File Navigation
« Reply #1 on: October 18, 2006, 03:27:03 pm »
I'm interested in this problem as well.  project_load does an OK job of this and brings up all of the files in the current workspace, but it's *slow* because it doesn't seem to cache files that it finds (maybe someone can hack this together?).  You can have it load only the files for the current active project by passing in the -p flag.  I have this macro:

Code: [Select]
_command void project_load_only_in_active_project() name_info(MULTI_FILE_ARG ','VSARG2_REQUIRES_PROJECT_SUPPORT)
{
   project_load( "-p" );
}

This is generally extremely fast.

If you have most of your active files open in buffers (I try to do this), you can use the code I posted at this thread: http://community.slickedit.com/index.php?topic=468.15

It lets you type buffer names to navigate to them, but you can also type any subsequence of characters instead of having to type from the beginning of the name.

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Easier File Navigation
« Reply #2 on: October 18, 2006, 04:13:41 pm »
You can do that with File > Find File. Use wildcards in the search pattern, like "*chart*" to find all files with "chart" in the filename.

Let me turn this around, though. Why do you want to open a file by its file name? Most editors are file-centric, meaning that you have to track down which file contains a symbol (function, class, etc.) and then manually open it. SlickEdit is symbol-centric, meaning that you focus on logical definitions and uses of symbols rather than the physical distribution of those elements to files.

I almost never open files using the filename. The reason I need to open another file, typically, is because I'm looking for the definition of a function or class, so I use Ctrl+Dot (in CU emulation, push-tag is the command) to jump from the use of a symbol to its definition. Or I might want to see all the places a symbol is used, so I use Ctrl+/ to list the references (push-ref). If I'm just looking around for a symbol, I can type the symbol name into the Symbol tab and it will display where matching symbols are defined. I can also search for matches using the Classes tab. Using these facilities I can preview locations in the Symbol window or have SlickEdit automatically close a window if I navigate there but don't make any changes.

I wonder if this difference in work patterns underlies why some people request that we provide multiple rows of buffer tabs. I think they must be using File > Open or a similar mechanism to edit files rather than navigating their using one of our symbol mechanisms.

My purpose in posting this is to better understand your work patterns and try to determine if this is a case of SlickEdit needing to add additional capabilities or if users are not making full use of the capabilities we have.

--Scott

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5957
  • Hero Points: 467
Re: Easier File Navigation
« Reply #3 on: October 18, 2006, 04:51:37 pm »
The project/workspace Load Files dialog really needs to be a tool window.  Then the files would be cached.

hs2

  • Senior Community Member
  • Posts: 2752
  • Hero Points: 291
Re: Easier File Navigation
« Reply #4 on: October 18, 2006, 05:47:06 pm »
This is exactly the reason why I 'adopted' project_load to support an initial (optional) filter on cmdline which helps a bit (as a coarse pre-selection).
And I added a (toggle-)filter feature to the list box with the workspace / project files itself to narrow/expand the list.
Again my beloved list-* macros ... ;)

@SlickTeam:
I think it's highly appreciated by many users if the 'list-' fct.s would get an improvement as our projects getting larger and  laaarger and not everything can be done by tag lookup.
Sometimes you just have to struggle with stupid, huge file lists :(

HS2

Phil Barila

  • Senior Community Member
  • Posts: 742
  • Hero Points: 61
Re: Easier File Navigation
« Reply #5 on: October 18, 2006, 06:18:03 pm »
I almost never open files using the filename. The reason I need to open another file, typically, is because I'm looking for the definition of a function or class, so I use Ctrl+Dot (in CU emulation, push-tag is the command) to jump from the use of a symbol to its definition. Or I might want to see all the places a symbol is used, so I use Ctrl+/ to list the references (push-ref). If I'm just looking around for a symbol, I can type the symbol name into the Symbol tab and it will display where matching symbols are defined. I can also search for matches using the Classes tab. Using these facilities I can preview locations in the Symbol window or have SlickEdit automatically close a window if I navigate there but don't make any changes.
I only use the project browser to open a file when I'm starting from a clean state.  I use Ctrl-Dot, Ctrl-Comma, and Ctrl-Slash constantly.  However, I tend to leave things opened once I've modified them, and over time, I get more windows opened than is possible to contain in a one-row tab bar.  I don't always use Ctrl-Comma to return to where I was before for a while, and sometimes the file I want to get to is way over at one end of the tab bar, and the current one is all the way at the end.  So I have to scroll through the tab bar to get where I want.

All that said, Scott, I will be very unequivocal about this.  Your faithfully paying customers have made it clear that a multiple-row tab bar is important to them.  I know it's "them", and not just "me", because you said as much in a voice conversation sometime when v10 was the latest release.  Therefore, a multi-row tab bar is now important to you.  It doesn't matter that the users can change their working habits so they don't need it.  That's users adapting to the tool.  Does that remind you of anyone?  Does that rememberance evoke good feelings?  Or do you want to remain the bunch with the best editor available by giving your users what is important to them, and keeping it adapting to us like it always has?

hs2

  • Senior Community Member
  • Posts: 2752
  • Hero Points: 291
Re: Easier File Navigation
« Reply #6 on: October 19, 2006, 06:33:57 am »
@Slickteam:
... And for those who don't like 'tabs' (e.g. no-mouse users) an improved 'list-buffers' (again - sorry) as already mentioned a few times would be fine.
Meanwhile I've seen an increasing number of posts related to 'How to handle a bunch of open buffers more elegant ?'
It would be really great if this would be added to your 'things to think about list' ...

Thanks a lot,

HS2

asipe

  • Senior Community Member
  • Posts: 113
  • Hero Points: 4
Re: Easier File Navigation
« Reply #7 on: October 19, 2006, 02:45:01 pm »
Having just started using SE, I've also found the lack of easy to use file navigation a problem.   

I like the idea of navigating by symbols, but there are a lot of times when this doesn't work (configuration files, log files, xml files, templates, etc.... the list is huge).   There are also a lot of times where I want to open something that may not be part of the project.   Another problem is that the symbol support is lacking for a lot of languages.  I do like the fileman utility and am using it more and more, but it does require that you know something about what you are looking for, it isn't good for browsing.

I also don't like the idea of the tabs (or multiple row tabs) - regardless of how tabs are laid out, they don't support more than a few buffers.   I'd much rather prefer a simple dropdown of all the open buffers (ala JEdit) that can easily be navigated via keyboard shortcuts.  JEdits idiom of windows is quite different than SEs, but it has some nice features for handling larger numbers of buffers.

Just thought I'd throw out my opinion :)

-andy

dfrobison

  • Community Member
  • Posts: 6
  • Hero Points: 0
Re: Easier File Navigation
« Reply #8 on: October 19, 2006, 08:02:52 pm »
You can do that with File > Find File. Use wildcards in the search pattern, like "*chart*" to find all files with "chart" in the filename.

Let me turn this around, though. Why do you want to open a file by its file name? Most editors are file-centric, meaning that you have to track down which file contains a symbol (function, class, etc.) and then manually open it. SlickEdit is symbol-centric, meaning that you focus on logical definitions and uses of symbols rather than the physical distribution of those elements to files.

I almost never open files using the filename. The reason I need to open another file, typically, is because I'm looking for the definition of a function or class, so I use Ctrl+Dot (in CU emulation, push-tag is the command) to jump from the use of a symbol to its definition. Or I might want to see all the places a symbol is used, so I use Ctrl+/ to list the references (push-ref). If I'm just looking around for a symbol, I can type the symbol name into the Symbol tab and it will display where matching symbols are defined. I can also search for matches using the Classes tab. Using these facilities I can preview locations in the Symbol window or have SlickEdit automatically close a window if I navigate there but don't make any changes.

I wonder if this difference in work patterns underlies why some people request that we provide multiple rows of buffer tabs. I think they must be using File > Open or a similar mechanism to edit files rather than navigating their using one of our symbol mechanisms.

My purpose in posting this is to better understand your work patterns and try to determine if this is a case of SlickEdit needing to add additional capabilities or if users are not making full use of the capabilities we have.

--Scott

I'm not one that likes multiple rows of tab buffers--it takes up a lot of space and I still struggle to find what I'm looking for. I would like, however, an easier way to get back to a buffer. I work in a file centric mode instead of a symbol centric mode. We have file naming conventions that provide a very quick way of narrowing things down. One of the main issues with a symbol centric mode is performance. I have found that SlickEdit can take a loooong time to show symbolic information. I've gotten to the point where I've just turned it off because it disrupts my train of thought. The other issue is correctness. As new symbols are added, it takes time to recognized them and some symbols are not properly parsed--C++ is a complex language. When an editor feature gets in my way or hinders my work, I disable the feature. I have learned that a quick way of finding files enhances my productivity more than symbol searching. I use VS2005 with the WholeTomato plugin to get to my files quickly. I've started editing more and more in VS2005--file navagation is easier. When I need to do a large amount of editing in a file, I then edit in SE. I'd perfer to work in SE more but file navagation has become a real issue for me.

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Easier File Navigation
« Reply #9 on: October 19, 2006, 08:32:23 pm »
Another excellent thread!  Thanks for all the feedback.

@dfrobison:
I meant to say "Search > Find File". Did you find that? Did it take care of what you were looking for? What facilities do you use in VS2005 that makes file navigation easier?  Can you give me specific examples of when the symbol look-ups were slow? We're still looking into this and trying to pin down cases.

Here are some things you should try in SlickEdit:
  • Use pushed bookmarks to create a stack of locations (Search > Push bookmark or use the push-bookmark command). You can return to a previous location by popping the bookmark (Search > Pop bookmark, pop-bookmark, or Ctrl+,). This is the same mechanism we use for the Ctrl+. and Ctrl+/ navigation (assuming CUA emulation, push-tag and push-ref, respectively).
  • Cycle through buffers/windows with next-buffer and prev-buffer and next-window and prev-window. These do the same thing if you have selected "One file per window" on Tools > Options > General, General tab. Bind these to keys to make this faster using Tools > Key bindings.
  • Experiment with turning "Smart next window" on/off. This can change how the next-buffer and prev-buffer commands work.
  • Try opening files using the e command. This will provide completions as you type. Define a directory alias for the working directory and use Ctrl+Space to expand it. You can see an example if you type "e ma" followed by Ctrl+Space. We have a predefined directory alias for the macro directory in SlickEdit. To define a directory alias, select Tools > Options > Aliases and then select "alias.slk" from the list. There are a couple of directory aliases already defined which should serve as examples.
  • You might also try using the File Manager. Select File > File manager > New file list. This will create a directory listing view in a buffer. You can then select a file for editing using the arrow keys and pressing Enter or by double-clicking. Navigate directories the same way. Right-click to bring up the context menu for tons of options on filtering and sorting. I haven't used this a lot, but I've seen Clark fly around the computer using this.


@hs2:
This is definitely on our "things to think about" list. Certainly our particpation in this thread is evidence of that.

@Phil:
I'm definitely convinced there is enough demand to make mods to the File tabs. But instead of just implementing requests, I think it's important to understand the work habits that motivate them. By doing so we can develop mechanisms that truly improve the process of editing code. Without doing this, we become nothing more than a collection of features available in other editors.

@Everyone:
Please don't interpret any of this conversation to mean that we don't care what you want. We do. As you can see from this one thread, though, there is almost always a difference in opinion on what should be done. Some say enhance the file tabs, and others say they don't use them.

We have a limited amount of development resources, and I have to decide where to put our time. Do I have someone work to add multiple rows of file tabs or do I have that person work on a better mechanism to search for files in the workspace that are not yet open? At this point, I'm not sure whether I can fit either in the v12 schedule. So if I can only do one, which do I pick?

That's why I ask about your work habits. I need to understand why you need a feature and not just that you need it. That way I can determine if there are work-arounds. Often, we must delay work in one area where we think there is a reasonable work-around to address another area where there isn't one.

Sometimes, the best answer is for the user to learn a new way to work. The limitations in other editors (or any tool for that matter) often cause people to develop inefficient work patterns. Over time, repetition becomes familiarity, and familiarity becomes preference. So, a person's preference for file tabs, as an example, may be because that truly is the best way for them to work with multiple files, or maybe it's just the best mechanism available in a previous tool. Looking at how the new tool addresses the same need may introduce you to a new mechanism that is more efficient.

I have created another topic to discuss the specifics on multiple rows of file tabs: http://community.slickedit.com/index.php?topic=572.0

Please continue to use this topic for more on file navigation. Thanks, everyone, for your contributions! Now, I need to go soak my aching fingers.   ;)

--Scott



dfrobison

  • Community Member
  • Posts: 6
  • Hero Points: 0
Re: Easier File Navigation
« Reply #10 on: October 19, 2006, 10:07:35 pm »
An example of easy file navigation is found at www.wholetomato.com. They have a free trial period. You should download it and use it against a large project. They cache up all the file names in the solution file. The first time searching is slow but once that's done it's fast. It also does partial name match which I find very helpful. Since it works in a tab, there are no modal issues. That is unlike the "Open->Find File." It's a modal dialog. It doesn't cache up results so it is slow on every search. It requires a file spec and the dialog is not re-sizable so I need to do a lot of scrolling. The SE "file tab" would be the perfect place to put this feature. I know that I can use bookmarks (and I do) and directory aliasing. Once you see how easy it is WholeTomato, you just can't go back.

Slow symbol lookup--Many of our classes use the "Pimpl Idiom" as discussed by Herb Sutter (Exceptional C++). When the main class is trying to look up a symbol going through the Pimpl class (m_pImp->), it takes anywhere between 15-30 seconds to show the list. No matter how I've tries to optimize the performance with different settings, it just doesn't make any difference. I've finally turned the feature off because it is so bothersome.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5957
  • Hero Points: 467
Re: Easier File Navigation
« Reply #11 on: October 20, 2006, 02:54:15 pm »
@dfrobison Are you looking for a tool window implementation of our Load Files dialog with some enhancements like wildcards and maybe regex support (multi-select might be handy)?

Scott H

  • Senior Community Member
  • Posts: 240
  • Hero Points: 9
Re: Easier File Navigation
« Reply #12 on: October 20, 2006, 03:28:51 pm »
An example of easy file navigation is found at www.wholetomato.com. They have a free trial period. You should download it and use it against a large project. They cache up all the file names in the solution file. The first time searching is slow but once that's done it's fast. It also does partial name match which I find very helpful. Since it works in a tab, there are no modal issues. That is unlike the "Open->Find File." It's a modal dialog. It doesn't cache up results so it is slow on every search. It requires a file spec and the dialog is not re-sizable so I need to do a lot of scrolling. The SE "file tab" would be the perfect place to put this feature. I know that I can use bookmarks (and I do) and directory aliasing. Once you see how easy it is WholeTomato, you just can't go back.

The SlickEdit Tools for Visual Studio 2005 product has a feature similar to Load Files.  The VS Tools dialog has a more robust filter which allows you to do partial matching, like you talked about. For example, entering impl will reduce the listing to files with the string impl in the file name.  Likewise, entering impl*.cpp will only show CPP files with impl in the name. You can filter based on just the file name, or the whole file path.  I ran it with an 800 file solution and it was very responsive.  Just wanted to let you know that we offered similar funcitonality for Visual Studio, as well as a lot of other great features in the same product.

dfrobison

  • Community Member
  • Posts: 6
  • Hero Points: 0
Re: Easier File Navigation
« Reply #13 on: October 23, 2006, 04:11:23 pm »
What I'm looking for is to stay within the SE evironment and quickly access my files. I already have an addin for VS2005 that gives me what I want.

hs2

  • Senior Community Member
  • Posts: 2752
  • Hero Points: 291
Re: Easier File Navigation
« Reply #14 on: October 24, 2006, 08:07:52 am »
The VSTools feature sounds promising !
Please port it also to SE w/ i-search support for the listed files and I can throw away my SE patches for this ;)
Please take into account that i-search should also accept a leading wildcard (e.g. '*') to be able to skip common (filename-)prefixes.

HS2