Commander X16

An actual line feed char is inserted when wrapping a long line.

GNU Nano's long line wrapping function (ESC+L) does this too.

I had a discussion with @BruceMcF above in this thread on the design of a word wrap function.

Apparently, his favorite editor from the past, VDE, also did this.

This is my second attempt to create a text editor for X16. My first program had word wrap calculated on the fly without inserting line feed chars. However, this became very complex and error prone, and I finally had to discard that work.

Based on my first experience, I had decided not to do word wrap, but Bruce talked me into it. I think the word wrap function is a nice addition and that it will be sufficiently usable. I'm not making a word processor.

The next version of X16 Edit will have word wrap, and then I will consider the program to be feature complete. Thereafter I will focus on bug fixes and minor improvements to the user interface.

I think version 0.1.1 already works pretty well. If you try it, please let me know what you think.

Thank you for clearing things up. Would be nice to make an option to turn wrap functiom on and off. Idealy by a hotkey during typing.

You will be able to turn it on and off (Ctrl+Z).

When turning on, you are prompted to set at what column to wrap.

Version 0.2.0 of X16 Edit now released.

It supports word wrap. Word wrap is turned off by default. Enable by pressing Ctrl+Z.

X16 Edit is now feature complete as I've planned version 1.0.

I will continue cleaning the code, fixing bugs, and improving the user interface.

Hi.

Version 0.2.1 uploaded. Some bug fixes, especially the automatic word wrap function that wasn't working.

I've written a short user manual that is also available on the download page.

And I finally got the "Try it now" button to work. However, there are some differences. For instance not all Ctrl+key commands are recognized when you run the program in the online emulator. I think it's still best to download the program and run it in your emulator locally.

And one more thing I forgot to mention. I've implemented a defragmentation routine that runs in the "background". Actually it's invoked to defrag one memory page each interrupt if there is no user input to handle. The memory model discussed at the beginning of this thread makes it possible to edit large files. The downside is that there is a lot of unused space, especially if you back and forth in the file editing it. The defrag routine takes care of that problem.

Hello,

I have some problem running x16edit. I mount the bundled sdcard.img, copy x16edit-0.2.3.prg to mounted drive, dismount then tried to run x16emu using the following line:

x16emu.exe -sdcard sdcard.img -prg x16edit-0.2.3.prg -run

The output:

SD card attached.

Cannot open x16edit-0.2.3.prg!

*EDIT*

In the meanwhile, i tried to run another prg (rallyspeedway.prg) from the sdimage but get scrambled, freezing screen. Seems sdcard image handling is far from being usable.

Btw, for x16edit, not even the filename renders correctly (i get PETSCII scrambled filename by listing the sd image with DOS"$ - thats why the above command fails).

Only files written out from basic editor, works from sd image.

Everything working fine from the host's drive.

 

 

@tibi

I'm glad you want to try x16edit.

If you use the command "x16emu.exe -sdcard sdcard.img -prg x16edit-0.2.3.prg -run" there is no need to copy the prg file to the sdcard image.

When starting the emulator with the -prg option, the emulator loads the prg file directly from the host file system. The -run option runs the program automatically as soon as the emulator is started. The error message simply means that x16edit-0.2.3.prg wasn't found, presumably not being in the path where you started the emulator from. The easiest solution might be to stand in the folder where x16edit-0.2.3.prg is saved in the host file system when you start the emulator. Then the command should work without any changes. If you still have problems it may help to copy x16edit-0.2.3.prg to the same folder where the emulator executable is stored. 

Another solution would be to use an absolute path to the prg file. As I have no Windows installation, I cannot test exactly how you would specify an absolute path, but you could test "c:/downloads/x16edit-0.2.3.prg" or "c:\downloads\x16edit-0.2.3.prg" (assuming that the prg file is stored in the c:\downloads folder. The command would then be:

• 
  x16edit.exe -sdcard sdcard.img -prg c:/downloads/x16edit-0.2.3.prg -run (if forward slashes work on the Windows version of the emulator)
  

However, it's also possible to copy the prg file to the sdcard image as you did. If you do this, you need to load and run the program in a different way:

• 
  Ensure that the sdcard image is not mounted in Windows. Mounting the image on two systems at the same time may corrupt the sdcard image.
  


• 
  Start the emulator with the following command: x16emu.exe -sdcard sdcard.img
  


• 
  In the emulator, first type: LOAD "X16EDIT-0.2.3.PRG"
  


• 
  Then type RUN
  

 

Thank you it's clear now!

Is there any chance to make x16edit capable of parsing tokenized BASIC files, then save them tokenized? 

It would be great to use the editor for enhanced BASIC programming.

I started to look at a solution a couple of weeks ago:

• 
  Write BASIC code and save as text file (=source)
  


• 
  Run a parser/translator on the source file which outputs a tokenized BASIC program
  


• 
  I don't know if the parser/translator should be integrated into the editor or if it should be a separate program.
  


• 
  The parser/translator could make it possible to write BASIC code with support for labels and long variable names, and without using line numbers.
  

It's feasible, but a lot of work.

54 minutes ago, Stefan said:

It would be great to use the editor for enhanced BASIC programming.



I started to look at a solution a couple of weeks ago:

• 
  Write BASIC code and save as text file (=source)
  


• 
  Run a parser/translator on the source file which outputs a tokenized BASIC program
  


• 
  I don't know if the parser/translator should be integrated into the editor or if it should be a separate program.
  


• 
  The parser/translator could make it possible to write BASIC code with support for labels and long variable names, and without using line numbers.
  

It's feasible, but a lot of work.

It would be great! Maybe the parser could be a separate program to make things more clean, then it can be integrated later.