BTW, is there any ASCII value that we could be sure is never used ? If so it could be used as a trigger to change some rendering attributes. No doubling of size and no big overhead, just an if (Mychar == TriggerValue) check. Just thinking out loud here, it probably would imply various changes to the source like the size of a text block with certain attributes when passed to the render.

_________________

José

@Jose

Please figure out how Olsen can add Folding/Unfolding to CED.

That's what the public wants. Thanks!

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

Quote:

BTW, is there any ASCII value that we could be sure is never used ?

I don't know about ever, but what about ASCII value 7 - The Bell (alarm) Sound?

That shouldn't be used in documents.

_________________
OS4.1 + SAM Flex
RIP my A1XE.. that used to have an appetite for batteries!

@Bean

There's also 0x80 to 0x9F that are unused by the standard character set,

iirc 0x01 to 0x06 should be available for use as they have no use in a text document

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.

Quote:

Can you share what 2 ideas do you have ? It would be a cool interesting thread.

Either that, or people will be bored to death: text editor design and implementation is not the kind of task that fascinates a lot of people

Quote:

Maybe some of us will come up with a brilliant solution if we dedicate some though to it. From what I remember CEd deals with a whole buffer of text as ASCII values and that's why attaching attributes to the data would be difficult right ?

That is correct. The document data in memory does not look any different, in terms of layout, from what's stored on the disk in a file.

Quote:

Is one of the ideas using a LONG instead of a BYTE for characters ?

Actually, I wasn't shooting that high A WORD per character would be sufficient (as long as nobody tries to retrofit Unicode support, but that would open an entirely different, much larger, can of squiggly things). Advantage: editing operations stay very much the same, except that they operate on "characters" of WORD size rather than BYTE size. Disadvantage: will require large rewrites of the editing code to get rid of the size assumptions, and file I/O operations will become more complex.

My other idea was to "cache" what the text output engine already produces: it breaks the text down into single lines while it's printing it to the screen. If you can cache that information, specifically where the lines start and where they end, then you can attach more information to the line data, such as colouring information. Advantage: will not require great changes to the editing code. Disadvantage: keeping the raw text data in sync with the line cache.

Take your pick, which idea do you prefer?

Quote:

BTW, is there any ASCII value that we could be sure is never used ?

No, CygnusEd can be used as a binary editor (a weird one, though). And that pretty much rules out reserving escape characters or escape sequences.

Quote:

Please figure out how Olsen can add Folding/Unfolding to CED.

I'd like to have folding, too (folding is one of the features of TurboText 2.0, which is why I still occasionally use it; it's a pity that it does not support undo/redo like CygnusEd does). One of the ideas I had for changing the text output engine would allow for folding.

Quote:

Upgrades from older versions are available at a reduced price. In order to obtain an upgrade you will need to mail your old CygnusEd floppy disk or CD-ROM to APC&TCP. http://www.apc-tcp.de

I learned the upgrade price was 30 euros but I fear our postoffice
does not understand a link as a physical address. I went to the site
and looked up the contact page so my best guess is:

APC&TCP
Postfach 83
83234 Übersee

Is this a complete address? Presumably if I add Germany to the bottom
they will find it.

Noel

Ok, what about a sequence of ASCII values that never happends, is there any ? I guess not since the editor can be used as a binary editor, but couldn't the syntax highlighting feature be enabled for C/C++ code only for example ?

Last edited by Jose on 08-Jun-2006 at 03:50 PM.

_________________

José

yes, that is our correct adress.

_________________
Andreas Magerl
APC&TCP - Home of Amiga Future
Publisher for Amiga Software, Merchandising and many more.
http://www.apc-tcp.de - https://www.amigafuture.de - https://www.amigashop.org

Quote:

Ok, what about a sequence of ASCII values that never happends, is there any? I guess not

Come on guys ;) The concept of escape characters can't be that unfamiliar.

Quote:

Come on guys ;) The concept of escape characters can't be that unfamiliar.

It's only been around since 1960...

Quote:

BTW, is there any ASCII value that we could be sure is never used ?

PLEASE NO: Cygnus Ed makes a great binary editor, in fact it is unique in this respect as far as I know. This is a major feature of Cygnus Ed - other editors even get confused if the line length is too long, whereas CEd never corrupts a document whatever it contains.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

The only binary editor I have ever used is CygnusED.
It works great!
We used to edit our characters for Might & Magic 2 with it back in the days of yore.

Please don't damage the binary editing capability.

P.S. Please add folding. When working on large sources it is soooooo great!

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

Quote:

PLEASE NO: Cygnus Ed makes a great binary editor, in fact it is unique in this respect as far as I know. This is a major feature of Cygnus Ed - other editors even get confused if the line length is too long, whereas CEd never corrupts a document whatever it contains.

Well, if the lines got too long CygnusEd could corrupt the contents and even crash. At some point a semicolon was magnetically attracted to an overflow check, where it stuck and disabled the test. Back in the old days I remember CygnusEd warned you that you were trying to edit a line that had become too long. At some point the semicolon disabled the test...

I did something about the usable line length in version 5. You can now have lines that are much longer than before, certainly much longer than 16K. And I changed the set of characters which break a line. These are now only ASCII codes 10 (line feed) and 13 (carriage return). Previously, everything with an ASCII code < 32 broke a line.

Ah, well I've used editors which didn't like lines a couple of screens wide! CygnusEd lines could be infinite width by comparison

I had wondered why binary stuff often had short lines, your fix sounds good.

Now, if only I can work out how to order an upgrade...

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

I just placed my order for CygnusEd 5 as well.

I have been using CygnusEd both personally and professionally
for years and own at least four copies of it including two copies
of CygnusEd Professional 4 on CDROM.

A couple of years back I was using it to control the compilation
of software on over 14 UNIX machines from a single A4000T,
and to manage their construction directly from the network back
to the Amiga for mastering on CDROM. All with just the Amiga,
CygnusEd, a custom Arexx script, and one Keyboard Macro.

I ordered a full copy again this time, as I'm unwilling to give up
any of my older copies (they are afterall still in use on other
Amiga machines), and I am happy to support the further
development of this great product still today on OS4!

Best Regards,

Jamie Krueger

_________________
Jamie Krueger
BITbyBIT Software Group LLC
jamie@bitbybitsoftwaregroup.com
PLEASE NOTE: I only speak for myself and my company,
and am not a spokesperson for Amiga Inc.

@olsen

Just another curiosity of mine . I remember someone (maybe you) stating the speed of CE was in part due to it's one char chunk buffer organization. Why should that be faster than an array of arrays in most operations (except stuff like find ). Shouldn't it be even faster when scrolling cause the start of each line is know instead of having to search for line breaks ?

_________________

José

Quote:

I had wondered why binary stuff often had short lines, your fix sounds good.

Actually, the reason behind this particular change is a little different: there is 'C' source code around which contains line feed characters ('\f') which separate sections of interest. These characters were probably added to make it easier to print the code and have it come out neatly separated. Anyway, if you built this code and the 'C' compiler reported the line number in which it found something to report with a warning or error, that line number was not identical to what CygnusEd expected. A 'C' compiler treats the line feed like any other blank space character, and with CygnusEd treating it like a line feed character things got needlessly complicated. Hence the change I made, now that I'd successfully fixed the line length issues.

Quote:

Now, if only I can work out how to order an upgrade...

Updates to the web pages are in the works. So please stay tuned...

Quote:

I remember someone (maybe you) stating the speed of CE was in part due to it's one char chunk buffer organization. Why should that be faster than an array of arrays in most operations (except stuff like find ).

File I/O operations are generally faster because you do not need to perform any pre- or postprocessing on the file involved. You just load it into the prepared buffer, or store the buffer's contents with a single dos.library/Write() call. Search & replace operations also can be faster because you are dealing with what's actually one consecutive string of characters. Of course, the size of the file can degrade the performance if you have to move a lot of data around. Copy & paste operations also can be faster since there is comparatively little overhead in moving data around.

Because the data is stored the way it is, CygnusEd's text manipulation features do not scale very well. If the files are rather small, editing is slick & responsive. Load a much larger file into memory (say, several ten megabytes worth) and the results will be less impressive. I believe CygnusEd works particularly well with documents < 1 MByte, which should be most common.

Quote:

Shouldn't it be even faster when scrolling cause the start of each line is know instead of having to search for line breaks ?

Not only should it be faster, it actually is. When I tested the changes which finally allowed for very long lines of text to be displayed I noticed for the first time what price is paid for the "on the fly" text display function. If you have a line with several hundred thousand characters in it in the middle of a file with shorter lines, text scrolling performance suffers. In fact, dragging the scroller around suddenly ceases to be as responsive as usual and become a bit "sticky".