Jump to content

New productivity upload: X16 Edit - a text editor


Stefan
 Share

Recommended Posts

I can't get it to work, no matter what I try the cursor always jumps to the first column when I press enter.  Tried ^A to turn auto indent on /off, no difference.  I'm quite confused and feel stupid 😛  There's no visible indicator to tell me if autoindent should be enabled or not so I just assume it should be. This is what I configured in the config registers as well when jumping into the editor from the assembler.   I type: <TAB>test<ENTER> and expect the cursor to be put under the t of test, but it stays in column 1 instead.

Edited by desertfish
Link to comment
Share on other sites

Sounds intriguing...

After pressing Ctrl+A to activate auto indent, there should be a message in the status bar at the bottom of the screen saying "AUTO INDENT ON". And when disabling you should see "AUTO INDENT OFF" in the status bar. You may see the status bar message at the start of the video I attached to my last post.

On Windows and Linux, some Ctrl+key sequences are used by the emulator. One example is Ctrl+R, that resets the emulator instead of its intended action, to open a file. Maybe Ctrl+A is masked in the same way on Windows and Linux.

If that is the case, auto indent may alternatively be enabled by first pressing and releasing ESC. In the status bar you should see "ENTER COMMAND OR PRESS ESC TO ABORT". If you now press A, it should enable auto indent.

However, that doesn't explain why you did not get auto indent when using the new load-file-with-options entry. Need to see your code to understand that (hopefully).

Link to comment
Share on other sites

Thanks Stefan, the ^A is eaten by the emulator somehow - esc+A did the trick!

Also the editor not launching with auto-indenting enabled was a typo on my part where I set the wrong bit in the config register, sorry 🙂  Works beautifully now. 

I think I'll release a new version of the assembler with the changes so far.

  • Like 1
Link to comment
Share on other sites

@desertfish, glad you got it working, even if the "eaten" keys are a bit annoying.

I have been thinking about supporting another control key than Ctrl.

At least on MacOS, Alt works like the Commodore key. In Petscii upper case/graphics mode, pressing Alt+A results in a "top left corner" kind of char. Pressing Alt+Shift+A returns a heart. Is that the same on Windows/Linux? Alt seems not to be a good candidate.

Maybe the Win key is not used for anything else by the X16 Kernal or the emulator, and could be used as an alternative control key.

Link to comment
Share on other sites

  • 1 month later...

Since version 0.4.0, published in September 2021, you haven't been able to run X16 Edit in the last stable release of the emulator and Kernal (R38).

In order to run X16 Edit, you have had to compile the emulator and Kernal from the Github master branch, what might become R39. I understand that setting up the build environment and compiling is not for everyone.  Therefore I tried to modify the last version of X16 Edit (0.4.2) to make it run in R38. The result of this was published today as version 0.4.2-R38.

The changes were fairly simple to do, but I haven't tested it thoroughly.

One difference is the addresses used for bank switching. But this is just two definitions in the source code, one for RAM bank and one for ROM bank select.

The other significant difference is keyboard functionality. Since 0.4.0, X16 Edit uses a custom PS/2 scan code handler in order to read modifier key status and some extra keys such as DELETE, END, PgUp, PgDn, and the numerical keypad. This is simply not possible to do in R38. The modifier keys can be read by other means in R38, but there is no way that I know of to support keys ignored by the Kernal in R38.

A benefit of supporting R38 is that the Try It Now button now may run 0.4.2-R38.

  • Thanks 1
Link to comment
Share on other sites

Great that the try it now button works! I believe it is possible to inlude example files that work with the try it now button.

You use Ctrl+S for replace, but in ordinary Nano that is save without prompt, and that is one of my favourite commands since it is the same in many editors, e.g. Notepad. In Nano replace is a subcommand to Ctrl+W (search): Ctrl+R.

Edited by mobluse
Link to comment
Share on other sites

Thanks.

It would be interesting to replicate Nano keyboard shortcuts more closely.

When I've looked into this question before, I've been put off by Nano's use of two modifier keys, and the fact that the Alt key is already used by the X16 for inserting graphical characters. Nano alternatively lets you single or double tap the ESC key instead, but it feels like a fallback.

I didn't know that Ctrl+S could be used for saving. Traditionally Nano returned the error message "XOFF ignored, mumble, mumble" when you pressed Ctrl+S, and it still does on my computer running Nano 2.0.6.

Replace is, at least in Nano 2.0.6, also available by Meta-R. Using subcommands adds a little complexity to the UI, but it is certainly doable. There is already support for context menus in X16 Edit.

X16 Edit has some commands that is not needed/available in Nano:

  • Ctrl+D to change device number
  • Ctrl+E to change character set
  • Ctrl+I to invoke DOS commands
  • Ctrl+T to change text color, and Ctrl+B to change background color
  • Ctrl+M to show memory usage

If you would like to make a table of shortcuts, I would be more than happy to look into that.

Link to comment
Share on other sites

  • Super Administrators
On 1/24/2022 at 12:14 PM, desertfish said:

if you're short of key combinations you could perhaps opt to make those lesser used functions as 2 key sequence or popup menu or something ?

Since he's been referencing Nano... nano actually does this with the "Meta" key, which is usually the Escape key. One I use frequently is M-6, which is "Copy". 

 

Link to comment
Share on other sites

Hi,

There is currently no lack of control keys, it's just the question of replicating Nano more closely.

According to Nano's user manual, Alt is normally used as the other control key (Meta). It is stated that pressing ESC once is a fallback for the Meta key, should Alt not work on your system. And pressing ESC twice is a fallback for the Ctrl key, if that doesn't work.

Using the ESC key in this way is not the most convenient. I would try other methods first. In R38 you have less control over the keyboard, which limits the options a lot. In R39 you could consider to use one of these as Meta:

  • Ctrl+Shift
  • Ctrl+Alt
  • Windows key (the emulator will not like it though)
Link to comment
Share on other sites

On 1/24/2022 at 9:35 PM, Stefan said:

Windows key (the emulator will not like it though)

NOOOO! Apple use to have an Apple key, but probably never will have a Windows one. 

Yes, I do realize that Mac OS is based on a unix core where Windows is not. Also that text based editors with keyboard commands are so passé, save when on a retro 8 bit machine 😜

Link to comment
Share on other sites

On 1/25/2022 at 9:01 AM, Edmond D said:

NOOOO! Apple use to have an Apple key, but probably never will have a Windows one. 

Yes, I do realize that Mac OS is based on a unix core where Windows is not. Also that text based editors with keyboard commands are so passé, save when on a retro 8 bit machine 😜

???

 

Link to comment
Share on other sites

Agreed.

But don't forget that we are really targeting an OS called X16 Kernal 🙂

Anyway, the closest equivalent to the Windows key on MacOS should be the command key. This key used to have the Apple logo back in the days I think.

The X16 Emulator does not currently relay either the Windows or Command key. This would happen at line 183 in keyboard.c, but it is commented out:

//case SDL_SCANCODE_LGUI: //Windows/Command

Any other ideas for the Meta key?

Maybe the right Alt or Control key?

Link to comment
Share on other sites

On 1/26/2022 at 6:46 AM, Stefan said:

Anyway, the closest equivalent to the Windows key on MacOS should be the command key. This key used to have the Apple logo back in the days I think.

Yes, at least on my Apple II machines it is Apple logo keys. Love them! 🙂

Personally I would have liked Apple to continue with the apple-symbols instead of the  on my macs.

Link to comment
Share on other sites

I've done some minimal testing, and think there is a reasonable solution for the other modifier key "meta".

That is to use the left Alt key.

The right Alt key (labeled AltGr on some international keyboards) could continue to be the "Commodore" key used to insert graphical characters.

The ESC key could be used as a fallback in case the Ctrl or Alt key doesn't work in a particular setup. Pressing ESC once could be a fallback for the Alt key. And pressing ESC twice could be a fallback for the Ctrl key.

This solution doesn't require any changes to the Kernal, but you need R39 to get sufficient control over the keyboard.

The question is if it's needed, though. The number of functions in X16 Edit is quite limited. Maybe if I move things around a bit using only Ctrl it's good enough. 

Link to comment
Share on other sites

I appreciate the amount of thought you put into this! One little remark from my side: if it's not too much of a hazzle, would it be possible to put the key combinations that are used often (like copy/cut/paste) into a place where one could do the combination with a single hand easily? I've found that using Ctrl+P, Ctrl+U is awkward to use compared to Ctrl+C, Ctrl+V. Just one little feedback 🙂

Link to comment
Share on other sites

It might be hard to make everyone happy.

Maybe I should let the keyboard shortcuts be user configurable.

The current source code is not very far off. The shortcuts are just a list of PETSCII/ASCII values stored within the executable.

This could be changed so that the editor loads the shortcut list from a file on startup.

  • Like 3
Link to comment
Share on other sites

  • Super Administrators
On 1/27/2022 at 4:46 AM, Stefan said:

It might be hard to make everyone happy.

Maybe I should let the keyboard shortcuts be user configurable.

The current source code is not very far off. The shortcuts are just a list of PETSCII/ASCII values stored within the executable.

This could be changed so that the editor loads the shortcut list from a file on startup.

That's how I would go. Everyone wants something different, and you can't please everyone with a fixed layout. Personally, for example, I prefer a more Windows standard shortcut set, with Control-C for copy, Control-V for paste, Control-H for search/replace, and so on. While I can get by on Nano, I find its shortcuts to be obtuse and often frustrating, since I rarely use it and spend my time on Visual Studio and Notepad++.

On the other hand, someone who spends their time in Linux or Unix would likely be most comfortable with Nano or maybe even VI if you're old school enough.

 

 

  • Like 2
Link to comment
Share on other sites

User-configurable key bindings are now in version 0.4.3.

I also made a simple tool to create the config file, also in the download section (X16EDIT-KEYBINDINGS.PRG).

And finally, I have now tried to support both Ctrl+key and left Alt+key combinations in the editor. Ctrl+key worked fine on MacOS, but there are a lot of problems at least in the emulator on Windows and Linxux as the emulator uses Ctrl+key combinations for its own purposes. Let me know how this works out, as I do not have the X16 Emulator set up on Windows or Linux myself.

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

The help screen in X16 Edit is embedded into the executable as ASCII text, and takes quite a lot of space.

I've been looking for ways to make the executable smaller. One interesting option is to compress the text with Huffman coding:

https://en.wikipedia.org/wiki/Huffman_coding

After a lot of fiddling, I finally got it to work.

The compression is done by a python script. Decompression is done in 65C02 assembly within the X16 Edit executable.

But how well does it work? Some metrics:

  • Original help screen text size: 1,818 bytes
  • Compressed text size: 1,093 bytes (60 % of the original)
  • Lookup tables needed for decompression: 194 bytes 

And the 65C02 decompression code also takes some extra space. In my first working implementation, the executable became 422 bytes smaller, a saving of about 23 %.

Another issue is speed. The help screen is not displayed instantly, but I think it still is quite fast. I uploaded a video so you may see the decompression code in action for yourself.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use