Softpanorama May the source be with you, but remember the KISS principle ;-)
	Contents	Bulletin	Scripting in shell and Perl	Network troubleshooting	History	Humor

Orthodox Editors as a Special Class of Advanced Editors

The introductory paper Orthodox Editors introduced some ideas on which this page was build. Here is the abstract of the paper:

This paper tried to introduce a new concept: orthodox editors as a special category of editors. All of them have command line set of commands and respective glue macrolanguage. We have found two such families:

• Eastern Orthodox family represented by such editors as XEDIT, Kedit, THE. All of them use REXX as a glue macrolanguage.
• Western Orthodox family represented by vi and its derivatives with VIM as the top representative of the category. They have ad-hoc macro language (primitive in VI, better but still ugly in VIM) but have unique and unmatched ability to use shell as an extension of the command set. They also support folding.

We define the notion of  "orthodox editors" as having the following distinct features:

1. They have a well-defined command set that is comparable in power to GUI based commands and command line can be used to enter editor commands. For some of them (vi - line ) that comes naturally, from the fact that they were initially designed for typewriters. 
2. They permit doing any editing task using keyboard  (although mouse can speed up or simplify many of those tasks and is not rejected in the extremist way)
3. They use a standard scripting language as a macrolanguage (TCL, REXX) or unique for the application (YASL  - yet another scripting language) like in vim 6 as a macrolanguage. It serves as a glue for the command set implemented by the editor. With some reservations we can accept  a unique for the application (YASL  - yet another scripting language) like in VIM. This is definitely less attractive solution as it is difficult to master the language that you use only for a specific application (in this case an editor).  The same consideration is applicable to Emacs. 
4. They support folding (all command in XEDIT and its derivatives; folding capabilities in VIM )
5. They distinguish between editing buffer and the windows in which this editing buffer is displayed allowing multiple windows to display the same buffer.
6. They support regular expressions
7. They permit processing selected part of the editing buffer or all the buffer via pipe connected to external command (! command in vi)
8. They support multiple views of the same editing buffer.
9. They allow piping in output from arbitrary pipe into the current position of cursor, selection, or all buffer as well as exporting a selection or all buffer as an input stream for an arbitrary pipe.  

This article is a modest attempt to create a basic classification useful for further studying this important class of editors. The author argues that this class of editors can serve as viable mid-weight editors for programmers (see a companion paper A Note on Size-based Classification of Text Editors for this further discussion of related ideas).

This article is a modest attempt to create a basic classification useful for further studying this important class of editors. The author argues that this class of editors can serve as viable editors for programmers providing despite Spartan interface rich functionality absent in almost any other editor with possible exception of vi and its derivatives. Despite integrating a macro language they are actually pretty small, mid-weight by some standards (see a companion paper A Note on Size-based Classification of Text Editors for this further discussion of related ideas).

Please note that both subclasses of orthodox editors were pioneers in introducing several important for any modern editor features, features that unfortunately still are absent or poorly implemented in most other editors: 

• Eastern orthodox editors introduced
  • folding (all command in XEDIT)
  • Usage of a standard scripting language as a macro language (REXX).  
  • Multiple views on editing buffer
  • Ability to bind execution of a command on the command line to the selection on the screen
• Western Orthodox editors have command set of ex editor. They introduced
  • regular expressions as a editing tool
  • extremely powerful concept of editing buffer via Unix pipes; the latter is still mostly missing in most other advanced editors.
  • The idea of two command channels: channel to internal interpreter (":" commands) and channel to OS shell ("!" commands).

This paper explores two sets of  deep interconnections that were previously unnoticed in the literature:

• There is a deep interconnection between OFMs and Orthodox Editors. Actually OFM can be implemented on the base of EOE and VM/CMS actually contains a file manager that is XEDIT-based.
• There is a subtle similarity between XEDIT family and VI family,  those two seemingly unconnected families of editors one originating at East Coast and the other in West coast (that's why I used names Eastern Orthodox and Western Orthodox for them ;-).

Actually the second point was the main reason that I decided to use a superclass term "orthodox editors" that includes as subclasses both XEDIT editors line and VI editors lines. Not only because I like to invent new terms (that goes with Ph.D ;-), but I really see deep similarities between them and their connection to a similar phenomenon that I studied earlier in case of File Managers (see OFM page for details). Those tools are representative of a different approach to GUI interface then Apple GUI or Microsoft GUI (which are converging). Interface that can be called "Orthodox Interface".  And this Spartan interface with ancient-looking, "half-baked" GUI with command line present give users important and unique capabilities that are missing in other similar "pure GUI" Tools. They survived because they are capable of giving advanced users the ability to achieve an extremely high productivity, beating competition. Although some design decisions in those editors were dictated by limitation of old hardware they withstand the test of time and proved to be useful and extremely productive tools for modern environments.

Read more

Another interesting for me issue is the value of editors of different sizes (lightweight, mid-weight and heavyweight). My thought on this issue are reflected in another paper  A Note on Size-based Classification of Text Editors  Here is the abstract:

The article presents an attempt to understand correlation between features of text editors and editor size based of tasks each weight category performs better and1 propose size based classification of editors

The concept of "editor weight" is useful for explaining why most programmers use several editors (usually three: standalone lightweight editor like Notepad, midweight editor like Vim, Kedit or SlickEdit and heavyweight editor /IDE type of environments like Microsoft Visual Studio .Net, Emacs, etc). 

That suggests that there are tasks for which one editor of a certain size suit best and perfoming of which with the editor of a different category is less efficient despite the additional power it might provide. This paradox that most programmers use several editors while leading one would be more efficient can be explained by the hypothesis that editors can be classified into three distinct categories and that each category of editors has its own unique set of features In this case one size does not fit all. We will distinguish 

• lightweight editors (editors that does not need installation and can be fully functional if the computer contains one executable and a user can start editing after moving this executable to new computer. They can  They can use additional initialization and configuration files but they should be optional of at max two files (editor executable and optional initialization file/files)

• midweight editors should have powerful macro language, folding and full multi-windows support. That's the category were orthodox editors fall into.

• heavyweight editors are essentially in IDE in disguise. Emacs is classic example of heavyweight editor, Visual Studio .Net is another example.

The main idea here that there are tasks that are better, quicker performed by lightweight editors and they're are tasks that are better performed by midweight/heavyweight editors, so those categories of editors develop in different directions. 

Read more

Most programmers spend  a lot of time editing the code (may as much as 40%). If that's the case, finding the best tool available and, if necessary, spending a few extra dollars for it definitely is a good investment.

NEWS CONTENTS

•  
• LE - Lukyanov Editor
• AEditor – Freecode
• Highly programmable non-Emacs editor?
• How many other editors in use - comp.editors Google Groups
• would like a recipe to pull down a free online book - 2
• What is a folding editor
• Code Browser - A Folding Text Editor
• freshmeat.net Project details for Cooledit
• Code Browser
• ConText Editor
• CUTE User-friendly Text Editor
• Linux.com Some Linux apps are small wonders
• The Right Size for an Editor
• Eric Raymonds view on the subject. IMHO he did not understand the real tradeoffs that make vi a great editor for so many years, but he at least is able to site right people ;-). With all due respect to RMS, Emacs is definitely anti-Unix type of editor :-).

Old News ;-)

Replacing KEdit by UltraEdit - any thoughts?

This forum is user-to-user based and not regularly monitored by IDM.
Please see the note at the top of this page on how to contact IDM.
 

Post a reply

Re: Replacing KEdit by UltraEdit - any thoughts?

by rhapdog » Tue Feb 14, 2012 9:34 pm

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.

 

---

Re: Replacing KEdit by UltraEdit - any thoughts?

by billdehaan » Wed Feb 15, 2012 12:21 am

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/UltraEdit/976352095/1?all_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.
 

---

Re: Replacing KEdit by UltraEdit - any thoughts?

by rhapdog » Wed Feb 15, 2012 10:03 am

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/UltraEdit/976352095/1?all_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.
http://www.ultraedit.com/products/uestu ... 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.

---

Re: Replacing KEdit by UltraEdit - any thoughts?

by billdehaan » Wed Feb 15, 2012 7:01 pm

...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 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.

---

Re: Replacing KEdit by UltraEdit - any thoughts?

by rhapdog » Wed Feb 15, 2012 10:59 pm

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.

LE - Lukyanov Editor

Great light-weight Windows style editor from Alexander Lukyanov.

LE has many block operations with stream and rectangular blocks, can edit both unix and dos style files (LF/CRLF), is binary clean, has hex mode, can edit text with multi-byte character encoding, has full undo/redo, can edit files and mmap-able devices in mmap shared mode (only replace), has tunable syntax highlighting, tunable color scheme (can use default colors), tunable key map. It is slightly similar to Norton Editor, but has more features.

AEditor – Freecode

AEditor is a programmer's editor for Windows, Unix, and Mac OS X that relies on the fox toolkit. It can do syntax coloring of Ruby and C++ files. It's easy to change the color theme. Most things are customizable. It is written in Ruby and is carefully unit-tested (it has 421 tests). It is written in only ~5500 lines of code, so it should be easy to grasp and extend.

[Nov 23, 2012] Highly programmable non-Emacs editor?

December 24, 2003 | http://www.fogcreek.com/

Junkster

I'm an editor junkie. I've used dozens of them. I'm currently using with EditPlus for Windows, but it's still not my perfect editor. These days, it should be easy enough to have a more componetized editor: a simple visual display component, plus ways of shooting text to Perl or Python (or your favorite language) to do fancy grunt work. Instead, text editor authors tend to take a GUI-heavy approach, building everything into one, monolithic application. I have seen two alternatives. One is Emacs. I don't want to get into a flame way about Emacs. I've used it. But it's more a lifestyle than a text editor. And then there's Wily, which is a clone of an editor for Plan9 called ACME. Wily looks interesting, but it is a UNIX-only program--no Windows version. And, okay, someone is going to mention vi. Yes, I've used vi. I've written tens of thousands of lines of code with vi. But in the end both vi and Emacs strike me as editors from another era. The cleanliness that comes from an editor like EditPlus or BBEdit (a Mac editor), is something I don't want to lose.

Junkster

Extreme programmability is important for several reasons. The first is that it offers up a lot of options, letting you do things that the author hadn't thought of. For example, I often use non-mainstream programming languages that would benefit from being syntax colored in non-standard ways (certain types of lines colors a specific way, rather than just keywords). I'd also like to be able to extend an editor to context-sensitive tab completion; build custom, interactive project management systems, etc. All of this stuff is business as usual in Emacs. But Emacs is a relic of the past otherwise.

Text munging is easy. We have entire programming languages devoted to it. An editor just needs to be a thin interface with hooks to routines written in such a language. It shouldn't be a monlithic application. I'm surprised that no one has followed this road, other than Stallman's Emacs.

Mac

Visual slickedit is a good alternative. But slick-c is a crappy hacked scripting language. I have written dozen of functions to do things that I want similiar in emacs and vim, but slick-c just can't live up with any other scripting languages that I have used (lisp, perl, python, js).

And the source code that came with vslick are not horrible mess. Good luck trying to learn and understand those source code - it's like I haven't had enough reading my peer's code...

Just my $0.02 

And the source code that came with vslick are JUST horrible mess.

BTW, the API provided by slick-c is very inconsistent (I'm not saying elisp is WAY better, but at least it's still managable...)

christopher baus (www.baus.net) Wednesday, 

I used to be a emacs bigot, but I'm over it. I still write code nearly every day in Emacs on Unix, and VC++ on Windows, but having seen a demonstration of XCode, I've decided to move my Unix development over to the Mac.

What I think is interesting is that emacs it is completely unique approach to application development, and it worth learning just for the alternative look at software applications. I has certainly influenced Gosling's (who used to work on emacs), NeWS and Java -- not to mention autocad which orginally had a lisp based scripting language. Lisp had a VM and garbage collection a million years ago.

Emacs is powerful enough that it is still useful 25+ years after it was orginally written. But I'm not a student anymore, and I don't have time to endlessly tune my .emacs and custom makefiles. Plus I've grown so used to modern IDEs that emacs + gud is painful.

What I think might be interesting is a editor or platform built with emacs as the model, but assuming a modern windowing environment. Maybe we have it in .NET, but it doesn't seem quite the same.

Junkster

Yes, I've used UltraEdit. It's essentially the same as EditPad Pro and EditPlus. But they're all very closed systems (in the extensibility sense, not the open source sense). An editor can just be shell and use Perl, for example, to do the real grunt work.

I have also tried vim, which I consider to vi plus some much needed extensions. It still comes across as dated and clunky under Windows. The interface in a typical Windows editor is so invisible compared to vim and Emacs. 

Phillip J. Eby

jEdit. It's scriptable with Jython and BeanShell. It has syntax highlighting for a bazillion languages, and it has a flurry of plugins available for every imaginable want or need. I use the XML plugin, the LaTeX plugin, the project management plugin, and there are many many many more available out there. It's hugely configurable, lots of GUI options. Extremely extensible, cross platform, and of course it's FLOSS.

It's written in Java, and startup takes a while on older machnes; 20-30 seconds on an old 400Mhz machine. My newer machines start it in 10 or 15. But I've never had any performance issues once it's loaded, even on slower machines.

Oh yeah, the syntax highlighting also configures lots of nifty features like autoindenting, block comment, bracket matching (tag matching in XML mode), code folding, and suchlike features. It's a *very* complete programmer's editor, and should not be confused with Eclipse (which is a generic IDE/tool platform with some editing capabilities, and whose plugins are heavily slanted towards Java development). 

Oops, forgot to include the URL: http://www.jedit.org/

Slartibartfast

Interesting that nobody mentioned Multi-Edit. http://www.multiedit.com/

Their kernel is Delphi, then everything else is built using CMAC, their scripting language. Their community is very active, and a new version was just released.

- Hector

Nils

I just played a bit with jEdit on my WinXP notebook. Can someone please explain to me why the font rendering sucks like a typical Java application? No AA. My XEmacs looks nice on Win XP. It's also a bit embarrassing that you have to reload the entire app to change the text font. (XEmacs is a fork of Emacs, not the X11 version)

There seems to be no viable alternative to Emacs or Vim...

C Rose

jEdit does offer anti-aliasing of text, and you enable it via Utilities -> Global options... -> Text Area. Choose Smooth text and Fractional font metrics (depending upon system spec.).

jEdit is an excellent modern editor. Emacs suffers from massive complexity -- there's so much to remember. The modal design of vi/m is just weird.

Pakter

I have JEdit installed, and it's not bad at all. JEdit had the same plugins as Eclipse, and more. But I don't feel "at home" with it. Like Junkster, I use mostly EditPlus. As Junkster probably knows, you can do a lot with EditPlus, though it's not extensible in the usual sense. At home, I also use ConText, which is similar to EditPlus, just a little less powerful.

Bored Bystander

I also use Multi-Edit and have ever since its DOS days. ME is a great value ($80-$120 or so depending on upgrade or new purchase) since it includes features like file differencing and a generalized compiler interface to act as a sort of self contained IDE to host command line tools.

The only drawback I've ever seen to ME is that you have to customize its key command mappings quite a bit in order to get reasonable behavior (ctrl-F for search, F3 for search again, Ctrl-F4 for close window, etc). ME has very strange notions about common shortcuts. And I have not found a way to make these definitions portable to a new system. (Or, I just don't know the MultiEdit configuration system as well as I "should".) So every time I move ME to a new PC I have to spend about 1/2 hour re-customizing it.

[Mar 06, 2011] How many other editors in use - comp.editors Google Groups

DMcCunney: Apr 27 2009, 12:15 pm

Newsgroups: comp.editors From: DMcCunney <pl...@xyzzy.com> Date: Mon, 27 Apr 2009 13:15:51 -0400 Local: Mon, Apr 27 2009 12:15 pm Subject: Re: How many other editors in use Print | Individual message | Show original | Report this message | Find messages by this author

JussiJ wrote: > On Apr 3, 9:01 am, Chetan <chetan.xs...@xspam.sbcglobal.net> wrote:

I am surprised to find that most of the posts here are about vi or  vim. Aren't there other editors (besides the ones that have their own  groups) that people use?

> On the Windows platform, the Zeus editor/IDE:

> http://www.zeusedit.com/

> Zeus is a scriptable programmer's editor.

With configurable keymaps for WordStar, Brief, Emacs, and Epsilon, and scripting in Lua, Python, Tcl, VB, or JavaScript. ______ Dennis

Mark:  04 Apr 2009 17:30:31 -0500,

Aaron W. Hsu wrote: > For me, it's just a thing that I do, for no particular reason, because > I don't think I really gain too much productivity one way or the other > ..

But you're wrong Aaron. If you are a software developer than you really can improve your productivity significantly by learning your editor thoroughly.

As a professional developer I spend much/most of my day in my editor (vim). It's my paintbrush with which I create beautiful worlds. I'm just not going to blithely pick up and use any old brush.

I'm not exactly sure I understand the chain of creative or physiological process that occurs when I write software but I do know, for me, that vim is part of it.

 

Carl: Sun, Apr 5 2009 9:05 pm

Subject: Re: How many other editors in use

Editors are like OS's, personal preferences to some extent. I agree with several of
the comments above that knowing your editor well is a major plus.
Consider your "needs" and what you might like to do, how extensible it should be,
and pick one.
 

Building on past knowledge is surely an advantage but looking at new
editors can be enlightening. I found one, Manfield's KEdit, many tears back and
embraced it :)

It isn't free, has some quirks, and the company is dropping support. It is quite nice, has a neat extensible macro language, several sites that provide sample macros, and people who use it who are extremely helpful.

The Editors Group is interesting but doesn't provide the "gee, I'd  like to see only code that begins to the left of this column" or "what data is unique in these columns."  Maybe an Editors Concepts group is needed. But, to address the initial thread start, if you have a question on Joe or whatever, ASK!

I've posted  notifications here of KEdit's changes as well as questions and been
happily surprised. YMMV!
 

Aaron W Hsu

> Chetan <chetan.xs...@xspam.sbcglobal.net> writes:
 

>>I am surprised to find that most of the posts here are about vi or
>>vim. Aren't there other editors (besides the ones that have their own
>>groups) that people use?
 

> As has already been mentioned, many other editors have their own lists
> or groups to which people post.  However, I myself regularly switch
> between using Vi and NEdit.  On Windows I use Boxer Text Editor, and
> on Mac I often use BBEdit.  
 

> If you want to have a general discussion about text editors, I'd be
> happy to read it. :-)

  I think the reason most questions are about vim is because other editors
don't provide so many "hidden" tricks" or offer so much functionality.
I use vim and occasionally emacs, but in different contexts: I prefer
vim for config file editing but emacs for email and longer works.  But
in GUI environments I mostly enjoy jedit, a java editor that works
equally well on every platform I use - that's handy.  I carry my macros
and config files on a USB key and can instantly work the way I like to
on any machine I use.  I also find it easier to customize than emacs,
whose lisp I've never really gotten the hang of.

But if I don't post any questions about jedit here it's because it's been pretty easy to figure out and I haven't got any questions to ask. Still, I think a comp.editors.vim group would be appropriate, since the emacites have a separate group.

For the record, I, too, like switching around my editors from time to time, but mostly because it's fun to learn new software.  I've used jed, and joe as well: they're fun for what they are.  Joe is actually good on usenet because it defaults to hard wrapping, something I want on usenet  but don't want on longer works.  (yeah yeah yeah, vim and emacs can do that too.  I get it, I get it).

Cheers.
--
http://www.therandymon.com

DMcCunney: Apr 18 2009, 11:58 am

Newsgroups: comp.editors From: DMcCunney <dennis.mccun...@gmail.com> Date: Sat, 18 Apr 2009 09:58:39 -0700 (PDT) Local: Sat, Apr 18 2009 11:58 am Subject: Re: How many other editors in use Print | Individual message | Show original | Report this message | Find messages by this author Coming late to this party...

I think which editor you use depends upon where you start and what you grow accustomed to.

For instance, the first editor I used was back in the late 70's at a bank. It was a product called ACEP, intended to replace TSO/SPF on IBM mainframes running OS/VS1 and OS/MVS (now zOS). It was accessed through 3270 terminals or compatibles. 3270s were "block-mode" terminals, not character mode, and had a completely different idea of full-screen editing than what most people think of. On a 3270, you moved the cursor around the screen, made changes, pressed the Submit key, and the entire *screen* was sent to the host. ACEP's developers developed under Unix, and it had features inspired by Unix. When my shop replaced ACEP with "real" TSO/SPF, I thought it a step backward.

This was back when the IBM PC was first becoming popular in corporate environments, and Lotus 1,2,3 was forcing everyone to upgrade theier 256KB PCs to a full 640KB of RAM to accomodate huge Lotus spreadsheets. So the second editor I learned was WordStar. Back then, WordStar was probably the second editor you learned, because the one you preferred might not be available on the machine you had to use, but WordStar probably was.

The third editor I learned was vi, because I left the bank and found myself working for a small Unix systems house. This was the early 80s, and Vim wasn't around -- vi was the original Bill Joy product, running under AT&T System V. Vi was a rude shock, until I started to grasp the design concepts, whereupon it made sense. (And I found a set of macros that made the arrow keys work in insert mode, which eased a lot of the pain...)

Vi and WordStar shared.a design concept: they were keyboard independent. If you had a qwerty keyboard with a Control key, you could use them. It made sense, because a lot of odd things got used as terminals on early Unix systems, some of which didn't *have* arrow keys or F-keys, and there was almost as much variation in the early CP/ M systems on which WordStar originated.

As I started using PCs more, back in the MS-DOS days, I kept some WordStar fluency because many PC editors either used the WordStar command set or could be told to. For that matter, I loaded a WordStar emulation package in Gnu Emacs on *nix boxes to avoid retraining my fingers, and wrote a WordStar emulation macro package for the MicroEMACS editor I ran on the PC.

In the process, I got interested in editor design and implementation, and collected them. I have a hundred or so here for various platforms, and am aware of many more. (Like, someone actually wrote a partial vi clone for the Commodore 64...)

Which I use depends on what I'm doing. My standard editor on the PC under Windows XP is Don Ho's Notepad++, with a tabbed interface and based on Neil Hodgson's Scintilla edit control, which provides code folding and syntax highlighting for a large number of languages. http://http://notepad-plus.sourceforge.net/uk/site.htm

On Solaris, I use vi. On some flavors of Linux, I use Vim, but I might as well be using vi - I have no need for and have never used most of the fancy features Vim implements.

There are a number of other things in the mix. For instance, I have an old Fujitsu Lifebook running Puppy Linux. Puppy is intended for lower end hardware (and thre are people reporting running it on P200s with 64MB of RAM). The Puppy devs make a point of a small distribtion (the ISO is about 100MB), and do various things to save space. For instance, Albrecht Kliene's e3 editor is bundled and linked as vi for console usage. e3 partially emulates vi, emacs, WordStar, Pico, and Nedit. Which personality it assumes depends upon which name it was called by. http://www.sourcefiles.org/Editors/Console/e3-2.7.0.tar.gz - tarball with source and binaries for DOS, Windows, Linux, and *BSD

The standard GUI editor on Puppy is Geany, a cross-platform editor based on Scintilla, with tabbed interface, code folding, and syntax highlighting. http://www.geany.org/Main/HomePage

There are a few things I'm looking at in the background but don't use regularly. One is IBM's open source Eclipse IDE. Eclipse is written in Java, and will run on anything with a current Sun JVM. While intended for Java development, it can be used for a large number of other languages, and is extensible through plugins. Eclipse seems to have largely killed off the commercial IDE market. MS Visual Studio is still out there for the Windows only folks, and Embarcadero Technologies (formerly Codegear, formerly Borland's compiler and tools division) still offers things like C++ Builder and Delphi, but they seem to be catering to an existing market which is too deeply embedded to make switching easy. Everyone else just opts for the free, open source product. :-) http://www.eclipse.org

Another interesting direction is ActiveState's Komodo Edit, which is an open source component of their commercial Komodo IDE. Komodo is built on the Mozilla code base, using the Gecko rendering engine to display the editor on the screen. Because it's based on Mozilla code, it's cross platform, and it can be be customized with themes and extensions. Komodo incorporates Scintilla, so code folding and syntax highlighting are part of the package. http://www.activestate.com/products/komodo_edit/

There are over 1,000 different text editors out there for various platforms, based on a variety of paradigms and intended uses. I don't believe in a "one-size-fits-all" editor, and use what best suits what I'm doing at the moment. I roll my eyes at emacs vs vi Holy Wars.

Folks interested in exploring a bit should visit http://TextEditors.org, a wiki devoted to the topic. If you know of something not listed, or have updates/corrections for stuff that is listed, please add them.

______ Dennis

[Mar 05, 2011] would like a recipe to pull down a free online book - 2

10-09-2010 | MobileRead

DMcCunney

I wish the new Lisp version John Graham et al are working on would move beyond the experimental and "in flux" stage already, and continue to make an interpreter that can somehow make use of all the useful Python libraries

Like he points out himself; Lisp isn't much in use, cause except for command shell scripts, its tough to use for real world stuff, cause there's not much in the way of libraries... I don't know about the interpreter / compiler situation

I liked Dr. Nikolai Bezroukov's commentary in his commentary on editors on his Softpanorama website. He talked about macro languages for text editors, and was less than thrilled with Emacs using a dialect of Lisp, because he felt the language ought to have some use ouside of the editor, and what other use of Lisp did the majority of Emacs users make? Eric S. Raymond was going on a while back about what Emacs got wrong, and how much better Python would be for the purpose. When I said "So rewrite Gnu Emacs to use Python instead of Lisp." the response was "Don't tempt me..."

I have to agree. I have Gnu Emacs here, but the only use I made of elisp was years back, learning enough to hack my .emacsrc to properly support the various special keys on the machine I was running it on. I've had no cause to touch it since.

Dennis

[May 9, 2008] What is a folding editor

Most folding capabilities in editors such as GNU Emacs and most folding editors such as Origami and fe, are inspired by the Inmos Transputer Development System. After several years, folding/outlining capabilities in text editors are not as exotic as they used to be, but they are still far from being well known. This document explains what "folding" is all about.

A folding editor extends the principle of tree structured directories to editing text files. This allows the simultaneous display of large amounts of text by folding sections of text away behind a descriptive heading. This results in a tree structure very similar to a subdirectory structure of, for example, UNIX. By suitable structuring of a text it should be possible, in most circumstances, to ensure that no display exceeds a single screen at any time. To access text that is folded away, you open the fold, in which case the contents are displayed in context of the surrounding text. The advantage of this system is that it eliminates the need for seemingly endless paging through long files to find the section of interest, allowing you to move down the tree structure, following the (hopefully) descriptive headers to locate the text you require.

[May 9, 2008] Code Browser - A Folding Text Editor

Code Browser supports only the marker-based folding.  See  Introduction to Folding page  for the explanation.

Code Browser is a folding text editor for Linux and Windows, designed to hierarchically structure any kind of text file and especially source code. It makes navigation through source code faster and easier.

Code Browser is especially designed to keep a good overview of the code of large projects, but is also useful for a simple css file. Ideal if you are fed up of having to scroll through thousands of lines of code.

See the Introduction to Folding page if you want more information on text folding and the way it is implemented in Code Browser.

It supports syntax highlighting for all major languages and custom syntax highlighting can also be added.

Although Code Browser was initially designed to edit programs, it can also be used for different tasks such as plain text outlining or understanding existing source code. I've added a page with tips on alternative uses.

freshmeat.net Project details for Cooledit

Cooledit is a text editor for the X Window System. It contains a built-in Python interpreter for macro programming, and it includes a rich set of utilities and features. It has multiple edit windows and a beautiful, intuitive user interface that requires no tutoring to learn to use. It can be used as a programmer's IDE and has syntax highlighting for a large number of programming languages. It contains an interactive graphical debugger for C/C++ programs.

Code Browser

Code Browser is a folding and outlining editor for Linux and Windows.

The editor is between a traditional text editor, a smalltalk class browser and a web browser like mozilla. It displays a structured text file (marker-based folding) hierarchically using multiple panes.

It is especially designed to keep a good overview of the code of large projects. Ideal if you are fed up of having to scroll through thousands of lines of code.

See the Introduction to Folding page if you want more information on text folding and the way it is implemented in Code Browser.

It supports syntax highlighting for all major languages and custom highlighting can also be added. For other editor's features, see Features.

Although Code Browser was designed to write and maintain programs, it can be used for different tasks such as plain text outlining or understanding existing source code. I've added a page with tips on alternative uses.

ConText Editor 

A very interesting Windows editor. Flexible customizable syntax highlighting. Well organized features

This syntax highlighting editor supports numerous programming languages including C/C++, Delphi, Pascal, Java, JavaScript, Visual Basic, Perl, HTML, SQL, FoxPro, 80x86 assembler, Python, PHP, Tcl/Tk, etc (you can customize the syntax highlighting). Other features include code templates, customizable help files for each file type, export to HTML/RTF, file conversion (DOS, Unix, MAC), bookmarks, commenting, uncommenting code, capturing the output from console applications, etc. It's a Windows editor.

CUTE User-friendly Text Editor

CUTE is a text editor that is extensible using Python. It supports projects, syntax highlighting of various programming languages (C, C++, C#, Java, Python, JavaScript) as well as HTML (etc), multiple documents (tabbed or child frame), ctags, auto-completion, search and replace with regular expressions, bookmarks, undo/redo, has an integrated file browser, themes, key macros, etc. Binaries (executables) are available for Linux. The source code is released under the GPL and can be compiled for Windows

Linux.com Some Linux apps are small wonders 

13K in size for the editor that's something from DOS era :-).  It is  written in NASM assemblerThat's a great achivement and it refreshing to see that not all useful software is bloatware !!!

e3 text editor

The e3 console text editor takes minimalism to the max - the binary is a minuscule 13KB in size! So why use this instead of [insert the name of your favorite editor here]? If you're anything like me, you'll find a lot of your editing tasks are very short -- little more than tweaks. e3 starts instantly and has all the basic features you could want, including find/replace, block cut/copy/paste, and undo. For complex tasks I use a more feature-packed program, but for a quick change to /etc/fstab or something similar, this little editor wins every time.

e3 also does its best to be ubiquitous. It works on a whole host of operating systems, and perhaps best of all, it supports keyboard mappings that emulate WordStar, Pico, emacs, vi, and Nedit. You can hardly fail to feel at home with it.

Exuberant Ctags Version 5.5.2 [17 September 2003]

[Sept 12, 2003] The Right Size for an Editor

Eric Raymonds view on the subject. IMHO he did not understand the real tradeoffs that make vi a great editor for so many years, but he at least is able to site right people ;-). With all due respect to RMS, Emacs is definitely anti-Unix type of editor :-).

Is Emacs an Argument against the Unix Tradition?

The traditional Unix view of the world, however, is so attached to minimalism that it isn't very good at distinguishing between the adhocity-trap problems of vi and the optional complexity of Emacs.

	The reason that vi and emacs never caught on among old-school Unix programmers is that they are ugly. This complaint may be “old Unix” speaking, but had it not been for the singular taste of old Unix, “new Unix” would not exist.
-- Doug McIlroy

Attacks on Emacs by vi users — along with attacks on vi by the hard-core old-school types still attached to ed — are episodes in a larger argument, a contest between the exuberance of wealth and the virtues of austerity. This argument correlates with the tension between the old-school and new-school styles of Unix.

The “singular taste of old Unix” was partly a consequence of poverty in exactly the same way that Japanese minimalism was — one learns to do more with less most effectively when having more is not an option. But Emacs (and new-school Unix, reinvented on powerful PCs and fast networks) is a child of wealth.

	As, in a different way, was old-school Unix. Bell Labs had enough resources so that Ken was not confined by demands to have a product yesterday. Recall Pascal's apology for writing a long letter because he didn't have enough time to write a short one.
-- Doug McIlroy

Ever since, Unix programmers have maintained a tradition that exalts the elegant over the excessive.

The vastness of Emacs, on the other hand, did not originate under Unix, but was invented by Richard M. Stallman within a very different culture that flourished at the MIT Artificial Intelligence Lab in the 1970s. The MIT AI lab was one of the wealthiest corners of computer-science academia; people learned to treat computing resources as cheap, anticipating an attitude that would not be viable elsewhere until fifteen years later. Stallman was unconcerned with minimalism; he sought the maximum power and scope for his code.

The central tension in the Unix tradition has always been between doing more with less and doing more with more. It recurs in a lot of different contexts, often as a struggle between designs that have the quality of clean minimalism and others that choose expressive range and power even at the cost of high complexity. For both sides, the arguments for or against Emacs have exemplified this tension since it was first ported to Unix in the early 1980s.

Programs that are both as useful and as large as Emacs make Unix programmers uncomfortable precisely because they force us to face the tension. They suggest that old-school Unix minimalism is valuable as a discipline, but that we may have fallen into the error of dogmatism.

There are two ways Unix programmers can address this problem. One is to deny that large is actually large. The other is to develop a way of thinking about complexity that is not a dogma.

Our thought experiment with replacing Lisp and the extension libraries gives us a new perspective on the oft-heard charge that Emacs is bloated because its extension library is so large. Perhaps this is as unfair as charging that /bin/sh is bloated because the collection of all shellscripts on a system is large. Emacs could be considered a virtual machine or framework around a collection of small, sharp tools (the modes) that happen to be written in Lisp .

On this view, the main difference between the shell and Emacs is that Unix distributors don't ship all the world's shellscripts along with the shell. Objecting to Emacs because having a general-purpose language in it feels like bloat is approximately as silly as refusing to use shellscripts because shell has conditionals and for loops. Just as one doesn't have to learn shell to use shellscripts, one doesn't have to learn Lisp to use Emacs. If Emacs has a design problem, it's not so much the Lisp interpreter (the framework part) as the fact that the mode library is an untidy heap of historical accretions — but that's a source of complexity users can ignore, because they won't be affected by what they don't use.

This mode of argument is very comforting. It can be applied to other tool-integration frameworks, such as the (uncomfortably large) GNOME and KDE desktop projects. There is some force to it. And yet, we should be suspicious of any ‘perspective’ that offers to resolve all our doubts so neatly; it might be a rationalization, not a rationale.

Therefore, let's avoid the possibility of falling into denial and accept that Emacs is both useful and large — that it is an argument against Unix minimalism. What does our analysis of the kinds of complexity in it, and the motives for it, suggest beyond that? And is there reason to believe that those lessons generalize?

Recommended Links

Softpanorama Recommended

• Description of Folding

• What is a folding editor-

• Code Browser - Introduction

• Moolenaar.net - Vim Seven habits of effective text editing

  • the paper in plain text (14 Kbyte).

  • the paper in MS-Word (43 Kbyte).

  • the paper in compressed PostScript (47 Kbyte).

  • the paper in PDF (24 Kbyte).

  • the presentation in Powerpoint (156 Kbyte).

  • the presentation in compressed PostScript (228 Kbyte).

  • the presentation in PDF (205 Kbyte).
     

See also

• Softpanorama Society Orthodox File Managers Site

• Eastern Orthodox editors

• Western Orthodox Editors

• TCL-based editors

• Lightweight Win32 Editors

• Heavyweight Editors: alternatives to the MS Word

Top

• Open directory Editors page -- all major editors are mentioned with current links to each. Good starting page!
• Vim Cookbook
• DaveCentral Programming - Text Editors, Page 1
• Sinsite -public-ftp-pub-Linux-apps-editors-terminal
• Linux Applications and Utilities Page - Programming
• Freshmeat Console-Editors
• Freshmeat X11-Editors
• X-apps FAQ II. X-based Editors
• [July 15, 1999] Ailanto Editing & Textprocessing -- very nice collection of links. The author seems to be VI enthusiast. This collection has a lot more editors listed, that on this Softpanorama page. Suggested by Tom Moran.
• There is A Perfect Editor  by Bruce Ediger  --- an good bibliography of research papers dealing with editor design, usability, interface, etc. The author personally prefers Vim ;-)

• Text Editor Compendium (v2.07) -- by Roger Nelson  -- very interesting comparison tables.

  • program.htm -- Programmer features comparison table. He list several features that are really important and thus the table can serve as a guide for the selection of the editor

• SAL -- Office Software - Text Editors -- ( Kachina Technologies site) another collection of links. Each editor listed has small annotation. I checked a couple and it looks like annotations are correct and useful.

•  Tcl Resource Center: software.applications.editor -- list of TCL-friendly editors

• PERL Reference/Editors -- a very useful page -- contains information about Perl enabled editors. Not much but better than nothing

• Text Editors For Linux

• QRG UNIX 10.Text editors and browsers -- quick reference guide for linux
•  Ailanto: Editing & Textprocessing
•  Goldshell is the home of: DirSaver, FlashForga, Hoolicon, Pedit -- freeware DOS editor
•  OS/2 Warp on the 'Net, Software Developers, Utilities. -- some russian developers
•  FreeBSD Ports: Editors

• GS31 Unix Editors An Overview

• X-apps FAQ II. X-based Editors

• The Programmers Vault - Programming Downloads

• UNIX Linux OS2 Dos Editors

• exuberant ctags -- Darren Hiebert's page.

  Ctags generates an index (or tag) file of C language objects found in C source and header files that allows these items to be quickly and easily located by a text editor or other utility. A tag signifies a C language object for which an index entry is available (or, alternatively, the index entry created for that object).

  Alternatively, ctags can generate a cross reference file which lists, in human-readable form, information about the various objects found in a set of C language files.

  Tag index files are supported by the vi editor and its derivatives (such as vim, elvis, stevie, xvi) through the use of the ":ta" command, and by the emacs editor through the use of the "Meta-." command, both of which locate the object associated with a name. There are other a number of other editors which support tag files. A list of these is found here.

• Editors - Popular Editors as on comp.editors --by  Sven Guckes Includes small annotations and links to the foolowing editors:  bingo, crisp, ee,  asyedit, fte, jed, medit,  mined,  nedit, qedit, slickedit ,THE

Design issues:

• Interface Hall of Fame
• MICO

  The acronym MICO expands to MICO Is CORBA. The intention of this project is to provide a freely available and fully compliant implementation of the CORBA 2.2 standard. MICO has become quite popular as an OpenSource project and is widely used for different purposes (see our success stories). Our goal is to keep MICO compliant to the latest CORBA standard. The sources of MICO are placed under the GNU-copyright notice. The following design principles guided the implementation of MICO:

  • start from scratch: only use what standard UNIX API has to offer; don't rely on propietary or specialized libraries.
  • use C++ for the implementation.
  • only make use of widely available, non-proprietary tools.
  • omit bells and whistles: only implement what is required for a CORBA compliant implementation.
  • clear design even for implementation internals to ensure extensibility.

• Wishlist for KDE 1.x2.0 main page
• EMACSulation LG #27 -- ediff capability
• EMACSulation Issue 26 -- emacs internet capability
• EMACSulation LG #25 -- transparent compress
• EMACSulation LG #39

Articles

The Craft of Text Editing by Craig A. Finseth -- free e-book

Preface
Introduction: What Is Text Editing All About?
Chapter 1: Users
Chapter 2: User Interface Hardware
Chapter 3: Implementation Languages
Chapter 4: Editing Models
Chapter 5: File Formats
Chapter 6: The Internal Sub-Editor
Chapter 7: Redisplay
Chapter 8: User-Oriented Commands: The Command Loop
Chapter 9: Command Set Design
Chapter 10: Emacs-Type Editors
Epilogue
Appendix A: A Five-Minute Introduction to C
Appendix B: Emacs Implementations
Appendix C: The Emacs Command Set
Appendix D: The TECO Command Set
Appendix E: ASCII Chart
Bibliography
Book Index

• ****There is A Perfect Editor  Compiled by Bruce Ediger

  "The comparison of widely varying text editors
  has only recently evolved beyond
  subjective preference and name-calling."
  - Nathaniel S. Borenstein, 1985

  The "My editor is better than your editor" argument easily comprises the longest-running continuous argument in computer programming. One can easily dismiss most of the common arguments on the topic, since the argument-makers appear ill-informed, no definitions of terms ever get offered or agreed-upon, hidden assumptions riddle the arguments and subjective preference carries more weight than experiment. Nevertheless, editor users bring up important points on ease-of-use, editing power, and what sort of interface an editor possesses. Despite endless discussion, poorly-formed concepts like "easy", "powerful", "consistent" "intuitive" and their opposites appear in most of the arguments. No two arguers agree on what the terms mean.

  In order to form more perfect arguments, I present a first cut at a bibliography of real research that seems directed toward finding the perfect editor. I did not perform an exhaustive literature search, so please inform me of any missing citations. I'm missing electronically-retrievable forms for almost all of these papers.
  
  

• ***** Anti-Mac -- an interesting critique of MAC-style graphic interface
   

• ***** Science Fiction Writer Robert J. Sawyer WordStar A Writer's Word Processor

  WordStar was first released in 1979, before there was any standardization in computer keyboards. At that time, many keyboards lacked arrow keys for cursor movement and special function keys for issuing commands. Some even lacked such keys as Tab, Insert, Delete, Backspace, and Enter.

  About all you could count on was having a standard QWERTY typewriter layout of alphanumeric keys and a Control key. The Control key is a specialized shift key. When depressed simultaneously with an alphabetic key, it causes the keyboard to generate a specific command instruction, rather than the letter. The control codes are named Ctrl-A through Ctrl-Z (there are a few punctuation keys that can generate control codes, too). Control codes are frequently indicated in text by preceding the letter with a caret, like so: ^A.

  WordStar's original designers, Seymour Rubenstein and Rob Barnaby, selected five control codes to be prefixes for bringing up additional menus of functions: ^O for On-screen functions; ^Q for Quick cursor functions; ^P for Print functions; ^K for block and file functions; and ^J for help.

  Now, the first three of these are alphabetically mnemonic. The last two, ^K and ^J, might at first glance seem to be arbitrary choices. They aren't. Look at a typewriter keyboard. You'll see that for a touch typist, the two strongest fingers of the right hand rest over ^J and ^K on the home typing row. WordStar recognizes that the most-often-used functions should be the easiest to physically execute.

  To serve as arrow keys for moving the cursor up, left, right, or down, WordStar adopted ^E, ^S, ^D, and ^X. Again, looking at a typewriter keyboard makes the logic of this plain. These four keys are arranged in a diamond under the left hand:

                                E
                               S D
                                X

  Such positional, as opposed to alphabetic, mnemonics form a large part of the WordStar interface. Additional cursor movement commands are clustered around the E/S/D/X diamond:

                              W E R
                             A S D F
                              Z X C

  ^A and ^F, on the home typing row, move the cursor left and right by words. ^W and ^Z, to the left of the cursor-up and cursor-down commands, scroll the screen up and down by single lines. ^R and ^C, to the right of the cursor-up and cursor-down commands, scroll the screen up and down a page at a time (a "page" in the computer sense of a full screen of text).

  ^Q, the aforementioned quick-cursor-movement menu prefix, extends the power of this diamond. Just as ^E, ^S, ^D, ^X move the cursor up, left, right, and down by single characters, ^QE, ^QS, ^QD, and ^QX move it all the way to the top, left, right, or bottom of the screen. ^W scrolls up one line; ^QW scrolls up continuously. ^Z scrolls down one line; ^QZ scrolls down continuously. And since ^R and ^C take you to the top and bottom of the screen, ^QR and ^QC take you to the top and bottom of the document. There are many more ^Q commands, but I think you can see from this sampling that there is an underlying logic to the WordStar interface, something sorely lacking in many other programs -- particularly WordPerfect.

  Now, for many of these functions there are dedicated keys on IBM PC keyboards. WordStar allows you to use these, if you're so inclined. But touch-typists find that using the WordStar control-key commands is much more efficient, because they can be typed from the home row without hunting for special keys elsewhere on the keyboard. Because of this, many applications, including dBase, SuperCalc, SideKick, CompuServe's TAPCIS and OzCis, Genie's Aladdin, Xtree Pro, and even Microsoft's own editor included with MS-DOS 5.0 and above, have adopted some or all of the WordStar interface.

  Some keyboards have the Control key to the left of the letter A. This makes using WordStar commands very simple. Other keyboards instead have CapsLock next to the A and place the Control key below the left Shift key, making WordStar commands a bit of a stretch. Because of this, WordStar comes with a utility called SWITCH.COM to optionally swap the functions of the CapsLock and Control keys. One of the problems with other word-processing programs is that many commands can only easily be issued through function and dedicated cursor keys, and the locations of these keys changes radically from keyboard to keyboard (for instance, function keys are sometimes arrayed as two columns of five on the left-hand side of the keyboard and sometimes as a continuous row across the top of the keyboard; cursor keys are sometimes clustered in a diamond and sometimes laid out in an inverted-T shape; on laptop computers you may have to press a special "Fn" key in combination with the arrow keys to access PgUp and other functions, making using these programs an exercise in contortion). But all one has to do to make any keyboard an optimal WordStar keyboard is run the CapsLock / Control switcher, if necessary. The locations of the other keys are irrelevant, because you don't need them for WordStar.

  On the other hand, WordPerfect's interface forces touch typists to constantly move their hands from the home typing row, slowing them down. To issue a WordPerfect command, you must first press a function key, either separately, or simultaneously with a Control, Shift, or Alt key. Then, for many functions, you must select a sub-function. Now that your hands have moved to the bank of function keys, can you select your sub-function using them as well? You cannot. Rather, you must next reposition your hands to the numeric keys and select your sub-function by number. Finally, you must re-orient your hands on the home row before continuing typing (recent versions of WordPerfect attempt to smooth out this tortuous interface, but it's still difficult to use).

   

• Linux Text Editors and A New One by Oleg L. Machulskiy machulsk@shade.msu.ru
  

• Conceptual Program Editors
  

• Thomas W. Reps's Home Page -- Program Slicing, Differencing, Merging, etc.
  

• Word Processing vs. Text Processing
  

• What has WYSIWYG done to us -- choose a version by by Conrad Taylor

Folding

See also: Eastern Orthodox Editors (Xedit/Kedit/THE) are probably the oldest (Xedit seems to be around on VM/CMS from early 70th) and the most widely used folding editors. Although it's hard to teach old dog now tricks vim 6.0 will support folding.  I consider folding (actually there are several types of folding -- one is slicing (and in orthodox editors command All, the other is outlining as implemented in Ms Word and other word processors and some HTML-editors) an extremely useful feature. Once you have got used to the folding paradigm, you will not want to use a flat editor again! That's why I consider EOE family of editors so important.  Franz J. Kurfess -- Master's Project Topics at NJIT   include folding

comp.programming.literate FAQ

9.5. Fold2Web

Developer: Bernhard Lang <lang@tu-harburg.d400.de>
Version: V0.8
Hardware: MSDOS
Languages: All (must allow comment lines)
Formatter: LaTeX
Availability: Anonymous ftp from:
kirk.ti1.tu-harburg.de (134.28.41.50)
/pub/fold2web/readme
/pub/fold2web/fold2web.zip
Readme: In distribution

Description:

The idea behind the Fold2Web tool is the following: A programmer can write his program source with a folding editor and later map the folded source files automatically to WEB-files. The generated WEB-files can then be modified by inserting required documentations.

The advantage by starting program developement with original sources is to get short design cycles during the compile/debug steps. By using a folding editor the global structuring information can be already captured in folds during this developement phase. Fold information is typically stored in comment lines and thus will not affect the
efficiency of the compile/debug design cycle.

Some folding editors and a folding mode for the emacs are available (e.g. see our FUE folding editor for MSDOS machines which is a modified micro emacs. Pick it at kirk in directory /pub/fold2web).

After reaching a stable version of a program source its time to convert the source file to a WEB-file and do the program documentation. Fold2Web is written to convert folded source text of any programming language to nuweb files. The folded structure is kept by mapping folds to scraps. Fold markers which differ between languages due to different ways of specifying comments can be configured for each language.

Good results can also achived when given but poor documented program sources have to be modified. Such sources can be folded using a folding editor to extract the global structures. This offers a global view tothe program structures and help to understand its functionality. Furthermore the program code is not affected, only comment lines are
inserted. Once folded the program source can be automatically translated to a WEB document using the above tool.

Illustrative Browsing A New Method of Browsing in Long On-line Texts

Fe User Guide

A few words on the design of fe

After working with Origami for many years, both as user and developer, I have decided to implement a new folding editor: fe. There are a few basic design decisions which make it different from Origami:

Origami is partially written in its extension language. While being more of a hack in the beginning, it has changed to a full programming language. As such, it takes time to be learnt. Code written in it is not well usable by most people who don't know it. The conclusion for fe is not to support any extension language, neither a homebrew one or a standardised language, like scheme. Instead, fe is implemented as a library of basic editor primitives. Its is easy to write your own editor by using that library. fe can be modified easy without having to learn a new programming language. The editor also stays small and elegant this way, while Origami has to offer zillions hooks for extension functions.

Origami implements folds as double-linked n-trees, with nodes being single lines or folds. This allows quick manipulation of folds or lines. But region oriented functions become hard to implement and are mostly not too quick any more. fe uses a gap buffer to store text, folds are represented as meta-characters in the flat buffer. This means basic fold primitives are slower than in Origami, but more complex and region oriented functions are faster. During development of the first prototype of fe, I found many functions in Origami not to be as canonical as they should be after I implemented them in fe. From my past experience, the performance of typical personal computers to have increased by a factor of 10 every 5 years in the last decade, so the circumstances for editor design have clearly changed over time.

Folding has its merits, because it adds a structure to flat files. But, it also means that by bad structure design and badly commented folds the file will get harder to understand, not easier. This can happen up to the point where you want all folds to be gone to see what the file contains. If you need to keep many folds open during development to see their contents, you are probably preparing that situation at least for others. Although in general I don't like programs forcing me to do something, fe makes an exception here for two reasons: If the structure is obvious, you want the editor to close folds for you automatically. If it is not, you want to recognize that before it is too late. For that reason, fe closes all folds when you leave them. If you want to transport code from one fold to another, just split the current display and edit the file at two places. If both places are sufficient far away from each other, that's what you even had to do if you could leave folds open. \"}}}

Richard King Home Page

Published Papers

A user interface for a multi-user folding editor

Animation techniques for folding editors

Masters Thesis

What is a folding editor -- not very correct, but still interesting discussion

Most folding capabilities in editors such as GNU Emacs and most folding editors such as Origami and fe, are inspired by the Inmos Transputer Development System. After several years, folding/outlining capabilities in text editors are not as exotic as they used to be, but they are still far from being well known. This document explains what "folding" is all about.

A folding editor extends the principle of tree structured directories to editing text files. This allows the simultaneous display of large amounts of text by folding sections of text away behind a descriptive heading. This results in a tree structure very similar to a subdirectory structure of, for example, UNIX. By suitable structuring of a text it should be possible, in most circumstances, to ensure that no display exceeds a single screen at any time. To access text that is folded away, you open the fold, in which case the contents are displayed in context of the surrounding text. The advantage of this system is that it eliminates the need for seemingly endless paging through long files to find the section of interest, allowing you to move down the tree structure, following the (hopefully) descriptive headers to locate the text you require.

Internet Parallel Computing Archive Tools Editors Folding-editors -- links to several implementations

Hybris -- a very interesting implementation of scrollable nesting -- it's actually more looks like outlining, but probably can be used for folding. anyway this is something new and no other editor seems to be able to do the same trick.

GRASP Graphical Representations of Algorithms Structures and Processes -- the idea of syntax diagrams

JED -- the latest version has folding

Internet Parallel Computing Archive Tools Editors Folding-editors -- I believe that folding is a must for any editor. Here we have slightly outdated and incomplete collection of relevant links.

Fe User Guide   -- A Folding Editor, which aims to be fast and small.

After working with Origami for many years, both as user and developer, I have decided to implement a new folding editor: fe. There are a few basic design decisions which make it different from Origami:

Origami is partially written in its extension language. While being more of a hack in the beginning, it has changed to a full programming language. As such, it takes time to be learnt. Code written in it is not well usable by most people who don't know it. The conclusion for fe is not to support any extension language, neither a homebrew one or a standardised language, like scheme. Instead, fe is implemented as a library of basic editor primitives. Its is easy to write your own editor by using that library. fe can be modified easy without having to learn a new programming language. The editor also stays small and elegant this way, while Origami has to offer zillions hooks for extension functions.

Origami implements folds as double-linked n-trees, with nodes being single lines or folds. This allows quick manipulation of folds or lines. But region oriented functions become hard to implement and are mostly not too quick any more. fe uses a gap buffer to store text, folds are represented as meta-characters in the flat buffer. This means basic fold primitives are slower than in Origami, but more complex and region oriented functions are faster. During development of the first prototype of fe, I found many functions in Origami not to be as canonical as they should be after I implemented them in fe. From my past experience, the performance of typical personal computers to have increased by a factor of 10 every 5 years in the last decade, so the circumstances for editor design have clearly changed over time.

Folding has its merits, because it adds a structure to flat files. But, it also means that by bad structure design and badly commented folds the file will get harder to understand, not easier. This can happen up to the point where you want all folds to be gone to see what the file contains. If you need to keep many folds open during development to see their contents, you are probably preparing that situation at least for others. Although in general I don't like programs forcing me to do something, fe makes an exception here for two reasons: If the structure is obvious, you want the editor to close folds for you automatically. If it is not, you want to recognize that before it is too late. For that reason, fe closes all folds when you leave them. If you want to transport code from one fold to another, just split the current display and edit the file at two places. If both places are sufficient far away from each other, that's what you even had to do if you could leave folds open.

Andys Source Code Folding Editor -- a language configurable folding source code editor

• AE documentation - Introduction 

  This editor was designed as a language configurable folding source code editor. A page describing the concepts involved is provided, and also a full list of all the editing primitives supported, with an index for speed.

  This editor provides these features :

  • Folding, the ability to group lines into a larger 'meta-line'.
  • Block operations.
  • Yank and put model for line copying etc.
  • Deleted item stack to allow multiple undeletes.
  • Extended Regular Expression searching.
  • Multiple buffers at any one time.
  • Portability across many environments.
  • Bracket matching.
  • User configurable key binding.
  • Shelling out to and filtering through operating system commands.
  • The editor is relatively small for what it does.

Salon 21st The Xy files BY AMY VIRSHUP |

FOR THE REST OF THE WORLD, XYWRITE IS HISTORY --
BUT TO ITS DEVOTEES, THE ANTIQUATED WORD PROCESSOR STILL RULES.

 Not long ago, a writer friend and I were talking software (there's a sentence I never thought I'd write) -- specifically whether we were Luddites for resisting a Windows 98 upgrade. Well, she said, she hardly felt out-of-date, since most of her publishing-world friends were still using XyWrite. I was stunned. I hadn't even heard the name in years, and suddenly I'd learned that, in a world in which six months is a generation, there lingered a dedicated cadre of loyalists to a program that hasn't been upgraded since 1993, that still runs best in DOS, that isn't compatible with most printers, and that has all but vanished as a commercial product. It was like finding out that a cargo cult was operating down the hall from my apartment.

For those of you unfamiliar with XyWrite -- the "GOD of word processors," as one poster to alt.folklore.computers recently put it -- the program was an offshoot of ATEX, which in the '80s was the standard in newspaper and magazine editorial hardware and software. It was created in 1982 by an ATEX programmer named David Erickson, who'd bought a PC and was unhappy with the word processor that came with it. So Erickson decided to write his own, and not long after he and another employee left ATEX to set up shop as XyQuest.

XyWrite was fast, it could do things no other word processor at the time could (like open two windows simultaneously), and because of the nature of the underlying programming language, XPL, it could be endlessly customized. The screen was a blank page with a command line at the top (hitting F5 would take you there), and when you wanted XyWrite to do something, you simply typed in an English-language command (such as "print" to print a file) or used one of your own custom keystrokes to carry out the task. It was defiantly not a "what you see is what you get" program, but it was extremely transparent, with all the formatting information easily viewable. And it was an instant hit among professional writers and editors, many of whom, um, borrowed their copies from their employers on a single 5 1/4-inch floppy -- mine, I confess, came from New York magazine, circa 1984.

Nancy Friedman was editorial director at Banana Republic when the clothing retailer started using XyWrite (version 2). "I loved it," says Friedman. "All of a sudden I was using this program that thought the way a writer thinks. All other word processing programs were created for secretaries -- they're all about creating standard one page documents. This one really expected that I was doing sophisticated editing and writing."

High-profile devotees included television's Brit Hume, John Judis of the New Republic and high-tech guru Esther Dyson. Critics called it the "Porsche 911 Carrera" or the "velociraptor" of word processors. And as much as they admired the software, users also loved the scrappy, down-home nature of the company: Erickson would sometimes answer tech support calls himself, and XyQuest was headquarted in decidedly unglamorous Billerica, Mass. "I was always so happy driving through Billerica knowing they were working to update XyWrite," remembers one writer who had occasion to pass through town in XyWrite's heyday. "It sounds so dopey, but that's how it was."

But XyQuest's marketing was never as good as its software, and it lacked the resources to compete with the big boys -- like WordPerfect, which the XyWrite faithful held in contempt. Then, in early 1990, IBM stepped in. The computer giant announced it was hooking up with XyQuest to create a new product, called Signature, based on the XyWrite model, and it looked like XyWrite was about to join the commercial mainstream. Instead, IBM delayed the product for a year and a half -- then, with boxes printed and diskettes ready to go, decided it was getting out of the software business altogether. A reconstituted XyQuest tried to sell the program on its own (renamed XyWrite 4), simply slapping stickers over the IBM logos on the boxes, says Tim Baehr, then a XyQuest programmer. But "sales just got lower and lower. We were bleeding money."

Random Findings

Etc

Society

Groupthink : Understanding Micromanagers and Control Freaks : Toxic Managers : Bureaucracies :  Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Two Party System as Polyarchy : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

Skeptical Finance : John Kenneth Galbraith : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Oscar Wilde : Talleyrand : Somerset Maugham : War and Peace : Marcus Aurelius : Eric Hoffer : Kurt Vonnegut : Otto Von Bismarck : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Oscar Wilde : Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 26, No.1 (January, 2013) Object-Oriented Cult : Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks: The efficient markets hypothesis : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2014 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine. This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.

Disclaimer:

The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: June 08, 2014