search

kareltucek / firmware

This is fork of UHK's firmware featuring extended macro engine.
Other
82 stars 9 forks source link

Using space character in text #81

Closed soraxas closed 1 year ago

soraxas commented 2 years ago

Hi! What would be the best way to input space characters in the macro engine? For example, to display " HI" as the led text.

kareltucek commented 2 years ago

Currently there is no way to do that. (Let's call it technical debt.)

At some point, the language definition should be refactored so that strings are unambiguously regex-recognizable tokens (some type of quote notation). This loosely relates to https://github.com/UltimateHackingKeyboard/agent/issues/1630 and its plan to provide syntax-aware editor features - I assume that the refactor may be either necessary, or desirable in order to make those features work.

(Also, during such refactor, other features may be considered - like scoping or expression parser.)

soraxas commented 2 years ago

I think it's amazing how this macro engine had implemented such a workable token parsing engine for the macro engine. But indeed it is always cumbersome to reinvent string token parsing. Perhaps we should leverage existing scripting engines (or at least get inspiration on how they are implemented) to avoid re-inventing the wheels?

For example, this lisp interpreter in C looks interesting and it directly follows the operator / args expression that we currently have. The brackets also helps scoping the expression (and chaining actions)

kareltucek commented 2 years ago

(or at least get inspiration on how they are implemented) to avoid re-inventing the wheels

This is totally agreed.

Perhaps we should leverage existing scripting engines

Please note that we are very tight on RAM.

UHK has 128 kb of RAM out of which 2x 32 kb are taken by configuration. It might be possible to free one of these regions by some clever refactor. The 64 kb are almost depleted - there are some 3kb of reserve in buffers - and we will probably need to free some of it for custom RGB backlight. I am not sure how good idea it would be to introduce malloc into the codebase - so far, everything is statically allocated, and the macro engine is designed so that it is almost stateless.

For example, this lisp interpreter in C looks interesting and it directly follows the operator / args expression that we currently have. The brackets also helps scoping the expression (and chaining actions)

I will give it more thought another time. However, if you are eager to dig deep into it, feel free to.

kareltucek commented 2 years ago

I have looked briefly into the interpreter, and realized that I am not sure how to maintain stateful information if the interpreter is employed.

It seems to me, that either a lot of the logic of "modifier commands" would either have to be re-implemented in lisp and consequently loaded as a lisp library, or a lot of state would have to be maintained outside of the lisp interpreter itself, including scoping.

As a result, it seems like employing the interpreter would mean having to write and maintain an engine which would actually execute as a "Cartesian product" of the current macro engine and the lisp interpreter. I.e., the solution would have to switch between C runtime and lisp interpretation modes in a very intricate and delicate manner.

I have a feeling that lisp, as a pure functional language is well suited for computing results, but badly suited to do effectful processing. In this sense, current macro language is 100% procedural language, which does 100% of its work by performing effects, rather than computing values in a functional sense.

kareltucek commented 2 years ago

(This is assuming that we would actually want UHK to run a full fledged lisp interpretter.)

kareltucek commented 1 year ago

Is/will be solved by https://github.com/UltimateHackingKeyboard/firmware/pull/674