The Last Word 3.2 Released

[+Stephen]

Thanks for the speedy reply! I wil try a different OS and see if the ATTRACT flag works. It's not a big deal either way.

[flashjazzcat]

Thanks for the speedy reply! I wil try a different OS and see if the ATTRACT flag works. It's not a big deal either way.

Hope so - else we have ourselves the first bug.

 

EDIT: we have indeed. It turns out that if you're not using LW's internal keyboard buffer, the attract toggle doesn't work. The SDX keyboard buffer always overrides LW's buffer, so the only workaround is to turn off the SDX buffer and turn on the LW buffer.

 

This is a simple transpositional error so I'll be able to fix it without altering any equates. I'll publish an update shortly.

Edited September 17, 2010 by flashjazzcat

[+Stephen]

Thanks for the speedy reply! I wil try a different OS and see if the ATTRACT flag works. It's not a big deal either way.

Hope so - else we have ourselves the first bug.

 

EDIT: we have indeed. It turns out that if you're not using LW's internal keyboard buffer, the attract toggle doesn't work. The SDX keyboard buffer always overrides LW's buffer, so the only workaround is to turn off the SDX buffer and turn on the LW buffer.

 

This is a simple transpositional error so I'll be able to fix it without altering any equates. I'll publish an update shortly.

I just this second verified it (takes a LONG time for the colors to cycle when you are staring at the screen ).

 

I can't believe I didn't see the error in my $PATH! Corrected it and everything is fine. I can't wait to start running this via hard drive (MyIDE for now) so it loads as fast as the RAM Disk all the time.

 

EDIT: if it makes you feel any better, two bugs were found (one each in two of our production apps) at work. My brother and I have been taking turns on this one for the past 2 years. Thought I had it fixed as it went for nearly 6 months before getting bad data in it. I told my bro it's his turn to work on it.

[flashjazzcat]

I just this second verified it (takes a LONG time for the colors to cycle when you are staring at the screen ).

 

I can't believe I didn't see the error in my $PATH! Corrected it and everything is fine. I can't wait to start running this via hard drive (MyIDE for now) so it loads as fast as the RAM Disk all the time.

 

EDIT: if it makes you feel any better, two bugs were found (one each in two of our production apps) at work. My brother and I have been taking turns on this one for the past 2 years. Thought I had it fixed as it went for nearly 6 months before getting bad data in it. I told my bro it's his turn to work on it.

I wish I was doing this kind of bug hunting for a living...

 

I take heart from what you say, though: few (if any) large projects are totally bug-free, and that goes for the realm of the PC as much as the Atari. There were bugs in version 3.11 which had been around for over a decade...

 

The (fixed) version 3.21 is ready and sitting on the back-burner, just in case anything else crops up.

[dwhyte]

I just this second verified it (takes a LONG time for the colors to cycle when you are staring at the screen ).

 

I can't believe I didn't see the error in my $PATH! Corrected it and everything is fine. I can't wait to start running this via hard drive (MyIDE for now) so it loads as fast as the RAM Disk all the time.

 

EDIT: if it makes you feel any better, two bugs were found (one each in two of our production apps) at work. My brother and I have been taking turns on this one for the past 2 years. Thought I had it fixed as it went for nearly 6 months before getting bad data in it. I told my bro it's his turn to work on it.

I wish I was doing this kind of bug hunting for a living...

 

I take heart from what you say, though: few (if any) large projects are totally bug-free, and that goes for the realm of the PC as much as the Atari. There were bugs in version 3.11 which had been around for over a decade...

 

The (fixed) version 3.21 is ready and sitting on the back-burner, just in case anything else crops up.

 

I've always found it to be a good idea to not use the SDX keyboard buffer. It's way to easy to overshoot your edit spot when scrolling through a document with the SDX buffer activated. Is there a way to turn it off completely during the load processes? Or perhaps a new config option for version 4.0 (which I still think should be cartridge based).

 

I've also been working with TLW everyday, Jon, and have yet to find any issues that plague my usage of it, hence why I've been so quiet lately. I've switched over from TextPad to TLW for tightening up all the scenes for Undone when I have the time (it will be released someday... hopefully). I've also been working on a companion program for TLW that is specifically geared for bibliographies. And that has brought me to another question: could you possibly PM me the TLW doc header specs so I can include them into Bibliographer's export function?

Edited September 17, 2010 by dwhyte

[flashjazzcat]

I've always found it to be a good idea to not use the SDX keyboard buffer. It's way to easy to overshoot your edit spot when scrolling through a document with the SDX buffer activated. Is there a way to turn it off completely during the load processes? Or perhaps a new config option for version 4.0 (which I still think should be cartridge based).

 

I've also been working with TLW everyday, Jon, and have yet to find any issues that plague my usage of it, hence why I've been so quiet lately. I've switched over from TextPad to TLW for tightening up all the scenes for Undone when I have the time (it will be released someday... hopefully). I've also been working on a companion program for TLW that is specifically geared for bibliographies. And that has brought me to another question: could you possibly PM me the TLW doc header specs so I can include them into Bibliographer's export function?

The keyboard buffer in the latest beta of SDX was changed to stop the "overshoot" problem. I explained to Draco that there was no point in buffering auto-repeat keys, and he agreed. So come December, the problem will dissapear, and I'll happily recommend use of the SDX buffer.

 

Here's the source code for the doc mode header (which only gets saved when the program is in "DOC" mode):

 

DOCHEADERID
.BYTE +128,"LW31" ; DOC FILE HEADER ID
PMKTAB .DS 10 ; LAST ENTRY IS FOR INTERNAL USE
TABLINE ; TAB COMB
.DS 30
;

 

So that's a four byte ID ("LW31") in reverse video which denotes the doc format revision, followed by the bookmarks (five in LSB/MSB format; the last one is use by global search and replace), and finally the tab comb, which covers 240 columns with 1 bit per column (1 = tab, 0 = clear).

 

Any more questions - ask away. I look forward to seeing what you come up with. I still need to compile the add-in docs, and it's a huge job. I hope that in the next version add-ins will be relocatable and will use symbols (similar to SDX). I'll get around to writing a word-target add-in some time.

Edited September 18, 2010 by flashjazzcat

[dwhyte]

Here's the source code for the doc mode header (which only gets saved when the program is in "DOC" mode):

 

DOCHEADERID
.BYTE +128,"LW31" ; DOC FILE HEADER ID
PMKTAB .DS 10 ; LAST ENTRY IS FOR INTERNAL USE
TABLINE ; TAB COMB
.DS 30
;

 

So that's a four byte ID ("LW31") in reverse video which denotes the doc format revision, followed by the bookmarks (five in LSB/MSB format; the last one is use by global search and replace), and finally the tab comb, which covers 240 columns with 1 bit per column (1 = tab, 0 = clear).

 

Any more questions - ask away. I look forward to seeing what you come up with. I still need to compile the add-in docs, and it's a huge job. I hope that in the next version add-ins will be relocatable and will use symbols (similar to SDX). I'll get around to writing a word-target add-in some time.

 

Thanks, Jon. I've switched over to using DOC mode as of late to differentiate my TLW files from standard ATASCII text files. I planned on exporting from Bibliographer as "DOC mode" files in the spirit of TLW. I may add exporting to other word processor formats, but for now I'll keep it TLW compliant only.

 

EDIT: I've just realized that I begin almost every sentence on this forum with "I" or "I've".

Edited September 18, 2010 by dwhyte

[flashjazzcat]

Thanks, Jon. I've switched over to using DOC mode as of late to differentiate my TLW files from standard ATASCII text files. I planned on exporting from Bibliographer as "DOC mode" files in the spirit of TLW. I may add exporting to other word processor formats, but for now I'll keep it TLW compliant only.

 

EDIT: I've just realized that I begin almost every sentence on this forum with "I" or "I've".

I'm glad to hear DOC mode works reliably, since it was a relatively late addition. The special format could be expanded in the future, perhaps to include stuff like autorunning macros to create "live" documents.

 

I'm pretty careful about that style guideline! After writing a group of paragraphs, I tend to asses them and ensure no two consecutive paragraphs begin with the same word.

Edited September 18, 2010 by flashjazzcat

[flashjazzcat]

Glad I hung on for the LW 3.21 update: I just realized that the program aborts loading the config files as soon as it encounters an error other than 170: file not found. It assumes anything else is fatal and doesn't try to load the rest of the config files. This is all very well unless you don't have drive 1 online. Version 3.21 will ignore any error # when trying to open startup config files and just try the next file. I only found this one because I was just testing my 600XL with only drive C mounted.

[MEtalGuy66]

Hey I got a feature for you to add. heheh..

Right-to-left typing..

 

I wanna load an arabic font and write some stuff in arabic.. Its a total PITA to do it with the editor running in normal left-to-right mode..

 

[flashjazzcat]

Hey I got a feature for you to add. heheh..

Right-to-left typing..

 

I wanna load an arabic font and write some stuff in arabic.. Its a total PITA to do it with the editor running in normal left-to-right mode..

 

Yikes!

 

That would actually be quite easy to do. Remind me about it when I'm working on the next version. I think it should be an add-in...

[MEtalGuy66]

Kewl.. I have an arabic atari that does it in the OS, but a) I never use that machine, I keep it preserved in a locked case, along with the original box it came in. and b)it's not really too useful to type right-to-left in DOS or BASIC.. (except maybe if your entering text strings in arabic for a BASIC program).. But if the Last Word would support it, It would totally rock because theres damn few applications even on the PC that will handle arabic text processing in any sort of convenient or efficient manner.

[flashjazzcat]

So (forgive me: I know nothing about Arabic) is this basically a case of mirroring the text, so that word wrap, etc, occurs at the left hand side of the page, and the "home" position is the top right corner of the screen? If so, it would basically be a case of reversing the screen coordinates, so that x = rightmost column - offset into line buffer.

Edited October 4, 2010 by flashjazzcat

[flashjazzcat]

Had a short break from MyIDE this evening to put together the 3.21 update of The Last Word. I've been using it intensively over the past week or so and a couple of bugs cropped up.

 

Changes:

 

• The disk menu now always displays SpartaDOS directory names as well as the file selection when the file mask is anything other than "*.*" (this was an out and out bug I noticed tonight).
• The attract mode can be disabled reliably (this previously only worked if you were using the internal keyboard buffer)
• The bahaviour of the file selector when called from a save dialogue (with the <Tab> key) has been augmented so that pressing <Return> in the file selector (even if there are no files in the directory) will return you to the input prompt with the original filename and the same drive number which has just been catalogued. This makes sense for the most common save scenario, namely realizing you want to save the file to a different folder to that which is currently logged, or pop into the disk menu to create an empty folder for the file. Previously, not only was it impossible to save the file from the file selector if there were no files in the logged directory, but the name of a highlighted (existing) file would be placed in the input dialogue after <Return> was pressed. The change is both an added convenience, and a safeguard against accidentally overwriting an existing file.
• It is now possible to disable the progress bar with the "PROGBAR OFF" command in LW.SYS. This is an attempt to deal with SIO timeouts with SIO2PC (seemingly caused by LW's immediate VBI updating the progress bar). It's also a useful cosmetic enhancement.

The update will be released in a day or two, once I'm certain it's stable.

 

It might be worth writing an add-in for doing mailmerges with D65 databases...

Edited October 11, 2010 by flashjazzcat

[MEtalGuy66]

So (forgive me: I know nothing about Arabic) is this basically a case of mirroring the text, so that word wrap, etc, occurs at the left hand side of the page, and the "home" position is the top right corner of the screen? If so, it would basically be a case of reversing the screen coordinates, so that x = rightmost column - offset into line buffer.

 

Well, you wouldnt mirror the characters.. Just make the positioning of the characters go from right to left. Of course, since your program uses custom fonts anywayze, If it was easier to implement with a "backwards" defined charset, then I guess it wouldnt matter. Arabic is similar to "cursive", in that there are differences in the way a letter is drawn and/or joined to the previous/next letter depending on whether it comes at the beginning, middle, or end of a word. Also, in most printed or typewritten arabic, "vowels" are implied, rather than written. In very formal, academic, or handwritten arabic, vowels and special case denominatives are expressed by diactric symbols that are added above or below the text. But as I said, automated or mechanized printing systems arent expected to deal with these. They are simply implied by the reader based on contextual experience.

 

So yeah, for our purposes, it is just like the english/roman/latin method of writing, only it goes from right to left. Whether or not you define the characters with the bitmaps reversed or forward, is up to you. It would certainly be easier for font editing purposes if they were defined/displayed in a normal manner.

 

As far as comming up with the chracter set, itself, I would suggest using the one from the arabic atari rom as a basis. They did a pretty good job. I could produce an 80 column (4x8 pixel) version of it for you using a standard font editor. I'd just leave half of each character blank, and you could then convert it into whichever format you need it.

Edited October 12, 2010 by MEtalGuy66

[flashjazzcat]

Well, you wouldnt mirror the characters.. Just make the positioning of the characters go from right to left. Of course, since your program uses custom fonts anywayze, If it was easier to implement with a "backwards" defined charset, then I guess it wouldnt matter. Arabic is similar to "cursive", in that there are differences in the way a letter is drawn and/or joined to the previous/next letter depending on whether it comes at the beginning, middle, or end of a word. Also, in most printed or typewritten arabic, "vowels" are implied, rather than written. In very formal, academic, or handwritten arabic, vowels and special case denominatives are expressed by diactric symbols that are added above or below the text. But as I said, automated or mechanized printing systems arent expected to deal with these. They are simply implied by the reader based on contextual experience.

 

So yeah, for our purposes, it is just like the english/roman/latin method of writing, only it goes from right to left. Whether or not you define the characters with the bitmaps reversed or forward, is up to you. It would certainly be easier for font editing purposes if they were defined/displayed in a normal manner.

 

As far as comming up with the chracter set, itself, I would suggest using the one from the arabic atari rom as a basis. They did a pretty good job. I could produce an 80 column (4x8 pixel) version of it for you using a standard font editor. I'd just leave half of each character blank, and you could then convert it into whichever format you need it.

Hmmm, yeah... "mirror" was surely the wrong word there. I just meant fill the screen lines from right to left.

 

How would this impact on the search/replace dialogue, etc? (Man - all I need right now is to have to think about things backwards, LOL!).

 

Seriously, if you were to produce an 80 column font (and send me the 40 col font too if you like), I'd be happy to support it. There's no room in 3.21... it could probably be written as an extension (it would have to patch the code and then unhook itself when another extension gets loaded: no problem, since there's an "unhook me" vector), but heck, we could have it as a built-in feature in the next release (after all, the code overhead is trivial: it's just that I still need to shave eight bytes off version 3.21; this involves scanning the source code and replacing jumps with branches where possible; there's not much more scope for optimisation).

 

The biggest PITA for me at the moment with this program is the 16/18K text buffers. Rather than try VBXE drivers/pull down menus/256 character fonts/large buffers all at once, I'm going to try an incremental modification soon that will:

 

• Free up the Shadow RAM
• Provide 10 x 32K (or possibly 48K) text buffers

Moving the program code out from under the OS to the $4000-$7FFF area ("under" the windowed text buffer banks) usefully increases the available code space by 2K. Needless to say this will leave stock 64K machines in the cold. Once that works, I will gradually add the other things on the to do list.

Edited October 12, 2010 by flashjazzcat

[flashjazzcat]

Something for SDX users to appreciate (look carefully):

 

 

The change is a tiny one, but man do my brain and fingers appreciate it.

Edited October 12, 2010 by flashjazzcat

[Roydea6]

A: replaces D1:

[flashjazzcat]

A: replaces D1:

Well done. This was nice an easy to implement: place "D" before the start of the filespec buffer and point the IOCB address to BUF-1.

[flashjazzcat]

LW 3.21 will be released with a spelling checker (implemented as an extension for 128K+ machines).

Edited October 19, 2010 by flashjazzcat

[MEtalGuy66]

Just dont make it do that annoying "realtime" spellchecking crap that MS Word does!

[UNIXcoffee928]

Just dont make it do that annoying "realtime" spellchecking crap that MS Word does!

 

I hate that too. It is easy to turn off, though:

 

Tools-->Options-->Spelling & Grammar

 

 

The Grammar checker is particularly useless, because it often suggests blatantly incorrect English grammar. No one should ever turn that feature on.

 

 

 

 

 

[+Stephen]

Just dont make it do that annoying "realtime" spellchecking crap that MS Word does!

 

I hate that too. It is easy to turn off, though:

 

Tools-->Options-->Spelling & Grammar

 

 

The Grammar checker is particularly useless, because it often suggests blatantly incorrect English grammar. No one should ever turn that feature on.

It's funny to let it auto-correct every spelling and grammar mistake, then try to read it back.

[flashjazzcat]

Don't worry: no realtime stuff. I checked out Superscript the other day and decided it would be easy to write a spell checker which worked in a similar way. It's written inside of 1.5K and you just run it like any other extension. It can be ignored if you don't want to use it.

 

Back in 1999, I did wrote an extension for LW 2.1 which was realtime. It was like Word's Auto-Correct feature and was actually quite useful, since you could effectively set up shorthand names for longer slices of text.

 

 

[flashjazzcat]

Any volunteers to test the spelling checker? I wasn't going to beta 3.21 but with the proofreader (now just about complete), it seems wise to.