shell macro seems not working in v19

[rowbearto]

Hi:

Below is my "cb.e" macro that I use successfully in v18. It invokes a script in my HOME directory called "cbl".

This macro no longer seems to work in v19 - I see that the script it invokes ($HOME/cbl) is not executed.

I use this macro under SE Linux version.

Contents of the macro are:

#include "slick.sh"

_command void lrd_cancel_build() name_info(','VSARG2_REQUIRES_EDITORCTL|VSARG2_READ_ONLY)
{
    shell(get_env("HOME")"/cbl");
}

When I invoke "lrd_cancel_build" after pressing 'esc', I can tell that my script $HOME/cbl is not getting executed.

This worked fine in v18, but it is not working in v19 beta 6.

[Clark]

Reproduced. Thanks for reporting this.

[rowbearto]

Thanks!

[Clark]

Fixed in next build

[Clark]

You may wonder how this got broken when according to things we've posted, there are supposed no changes in this area.

v19 has a totally new run-time toolkit that all of SlickEdit's code is based on. This includes strings, XML, file I/O, socket handling, process handling, regular expressions, collections, and a lot more. The reason we replaced so much code was so we could develop new features faster. All that's seen from the users perspective is some new file I/O features and roughly XPath 1.0 support in the _xmlcfg_XXX macro functions.

The new regular expressions are only used internally and are not used by search and replace. However, the new regex engine will be used in the future. Not sure if the new regex engine will make v20 though. The record file editing must be rewritten before we can use the new regex engine.

[Graeme]

So is that the reason there have been a lot more bugs reported in the beta testing than normally?  I've been wondering what was causing that.  Is it the Qt toolkit? 

I'm also wondering how you changed "single instance" toolwindows into multi-instance toolwindows.  Was that much of an effort?

[Clark]

So is that the reason there have been a lot more bugs reported in the beta testing than normally?  I've been wondering what was causing that.  Is it the Qt toolkit? 

I'm also wondering how you changed "single instance" toolwindows into multi-instance toolwindows.  Was that much of an effort?

Definitely NOT the Qt toolkit. The Qt toolkit is pretty good but we needed custom classes for what we do here. For example, our String classes are totally kick XXX. Not only fast but extremely rich with built-in automated encoding translations (Utf-8, Active code page, wchar_t, Utf-16 -- Regex support too). Easier to use than C#.

Not that many of the bugs have been related to the new tool kit (a few File I/O issues and shelling-- I think that's it). I think people have noticed how fast we're making fixes and are reporting more problems. Many of the problems reported aren't even new (not due to either this toolkit or v19 changes).

[Clark]

We are beating up the code base quite a bit. All for long term goals (Qt, new GUI stuff, beautifiers, new toolkit, various engine changes). There are still a few very difficult hurdles to get over (multi-year work).

We don't like to just hack features in. Instead, we want all engines to be powerful and optimally designed for whatever they need to do. At least with the Qt GUI changes, it's obvious to customers that we made huge changes. Unfortunately, customers don't see much when in comes to major engine changes. Most companies out there either don't bother or let their product just die.

[hs2]

We don't like to just hack features in. Instead, we want all engines to be powerful and optimally designed for whatever they need to do.

That's what I'd call a very professional approach ! And I wouldn't expect anything less from the SlickTeam
HS2

[rowbearto]

Clark: Thanks for sharing the info. I wonder if these new engines can help with adding more threading? I'd like to see more use of multi-threading particularly for search, as I have an 8 core i7 and it would be good to utilize all the cores during a search.

[Clark]

If you mean multi-file searching, there are more issues than just threading.  For example, the stand alone sgrep.exe runs WAAAAAAY faster than the multi-file search. This may seem like any easy problem to solve but it isn't. Keep in mind, the editor searching supports color coding and encodings (sgrep.exe doesn't do any of this). Eventually, we will tackle this but there are some other big issues we need to tackle first which will get us closer to the toolset we need for this.

For large multi-file searches, I use "sgrep.exe" in the process buffer (build window) instead of the GUI. That way I get lightning speed now (single threaded in the background). I typically don't need encoding or color coding support. You can use next-error to go through the occurrences. There are times when I do need the extra power of the GUI though.

[Clark]

Here are some "sgrep.exe" examples:

sgrep -w findwordrecursive -t "*.cpp" "*.h"
sgrep "find this recursive" -t "*.cpp" "*.h"
sgrep -e "-starts with dash" -t "*.cpp" "*.h"
sgrep -c "print filenames only with count of matches" -t "*.cpp" "*.h"
sgrep "find?*this SlickEdit syntax regex" -r -t "*.cpp" "*.h"
sgrep "find.*this unix/perl syntax regex" -u -t "*.cpp" "*.h"

Note: For the next build of sgrep, the -u option will specify Perl syntax and not Unix. We are moving away from Unix regular expressions since we really never should have had the "Unix" (made up) syntax but Perl wasn't the standard is is now when we created our own "Unix" syntax.

[hs2]

@Clark: Thanks for reminding us of this gem
I should really use more often since I also love speeeeed and often simple grepping is good enough.
HS2

[rowbearto]

Clark:

Thanks for the info about sgrep. I wonder if it would be possible as an intermediate step (maybe v20) to be able to use the search GUI in "sgrep mode". So that I can use the Ctrl-F GUI dialog, which I really like, to enter in all the search criteria, and then SE translates this into an "sgrep" command and performs the search in the build window. I realize some search features would be lost (and could be greyed out when 'sgrep' is checked), such as color coding and encoding, but for a user who is used to using the GUI to pull up things like recent directories and search terms, and just likes the GUI interface, it could be helpful.

Meanwhile, I will take the time to learn the 'sgrep' interface next time I need fast searches through lots of files. Thanks for this tip!

Rob

[Clark]

That's something I've thought about doing but it's quite a bit different than what we're currently doing. In other words, it's far from simple. This would be a substantial amount of work which I would be hoping to rip out later.