> Doesn't this amount to a GNU/APL-specific implementation of the
> standard X Compose mechanism?
>
> https://lists.gnu.org/archive/html/bug-apl/2014-05/msg4.html
Not exactly. akt's mapping is targeted rather than global to the login
session. More important (from my perspective) is that the m
On Thu, Oct 23, 2014 at 01:04:50AM EDT, David Lamkins wrote:
> As much as I like gnu-apl-mode and aplwrap (I use both on a daily basis), I
> felt like there ought to be a more lightweight approach to getting APL
> characters into GNU APL.
>
> Today I wrote `akt`, the APL Keyboard Translator.
>
>
On Thu, Oct 23, 2014 at 01:37:18PM EDT, Chris Jones wrote:
> On Thu, Oct 23, 2014 at 01:04:50AM EDT, David Lamkins wrote:
> > As much as I like gnu-apl-mode and aplwrap (I use both on a daily basis), I
> > felt like there ought to be a more lightweight approach to getting APL
> > characters into GN
Yes, I did look at APL_keyboard a long time ago. (I had forgotten about it
until now.)
On Thu, Oct 23, 2014 at 5:49 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi David,
>
> did you have a look at *tools/APL_keyboard* ? It works in the same way
> (piping its output to GNU AP
On Thu, Oct 23, 2014 at 01:04:50AM EDT, David Lamkins wrote:
> As much as I like gnu-apl-mode and aplwrap (I use both on a daily basis), I
> felt like there ought to be a more lightweight approach to getting APL
> characters into GNU APL.
>
> Today I wrote `akt`, the APL Keyboard Translator.
>
>
Hi David,
did you have a look at tools/APL_keyboard ? It works in
the same way (piping its output to GNU APL),
but makes fewer assumptions about the encoding of the keyboard sequences.
And it can be "trained"
for not-so-standard keyboards.
Fair enough. I'll put high-bit controls on the TODO list along with
alternate prefixes.
On Thu, 2014-10-23 at 14:26 +0800, Elias Mårtenson wrote:
> I have no idea. Probably not. :-) The point, however, is that if there
> is a standard way of doing it, that should be used. And I believe
> there is
I have no idea. Probably not. :-) The point, however, is that if there is a
standard way of doing it, that should be used. And I believe there is a
most standard way (or am I wrong? I might mis-remember).
Regards,
Elias
On 23 October 2014 14:24, David B. Lamkins wrote:
> Interesting. I knew abo
Interesting. I knew about the high-bit controls, but honestly can't
remember the last time I saw a system that used them. Aside from xterm
(given appropriate configuration), are high-bit controls used on any of
your available platforms?
On Thu, 2014-10-23 at 14:09 +0800, Elias Mårtenson wrote:
> I
If you have never seen anything else, then I must assume that you haven't
looked hard enough. :-) In fact, the usual way was to simply set the high
bit to 1 to indicate Alt. Emacs implemented a workaround for terminals that
did not support this (the Esc-prefix) and many terminal emulators have
ado
Thanks, Elias.
I was inspired by what I saw coming out of `showkey`, so I looked at the
source and realized that the foundation was very simple. The only really
tricky part was distinguishing between the ANSI CSI (a two-character
prefix of all ANSI cursor and function keys) and the APL `←` which i
This is a neat idea, and something like this should be integrated in GNU
APL itself, I think.
However, making the assumption that Alt causes esc-prefixing is not an
ideal approach. May I suggest that you take a look a the features that
Curses offers to do this in a terminal-independent manner?
Al
As much as I like gnu-apl-mode and aplwrap (I use both on a daily basis), I
felt like there ought to be a more lightweight approach to getting APL
characters into GNU APL.
Today I wrote `akt`, the APL Keyboard Translator.
https://github.com/TieDyedDevil/akt
This small C program simply reads stdi
13 matches
Mail list logo
