CopyMem Quick & Small released!

[psxphill]

That is just multitasking unfriendly editor. It is different requirement.

No it is exactly the same requirement as the text editor being able to use as much of your cpu as it wants as long as it can keep up with your typing. If you have other secret requirements that are obvious to you then you should specify them.
 
There may be software running in the background that needs to run at a high priority so that only 50% of cpu is left. The text editor needing 100% of cpu to keep up with typing is now unable to keep up with your typing.

I'm using quite extreme examples because it makes the maths easier, I understand that you can't practically optimise everything completely and there is an upper limit on the cpu resources available.
 
 There are other vague issues like not saying how big the document is when you measure if it's able to keep up. A text editor that is designed for editing large documents will be able to insert and delete text in the middle without CopyMem()'ing the rest of the document around every time you type a character. On windows I regularly edit text files 100's of megabytes in size.

[itix]

No it is exactly the same requirement as the text editor being able to use as much of your cpu as it wants as long as it can keep up with your typing. If you have other secret requirements that are obvious to you then you should specify them.

I thought it was obvious to you that Amiga software should not use busy loops when doing nothing.
 

There may be software running in the background that needs to run at a high priority so that only 50% of cpu is left. The text editor needing 100% of cpu to keep up with typing is now unable to keep up with your typing.

It is matter of evaluating ROI (return of investment). If it is slow for everyone then it might be necessary to optimize. But if it is slow only for one or few users, maybe I would spend my time elsewhere.

I'm using quite extreme examples because it makes the maths easier,

Sure, I got that.

I understand that you can't practically optimise everything completely and there is an upper limit on the cpu resources available.

It is also how much resources you allocate to optimizations versus new features. You can have ultimately optimized fast text editor but poor in features. Or you can have feature rich text editor that is too slow to use. Or you can try to find balnace with optimizations and features.

There are other vague issues like not saying how big the document is when you measure if it's able to keep up. A text editor that is designed for editing large documents will be able to insert and delete text in the middle without CopyMem()'ing the rest of the document around every time you type a character. On windows I regularly edit text files 100's of megabytes in size.

If you choose your algorithm wisely text editor scales up to GB documents easily.

Interestingly, the original Ed found from Workbench 1.3 does not. On Amiga 500 it could not handle even 50 kB text files very well. There was always noticeable lag when inserting new line.

[olsen]

Interestingly, the original Ed found from Workbench 1.3 does not. On Amiga 500 it could not handle even 50 kB text files very well. There was always noticeable lag when inserting new line.

The original Ed managed its text buffer in a very peculiar manner. The entire text was stored in a single consecutive buffer, whose contents had to be moved around prior to inserting text, and after removing text.

Because of how the BCPL memory management worked out, the text was not managed by storing a list of pointers which then referenced the individual lines. Instead, the management data structures were interleaved with the text itself. If you looked at it, you would find that the whole text buffer would be broken down into individual lines, which would begin with a pointer to the next line, followed by the text itself (which would begin with a byte indicating how long the text is). This is one of the reasons why the size of the file managed by Ed is restricted.

Because the text has to be shuffled around, and because there is another layer of management data structures which keeps track of where the first and the last line currently displayed ends up, which lines precede that, etc. every display update and every editing operation kicks off an avalanche of data structure maintenance operations.

The code is clearly optimized so as to minimize the impact of display updates, which was a sensible and necessary strategy back in the 1970'ies when you had one server connected to a bunch of terminals through slow serial links.

The scalability of the implementation is poor, though, and that's because the code is not optimized to minimize the impact of making changes in the document. Even reading and writing files is painfully slow because the editor has to extract the interleaved management/text data in order to store it to disk, and it has to interleave the management/text data when it reads documents from disk.

Here comes the fun part: the operating system which the old "Ed" was a part of was likely written using "Ed" itself. How can you tell? The "Ed" source code is larger than 64K, and the author broke it down into six individual files, presumably in order to keep it manageable. The longest line in that source code is about 105 characters, and almost every line is shorter than 80 characters. The same holds true for the dos.library code, which contains only a few files that are larger than 64K (by 1985 somebody must have used a different text editor, I suppose).

[Thorham]

What an absolutely horrible editor that Ed thing

[psxphill]

I thought it was obvious to you that Amiga software should not use busy loops when doing nothing.

When making a statement that the ONLY thing important with performance of a text editor is it can keep up with typing speed then it's actually not obvious at all. If you are making assumptions about what the statement really means, then you're agreeing with something without actually understanding the point it's making.

By saying there are loads of little implied things that we have to know, then making the statement in the first place is irrelevant as it's trying to say there is only one thing you have to know.
 
 Ed isn't fast enough.

[olsen]

What an absolutely horrible editor that Ed thing

We can only judge the design from today's point of view. Nobody sets out to write a slow, restricted text editor. What drove the design must have made great sense at the time "Ed" was written, but it did not hold up. I suppose even by 1985 the limitations may have become hard to bear.

Or maybe the Amiga as it was back then may have been just as powerful as the minicomputers of the late 1970'ies on which the TRIPOS system, from which AmigaDOS and its shell, commands, etc. derive, was developed, and the constraints we see today did not seem like constraints at all back then. There must have been a reason why TRIPOS was picked for the Amiga, other than there was time pressure and not many other options were available then.

[kolla]

Remember when I discovered that by removing ed-startup, I got a whole lot more menu entries Actually, I like Ed, it seems related to vi. Personally I use vim all day long, which started out on Amiga, I still have a Fish disk somewhere with version 1.0.5 or something like that

[itix]

What an absolutely horrible editor that Ed thing

It is not. If there were not such limits (slowness and max text length) it does its job. I cant remember any of its commands anymore (perhaps esc+x, was it save and quit?) but I used it for a while for coding until I found DME.

@olsen

We can only judge the design from today's point of view. Nobody sets out to write a slow, restricted text editor. What drove the design must have made great sense at the time "Ed" was written, but it did not hold up. I suppose even by 1985 the limitations may have become hard to bear.

For coding its limitations are hard to bear but it was still good to edit startup-sequence or create small text files. After all it was not easy to find replacement text editor... such thing had to be ordered by snail mail from shaddy PD distributors.

[psxphill]

There must have been a reason why TRIPOS was picked for the Amiga, other than there was time pressure and not many other options were available then.

 I think the main consideration was that it was quick to graft it onto exec. If they'd had to wait a long time then they may as well have developed CAOS.
 
 It probably was the only 68000 operating system that they could have used.

[Thorham]

Ed is a crappy editor, period. Why defend the damned thing? If it's so good, then how come no one really uses it for anything? The answer is because it sucks.

Just because some software is old doesn't mean that higher standards don't apply to it, and the platform it had to run on back then can do much better than that. Especially if you have an A500 with one megabyte of memory there's absolutely no reason whatsoever to use Ed.

Really, defending Ed? Why?

[SpeedGeek]

** 2ND NEWS UPDATE **

CMQ&S v1.6 released
v1.6 minor change
- fixed install code which could (but seldom ever did) trash a few bytes
of memory past the end of the patch

CMQ&S040 v1.7 released
v1.7 minor changes
- fixed install code which could (but seldom ever did) trash a few bytes
of memory past the end of the patch
- fixed 4 byte offset on Move16 compare code

[itix]

Ed is a crappy editor, period. Why defend the damned thing? If it's so good, then how come no one really uses it for anything? The answer is because it sucks.

Just because some software is old doesn't mean that higher standards don't apply to it, and the platform it had to run on back then can do much better than that. Especially if you have an A500 with one megabyte of memory there's absolutely no reason whatsoever to use Ed.

Really, defending Ed? Why?

Why not? I could download DME and use it on my Amiga 500 but why bother? For quick text editing Ed does its job. It works, it is reliable, it is small and it is easy to use if you know the commands. Very simple: open text file, edit, save, quit.

Heck, I am even using Pico occasionally to edit some source code files or configs on Linux.

[olsen]

Actually, I like Ed, it seems related to vi.

When I used "vi" for the first time (that must have been around 1991-1992; I never used a Unix system before I went to university), I was puzzled by the fact that some of the control sequences were exactly the same as in "Ed".

Since TRIPOS seems to have had so much in common with early Unix, by way of imitation and reimplementation, you can't rule out that the design of "Ed" was shaped by "vi". Both were created in about the same time frame around 1978. Also, there's another odd "parallel evolution" in that what "Edit" is for "Ed", "ed" is for "vi".

[guest11527]

When I used "vi" for the first time (that must have been around 1991-1992; I never used a Unix system before I went to university), I was puzzled by the fact that some of the control sequences were exactly the same as in "Ed".

Since TRIPOS seems to have had so much in common with early Unix, by way of imitation and reimplementation, you can't rule out that the design of "Ed" was shaped by "vi". Both were created in about the same time frame around 1978. Also, there's another odd "parallel evolution" in that what "Edit" is for "Ed", "ed" is for "vi".

There's actually more stuff like this. Look at the Aztec-C editor "Z" that came with one of the later versions. The same type of crude (aka "unusable") editor. "Ed" has a lot in common with "vi", though the v37 version finally got a menu (which improved usability by about 200%).  

"Ed" was partially ok, good enough to modify the startup-sequence, but not really usable for anything beyond that. "vi" is pretty much the same, and I'm still scared that people use that (or vim) to work on projects, but who am I to judge...  :wq

[olsen]

There's actually more stuff like this. Look at the Aztec-C editor "Z" that came with one of the later versions. The same type of crude (aka "unusable") editor. "Ed" has a lot in common with "vi", though the v37 version finally got a menu (which improved usability by about 200%).

Back in the early days of Amiga programming (that would have been 1987/1988 in my case) it was hard to find a decent programmer's editor.

I knew "Z" but quickly discarded it for being too obtuse. Funny that the Aztec 'C' documentation gave it such prominence, stressing the fact how compatible it was with "vi". I think the defining sentence in the documentation was "if you know vi, then you know Z", which works the other around, too, but not in Z's favour: I didn't have a clue what the documentation was talking about in the first place ("vi"? was that a roman numeral or something? and what does the number six have to do with text editors anyway?) and had to conclude that whatever the authors were so excited about probably wasn't for me.

My first 'C' programs were written using "Ed", until the programs became too large to endure the time it took for "Ed" to read and write them. At some point "Ed" even complained that the file was too large. I could take a hint: if the row of '@' characters "Ed" printed as it read a file was so long that it caused the screen to scroll it was high time to look for something else. The more '@' characters "Ed" printed, the slower it became, like it was climbing a steep hill and sweating & cursing with every step; I held out for more cartoon character swearing but "Ed" never even once admitted that it wanted to use one of "#$&%*", possibly because it was too well bred, coming from a posh British university. I now know that the original "Ed" prefers files to be not much larger than 10.000 characters. I could have used the often overlooked "size" parameter for "Ed", but then again who has that much patience in the long run?

Back then the next best text editor which I could find was on a Fish Disk with a number < 100, written by a French author (if I remember correctly). That too had its limitations. Don't get me started on "Microemacs" which, while it shipped on the Workbench disk, was barely usable either. And then there was "uEdit" (also found on a Fish Disk), which at the time appeared to me to be some sort of science fiction experiment gone terribly wrong. There were other Amiga text editors which I tried along the way. There was something called "SuperEd" which was not only fast, but also had a crash recovery feature (which I learned to appreciate). Then there was strange editor which was ported over from the Atari ST which had a split screen feature that promised to be super wonderful: how odd that it only supported *vertical* split screen (and didn't have a crash recovery feature, which I quickly learned that it ought have had).

These were really tough times. Eventually, I was saved by discovering what still is my Amiga text editor of choice, and in fact would be *the* text editor of choice on any platform, if it were more portable than it is. "CygnusEd" for life

"Ed" was partially ok, good enough to modify the startup-sequence, but not really usable for anything beyond that. "vi" is pretty much the same, and I'm still scared that people use that (or vim) to work on projects, but who am I to judge...  :wq

I suppose "vi" is somewhere in the sweet spot of being quick to launch and (given enough available brain capacity) quickly allows you to commit keystroke sequences to muscle memory. Yes, it's a weird design, but so is the standard keyboard layout. If you learned touch-typing, it's amazing how well you can use that weird layout at great speed. It doesn't work quite so well with more heavy-weight editors such as the original "emacs".

[Thorham]

Lol at Vim (68k AOS).