You could run the following command to get the info shown on the status bar
- or run the "explore" command - tools -> OS file browser.
_command void xsfdate_time() name_info(',')
{
if (_no_child_windows()) {
return;
}
_str fname = _mdi.p_child.p_buf_name;
message(strip_filename(fname, 'PD') :+ ' ' :+
_file_date(fname, 'L') :+ ' ' :+ file_time(fname) :+ ' ' :+
strip_filename(fname, 'N'));
}
Thanks Graeme.
But the issue for me is, I don't have time (or the interest) to look up cryptic command lines for every little editor function. Instead, I just "bop-over" to Boxer do the utilitarian editor task and come back to SE. I do this 10 times a week or more. In fact, I'm writing this response in Boxer. I turned on Visual Wrap and it asked me if I want to retain or delete the trailing spaces. I didn't have to look anything up. Don't get me wrong. SE is much more powerful than Boxer in many areas (Project management, symbol search, etc). But for editing a file, Boxer has so many easy-to-use utilities built in to the menu system. I think SE probably has some of the features I want but they are not exposed in the UI.
I want a toolbox full of tools that are easy to access, ring compressors, valve spring compressors, wrenches, etc. Yes, I can put a socket over the valve retainer, smack it with a hammer, and pop the valve keepers out. But, I would rather just use a valve spring compressor from the tool box. I can cut a slot in a box-end wrench but I would rather just grab a line wrench from the tool box.
This is the reason that I am still on v2011. For example, v2014 came out with multiple cursors. I have been using the same feature called Power Columns in Boxer for 10 years.
** I DO like the command line for a small subset of tasks that are performed often. It is a very powerful feature!
==========================================
The other answer for SE is often, "Write a macro". There are a couple of issues with this.
--------------------
1) I don't stay familiar enough with the macro language, syntax, and command set to do it quickly.
2) It detracts from the editing I was trying to do (say sort lines by date,length, whatever).
3) Macros are not part of the help file so they are not documented unless the user puts good notes in the source.
4) Because macros are not part of the product proper, they are not listed under menus and context menus that make sense.
5) Getting macros from other users is great but again #3 gets in the way. Was that compare region that I got from Graeme last year limited to 50 lines? I don't remember. Go to the forum and find the old post or look in the source.
6) I don't want to write the editor myself. Hey, I can use Notepad & Perl if I want to create the functionality myself. SE sometimes seems like an old Heathkit television project. Of course, I'm being facetious about with the Notepad\Perl comment, but it makes the point.
7) Macros are great for business logic. But, SE is a very mature product and should have useful editing utilities built in without looking up cryptic commands and resorting to macros.
==========================================
I see 4 categories of SE users. There are probably more, but from my vantage point, this is how it seems:
--------------------
1) Hard-core editor users\enthusiasts. That is, those who really love or have the patience to take the time to learn the editor inside and out. I used to be quite like that back in the DOS and early Windows days with Boxer Tko and Brief.
2) Those who program in languages other than C, C++, C#, VB, HTML, etc. Languages that are supported by SE but not so much by other editors.
3) Non-Windows users. The cross-platform capability of SE is very compelling in this case.
4) Non-hard-core Windows only users. In my case, add primarily embedded programming. The value proposition for these users is much weaker.
==========================================
I fall into category 4. I work with 4 other developers that are also in the same category. In fact, they are still using CodeWright, have not written scripts in it and think I'm crazy for even taking the time to post about an editor. So, I would rate them a 4-minus. But, they crank out code.
(Unfortunately, some functionality of CW is broken on 64-bit systems so they are looking for a replacement.)
Years ago, I was a catagory 1. I am sometimes disappointed that I am not into that anymore. I used to be a hands-on-the-keyboard, no mouse user. Now, schedules are too tight, tool applications are so rich, and I use too many tools with their own UI, that I am not willing to become an expert in all of them.
That includes CodeWarrior (v5;v6;pre-Eclipse) for legacy support, CodeWarrior Eclipse, Code Composer (v2.2,3.3,pre-Eclipse) for legacy support, Code Composer Eclipse for current product development, Beyond Compare (licensed user for years), Boxer (legacy user and easier to use for editing utilitarian tasks than SE), Visual Studio, Microchip very sporadically, SlickEdit, & DiffZilla (if I ever get around to working with it).
Further, I considered buying the SE plug-in for Eclipse. However, in Code Composer's case, once you switch to the "Debug perspective" it will not use the SE plug-in so I am still stuck with two UI's. I have not tested this but read it over at the Texas Instruments forums. Further, when users have issues with CCS that are using the plug-in, the first thing the staff tells them is to un-install the plug-in and see if it fixed the issue. Thirdly, buying another license is more money. Lastly, I still have to turn to Boxer too often.
So, currently, I bounce between CCS Eclipse, SE, and Boxer all day. As I become more used to the Eclipse, I consider just dropping SE out of the mix.
Where this ends is with market share and the value of that market share for SlickEdit. It may be that category 4 users are only a sliver of the market that will actually pony up money for a license. What market percentage do Category 4 users represent? 1%, 2%, .5%, or 5%? That market may be to small to invest in considering feature specification, code implementation, documentation and support. If that's the case, I certainly respect that. A business needs to know it's market and limits.
SlickEdit is still deep-seated in its early command-line power-user roots. For the category 4 users, the learning curve is too steep.
