Poll

How often do you use the SlickEdit file manager?

Frequently
7 (13.5%)
Moderately often
5 (9.6%)
Occasionally
7 (13.5%)
Rarely
13 (25%)
Never
20 (38.5%)

Total Members Voted: 46

Author Topic: Poll : File manager usage.  (Read 8497 times)

Graeme

  • Senior Community Member
  • Posts: 2300
  • Hero Points: 302
Poll : File manager usage.
« on: July 19, 2006, 11:30:58 am »

Just wondering how much the file manager is used.

(The file manager is found on the "File" menu in Slickedit.)

Graeme

nielsenj

  • Community Member
  • Posts: 7
  • Hero Points: 2
Re: Poll : File manager usage.
« Reply #1 on: July 19, 2006, 12:48:19 pm »
To be honest i never even knew it existed :)
I still choose the "rarely" option since i do a lot of development on various network connected drives, and it does seem a lot faster than the standard windows explorer.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4690
  • Hero Points: 378
Re: Poll : File manager usage.
« Reply #2 on: July 19, 2006, 01:55:21 pm »
Ok, I'm not the average SlickEdit user :)  I use it very often.  Usually I use it to do something simple like find a file, check a file size, see which files were the last ones modified (type "fsort d" on the command line), or remove some large files when cleaning up disk space (type "fsort s" on the command line).

Some of the operations I use it for are operations that can't be done with Windows Explorer like creating a file with a list of filenames or executing a macro/external program on the select files.  I almost always use Windows Explorer to do recursive file operations because I don't want to type directory names and possibly make a mistake.

mark

  • Community Member
  • Posts: 9
  • Hero Points: 0
Re: Poll : File manager usage.
« Reply #3 on: July 21, 2006, 11:54:00 am »
Depends what you call the File Manager.

I use the dir command all the time. Using it with aliases makes it even more productive. e.g. hit the esc button to bring up the command line and then type in dir c:\ This will show a list of files in the window. Move the cursor to a directory and you can drill down. Move the cursor to a file and you can open it.

I have a couple of customisations a) that only show the file name rather than the full path, b) allow navigation back up the directory tree, c) always show the file list in date descending order - that way what has change recently is always near the top.

Cheers
Mark

magpie

  • Senior Community Member
  • Posts: 100
  • Hero Points: 5
Re: Poll : File manager usage.
« Reply #4 on: July 26, 2006, 05:43:42 am »
 :-* Fantastic Mark, I had no idea that feature existed !

I think a file manager of some description is important, and I do use the more GUI-like one when exploring someone elses code that I don't have a .vpj for. However I have found it very limited compared to launching
Windows Explorer, and normally use Explorer, dragging files into SlickEdit to view them.

If it was a tree view I would use it more often. Also it would be good to be able to set the root of that tree, as it could be deep into the file system, or have long folder names.

An easy solution would be to simply show a Windows Explorer view in that pane of SlickEdit. IMHO that is superior to a floating seperate Explorer window, plus it would give access to TortoiseSVN. However there could be SlickEdit-specific features that could be hard to implement in such a view.

mrothman

  • Senior Community Member
  • Posts: 120
  • Hero Points: 1
Re: Poll : File manager usage.
« Reply #5 on: July 27, 2006, 05:51:21 pm »
I wrote a macro to use the file manager to search for write-able files in my copy of our code base.  This is a pretty good proxy for what I'm currently editing when I'm working on a large refactoring project.  I probably use that macro once a day at least.  Also makes it easy to create the file to submit the changes when I'm done.

(The macro was necessary only because there are a fair number of auto-generated files in the code base that are always writeable, and I needed to exclude them).

I also use it occasionally for large search and replace efforts.

It's one of those features that I keep having the feeling it would be even more useful if I had the time to explore all the things it could do for me, so I certainly think it's a Good Thing.

Dan

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2290
  • Hero Points: 128
Re: Poll : File manager usage.
« Reply #6 on: July 27, 2006, 07:31:54 pm »
I can't vote, but just to chime in, I use it a lot.  Although it looks a little dated it is very powerful.

Tips:
  • Use "dir <dirname>" or "list <dirname>" on the command line, it is faster than the menus
  • Try the "for-all" and "for-select" commands when you have to perform an operation on a batch of files
« Last Edit: July 27, 2006, 07:40:17 pm by Dan »

hs2

  • Senior Community Member
  • Posts: 2737
  • Hero Points: 288
Re: Poll : File manager usage.
« Reply #7 on: July 27, 2006, 09:59:35 pm »
Right - it's super-fast and I don't need any bells and whistles when doing file-management.
And I don't need a mouse when 'exploring' my filesystem ;D
HS2

hs2

  • Senior Community Member
  • Posts: 2737
  • Hero Points: 288
Re: Poll : File manager usage.
« Reply #8 on: July 30, 2006, 09:38:10 am »
I've forgotten to refer to my fantastic k_context_menu macro contained here  ;)
http://community.slickedit.com/index.php?topic=171.0
Bind it to a key and you get an add. boost also when using fileman - at least as a keyboard-only-user.
@SlickTeam: Would be a great idea to check the causing event in the official context_menu and if it's not the RMOUSE button please impl. the text cursor aligment as I did. It's really powerful (I think).
HS2

Andrew

  • Community Member
  • Posts: 12
  • Hero Points: 0
Re: Poll : File manager usage.
« Reply #9 on: February 08, 2007, 04:09:23 pm »
I use the File Manager constantly.

I was a point-and-click software developer for 10 years until I *truly* discovered the keyboard. I switched to EMacs\Epsilon @ five years ago (not by choice, many others on the team were using it), and learned to love the speed at which I can drive an editor with the keyboard. I'm now switching to SE since it has a larger installed and support base.

I should point out that I use symbol-based lookups in combination with file-based lookups. I've seen debates on this forum where people champion one over the other. I'm trying to use symbol-based lookups more but don't feel like it's the only solution, or that things should be either-or. Sometimes, you want to bring up a file, other times, chase a symbol.

I like this editor, but have had to wrestle with it a bit to make File Manager behave the way I'd like.

For starters, it's important to me to be able to navigate at a command prompt within the process buffer because I have DOS aliases I'd prefer to use (universal, whether I'm in SE, or not), and don't want to create a second set of aliases within SE (I'd imagine the same goes for users of BASH or other shells). As an aside, I LOVE the fact that the .process buffer isn't so "tightly coupled" with the editor (async) but wish it were more "tightly integrated", if you know what I mean. That's what I'm working towards.

One macro I wrote set the SE current directory to the directory at my .process buffer prompt. Another macro invokes this first one, then dir(). So I can CD to a directory in my .process buffer, then invoke a hotkey to bring up a File Manager listing, if I choose.

Clark or Lee, I also made a minor change to edit() so that, if a directory is returned from prompt() as the filename, you don't get an "invalid file" message, instead a File Manager listing is displayed. I think this would be a real value add for SE that wouldn't have any deleterious effect on existing users.

I also made some innocuous changes to the SE edit(), prompt(), and get_string() macros that provide optional behavior without breaking existing users. These optional parameters allow a caller of edit() to provide an initial value (rather than use previous value) and disable highlighting (which places cursor at end).

Another macro I wrote leverages these changes to set the current directory to the .process current directory, and populates the edit() window with this path. The user can then press 'Enter', bringing up a File Manager listing, or can start typing a file name at that directory (invoking file completion, etc...), or can backspace up the path, and so on.

These changes really helped me integrate the current directory of my .process buffer with the File Manager listing in SE. If anyone wants to know more, let me know, I can provide these three very short macros, and my (very minor) edits to edit()  :)

BTW SlickEdit developer guys - the existing macros provided by SlickEdit can oftentimes be made more extensible simply by adding optional parameters for various things and maybe providing for callbacks, so that a user could override behavior internal to an existing SE macro by implementing a small macro of their own. It sucks to have to change SE-provided macros because then you need to port your changes forward when you upgrade.

buggyfunbunny

  • Senior Community Member
  • Posts: 233
  • Hero Points: 4
Re: Poll : File manager usage.
« Reply #10 on: February 08, 2007, 04:35:29 pm »
For reasons I've not attempted to analyze, I still find it more intuitive and easier to do searches (either on filename or contents) from Windows Explorer (win2K).  Since the files in question will be launched by SE, a double-click opens it/them.  Have the SE team ever done any testing about such?

Graeme

  • Senior Community Member
  • Posts: 2300
  • Hero Points: 302
Re: Poll : File manager usage.
« Reply #11 on: February 08, 2007, 09:24:06 pm »
Quote
BTW SlickEdit developer guys - the existing macros provided by SlickEdit can oftentimes be made more extensible simply by adding optional parameters for various things and maybe providing for callbacks, so that a user could override behavior internal to an existing SE macro by implementing a small macro of their own. It sucks to have to change SE-provided macros because then you need to port your changes forward when you upgrade.

Interesting thought.  Do you have any examples?

Slickedit macros already often have a lot of parameters and I suspect taking a guess at what end users would like to customise would be quite hard.

You can actually override slickedit macros already.  Take a copy of the macro you want to replace, put it in a macro file of your own, customise it and load it.  The new macro overrides the SE version of the macro of the same name  - including when it's called from other previously compiled macros.  When you upgrade, you just reload your own macro files after upgrading (and having checked the consequences first).

Your macro won't be able to get at static variables/ functions in the module it was copied from.  If SlickEdit had a way of "undefining" a macro/function, you could #include the SE module in your new module, then override whatever you wanted without getting "identifier already defined" errors. 

Also, there's a tricky issue of how user macros are handled during an upgrade to do with whether they get recompiled automatically by the upgrade process - if they do, the .ex file can't be used by the previous version of slick as well as the new one, and if they don't, the key bindings get lost.

Graeme

Andrew

  • Community Member
  • Posts: 12
  • Hero Points: 0
Re: Poll : File manager usage.
« Reply #12 on: February 09, 2007, 10:58:14 pm »
Hi, Graeme.

Yes, I do this, but as you mentioned, there are some issues with the cut, paste, modify and load approach to customizing the macros that come with SE. The biggest hitch, to me, is merging SlickEdit's improvements to subsequent versions of their product into my macros (or vice versa).

I like the callback idea best but haven't thought about how this might be done, yet. So, in the meantime, I've modified some signatures to get better emacs emulation. The signatures I modified have, at most, five parameters. Not great, but not too bad.

Examples: get_string() on my local machine now does this at line 223 of get.e with the passed-through init_val parameter (which used to be a local variable):

   if (initial_value == '') {

      /* Reset command retrieval to end of buffer and get last retrieve value. */
      _reset_retrieve();
      // etc...


The _reset_retrieve() was there before, I just couched it in a conditional statement. So the user can specify an initial value into an edit() call, it'll trickle down. You could do this simple change w/o breaking existing users, and yet offer ability to specify initial value.

Here are the signatures I changed:

_command e,edit(_str filenameArg='', typeless a2_flags='',  _str auto_create_firstw_arg='', _str init_val='', boolean highlight=true)
_str prompt(_str arg1='', _str msg='', _str init_val='', boolean highlight=true)
_str get_string(_str &line,_str prompt, _str arg_type_info='', _str initial_value='', boolean highlight=true)

I could give you the "highlight" modification to get_string(), too, if you'd like. Also, I believe I've added emacs-like fileman navigation and i-search (see "Anyway to paste search string in emacs Emulation" post) without breaking anything, I could email you the changes, and my macros that use them, if you're interested, that might be better than cluttering up this post with yet more script :)

Phil Barila

  • Senior Community Member
  • Posts: 742
  • Hero Points: 61
Re: Poll : File manager usage.
« Reply #13 on: February 10, 2007, 03:00:36 am »
You could just attach your modified scripts and let us download them and peruse them at our leisure, you know...   :D

Andrew

  • Community Member
  • Posts: 12
  • Hero Points: 0
Re: Poll : File manager usage.
« Reply #14 on: February 12, 2007, 02:52:23 pm »
Sorry, hadn't thought of that :) Here you go...