The Last Word 3.0 Release Candidate 1

[flashjazzcat]

RC2 has just been mailed out to the testers. Please let me know if I've forgotten you, or if you'd like to be included on the testing list.

[+Roydea6]

RC2

 

How do I stop the seperation between pages? BTMARGIN 66 is set in the CFG.

[flashjazzcat]

How do I stop the seperation between pages? BTMARGIN 66 is set in the CFG.

Include a line like this at the top of the document, ending in Return and entirely in reverse video:

 

p66b66t0

 

This sets the page length to 66, bottom margin (in fact, last printing line) to 66, and the top margin to 0.

 

This highlights the fact that the preview window always displays a blank screen worth of lines regardless of the top margin setting. It's a cosmetic bug, but if you print the file to disk you'll find it comes out without any blank lines between page breaks. I've just tested it and it works. Print to disk (say, TEST.PRN) and then load the resulting file in the editor to check the output.

 

Alternatively, if you want to permanently save these settings, put these lines at the top of LW.CFG:

 

TMARGIN 0

BMARGIN 66

 

Perhaps TMARGIN hadn't been reset and that's why you were still getting the five blank lines.

 

---------------------------------------------------------------------------

 

This and few other bug fixes: please note before posting in the bug tracker:

 

• The print preview display now prints from the top of the window rather than the last line of the screen before scrolling the page.
  
• The Load Configuration command now no longer displays garbage on the input line.
  
• Exit to DOS now offers the chance to save changes to all unsaved documents, not just the current editing bank.
  

Edited July 21, 2009 by flashjazzcat

[flashjazzcat]

The revised manual is about two thousand words away from completion... it's been a tiring week at work so maybe I'll get the manual prepared for public download on Saturday. I'm also going to implement the add-in code in the program and then work through the manual myself testing everything. I just seem to be doing dozens of little tweaks now, mainly to do with the re-write of the "Save changes" code, which upset a lot of exisiting stuff, mainly in cosmetic ways. I'm still discovering the odd bug in things like the print formatter, introduced by the 80 column display back in January but undiscovered for six months! A week or so more of polishing and it will be done, though.

 

I'm thinking what might be pretty cool is to write a huge "demo" macro that the user can fire up when they first load LW. It would demonstrate things like footnotes, file tagging, automatic heading levels, cut and paste, 240 column editing, even macros themselves... all without any user intervention.

Edited July 23, 2009 by flashjazzcat

[flashjazzcat]

Here's an unfinished draft copy of the revised manual. It will be a couple of days before it's finished but I'd promised the testers something. Note that the manual mentions a couple of features not yet implemented in the program. Just the DOS Packages, command reference and techinical notes sections to complete now:

 

The_Last_Word_3__draft_.pdf

[flashjazzcat]

Had a bit of a pause in work this weekend 'cause my Mac OS X partition screwed up and I can't get the dual boot working again. Anyway, was thinking today about keyboard redefinition in LW, and it occured to me that the easiest and least destructive way to do it is using macros. My example was to change the Cut and Paste keystrokes in LW so they're the same as Windows. I've been designing all kinds of elaborate ways of redefining the keyboard table, when the best way to do it is to write a macro.

 

LW scans non-alpha keystrokes for macro definitions before running them by the "built in" commands (it didn't used to, but I bowed to pressure!). This way, you can make "Ctrl+S" do something other than "Save file". So to get Windows cut and paste command, clearly you just have to attach "Ctrl+X" to a macro which issues the "Ctrl+C" keystroke to the editor (that's LW's "Cut" command key). Of course, you'll need to map some other key so it issues "Ctrl+X", otherwise you'll never be able to exit to DOS.

 

This got me thinking about some refinements to the keyboard decoder. The goal was to make it so that "Ctrl+S" could issue an accented character right into the text. That's why I changed things so that macros take precedence over in-built commands. The trouble is, you start losing commands when you attach macros to these keystrokes.

 

What I'm thinking about is this: <Esc> in the editor runs the macro off the next keystroke (and it can be any character at all). <Esc> is at all other times an "abort" key in LW, and this is why <Ctrl+Esc> is used to set the escape flag for entering control characters.

 

<Option> held down with a key has a similar effect: it forces the key to be run through the macro scanner, no matter whether it's a control or an alpha key.

 

So, say you redefine <Ctrl+S> so it puts an international character in the text. You're left with a few choices for saving files. You could put save on <Option+S>, but NOT <Option+Ctrl+S>. There again, is it not as easy to put the accented character on <Option+S> or <Esc, S>?

 

We had this discussion a long time ago and it caused me to change the way LW works. In the past, macros would only run if you held <Option> down while holding a key or pressed <Esc>. This meant the core functionality of the program never changed, and the windows shortcut trick wouldn't work, because there was at the very least a console key involved in running a macro.

 

I think the "new" way is more flexible, but you need to plan ahead and know what you're doing.

 

I'm just thinking aloud here...

[flashjazzcat]

Got the dual boot working again, and I just tried the Windows Ctrl+X, Ctrl+C and Ctrl+V key definitions with a macro and they work perfectly. It's been a good evening so far!

[dwhyte]

Got the dual boot working again, and I just tried the Windows Ctrl+X, Ctrl+C and Ctrl+V key definitions with a macro and they work perfectly. It's been a good evening so far!

 

Awesome work flashjazzcat!!!

[flashjazzcat]

I'd just like to offer my thanks to all the beta testers who've helped in this project, and most of all to MrFish for the fantastic graphic design work and fonts. I'm still debugging the macro processor, and progress is VERY slow at the moment because these features are very difficult to make robust. But they're almost done. The fact I have about twenty bytes of code space must be prudence trying to tell me something...

 

The latest things I've included are configuration options so it's possible to devote memory to EITHER a larger main text buffer or to space for machine code extensions (such as the vapourware spell-checker!). It's also possible to grab up to sixteen extended RAM banks and share them out between text buffers and reserved buffers for said extensions. And believe me, the chapter on writing macros has been an exercise in plain-english prose: I'm using lots of screen-grabs so those finger-twisting keystrokes should be easier to understand.

 

My full-time job's coming to an (earlier than expected) end in four weeks, so if I don't have new job by then at least I'll have plenty of time to write the bug fixes in the wake of LW's "official" release!

Edited August 17, 2009 by flashjazzcat

[flashjazzcat]

Nearly there! Have made some useful last-minute changes to the search and replace routine. Video below (right click, save as):

 

Search and Replace

 

I was replacing LFs in this polish source file with returns the other day and I realized it was VERY slow in 80 column mode, because the screen refreshed after each replacement. Now, when selecting "Replace All", the screen refresh is suppressed and the document refreshes itself after the operation is complete. It's supposed to report the total number of replacements made at the end but there's a bug with that at the moment...

 

Am considering adding (optional) wrap-around to the top of the document if the global replace didn't begin at the top. Also considering whether editor should return the user to the original point in the document where the operation was begun. Thoughts?

Edited August 22, 2009 by flashjazzcat

[flashjazzcat]

Any thoughts about the wraparound, etc? My inclination is to make search and replace work on the entire document regardless of start position and return the editing position to the original start point when finished.

 

I've just squashed the scrolling up screen glitch bug which has plagued LW since the start if the year. I'm starting a week's holiday so I'll finish the last few bits of code and the manual and release the program on August 31.

[spookt]

Any thoughts about the wraparound, etc? My inclination is to make search and replace work on the entire document regardless of start position and return the editing position to the original start point when finished.

 

I've just squashed the scrolling up screen glitch bug which has plagued LW since the start if the year. I'm starting a week's holiday so I'll finish the last few bits of code and the manual and release the program on August 31.

 

 

I think making the replace work on the whole document makes sense. I would definitely like to end up back where I started afterwards too

[flashjazzcat]

I think making the replace work on the whole document makes sense. I would definitely like to end up back where I started afterwards too

Thanks! That agrees with what my friend said the other day. It's a bit of extra code but I think I have room. I was hoping to add the option of performing a search/replace solely on a block of marked text but I haven't looked at the logistics of that yet. I gave myself another (and positively the last) 256 bytes of code space the other day and I'm filling it up fast. It would be nice to leave some space free for changes and bug fixes in the future.

[flashjazzcat]

The "wraparound" to the top of the file in global search and replace elegantly takes care of the original cursor position issue, since the replace operation is terminated by reaching the place it started from. Looks much more polished and works faster too.

[+Stephen]

Any thoughts about the wraparound, etc? My inclination is to make search and replace work on the entire document regardless of start position and return the editing position to the original start point when finished.

 

I've just squashed the scrolling up screen glitch bug which has plagued LW since the start if the year. I'm starting a week's holiday so I'll finish the last few bits of code and the manual and release the program on August 31.

I like the idea of wraparound - would it be easy to make this an option? I think the editor should also return you to the place you called the find/replace from.

 

Stephen Anderson

[flashjazzcat]

I like the idea of wraparound - would it be easy to make this an option? I think the editor should also return you to the place you called the find/replace from.

The wraparound is now standard: I programmed it all on Sunday afternoon. At first I implemented a separate routine to save and return the user to the original cursor position, but once I implemented the wraparound (which stops searaching when it reaches the original start of the search), I realised I could jettison that original code. It works quite nicely, but will need rigorous testing. The "wraparound" also works when single stepping through replacements, and - once again - ends when it reaches the start of the original search. Ordinary "find string" commands don't wrap around, since they can be used to define the extent of a text selection so don't really want to be wrapping back around to the top. As for global replace inside the bounds of a selection: I think I'll leave that out. Can be done, but with too much of a code overhead.

[+Stephen]

The wraparound is now standard: I programmed it all on Sunday afternoon. At first I implemented a separate routine to save and return the user to the original cursor position, but once I implemented the wraparound (which stops searaching when it reaches the original start of the search), I realised I could jettison that original code. It works quite nicely, but will need rigorous testing. The "wraparound" also works when single stepping through replacements, and - once again - ends when it reaches the start of the original search. Ordinary "find string" commands don't wrap around, since they can be used to define the extent of a text selection so don't really want to be wrapping back around to the top. As for global replace inside the bounds of a selection: I think I'll leave that out. Can be done, but with too much of a code overhead.

Sounds good - I have plenty of text files on the 8-bit to test with. I'll give it a good workout stripping out ANSI escape codes from my saved BBS captures.

 

Stephen Anderson

 

***Edited to fix quote tags***

Edited August 24, 2009 by Stephen

[flashjazzcat]

Sounds good - I have plenty of text files on the 8-bit to test with. I'll give it a good workout stripping out ANSI escape codes from my saved BBS captures.

OK - depending on how I get on this week I'll try and get a last minute test copy out to you before the Bank Holiday.

[flashjazzcat]

The last minute improvements - they just keep on coming.

 

Video

 

I realized while fixing the "paragraph up" bug that even if going back or forward by a paragraph only resulted in a single line scroll, the who screen redrew itself. This is because the smooth scrolling mechanism only worked with line up/down. However, if the resulting scroll is less a screen's worth, it's faster to call the smooth scroll routine N times and then redraw the portion of the document which has been brought into view. Needs some tweaking and testing but it looks better.

 

Edit... actually, scrolling generally in 80 column mode now seems twice as fast. I'll be emailing a copy of the latest build to all the beta testers within the next day or so; if those who have time can give the program a good thrashing scrolling through different text documents and performing big search and replace operations, I'd be really grateful.

Edited August 26, 2009 by flashjazzcat

[+Stephen]

The last minute improvements - they just keep on coming.

 

Video

 

I realized while fixing the "paragraph up" bug that even if going back or forward by a paragraph only resulted in a single line scroll, the who screen redrew itself. This is because the smooth scrolling mechanism only worked with line up/down. However, if the resulting scroll is less a screen's worth, it's faster to call the smooth scroll routine N times and then redraw the portion of the document which has been brought into view. Needs some tweaking and testing but it looks better.

 

Edit... actually, scrolling generally in 80 column mode now seems twice as fast. I'll be emailing a copy of the latest build to all the beta testers within the next day or so; if those who have time can give the program a good thrashing scrolling through different text documents and performing big search and replace operations, I'd be really grateful.

That does look much faster. Looking forward to testing.

 

Stephen Anderson

[flashjazzcat]

Help screens are done, just macro examples, font catalogue and manual to get finished now. I say "just"... there's still stuff that hasn't been tested for ages. I'd like to see plenty of SpartaDOS X testing; I've been doing all the development work under DOS 2.5 since I migrated over to WUDSN (it's easier when dealing with H: drives; I intent to write a SDX app which will load an executable on H: from the command line), so SDX has been neglected a little. You can, for example, specify a file to edit on the Sparta command line. In fact, if you have several banks set up and you may specify more than one file name on the command line, LW (or TLW) will attempt to load them all into separate banks, one after another. There's also an environment path variable... I'll put a note in with the program when I email it out.

 

...and it's mailed out. Sorry if I've missed anyone - do let me know. Need to rest now: so much typing...

Edited August 27, 2009 by flashjazzcat

[flashjazzcat]

Just spent a whole afternoon fixing a bug which caused fatal crashes, lock-ups, you name it. Had me absolutely baffled. Turns out if you loaded the program without a config file containing the line "PAGEWIDTH 80", the screen width variable was left at 0, soon causing disastrous results. Took a very long time to track down, that one. This should explain most of the crashes people have been having with print preview, etc.

 

I'll mail out another copy with this fix.

[flashjazzcat]

Good news: I have two weeks off work so I should get LW released very soon. Scratching away looking for spare bytes, I managed to find room today for a page up/page down and home/end function for the disk menu, which is a real boon when navigating through hundreds of filenames under SpartaDOS X. 16 bytes of code space left, so I think that's the lot!

[flashjazzcat]

I was checking out YouTube tonight and it looks like one of the beta testers has welched on the NDA. Moreover, he seems to be passing LW off as his own work:

 

 

I know the culprit and I'll be having stern words with him!

[+Stephen]

I was checking out YouTube tonight and it looks like one of the beta testers has welched on the NDA. Moreover, he seems to be passing LW off as his own work:

 

 

I know the culprit and I'll be having stern words with him!

Get that bastar --- hmm. Maybe he didn't sign the NDA A little forgiveness may be in order.

 

Stephen Anderson