I have an older version of Ultraedit (probably 10 years old now). I believe in supporting software developers but I will NEVER pay for a yearly subscription of $80/yr for any piece of software unless it's being expensed by my employer. That's way too expensive once you start using it for a couple of years. $20-30/yr like Sublime is more appropriate. I also have purchased Sublime Text will pay for v4 as well.
I purchased this with my own money in the mid '90 to use in my work computer (Windows 3.11) because it saved me do much time inspecting the data dumps from our old data warehouse in preparation for a migration for the new data warehouse. No other application was able to load files of comparable size at the time.
The nostalgia is great in this one. Back in my Windows webdev days UltraEdit and HeidiSQL were the tools that got 90% of the job done. You didn't even have to rely on PuTTY with UE due to its auto sync features.
UltraEdit was a pure joy to use. back in the windows 3.1 days I could edit files larger than main memory. It was my first encounter with the now ubiquitous tabbed interface. It would hex edit, select rectangular sections, mouse beyond the end of a line, automate with macros. I am sure it did even more that I cannot remember. I should probably go buy a copy just to pay back idm for all the cracked copies that I used back in the 90s.
Seems pretty reasonable to me if it's as useful to people as it appears to be judging by the comments here.
Personally I'm willing to even pay a slight premium for non-subscription options too.
I find it's important to know what you're buying though; particularly if the thing it's targeting is changing rapidly, like an IDE for a modern language, or something else they know will be made obsolete in a short time.
A book on Android 1.5, or Kubernetes Pod Security Policies doesn't (didn't) have much of a future.
I still use it daily. The ability to switch into hex editor mode and back is wonderful! I am about to purchase a Mac version as I expect to migrate to Mac soon and want to buy one before it becomes subscription only.
I remember that the site used to have a message from the developer saying that if he got 30 sales he would go full time on the project. 30 sales were faxed through and he considered it a message from God.
Heh. I used this more than 20 years ago, maybe on windows 95 or 3.11. I think it was the one of the first software I paid for using my own doe. I switched to Emacs shortly after though. I don’t remember why exactly... maybe it was Emacs DOS support.
All these "simple" text editors like to show how easy it is to use "multiple cursors" to edit several spots at once but... Even though sometimes it's needed it's really usually a terribly bad way to "refactor". Real refactoring is done across multiple files / config files and that's one area where a real IDE excels. And this comes from an Emacs fan (and I do sometimes use "multiple cursors" in Emacs).
I really don't think it's somehow a "selling point" of a text editor to show that you can edit multiple cursor: what you typically want is real refactoring and multiple cursors simply aren't that at all.
I use a powerful IDE (Intellij) in a static language (Scala). And I do use the refactoring support all the time. But I use the multiple cursors feature just as often. Sometimes you want to change more than just a variable name. Sometimes you want to replace just a part of a variable name that's identical over several different variable names. Etc etc.
"real refactoring" isn't generally available to those of us using dynamic languages like Python (or at least I've never seen it done well) so multiple cursors is about the best we can get unfortunately.
It’s kind of weird that dynamic languages are known as being bad at refactoring, when Smalltak was doing advanced full system refactoring in the 1980s.
In the case of Python, I think the problem must be more syntactic and lacking an introspectable compile step than an issue with it being a dynamic language.
> All these "simple" text editors like to show how easy it is to use "multiple cursors" to edit several spots at once
IDEs aside, I use this feature a lot to reformat badly indented SQL, to work on multiple "columns" in CSVs at once, to unroll loops... The possibilites are numerous.
How about Sublime Text? That’s mostly my use case. Opening giant files that VSCode can’t, Ctrl-F a regex expression, selecting all matches, and pasting them into a new buffer. Like a visual interactive grep. Sublime handles big files pretty well but I’ve still managed to make it chug on occasion.
I'm not sure your definition of big file. But, the last thing that I tried to edit a full Wikipedia dump (in 2014) the file was 65GB, and it was slow even in UltraEdit.
I tried all the editors suggested at the time, including Sublime but notice that VS Code wasn't available at the time.
People love their programming editors, but UltraEdit is much more than that. It was an editor for data manipulation. It was the best for managing what used to be considered big files before (and too many other features, including moving around columns of data like what you can do in Excel - try that on other editor), but now the bar for file size is much higher, and UltraEdit had not improved there.
The fastest editor for big files according to my tests was EmEditor, and editor that like UltraEdit, is made for loading data files. However, EmEditor can load what in 2021 can be claimed to be big files. It can open filed of up to 248GB in the 32-bit version and 16TB in the 64-bits version of the platform. That (the 64-bits version) is what I call big files.
In Sublime 4 thread people were talking about UltraEdit, it is even probably the reason for this submission.
Anyway, there people mentioned UltraEdit has a "disk edit" mode, where it DOESN'T dump the file on the ram, and instead displays a chunk of whatever is on t he disk, this is how it allows the editing of gigantic text files, theoretically you can edit files of any size, maybe even infinite size.
On a 2017 MBP with an i7 and 16GB of ram loading things over 500MB and then trying to search/edit them takes minutes per search term/edit. Frequently I get the spinning wheel and have to force quit and start over.
I thought it was the nature of dealing with large text files. I wonder why my experience with Sublime has been so bad.
The context of my use is dealing with gigantic log files/json files doing digtal forensics for the purpose of discovering malicious activity. I also use grep and a ton of other tools but sometimes when you aren't looking for a particular thing and you're just looking for weird stuff the best way to explore the data is with the raw files and a text editor. Unfortunately the editors I've used are painfully slow when the file sizes are large.
I've become quite fond of vis[0] and it amazes me how quick it is with gigantic files. It's developed/mantained by a few people so its development is not as quick as one would want, though.
https://orbitalquark.github.io/textadept/