APL input revisited

APL input revisited

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

(I've been reading this list for a while, and I'm still not sure if this is
actually the best forum for this kind of question. If not, please accept my
apologies and simply ignore this mail).

Since I started developing gnu-apl-mode a few months ago (it has grown
quite a lot recently), I have been thinking of the best ways to deal with
APL input in Emacs.

The reason I'm posting this is that I would like to have some input from
people who know Emacs better than I.

Currently, I provide two main modes of inputting APL symbols:

  - The relevant key together with Super (s-G mapped to a function that
inserts "⍒", s-8 calls another function that inserts "≠", etc...)

  - A Quail mode that uses . (peroid) as a prefix. I.e. ".G" and ".8"
yields the previously mentioned characters. ".." generates a normal period.

The problems:

The "super" mappings are very nice, but has two problems: 1) They don't
work in the minibuffer, and 2) Linux desktops are notious in using the
Super prefix for other things. And GNOME doesn't event allow you to get rid
of screen rotation lock (Super-o).

The Quail mode is annoying in that I can't think of a good prefix character
to use that doesn't conflict with most other uses and is at the same time
easy to reach (you have to use it a _lot_ when programming APL). I admit
that "." is not a good choice, but when looking for better ones I always
come up short.

So, what is the best way to deal with this? What options do I have?

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1873 bytes --]

Re: APL input revisited

[Emilio Lopes]

2014-02-19 9:39 GMT+01:00 Elias Mårtenson <lokedhs@gmail.com>:
> Currently, I provide two main modes of inputting APL symbols:
>
>   - The relevant key together with Super […]
>   - A Quail mode that uses . (peroid) as a prefix […]
>
> So, what is the best way to deal with this? What options do I have?

One suggestion that comes to mind is an abbrev-table.  You could setup
abbrevs like ".G" and ".8" (but you don't have to use any prefix as ".").
The user can program with abbrev-mode turned on or he can expand
abbrevs manually ("C-x '").

The "prefix" for the abbrevs need not to have word constituent syntax.
You can e.g. use

    (abbrev-table-put apl-abbrev-table
                      :regexp
"\\(?:[^[:word:],]\\|^\\)\\(,?[[:word:]]+\\)[^[:word:]]*")

to allow for abbrevs beginnig with a comma (",").

Emílio

Re: APL input revisited

[Stefan Monnier]

> Since I started developing gnu-apl-mode a few months ago (it has grown
> quite a lot recently), I have been thinking of the best ways to deal with
> APL input in Emacs.

Any news on adding it to GNU ELPA?


        Stefan

Re: APL input revisited

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

I'm still waiting for my employer to clear the necessary documents.

Then there is a second issue. The package contains documentation snippets
(for the integrated documentation buffers) that is copyright IBM (they gave
me permission to use the material). However, they still keep the copyright
to this material.

The mode works fine without it, but there is practically no integrated
documentation then. I've been thinking of splitting it so that the
IBM-derived documentation is in a separate optional package, or something
like that. I decided not to think about it until my employers legal
department finally decides to sign the documents.

If anyone is willing to write GNU-licensed reference documentation for GNU
APL, that would also be a good solution.

Until all of this is cleared, it'll be available in MELPA.

Regards,
Elias

On 19 February 2014 22:20, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > Since I started developing gnu-apl-mode a few months ago (it has grown
> > quite a lot recently), I have been thinking of the best ways to deal with
> > APL input in Emacs.
>
> Any news on adding it to GNU ELPA?
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 1801 bytes --]

Re: APL input revisited

[Stefan Monnier]

> The mode works fine without it, but there is practically no integrated
> documentation then.  I've been thinking of splitting it so that the
> IBM-derived documentation is in a separate optional package, or something
> like that.  I decided not to think about it until my employers legal
> department finally decides to sign the documents.

Shouldn't the documentation come with GNU ALP rather than with gnu-apl-mode?


        Stefan