Reply to note from Bob Newell <dmarc-noreply@xxxxxxxxxxxxx> Tue, 01 Sep 2026 13:54:30 -1000 Bob, > I wanted a keyboard setup with my beloved Emacs keybindings. ... > I will continue to work on this as time allows and post the result > when I think it's close enough to Emacs. Interesting project. Yes, please do keep us posted. > (It's a bit confusing that xpl files use one comment marker and kbd > files use another.) It makes sense if you think about it. KBD files and XPL files are two distinct entities. The XyScript KBD file adopts the XyWrite file format virtually wholesale. Since XyWrite uses the semicolon for comments, it seems a bit gratuitous to change it. But there's a more compelling reason: The left-hand side of a key binding is pure KBD-file machinery; the right-hand side *consists of XPL* -- and potentially includes XPL comments. So the two comment symbols reinforce the distinction between a KBD-file comment (which disables a binding) and an XPL comment on the RHS of a key binding (e.g., to annotate the XPL code) -- and there is a real difference. > In my installation trying to open a file in the current directory by > just giving the file name on the command line doesn't work. It > creates a buffer with the right title but no content. A full path > name is necessary, for instance > > xyscript foo.txt > > doesn't work but > > xyscript /home/bnewell/foo.txt > > does work. That's not surprising. If your shell command is a bare "xyscript" (no path), it means that the current working directory is the directory with the xyscript executable, which presumably is different from /home/bnewell. Paths on the command line are resolved with respect to the CWD. > It would be nice if the file open dialog would start in the current > working directory or even better the last used file directory. Point taken. Currently, the OPEN dialog starts out in the XyScript program directory. If you use the dialog to open a file in a different directory, it will (or should) remember that directory the next time you open the dialog. But you're right, the first time it should open in the CWD. I'll add this to the punch list for the next release. > This may exist already but a cumulative buffer of all messages > (especially error messages) which can be saved and edited would help > a lot in debugging. It doesn't exist, and it's an excellent idea. I'll implement it as an optional error/status message logging feature. -- Carl Distefano cld@xxxxxxxxxx