Jump to content

Stefan

Members
  • Content Count

    21
  • Joined

  • Last visited

  • Days Won

    1

Stefan last won the day on August 22

Stefan had the most liked content!

Community Reputation

19 Good

About Stefan

  • Birthday 01/03/1973

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @BruceMcFI experimented a little with automatic word wrap. As you said earlier, it's quite easy to monitor the length of a line as each char is typed in, and wrap at the previous word boundary by inserting a line feed marker. That will be very close to GNU Nano's long line wrapping feature, which you enable by pressing ESC and then L. It's at bit more complicated if you delete text in the middle of a line. Word processors recalculate the word wrap if this happens, and move words from the beginning of the line below to the end of the currently edited line as soon as each word will fit. GNU Nano's long line wrapping feature works in a more simple way, and it will not recalculate the word wrap when you delete text. If I do this, I'm thinking about going the GNU Nano way with word wrap. Would that be alright?
  2. Hi all. I have just published version 0.0.4 of my text editor. New in this version: More bug fixes. Most of memory handler redesigned. The program is now more stable. The program tracks if a document has been changed and asks you to save before any operation that would discard those changes (closing the program, opening a new document, creating a new document). Other general user interface improvements. Function to display memory usage implemented (press ESC and then m). Displayed as number of blocks free, inspired by the 1541. One block is 251 bytes of actual text data. I also made a short video demonstrating some of the features. Look carefully, and you may spot a mistake in my C programming. Have a nice weekend! x16edit 0.0.4.mov
  3. Sounds like a good idea. If I understand, you mean automatic word wrap that inserts an actual line feed marker in the buffer. That might actually be possible to do. In my first attempt I had word wrap that was calculated from the top of the paragraph without inserting any line feed markers. That became complicated. An alternative is to use some other control char to mark automatic word wrap. If I remember correctly, WordStar used such an internal marker. The advantage is that you can strip the word wrap marker when saving to file. Another thing. In my last post I said I had no know bugs. Naturally I found a couple right after saying that. On my bug severity scale, irritating - serious - deadly, I was closing up on deadly. When you inserted text above text that was already typed in, a few letters every now and then would be duplicated, effectively a memory corruption problem. Usually, you see right away what's causing such a problem. But in this case the corruption seemed random. I used a good 5 hours to isolate when the problem occurred. Finally I found an off by one error in the routine deleting a char from memory. It's a good feeling fixing such a bug ...
  4. I do not plan to have word wrap, at least not now. When I use text editors, I never have word wrap enabled. If you're editing source code or config files, word wrap is of limited value. This is actually my second attempt at creating a text editor for X16. My first try in 2019 had word wrap. The code became ugly and had a lot of hard to find bugs. I dropped word wrap to make things easier, but I might revisit it in the future. V. 0.0.3 is quite stable, and I have no known bugs (they are probably there anyway). I think I have a solid base to continue from. These are the things I'm working on now and in the near future: Memory defragmentation routine Search and replace Cut and paste
  5. If you're disciplined, no project is too large or complex for command line + Nano. I must look into Forth. Have never tried it.
  6. I just published a new version of X16 Edit to the downloads page. What's new? A lot of updates to the UI Some bug fixes It might soon even be usable.
  7. @BruceMcF I don't remember ever hearing about XOR linked lists. You couldn't easily come up with such a concept. I guess it's true that there's creativity in limitation. The downside is, of coarse, more complex code which might be a bit harder to debug.
  8. That's an interesting subject. The editor might not work as you think. It is essentially a model-view design. The memory module (=model) has no concept of screen or line. It is just text data. So there is no limit to the length of a line. If you like, the text can be one line, 2MB long. And there are no links to previous or next line or to the previous or next screen page (or any other element of the view module). When designing this, I calculated the memory usage. 16 bits are needed to represent the bank of the previous and the next memory page. 10 bits are needed to represent the previous and the next memory page high byte (range a0-bf is 1f wide = 5 bits). That is a total of 26 bits, not quite fitting in three bytes. I can't do any better, I think. The memory not used is 6 bits per memory page. 8,192 memory pages x 6 bits = 6,144 bytes lost of the total 2 MB. In the future I might come up with a use for those unused bits...
  9. Yes. However, I think you may call it a feature, and keep the emulator as is No problem, as long as you're aware.
  10. Hi, I've been testing to write sequential files to the sdcard image using the standard KERNAL routines (SETNAM, SETLFS, OPEN, CHKOUT and CHROUT) in emulator R38. I've noticed that files sometimes get corrupted. It seems to happen if the sdcard is mounted on the host computer's file system at the same time as it's attached to the emulator. However, writing to the sdcard seems stable if it's not mounted to the host system at the same time. I'm running macOS Catalina.
  11. A small video of the v. 0.0.2. Opening one of the editor's source files (file.inc). Skärminspelning 2020-08-30 kl. 10.58.51.mov
  12. I've published my second pre-release (v 0.0.2) of X16 Edit in the downloads section of this web page. Courtesy of emulator r38 (nice work!), I've implemented basic file handling. It is now possible to load and save text files to an attached sdcard. Use the -sdcard switch when launching the emulator. File handling will not work without an attached sdcard. This is a limitation of the emulator, as far as I can tell.
  13. Version 0.0.4

    20 downloads

    X16 Edit is a text editor for the Commander X16 platform. Design goals: Use plain text files as the program's interface to the outside world Use banked RAM (about 2 MB) to store currently edited document Be able to handle large texts efficiently No limit to the number of characters per line or the number of lines in a document (other than the available RAM) Simple user interface inspired by GNU Nano Implement basic editing functions well - refrain from making it too feature-rich Support both ISO and PETSCII mode Consider supporting syntax highlighting, if it can be done efficiently Tested with emulator version r38. Run with the following command: x16emu -sdcard sdcard.img -prg x16edit-0.0.3.prg -run Source files available at https://github.com/stefan-b-jakobsson/x16-edit Released under GNU General Public License v 3 or later. x16edit-0.0.4.prg
  14. X16 Edit - a text editor View File X16 Edit is a text editor for the Commander X16 platform. Design goals: Use plain text files as the program's interface to the outside world Use banked RAM (about 2 MB) to store currently edited document Be able to handle large texts efficiently No limit to the number of characters per line or the number of lines in a document (other than the available RAM) Simple user interface inspired by GNU Nano Implement basic editing functions well - refrain from making it too feature-rich Support both ISO and PETSCII mode Consider supporting syntax highlighting, if it can be done efficiently Tested with emulator version r38. Run with the following command: x16emu -sdcard sdcard.img -prg x16edit-0.0.3.prg -run Source files available at https://github.com/stefan-b-jakobsson/x16-edit Released under GNU General Public License v 3 or later. x16edit-0.0.4.prg Submitter Stefan Submitted 08/29/20 Category Productivity Apps  
  15. Syntax highlighting would be nice. I'm worried about performance though. Multi-line highlighting would be especially hard to implement efficiently. For example multi-line comments in C. Highlighting not dependent on what's happening in the text above or below the current line would be simpler. However, it's a good idea, and I will have it in mind. A question: If the program should support highlighting, is there any reasonable way to make "plugins" for different file formats? I guess the program could load the selected highlighting code into RAM from the filesystem after startup. There could be a standardized jump table at the beginning of the code that exposes vectors to the needed subroutines. Or is there better way?
×
×
  • Create New...

Important Information

Please review our Terms of Use