flashjazzcat #1 Posted April 28, 2013 I'll give this its own thread since it's sufficiently different to The Last Word. This is a new text editor which supports expanding tabs, S_VBXE, RC_GR8 and other niceties. It's coming together quite quickly (which is fortunate, since I have little time during the week). Couple of screenshots: Unfortunately I ran out of time tonight before I could write the file selector, but I think this editor could easily be in beta in a week or two. 1 Quote Share this post Link to post Share on other sites
+Larry #2 Posted April 29, 2013 Nice! Will it be "MyDos friendly?" Drac030's text editor for SDX is very nice, but IIRC, it didn't work with MyDos. (?) -Larry Quote Share this post Link to post Share on other sites
drac030 #3 Posted April 29, 2013 Drac030's text editor for SDX is very nice, but IIRC, it didn't work with MyDos. (?) Do you mean "ED"? It is not mine, it is JBW's (of L. K. Avalon). It was originally written for DOS 2.5, trub has ported it over to SDX. There should be a version somewhere which works with MyDOS. Quote Share this post Link to post Share on other sites
flashjazzcat #4 Posted April 29, 2013 Nice! Will it be "MyDos friendly?" Drac030's text editor for SDX is very nice, but IIRC, it didn't work with MyDos. (?) If you mean ED.COM, then I don't think Drac030 was the author... but in any case, I aim to make the editor compatible with various DOSes... even if this means SDX gets a special, optimised build. Quote Share this post Link to post Share on other sites
+Larry #5 Posted April 29, 2013 Thanks. I'll look for an ED version for 2.5. Thought ED was yours, Konrad -- sorry about that! -Larry Quote Share this post Link to post Share on other sites
flashjazzcat #6 Posted April 30, 2013 Video showing all three available text modes: Very pleasantly surprised by performance with the RC_GR8 driver, which is obviously very efficient. The editor maintains its own internal cache of the frame buffer content regardless of the display driver in use, however, so redundant calls to the display driver's put character routine are always avoided. The VBXE driver uses the blitter to scroll the screen, while RC_GR8 and the internal (Graphics 0) driver both use a dynamic display list. Note the program is only run with the "X" command here to maximize the available buffer space. Note also that video transcoding has completely mangled the "smoothness" of the screen updates. 4 Quote Share this post Link to post Share on other sites
flashjazzcat #7 Posted May 6, 2013 File selector partially complete: Quote Share this post Link to post Share on other sites
flashjazzcat #8 Posted May 28, 2013 (edited) Finally overcame an obstacle with various UI elements thanks to ideas from Candle: basically, control captions now highlight to make the focus clear even if nothing in a control is actually selected... this will make sense once you use the file selector: A reasonable compromise between looks and functionality. I've also figured out how to edit files which are much bigger than the available contiguous RAM. Just a shame it took me all weekend to get back up to speed on this and now I can't do more until tomorrow evening. Edited May 28, 2013 by flashjazzcat Quote Share this post Link to post Share on other sites
flashjazzcat #9 Posted May 30, 2013 (edited) File selector just about done, showing a sample error message box displayed using the re-entrant dialogue handler: I'm doing 1-2 hours per evening on this if I'm lucky, but the green screen display is kind of nice. Note you don't need VBXE to use this... I just realized I'm posting nothing but VBXE driver shots. Edited May 30, 2013 by flashjazzcat 1 Quote Share this post Link to post Share on other sites
flashjazzcat #10 Posted June 9, 2013 Beta release coming soon: 1 Quote Share this post Link to post Share on other sites
Kyle22 #11 Posted June 17, 2013 It looks great, can't wait Quote Share this post Link to post Share on other sites
Frankie #12 Posted June 17, 2013 How much to transform it into VI? 1 Quote Share this post Link to post Share on other sites
flashjazzcat #13 Posted June 17, 2013 How much to transform it into VI? This editor is already so large (20KB) that I think we need a stripped down version. Something like VI could hopefully be 8-10KB... so it's being considered. Quote Share this post Link to post Share on other sites
Frankie #14 Posted June 17, 2013 This editor is already so large (20KB) that I think we need a stripped down version. Something like VI could hopefully be 8-10KB... so it's being considered. Who needs prompts and menus, it just needs to beep :-) Quote Share this post Link to post Share on other sites
flashjazzcat #15 Posted June 17, 2013 Who needs prompts and menus, it just needs to beep :-) Quite so. I think a streamlined version could be elegant. The fact is that part of the purpose of the "fat" editor was to develop the UI library. Been dying to see a "Visual Basic for DOS" type UI on the A8 for years, but there's a place for minimalism also. Quote Share this post Link to post Share on other sites
kogden #16 Posted June 18, 2013 Something like VI could hopefully be 8-10KB... so it's being considered. Complete with autoindent and parenthesis matching for LISP code? I'm only half-serious. This editor you're working on looks great though, I'll certainly use it! Quote Share this post Link to post Share on other sites
MEtalGuy66 #17 Posted June 18, 2013 What'd be uber-kewl would be to use PMG overlays in the atari native modes, and text color attributes in the VBXE mode, to make it mimic the red, white, and blue color scheme of the MSDOS 4+/QBASIC editor.. 1 Quote Share this post Link to post Share on other sites
flashjazzcat #18 Posted June 18, 2013 (edited) Complete with autoindent and parenthesis matching for LISP code? I'm only half-serious. This editor you're working on looks great though, I'll certainly use it! XEDIT (on my website) does pair matching and auto-indent and it didn't have too big of a footprint, so it should be possible. Fact is the UI library alone in the "big" text editor is 7KB long... What'd be uber-kewl would be to use PMG overlays in the atari native modes, and text color attributes in the VBXE mode, to make it mimic the red, white, and blue color scheme of the MSDOS 4+/QBASIC editor.. Best way to do this in 40 column mode would probably be to depend on yet a third display driver (in addition to the two 80 column drivers) which translated all the VBXE colour escape codes into something PMGs could handle. RC_GR8.SYS would be left out in the cold, though, since there's no colour support in that driver at the moment and we're aiming for complete hardware abstraction. Edited June 18, 2013 by flashjazzcat Quote Share this post Link to post Share on other sites
flashjazzcat #19 Posted June 30, 2013 Working with XEP80, albeit slowly: http://www.youtube.com/watch?v=RPHY-XcI8Ys&feature=youtu.be Quote Share this post Link to post Share on other sites
+Larry #20 Posted June 30, 2013 Hi Jon- What monitor are you using with the XEP80? A bit difficult to tell, but looks like you have 79 columns of text there? On NTSC, it is difficult to get 80 columns (generally 78) and only can get 23-1/2 lines. Have you somehow bypassed the built-in font (which I think is in rom in the XEP80)? Presumably you would be able to control the scrolling so that something less than 24 lines could trigger the scroll up? Looks nice, and sure would be nice to have something that can use the XEP80. Wonder how it would do at 7 MHz? -Larry Quote Share this post Link to post Share on other sites
flashjazzcat #21 Posted July 1, 2013 Hi Larry, I don't have the actual hardware, so what you see is all done in the emulator. I should have 80 columns of text, since I bumped the right margin up from 79 to 80 and this seems to take care of unwanted scrolling. I haven't implemented scrolling the screen yet, however: I'm assuming this will have to be done by judiciously inserting/deleting lines. I think Avery hand-coded the font, which will explain the visual differences. Regarding the speed: it's just about usable, but only just. The back-end of the text editor is highly optimised already, so it seems that calling put-one-character through the CIO is the bottleneck here. Quote Share this post Link to post Share on other sites
+Larry #22 Posted July 1, 2013 It's nice that Avery has added that feature to the emulator. But it will be interesting to see what happens on real PAL and NTSC hardware. Lot's of those XEP80's out there, and I believe can still be purchased new. -Larry Quote Share this post Link to post Share on other sites
flashjazzcat #23 Posted July 1, 2013 (edited) Yeah... wouldn't mind tinkering with one, but the emulation is all I need right now. Might be nice to make this text editor work with as many screen drivers as possible, within reason. Already it works with: Standard 40 column display VBXE 80 column display (via S_VBXE.SYS) RC_GR8.SYS soft 80-column display XEP80.SYS (WIP) Just added Edit->Replace form, and it takes about ten minutes to knock together a dialogue box like this. Most of the time is spent repositioning the controls by trial and error. Thing about replace is that the dialogue box will tend to get in the way, so these buttons will have to segue into status bar options after the form has closed ("Replace / Find Next / Replace All / Quit"). The MS-DOS EDIT app got around this problem by carefully scrolling the editor and moving the form so that found passages were never behind the dialogue box, but we'll have to see what's actually practical in the A8 editor. Funny thing is, the modern trend is for status-bar find/replace in browsers, etc. Edited July 1, 2013 by flashjazzcat Quote Share this post Link to post Share on other sites
flashjazzcat #24 Posted July 4, 2013 (edited) Here's search/replace in action: http://www.youtube.com/watch?v=RcHITduaAIY&feature=youtu.be Making the dialogue avoid found text was easy, as it turned out, although I need to make the found text show up as selected rather than just parking the cursor in front of it. The editor's coming together very quickly now, but the time-taking stuff will be bug elimination and adding the details, such as elegant error handling in the file selector, etc. Dialogues (and menus) also need shortcut keys so that tabbing to the required button / control / option isn't the only way to do things. Edited July 4, 2013 by flashjazzcat Quote Share this post Link to post Share on other sites
+Larry #25 Posted July 4, 2013 That is really nice! I may actually have to install my VBXE, since "there is going to be something for it to do!" -Larry Quote Share this post Link to post Share on other sites