Closed HeathenUK closed 8 months ago
lennart-benschop
commented
9 months ago How was it implemented in the old BBC micro? Back in the day we certainly did not flat out allocate 10 maximum length buffers for each of the function key definitions we might have.
HeathenUK
commented
9 months ago Good question, not sure. There's really only two camps though - you hold the space or your dynamically allocate it and make sure to free it. I'm sure we could achieve the latter with some fresh eyes.
stevesims
commented
9 months ago on the Beeb this was *key <num> <value>
This is described in chapter 25 of the BBC Micro user guide. The RISC OS command documentation is here: https://www.riscosopen.org/wiki/documentation/show/*Key
Further descriptions of how function keys can be set on RISC OS can be found on this page (search for *Key):
http://www.riscos.com/support/developers/prm/charinput.html
As you'll see from the RISC OS docs, you could also on that platform define keys using for instance *Set Key$7 Hello to set key f7 to insert "Hello" into the input buffer. *unset key$7 would clear f7, and *unset key$* would clear all the function keys. they also supported *SetMacro Key$n expression which does something more sophisticated, passing the expression thru the OS_GSTrans OS function - altho I don't think I ever used that.
Control characters could be inserted into the string value by using the pipe character, so |M for instance is equivalent to pressing the return key.
I must admit I've not yet looked properly at this implementation :grin:
my inclination would be to try to follow the Beeb first (i.e. supporting *key n), and RISC OS second (*set key$n and *unset, and probably ignore *setmacro). Acorn's use of the pipe character could be considered to be a bit odd/idiosyncratic - I might consider changing to use \, but that may also not work quite as expected
HeathenUK
commented
9 months ago Ok, I've:
This PR seeks to add the ability to assign a command string to keys F1 to F12. It hooks in to mos_EDITLINE and therefore supports anything that calls on that function for input handling including both MOS itself and BBC BASIC.
Welcome thoughts on the implementation. This works well but relies on creating thirteen more 256 byte-wide strings to store first a preserved, untokenised command line, and then twelve more for each potential hotkey command. That's 3.3K of RAM on top of the 4K we already reserve for command line history. Perhaps that's fine with 512KB to spare, but it seems wasteful. I considered mallocing each buffer as it's used but it's challenging to determine where you'd free them.
It also makes a tweak to the MOS internal VDU command to bring it in line with BASIC notation (; meaning to treat the preceding as a 16-bit value). Commas are optional for chars. Ignore the commit reverting this, I hate Git.