Replacing KEdit by UltraEdit - any thoughts?

billdehaan · Feb 14, 2012#12012-02-14T23:13+00:00

I'm a Kedit user since 1985, and unfortunately, I'm starting to run into walls because of increasing use of unicode, and a bunch of other limitations. I use the ALL command a lot, and RANGE quite a bit, too. But as much as I'm happy with Kedit, I'm having to look for a more current unicode-friendly editor; preferably one that's still being developed.

How painful was/is a translation from Kedit to UltraEdit? I've got about 30 years of KEXX macros written over the years, and pretty much every keystroke is mapped to some function or other (I even have keys that popup dialogs to remind me what functions everything is mapped to, there are so many

).

Obviously, the UltraEdit brochures show what it can do that Kedit can't, but what about the reverse? I often knock off a 20 line KEXX macro to handle some special case (like editting Wireshark telegrams that meet certain weird column-based criteria); how easy is it to do something comparative in UE?

rhapdog · Feb 15, 2012#22012-02-15T02:34+00:00

I used Xedit as well, as well as EDIT and EDGAR before it. Having learned programming on the IBM Mainframes, what else would I have used? I later picked up an editor with no name for DOS, just E.EXE. It was one of IBM's internal company programming editors never released to the public.

In 1993 I lost my copy of E, and I was unable to obtain a new copy. It was better than Xedit, and still used REXX as a scripting language.

In 1995, I picked up a copy of UltraEdit for Windows 95. It didn't do everything that my old E.EXE did, but I was pretty pleased with it, once I learned how to use it properly. The new versions of UltraEdit make E and Xedit pale by comparison. Yes, it is a whole new way of working. I hated getting away from the command line. I used to think that if you weren't doing it from the command line, you weren't a real programmer. However, I have learned that I can be much more efficient than I used to be by learning new ways of doing things.

UltraEdit has scripting language support that is very, very powerful. REXX is good, but UltraEdit uses JavaScript. It seems JavaScript is an important language to learn these days anyway. It can only help your resume to have it listed as a language that you are proficient in.

How painful was it for me to make the switch? Hey, I jumped from using DOS/DESQview, a Unix (not Linux) Server with XWindows, to Windows 95 and a Novell Server (because of the company I was working for), I was already complaining a lot.

It may be painful at first to have to get used to a new way of doing things, but rest assured, after you've had a few months under your belt learning all there is to UE and its powerful scripting language, the features, the ability to run your scripts on files from the command prompt, the ability to run command line utilities and pipe them through to be filtered into your editor and worked with... I could go on and on about the features that you will discover only after digging into it extensively, but let me tell you it will all be well worth it.

Yeah, I probably told a bit about my age telling you what I started out working with as editors, but I don't care. If someone like me can make the switch and learn to love it, you can too.

When it comes to editors that can handle the unicode properly, there is no better editor on the market. It is hands down the most powerful text editor available today, and it's on the Windows platform.

Personally, I've moved up to using UEStudio. It has all the features of UltraEdit, but adds quite a few extras to make it a full-fledged IDE instead of just the most powerful editor on the planet. Imagine an Integrated Development Environment that has an editor like that built in!

I often knock off a 20 line KEXX macro to handle some special case (like editting Wireshark telegrams that meet certain weird column-based criteria); how easy is it to do something comparative in UE?

It will be just as easy, once you learn JavaScript as well as you know KEXX. If it is simple enough to create a Macro instead of a script, you can "record" the macro, then play it back to finish your editing. I probably record and replay macros 10X as much as writing scripts, but scripts have their place for the real power.

billdehaan · Feb 15, 2012#32012-02-15T05:21+00:00

rhapdog wrote:I used Xedit as well, as well as EDIT and EDGAR before it. Having learned programming on the IBM Mainframes, what else would I have used? I later picked up an editor with no name for DOS, just E.EXE. It was one of IBM's internal company programming editors never released to the public.

Ah, yes. E, EOS2, EPM....

I contracted at IBM from 1990-1992. The funny thing was, I used Kedit before going to IBM, and by the time I was at IBM, I was using MultiEdit

. I original started with Jim Wylie's Personal Editor (remember EWS?), but it was DOS 1.x, so it didn't support subdirectories; plus, putting PE.PRO in every damn subdirectory was a pain. I started with Kedit to basically be a PE that knew about subdirectories. From there, I went to IBM, but since IBM at the time was OS/2 1.x, with a single penalty box, I switched back to Kedit for OS/2 so I could run native, and haven't looked back.

I'm considering MultiEdit again (a friend loves it), but I'm scoping out UE first. Reviews seem kinder to UE than ME. Most of what I do these days is C++, XML, Perl, and Ruby. I've downloaded the UE demo, and have played with it a bit. It's... different. I've been reading some hyper critical reviews of UE (http://fileforum.betanews.com/detail/Ul ... ll_reviews), but I've read several other glowing reviews, so I'm trying to do a fair Kedit/UE comparison.

I expect that whichever way I go, it will be painful enough that I want to select an editor that I can stick with for another 15 years before going through this again.

rhapdog wrote:I hated getting away from the command line. I used to think that if you weren't doing it from the command line, you weren't a real programmer. However, I have learned that I can be much more efficient than I used to be by learning new ways of doing things.

Kedit is considered Eastern Orthodox, UE seems more Western Orthodox (http://www.softpanorama.org/Editors/eoe.shtml).

I definitely miss the command line. The F10 in UE brings up a command window, but it's not the same.

rhapdog wrote:UltraEdit has scripting language support that is very, very powerful. REXX is good, but UltraEdit uses JavaScript. It seems JavaScript is an important language to learn these days anyway. It can only help your resume to have it listed as a language that you are proficient in.

Probably true. It certainly seems more verbose.

Compare

Code: Select all

 UltraEdit.document[index].top();
 UltraEdit.document[index].write("// Script Name: ");

to

Code: Select all

 'top'
 'text // Script Name: '

rhapdog wrote:How painful was it for me to make the switch? Hey, I jumped from using DOS/DESQview, a Unix (not Linux) Server with XWindows, to Windows 95 and a Novell Server (because of the company I was working for), I was already complaining a lot.

I remember using Desq (pre-DesqView) with X. Thankfully, I skipped Win9x and went straight to OS/2. One of the reasons I stuck with Kedit was that whether I was using DOS, OS/2, or eventually Windows NT, there was always a Kedit version. These days, DOS is pretty much a memory, as is OS/2, so compatibility with those platforms is no longer important.

I do see that UE has build in support for FTP, which is nice. Also telnet.

rhapdog wrote:It may be painful at first to have to get used to a new way of doing things, but rest assured, after you've had a few months under your belt learning all there is to UE and its powerful scripting language, the features, the ability to run your scripts on files from the command prompt, the ability to run command line utilities and pipe them through to be filtered into your editor and worked with.... I could go on and on about the features that you will discover only after digging into it extensively, but let me tell you it will all be well worth it.

Thanks. I already do a lot of that by having Kedit macros that call DOSQ and run Take Command scripts which pipe stuff back to Kedit. I work on a lot of apps that generate tons of log data (300MB is not uncommon, spread over ~100 files), so what I typically do is flag certain log conditions, tag them with a unique id (say bdh, my initials), and then have Kedit grab the 300MB file, and using ALL to see the filtered lines, expanding as required to see the state. That sort of thing is beyond most of the other editors I've looked at.

rhapdog wrote: Yeah, I probably told a bit about my age telling you what I started out working with as editors, but I don't care. If someone like me can make the switch and learn to love it, you can too.

I think any of us with Kedit 3 digit serial numbers are probably of an age.

rhapdog wrote: When it comes to editors that can handle the unicode properly, there is no better editor on the market. It is hands down the most powerful text editor available today, and it's on the Windows platform.

Not to be contrary, but have you looked at MultiEdit? It also claims to be the most powerful. I've got no dog in the race yet, I'm planning on kicking the tires of both (and maybe a dark horse called Zeus someone's mentioned: http://www.zeusedit.com/features.html). Zeus appears to be a next gen version of Brief, from back in the day. The only reason I even found it is that looking for a ME to UE comparison, the only thing close was this forum entry: http://www.zeusedit.com/zforum/viewtopic.php?t=200, which of course claims Zeus is better than either, but at least points out things about ME and UE I'll want to check).

rhapdog wrote: Personally, I've moved up to using UEStudio. It has all the features of UltraEdit, but adds quite a few extras to make it a full-fledged IDE instead of just the most powerful editor on the planet. Imagine an Integrated Development Environment that has an editor like that built in!

I've read the reviews. Someone mentioned that you're better off starting with UE than UES, since features are added to UE long before UES gets them. Also, you can move up from UE to UES, but it's more difficult to go back. I'm going to play with UE for 30 days and see how it goes.

rhapdog wrote: It will be just as easy, once you learn JavaScript as well as you know KEXX. If it is simple enough to create a Macro instead of a script, you can "record" the macro, then play it back to finish your editing. I probably record and replay macros 10X as much as writing scripts, but scripts have their place for the real power.

Thanks for the help. My problem is that almost all of my peers are of the Visual Studio generation. The idea of a standalone editor is foreign to most of them. Although some do use Notepad++ or VIM, there's no one other than me using anything else. The idea of a commercial editor is foreign to them, and anything derived from an IBM mainframe is before most of them were born. Suffice to say, talking about XEdit features really shows the generational divide. I wasn't sure if anyone had taken the plunge from Kedit to UE, but the fact that you've done it, and recommend it, is probably the best recommendation I can think of for me to invest in UE and give it a fair shake.

Thanks.

rhapdog · Feb 15, 2012#42012-02-15T15:03+00:00

billdehaan wrote:I expect that whichever way I go, it will be painful enough that I want to select an editor that I can stick with for another 15 years before going through this again.

If you want to do this long term, consider a lifetime license. That's the best way to go. Stay current. IDM is a strong company and isn't going anywhere. With the number of users they have world-wide, you will have support for your product for life.

billdehaan wrote:I've been reading some hyper critical reviews of UE http://fileforum.betanews.com/detail/Ul ... ll_reviews), but I've read several other glowing reviews, so I'm trying to do a fair Kedit/UE comparison.

These "bad" reviews are obviously from people who did not properly study or learn to use their editor. I will guarantee those complaining about slow startup didn't check to see that it was because of a slow network share, an antivirus monitoring program that was a bit haywire, or some other issue on their system. Those complaining about too many toolbars and getting lost in the options never studied about UE's Environments, where you can choose what to see and what not to see. I could debunk every criticism, but won't take time to do it here.

billdehaan wrote:Not to be contrary, but have you looked at MultiEdit? It also claims to be the most powerful.

Yes. I have. It just can't do everything that UltraEdit does. It is also considerably more expensive. For my money, UE is the best deal. They may "claim" to be the most powerful, but when I state that UE is the most powerful, it isn't just a claim from IDM, it is a claim by the People's Choice Awards, Shareware Industry, numerous magazine publications, and numerous 3rd party reviews.

If you Google for "Most powerful text editor for Windows", you will find many reviews that have a "list" of most powerful editors. I have seen "10 most powerful", "15 most powerful", "5 most powerful", etc., but have not once seen MultiEdit in a most powerful list. UE, in each of those, was stated to be the most powerful (at least the ones I looked at when I Googled this morning.)

billdehaan wrote:the only thing close was this forum entry: http://www.zeusedit.com/zforum/viewtopic.php?t=200, which of course claims Zeus is better than either, but at least points out things about ME and UE I'll want to check).

I read that just now. Zeus is laughable compared to UE. This is also an old post, and some of the things stated about UE were either in ignorance, or have been fixed since then. Not one negative he listed is currently true of UE.

billdehaan wrote:I've read the reviews. Someone mentioned that you're better off starting with UE than UES, since features are added to UE long before UES gets them. Also, you can move up from UE to UES, but it's more difficult to go back. I'm going to play with UE for 30 days and see how it goes.

This is not true. When it comes to new releases, there can be advantages to each direction. Yes, UE gets the features added first. Then with that widespread release, bugs are invariably reported (as any program as complicated as UE will have) and subsequently fixed. When these bugs are squashed, and the product is refined even further, then a few new features are usually added to UES that never made it into UE, because UES is supposed to have more features.

The time frame can be a couple of weeks, or a month, sometimes as long as 2 months. This is not a make or break time period to wait on the features to migrate over to UES, especially considering that once you get those features, they will be stable and you won't have to patch it later after being frustrated by the bug you found.

The real way you need to evaluate it is do you need to "compile" your programs from projects. If you're coworkers are using Visual Studio, and you're working from the same compiler that they are, then you'll find that once you get UES up and running, it will offer you features to handle multiple project files to allow them to interact in ways you can't do with UE.

Seriously, take a good look at the UE/UES comparison before you make a final decision.
https://www.ultraedit.com/products/uest ... ences.html

If you are going to make an investment, and take time to learn a product after you do, then you should seriously consider UES. If I were doing stuff that others were designing in Visual Studio, then I would be using UES. I'm actually using UES for Delphi 2010 replacement, and also for a number of PHP site projects. It works with the frameworks flawlessly.

Also, as far as "going back", I read recently that someone requested their lifetime license for UES be "downgraded" to UE, because they no longer needed the UES features. They were able to do so. To get the lifetime license for UES, after you have UE, you still have to pay again, although you get a loyalty discount. Something to consider. I can't imagine you doing that kind of programming and not being able to use the full power of UES, but I can see you regretting not going that route should you settle for the smaller package.

billdehaan wrote:The idea of a commercial editor is foreign to them, and anything derived from an IBM mainframe is before most of them were born. Suffice to say, talking about XEdit features really shows the generational divide. I wasn't sure if anyone had taken the plunge from Kedit to UE, but the fact that you've done it, and recommend it, is probably the best recommendation I can think of for me to invest in UE and give it a fair shake.

An excerpt from http://www.softpanorama.org/Articles/or ... tors.shtml

I would like to stress that an editor is probably the most important tool for programmers, therefore one needs to choose it wisely. A popular consideration that easy to learn editor (for example Pico or Notepad) is the best does not withstand any critique. An editor is too important tool for programmers to settle for the basic capabilities and it's a big disadvantage to select a mediocre or even primitive solution just because it's simple to learn. Any professional programmer needs a professional editor.

The main problem that I see is that people tent to stick to whatever editor they got used to first and even became emotionally attached to the "first choice".

The author argues that programmable editors are worth studying like programming languages and a powerful editor is huge advantage from the point of view of reaching high productively (and avoiding many typical frustrations).

That is good advice for anyone.

billdehaan · Feb 16, 2012#52012-02-16T00:01+00:00

rhapdog wrote:If you want to do this long term, consider a lifetime license. That's the best way to go. Stay current. IDM is a strong company and isn't going anywhere. With the number of users they have world-wide, you will have support for your product for life.

I expect I probably will.

rhapdog wrote:These "bad" reviews are obviously from people who did not properly study or learn to use their editor.

Well, just one day of testing showed me that at least the speed complaint didn't apply to me. I've not seen the "crashes every day" problem either, of course. I already know from Sturgeon's Law that 90% of the complaints are just bellyaching, that's why we have tryout periods.

I can already see how people could be overwhelmed by UE. It took me a bit of time to find how to set the environment to "Programmer". As always, it's obvious to those familiar with the product, but there are staggering number of pulldowns, menu options, and etc. in UE.

rhapdog wrote:Yes. I have. It just can't do everything that UltraEdit does. It is also considerably more expensive. For my money, UE is the best deal. They may "claim" to be the most powerful, but when I state that UE is the most powerful, it isn't just a claim from IDM, it is a claim by the People's Choice Awards, Shareware Industry, numerous magazine publications, and numerous 3rd party reviews.

As I said, I used ME back in the late 1980s, with the DOS version. Back then, it was quite competitive, which means absolutely nothing today. I noted that their price is higher (ME: $199, Zeus: $99, UE: $59-$89+). Obviously, I'd prefer cheaper, but I'm not going to disqualify based on price. Adjusting for inflation, ME today at $199 is cheaper than Kedit was at $125 in 1985. The time investment I'm going to put into whichever editor I end up choosing will certainly exceed $100 over the years.

rhapdog wrote:If you Google for "Most powerful text editor for Windows", you will find many reviews that have a "list" of most powerful editors. I have seen "10 most powerful", "15 most powerful", "5 most powerful", etc., but have not once seen MultiEdit in a most powerful list. UE, in each of those, was stated to be the most powerful (at least the ones I looked at when I Googled this morning.)

Of course, power is in the eye of the beholder. What's keenly important to web developers may not matter a bit to someone doing embedded assembler, and vice versa. A co-worker told me he considers EditPlus to be the most powerful editor. When I asked him what scripting features he said, he answer "I'm not sure if it has any. If it does, I might have just removed the menu item for it, since I don't use macros". Lots of people claim Eclipse is the best of breed, but when I played with it, I found I couldn't even remap the keyboard. I was asked "Why would you want to do that?".

rhapdog wrote:I read that just now. Zeus is laughable compared to UE. This is also an old post, and some of the things stated about UE were either in ignorance, or have been fixed since then. Not one negative he listed is currently true of UE.

Certainly the comparison is out of date. Looking at Zeus, I'm not about to rule it out without further checking. Especially since both Zeus and UE use javascript for a (of one of the) scripting language, it should be an easy comparison.

rhapdog wrote:The time frame can be a couple of weeks, or a month, sometimes as long as 2 months. This is not a make or break time period to wait on the features to migrate over to UES, especially considering that once you get those features, they will be stable and you won't have to patch it later after being frustrated by the bug you found.

I wasn't sure what the time frame was.

rhapdog wrote:The real way you need to evaluate it is do you need to "compile" your programs from projects. If you're coworkers are using Visual Studio, and you're working from the same compiler that they are, then you'll find that once you get UES up and running, it will offer you features to handle multiple project files to allow them to interact in ways you can't do with UE.

Well, we have a very customized environment. We use the VS compiler, but the IDE is really only used as a debugger, and for some of the developers, as an editor. Our application clocks in with over 30,000 source C++ files, a similar number of hpp files, plus an ungodly number XML configuration files, and god knows how many perl, ruby, tcl, tk, and bash scripts to glue the thing together. We don't use the Visual Studio "project" files at all, it's simply not possible. We run command line builds exclusively. As you can imagine, I've got a number of KEXX macros that parse the output of the build process and feed it back in so Kedit can deal with it directly.

So integration with Microsoft's IDE paradigm isn't a big deal, as least in this job.

rhapdog wrote:Seriously, take a good look at the UE/UES comparison before you make a final decision.
https://www.ultraedit.com/products/uest ... ences.html

Oh, I will be.

rhapdog wrote:The author argues that programmable editors are worth studying like programming languages and a powerful editor is huge advantage from the point of view of reaching high productively (and avoiding many typical frustrations).

That is good advice for anyone.

Oh, I agree fully. I still remember when I got my August 1985 issue of "Computer Language" magazine (they of the Jolt awards), where they devoted the cover story to comparing all of the editors on DOS at the time (Brief, Qedit, Kedit, all the various Unix and big-iron ports, etc). Just checking my Kedit macros directory, I see I've written 40,383 lines of macros over the years. The idea of just using any editor "as-is" just off the rack is anathema to me, although fairly common.

I think that's why so many people love Notepad++. Not to take anything from it, it's a terrific out of the box editor. But even with the plugins, the extensibility is pretty limited. If it does what you need already, it's great. If it doesn't, you're stuck.

To me, when it doesn't do what I want out of the box, that's where the real issue is. That's when I can judge how long it takes me to be able to get it to do what I need. A non-scriptable editor may be very powerful, but I notice most people who use them end up adjusting their work habits to confirm to the editor, rather than the other way around.

Usually, when someone shows me a cool feature from their editor and asks if my "20th century" Kedit can do that, the usual answer is "not yet, but give me an hour". But with unicode, and things like Kedit's line-only orientation (as opposed to keyword), that's increasingly become "no". That's why I'm seeing if UE is extensible enough to make it back into the "not yet, let me write a script" column.

rhapdog · Feb 16, 2012#62012-02-16T03:59+00:00

billdehaan wrote:As you can imagine, I've got a number of KEXX macros that parse the output of the build process and feed it back in so Kedit can deal with it directly.

I was thinking about that. With a little modification, you may be able to convert your KEXX macros into REXX, then run them from a REXX Interpreter like Regina as a Tool from within UltraEdit. Certainly not all macros will be able to be converted, but most should, I would think. Some may not require converting at all, if it doesn't use the KEXX specific subset.

Something to think about.

I actually use a number of PHP scripts and run them against my current document at times, because that is something I code in often. You could implement any number of scripting languages in this way, but you'll miss out on the UltraEdit application object that has been included in UltraEdit's version of JavaScript. It allows you to perform some of UltraEdit's functionality without having to reinvent the wheel, which is nice.

billdehaan wrote:Just checking my Kedit macros directory, I see I've written 40,383 lines of macros over the years.

Yeah, I'd definitely see if some of that can be converted to REXX and run through Regina. No sense in wasting it. If you could do that, you'd probably have something serious to share with the community.

billdehaan · Feb 17, 2012#72012-02-17T16:52+00:00

rhapdog wrote:I was thinking about that. With a little modification, you may be able to convert your KEXX macros into REXX, then run them from a REXX Interpreter like Regina as a Tool from within UltraEdit. Certainly not all macros will be able to be converted, but most should, I would think. Some may not require converting at all, if it doesn't use the KEXX specific subset.

Unfortunately, the majority probably do. Also, many of these are highly specific; a large number parse the output files that are generated by systems that are both proprietary, and frankly not all that interesting in general terms.

I've started to write a few javascript macros, and was quite disheartened to find what looks like a bug in the javascript engine. When I call a function that returns a string, it works the first time, but the second time, I seem to get a null string. Not encouraging. If a variable s is defined as a string (I was using time/date values), then return(s) works the first time, but when called a second time, it's null. However, if I write the function to return(s+""), it seems to work both times. I'm unsure if this is UE or whether UE is importing Javascript from a Windows dll or not, but it doesn't fill me with confidence.

I've also found that the C++ function listing finds duplicate headers on lines that aren't headers. In a file with 27 methods, Kedit found 27, and UE found over 30. If there is a line within a method of the form

Ptr<IClass> pGroup(Interface::Foo()->Bar(f(m_data)));

UE reports this as being a declaration of Interface::Foo().

Not a showstopper (I'm more concerned about the Javascript nondeterminism I've found), but surprising. Especially since Notepad++ does it properly.

rhapdog wrote:You could implement any number of scripting languages in this way, but you'll miss out on the UltraEdit application object that has been included in UltraEdit's version of JavaScript. It allows you to perform some of UltraEdit's functionality without having to reinvent the wheel, which is nice.

I've been reading the PDF of the ultraedit document object, since that's where 95% of the script work would be done. It looks fairly complete; I have to learn more javascript to learn the more generic abilities of the language. I didn't learn REXX or EXEC2 in a day, either.

rhapdog wrote:Yeah, I'd definitely see if some of that can be converted to REXX and run through Regina. No sense in wasting it. If you could do that, you'd probably have something serious to share with the community.

Some stuff, perhaps. Sifting through that, I'm surprised to find stuff that I have not looked at, or used, in decades (literally). There was actually a "project format to LIST3820" converter that probably hasn't been invoked since 1992.

There's more generic stuff that might be of general benefit, but I'm not sure yet. I wrote my own macro and bookmark handlers to supersede Kedit's, so instead of one keyboard macro, I could have a library of named macros, which could then be mapped to any key, or manually execute from the command line. Even if my implementation is better than UE's native version (which is unlikely), it's not likely to be worth porting over, given the existing functionality in UE. Likewise, my improved bookmark handling is better (IMO) than the native Kedit bookmarks, but is largely redundant compared to UE's bookmarks. But, as I bring things over, I'll see if there is anything useful that is general enough to be made public.

Mofi · Feb 18, 2012#82012-02-18T16:58+00:00

billdehaan wrote:I'm unsure if this is UE or whether UE is importing JavaScript from a Windows dll or not, but it doesn't fill me with confidence.

You can be quite sure that the mistake is in your JavaScript code and there is no bug causing a function to work only on first call. UltraEdit has integrated the JavaScript core engine v1.7 (or even a later version as Jaretin and I found out 3 days ago) developed by the Mozilla Developers. If the JavaScript engine would have such a serious bug, many users of Mozilla based browsers like Firefox would suffer on this bug.

billdehaan wrote:I've also found that the C++ function listing finds duplicate headers on lines that aren't headers.

The strings listed in the function list view are found by UltraEdit regular expressions defined in the wordfile c_cplusplus.uew. Click on Advanced - Configuration - Editor Display - Syntax Highlighting, select language C/C++, and press the button Open to open this wordfile. Close the configuration dialog with button Cancel.

You can customize the regular expressions to your coding style. The problem with regular expressions for finding functions in C/C++ is that there are so many different coding styles, especially for C. The regular expressions are written to find as many functions as possible for nearly all possible type of function definitions with the result of some false positive. But you can get a 100% perfect function list if you adapt the regular expressions to your coding style. For example for C+++ only the second regular expression is needed because all other are for C functions. See for example newlines in C function definition between function name and round bracket and other topics where I helped users to find the regular expression best matching their functions.

UltraEdit is very powerful and can be highly customized to personal needs. But that requires time, time to explore all the functions of this amazing editor and time to customize it for efficient work with it.

billdehaan · Feb 18, 2012#92012-02-18T19:35+00:00

Mofi wrote:If the JavaScript engine would have such a serious bug, many users of Mozilla based browsers like Firefox would suffer on this bug.

That's what I thought. That's why the behavior was surprising to me. I think it may have something to do with an implicit type conversion, or variable scoping. I've got it work, and I'm going to see if I can regenerate the original code that caused it. I was mixing and matching different sample scripts from different sources.

I think one thing that threw me was that in UE, script errors seem to terminate the script quietly; in Kedit, when there's a script error, an error message appears onscreen, like

Code: Select all

Macro "test" line 12 col 1 - Error 109 Unmatched "/*" or quote

When I left an end quote off a string in a UE script, there was no indicator onscreen that there was an error, the script simply failed. There's probably an error log somewhere, but there was no immediate feedback.

Mofi wrote:The strings listed in the function list view are found by UltraEdit regular expressions defined in the wordfile c_cplusplus.uew. Click on Advanced - Configuration - Editor Display - Syntax Highlighting, select language C/C++, and press the button Open to open this wordfile. Close the configuration dialog with button Cancel.

Ah, good. I do the same thing in Kedit (define the expressions that qualify a method header), and one of the criteria is that all method declarations must start at the first column of a line, which the function call does not.

I've also found a nasty in the Take Command file (tcctcmd11.uew). If there's an open quote mark in a command, i.e. "* macro won't handle cases where...", UE shows that as the start of a string, and makes the rest of the file up to the next quote mark as being a single string. Another low-priority thing for me to check

Mofi wrote:See for example newlines in C function definition between function name and round bracket and other topics where I helped users to find the regular expression best matching their functions.

Thanks. I'll check that out.

Mofi wrote:UltraEdit is very powerful and can be highly customized to personal needs. But that requires time, time to explore all the functions of this amazing editor and time to customize it for efficient work with it.

I agree fully. I've been configuring my Kedit installation for almost 30 years; obviously no editor is going to match that functionality out of the box. And I certainly don't expect to duplicate my Kedit environment within a month; even if it were possible, it's not desirable. But I do expect within a month to be able to determine if it *is* possible to duplicate the functions that I'm used to using (like editor folding and ranges) using the macro language.

A lot of the extended functions that I wrote for Kedit (bookmarking lists, multiple clipboard support, named keyboard macros) already exist in UltraEdit. And some of the base Kedit functions (like RANGE and ALL) don't exist in UltraEdit at all.

What I am doing now is attempting to duplicate some Kedit macros into UltraEdit, and learn the scripting abilities. JavaScript is very different from REXX and KEXX. One big difference is that since JavaScript is a common language, the UE documentation pretty much says "we just JavaScript, here's the UltraEdit application object and document object methods, look at the Mozilla documentation for the JavaScript behavior".

Anyway, thanks for the help. I'll look up the URLs you mentioned.

rhapdog · Feb 18, 2012#102012-02-18T19:50+00:00

If you need a good jump start on JavaScript to get you started, I would recommend using the JavaScript Tutorial at W3Schools.
http://w3schools.com/js/default.asp

It's really good to get you started. Since you already know some programming, you should be able to zip through it at a fairly decent pace, and it will do wonders to help your understanding of it.

The beautiful thing about using JavaScript as the scripting language is that there are so many resources to help you learn and that you can use for reference. Also, there are a plethora of ready-made scripts for download that you can pretty much just plug into whatever. If you need to know how to get JavaScript to do something, just Google for a JavaScript solution to that problem, and you'll probably find a script that meets your needs. You'd be surprised. (I never reinvent the wheel if someone else has already done it, unless someone is paying me specifically to reinvent.)

Mofi · Feb 18, 2012#112012-02-18T20:58+00:00

Errors detected by JavaScript interpreter on execution are captured by UltraEdit and printed to the output window. But UltraEdit does not automatically open the output window on error during script execution because with scripts it is also possible to control the appearance and contents of the output window. It is advisable to have the output window permanently open on script developing to see the errors immediately when one occurs.

Note: With disabling configuration setting Show status information in output window at Advanced - Configuration - Scripting it is possible to keep the output window unmodified by status messages usually printed to output window on script execution. But that option turns off also printing error messages from JavaScript interpreter to the output window. Therefore this setting should not be enabled on script development.

Some UltraEdit users use Javascript Lint to check syntax of an UltraEdit script before execution. UEStudio has built-in support for Javascript Lint. In UltraEdit a user tool must be configured to run Javascript Lint on active script file and capture all messages to output window.

The wordfiles, especially those on the user-submitted wordfiles page, are written by users and IDM has not checked any of them on correctness. If you find a mistake in one of the user contributed wordfiles, please correct it and send the updated wordfile packed with ZIP as attachment by email to IDM support with the request to replace the wordfile with same name on their server. Please make sure that the wordfile does not contain any color and font style settings usually added by UltraEdit. See The ultimate syntax highlighting tools and Template for Language File. The tools page contains a macro file with several macros to check a wordfile. It contains also a macro to delete all color and font style settings. The template page contains additional information not found on Syntax Highlighting page in help of UltraEdit. And of course you can simply ask when you need help on a syntax highlighting problem.

I looked into tcctcmd11.uew and could already see that the String Chars = definition can't be correct because only up to 2 characters can be defined as string starting and ending characters and not 3 as done in this wordfile. A marker characters definition could be used for highlighting a third type of strings within a line. But if straight single quote character is not used for strings (in your files), just remove it from first line.

billdehaan · Feb 20, 2012#122012-02-20T17:07+00:00

rhapdog wrote:The beautiful thing about using JavaScript as the scripting language is that there are so many resources to help you learn and that you can use for reference. Also, there are a plethora of ready-made scripts for download that you can pretty much just plug into whatever. If you need to know how to get JavaScript to do something, just Google for a JavaScript solution to that problem, and you'll probably find a script that meets your needs. You'd be surprised. (I never reinvent the wheel if someone else has already done it, unless someone is paying me specifically to reinvent.)

Oh, I'm a big fan of reuse, too. JavaScript doesn't look too bad. Of course, most of the focus of it is website development, rather than text editing, but the feature set seems fairly good.

Much of the difficulty in switching from Kedit/REXX to UltraEdit/JavaScript is changing from the row/line paradigm to stream. Blocks in particular are treated very differently; generally speaking, in CUA blocks are not persistent. Also, things like search seem to automatically select the search text, which led to some unexpected behavior.

I converted an old Rexx macro to this:

Code: Select all

if( UltraEdit.activeDocument.findReplace.find("Last Revision:  ") == true )
{
    UltraEdit.activeDocument.deleteToEndOfLine();
    var s = DateTimeString();
    UltraEdit.activeDocument.write(s);
}

and found that the "Last Revision: " string was overwritten. I solved the problem by adding UltraEdit.activeDocument.key("LEFT ARROW"); UltraEdit.activeDocument.key("RIGHT ARROW"); before the delete, which deselects the search text, but that seems rather clumsy. Is there a more elegant way to handle that?

One thing I am having trouble with, oddly enough, is insert mode. I tried using the UltraEdit.insOvrMode, but it was always returning true, regardless of whether the was in insert or overstrike mode. I see that that's documented as correct behavior, since the script sets insert mode to be true at the start of every script. But if that's the case, how can you determine what the editor's current insert status is?

I'm trying to see if I can get the backspace key to behave like it does in Kedit, where in insert mode it deletes the prior character, but in overstrike mode it cursors to the left, then blanks out the previous character. Unfortunately, I can't seem to get it to branch on the insert state in a macro, since the macro automatically resets it.

Feb 20, 2012#132012-02-20T17:37+00:00

Mofi wrote:Errors detected by Javascript interpreter on execution are captured by UltraEdit and printed to the output window. But UltraEdit does not automatically open the output window on error during script execution because with scripts it is also possible to control the appearance and contents of the output window. It is advisable to have the output window permanently open on script developing to see the errors immediately when one occurs.

Ah, got it. Now I see. In Kedit there was simply a one line status message line, and everything went there. In UltraEdit, the View->Lists shows a lot of specialized windows to separate everything.

Mofi wrote:Therefore this setting should not be enabled on script development.

I'm using the defaults. I've made a few changes, such as the editor display (cursor to underscore rather than vertical bar) and several keyboard mappings, but I'm still going through the other options. Generally speaking, I'm still running it in an out of the box configuration.

Mofi wrote:The wordfiles, especially those on the user-submitted wordfiles page, are written by users and IDM has not checked any of them on correctness. If you find a mistake in one of the user contributed wordfiles, please correct it and send the updated wordfile packed with ZIP as attachment by email to IDM support with the request to replace the wordfile with same name on their server.

I think it will be a while before I'm confident enough of my UltraEdit skills to start with that

Syntax highlighting is pretty much at the bottom of my list right now. I only included the tcc file because I use Take Command a lot (like Kedit, and UltraEdit, I heavily modify my environment with scripts). I

Mofi wrote:I looked into tcctcmd11.uew and could already see that the String Chars = definition can't be correct because only up to 2 characters can be defined as string starting and ending characters and not 3 as done in this wordfile. A marker characters definition could be used for highlighting a third type of strings within a line. But if straight single quote character is not used for strings (in your files), just remove it from first line.

The problem is that single quotes can be used for strings, but also in comments. When a word like "don't" was in a comment line, the parser considered the single quote mark as the start of a comment, and highlighted everything until the next quote mark as being a string. It was a simple fix (removing the single quote from the parser, or just using "do not"), but it's something I'll revisit when I get all of the higher priority issues I'm looking at in UE finished. That'll probably be about a year, at this rate

Thanks.

Mofi · Feb 20, 2012#142012-02-20T18:55+00:00

There is the scripting command UltraEdit.activeDocument.cancelSelect(); which discards current selection without changing the caret position.

I develop UltraEdit scripts always with View - Views/Lists - Tag List window open and tag group UE/UES Script Commands selected to get help on inserting UltraEdit specific scripting commands and avoid mistakes.

Yes, UltraEdit.insOvrMode returns now always true after script start. That was not the case as script support was implemented. In previous version of UltraEdit the property really returned current editing mode. When creating a new macro, the macro contains always 3 lines to turn insert mode on, turn column mode off and turn off hex editing mode. When recording a macro the current editing mode is recorded for the first 3 commands. So most macros have set the environment for the macro first on execution.

But most Javascript writers are lazy programmers. They have simply not defined the working environment for the script by using the appropriate commands. As you can imagine this caused lots of troubles later on exection of the script. I think, this is the reason why IDM changed the behavior and define temporary for script execution now always the editing mode and restore previous editing mode after script finished. That helps the lazy script writers, but has unfortunately the bad side effect that some properties and commands are not useful anymore or are of less usage. I have requested long time ago additional properties which contain the information of editing environment before UltraEdit defines it for the script and commands which can define the editing environment also after script finished.

Line and block comment highlighting have a higher priority than string highlighting. Quotes in comments should be completely ignored for string highlighting. If this is not the case, the line and block comment definitions are not correct specified in the wordfile. If the language does not support multi-line string highlighting, the keyword DisableMLS should be used on first line of the wordfile anywhere left the File Extesions = definition which must be always the last one on first line.

billdehaan · Feb 21, 2012#152012-02-21T03:22+00:00

Mofi wrote:There is the scripting command UltraEdit.activeDocument.cancelSelect(); which discards current selection without changing the caret position.

Ah, that did it (thought it's Cancel, not cancel; UE was fussy about that). But looking through the PDF file, it's not listed as a Document Object command. It looks like the UltraEdit_UEStudio_Help.pdf file I've been using is not as recent as the help file.

Mofi wrote:I develop UltraEdit scripts always with View - Views/Lists - Tag List window open and tag group UE/UES Script Commands selected to get help on inserting UltraEdit specific scripting commands and avoid mistakes.

That took me a second. I had looked at the tag list previous, but it was only for HTML tags. I hadn't noticed that it was a pulldown.

Mofi wrote:That helps the lazy script writers, but has unfortunately the bad side effect that some properties and commands are not useful anymore or are of less usage. I have requested long time ago additional properties which contain the information of editing environment before UltraEdit defines it for the script and commands which can define the editing environment also after script finished.

So, it sounds like there's no way currently to determine from a script whether insert mode is active or not at the moment. That's annoying.

Mofi wrote:Line and block comment highlighting have a higher priority than string highlighting. Quotes in comments should be completely ignored for string highlighting. If this is not the case, the line and block comment definitions are not correct specified in the wordfile. If the language does not support multi-line string highlighting, the keyword DisableMLS should be used on first line of the wordfile anywhere left the File Extesions = definition which must be always the last one on first line.

Oh, I can easily believe that there are errors in the config file. It's fairly good, but when I get better at it, I'll see about updating it.

One other question: I've noticed when playing back scripts and macros that the screen refreshes as they execute. Kedit used to do that, until people realized that continuous refreshes were wasting CPU cycles, especially when running huge scripts on massive files, when the intermediate states don't matter. Originally, they added DISPOFF and DISPON functions so that scripts could turn the screen on and off, but eventually they just turned it all off (which the exception of messages being sent to the message status line).

Given that one of UE's claims is support for huge files (4GB), I can't imagine that redraw performance hasn't been considered. Is there any way to disable updates from macros/scripts? I see operations for force refreshes, but not to suspend/resume them.

I also notice that in Kedit, a script is considered a single undo operation. In UE, if I run a script that makes 30 changes, that seems to add 30 operations to the undo stack. I set the option to have the undo stack go by word, rather than character, but it still leaves every operation in a script as a separate undo element. Hmpf.

Of course, I just saw today that v18 is coming out soon...

Oh, and I don't know what I did, but for a while yesterday, whenever I started UE, I got the the a bizarre dialog for about 30 seconds before the application started up. It continued whenever I started UE without any arguments (so it loaded all the files from the previous session). Eventually, when I started it with a file name as a command line argument, the problem disappeared, but I took a screencap (StarupScreenshot.zip). Any ideas what that would be?

Oh, and thanks again.