APL mode

APL mode

[Rustom Mody]

Resending my last message in plain text.
Sorry for the inconvenience!
----------------------------------------------------------


Hello all!

As some of you may know Gnu Apl has been very recently released
http://www.gnu.org/software/apl/

I feel in the modern unicoded world, APL may be more usable than it
has ever been, so having a modern (unicode-based) Apl running on
Gnu/Linux systems is quite a big thing. [Well at least for some
old-fogeys :-) ]

I asked the author Juergen Sauermann if there was an emacs mode.
He asked 'Whats a mode? " :-) . He agreed that if I provided one he
would put it in.

Is anyone working on this??

For the time being Ive put together something minimal by
a. taking scheme.el, cmuscheme.el
b. search-replace-ing scheme by apl
c. Do the minimal hacking required to make it work
d. Throw out obviously unneeded parts (like DSSSL stuff)

Also looking at perl and ada modes for characters, fontlock etc.

Any preferable sources to study/copy from?
I tried to study C-mode(s) but it was too vast to make sense :-(

About syntax:
What does sexp mean for non-lisp languages like C etc?
(Needed for functions like forward-sexp)

About Font lock:
APL is notorious for being unreadable. This is related to having
almost no keywords and only weird characters.
Having a good coloration for different categories of characters will
help a long way.

Is there somewhere I can 8-10 different faces ready?
And how faces are used in programming modes?

Input methods:
Current input method supplied by Juergen is xmodmap based.
We need other more emacsy method(s). I'll write about that
subsequently, if I can get the above working :-)


Rusi

-- 
http://blog.languager.org

APL mode

[Rustom Mody]

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

Hello all!

As some of you may know Gnu Apl has been very recently released
http://www.gnu.org/software/apl/

I feel in the modern unicoded world, APL may be more usable than it has
ever been, so having a modern (unicode-based) Apl running on Gnu/Linux
systems is quite a big thing. [Well at least for some old-fogeys :-) ]

I asked the author Juergen Sauermann if there was an emacs mode.
He asked 'Whats a mode? " :-) . He agreed that if I provided one he would
put it in.

Is anyone working on this??

For the time being Ive put together something minimal by
a. taking scheme.el, cmuscheme.el
b. search-replace-ing scheme by apl
c. Do the minimal hacking required to make it work
d. Throw out obviously unneeded parts (like DSSSL stuff)

Also looking at perl and ada modes for characters, fontlock etc.

Any preferable sources to study/copy from?
I tried to study C-mode(s) but it was too vast to make sense :-(

About syntax:
What does sexp mean for non-lisp languages like C etc?
(Needed for functions like forward-sexp)

About Font lock:
APL is notorious for being unreadable. This is related to having almost no
keywords and only weird characters.
Having a good coloration for different categories of characters will help a
long way.

Is there somewhere I can 8-10 different faces ready?
And how faces are used in programming modes?

Input methods:
Current input method supplied by Juergen is xmodmap based.
We need other more emacsy method(s). I'll write about that subsequently, if
I can get the above working :-)


Rusi

-- 
http://blog.languager.org

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

Re: APL mode

[Thien-Thi Nguyen]

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

() Rustom Mody <rustompmody@gmail.com>
() Sat, 12 Oct 2013 10:18:21 +0530

   What does sexp mean for non-lisp languages like C etc?
   (Needed for functions like forward-sexp)

(info "(elisp) List Motion")

An "expression", either atomic or, if compound, delimited by balanced
pairs (parens, braces, quote chars), but note that a "defun" may have
other conceptual cruft (typically at the beginning, e.g., a C function)
so that it is not a simple "sexp".  In a similar vein, multi-char pairs
(e.g,. "begin".."end") require more hair, but the idea is the same.

   Is there somewhere I can 8-10 different faces ready?
   And how faces are used in programming modes?

(info "(elisp) Faces for Font Lock")

Try also ‘M-x list-faces-display’.  Programming modes are encouraged to
use those whose names begin with "font-lock-", i believe.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: APL mode

[Stefan Monnier]

> What does sexp mean for non-lisp languages like C etc?
> (Needed for functions like forward-sexp)

It means "a subtree in the abstract syntax tree".


        Stefan

Re: APL mode

[Rustom Mody]

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

On Sat, Oct 12, 2013 at 7:56 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:
>> What does sexp mean for non-lisp languages like C etc?
>> (Needed for functions like forward-sexp)
>
> It means "a subtree in the abstract syntax tree".

In principle, that's fine. However in practice there are things like
a. comments which do not exist in the AST
b. preprocessor commands that appear and disappear before ASTs are on the
scene
c. (most important) emacs doesnt really do a full-scale context free
grammar analysis does it?

So I guess I am asking: Emacs uses regular exps to fudge a semblance of
context free structure. How does it do this?

Rusi
-- 
http://www.the-magus.in
http://blog.languager.org

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

Re: APL mode

[Stefan Monnier]

>>> What does sexp mean for non-lisp languages like C etc?
>>> (Needed for functions like forward-sexp)
>> It means "a subtree in the abstract syntax tree".
> In principle, that's fine. However in practice there are things like
> a. comments which do not exist in the AST

comments should normally be skipped by forward-sexp.

> b. preprocessor commands that appear and disappear before ASTs are on the
> scene

Indeed, there are cases where the source code does not correspond to
a tree (and not even a DAG either).  In that cases, the expected
behavior of forward-sexp is undefined (i.e. total freedom).

> c. (most important) emacs doesnt really do a full-scale context free
> grammar analysis does it?

Not sure what you man by "Emacs" here: Emacs just runs the code provided
by the major mode author, so it's the major mode's author's
responsibility to make sure forward-sexp works as it should.

> So I guess I am asking: Emacs uses regular exps to fudge a semblance of
> context free structure. How does it do this?

There's `forward-sexp-function' which lets you write your parser by
hand.

Else, there's a very simplistic builtin parser, which doesn't know about
infix operators and only know how to skip "normal" comments, how to
recognize "normal" strings, and how to skip parentheses (and related
pairs, with restrictions such as: the opening and closing markers are
single chars).  The "grammar" for this parser is given in the form of
what we call a "syntax-table".

In between, there's SMIE which does precedence parsing.  It's a very
weak grammar, but since we want to parse backward (for backward-sexp),
it's a good option since, contrary to LL/LR and friends it's fully
symmetric.  We use it for various different modes: Coq, SML, OCaml,
Prolog, sh, Ruby, Modula-2, Octave, css.


        Stefan "who doesn't know much about APL's syntax"

Re: APL mode

[Stephen J. Turnbull]

Rustom Mody writes:
 > On Sat, Oct 12, 2013 at 7:56 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
 >> RM wrote:

 >>> What does sexp mean for non-lisp languages like C etc?

 >> It means "a subtree in the abstract syntax tree".

 > In principle, that's fine. However in practice there are things like
[...]
 > c. (most important) emacs doesnt really do a full-scale context
 >    free grammar analysis does it?

If you use the semantic package, it can.  Most simple modes don't,
although use of semantic is becoming more common.

 > So I guess I am asking: Emacs uses regular exps to fudge a
 > semblance of context free structure. How does it do this?

Either it uses semantic, or it mixes regexp "parsing" with use of
regexps to match lexical tokens and custom lisp to parse.

Re: APL mode

[Rustom Mody]

On Sun, Oct 13, 2013 at 12:15 PM, Stephen J. Turnbull
<stephen@xemacs.org> wrote:
> Rustom Mody writes:
>  > On Sat, Oct 12, 2013 at 7:56 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>  >> RM wrote:
>
>  >>> What does sexp mean for non-lisp languages like C etc?
>
>  >> It means "a subtree in the abstract syntax tree".
>
>  > In principle, that's fine. However in practice there are things like
> [...]
>  > c. (most important) emacs doesnt really do a full-scale context
>  >    free grammar analysis does it?
>
> If you use the semantic package, it can.  Most simple modes don't,
> although use of semantic is becoming more common.

My choice is to preferably stay simple even if that means not covering
20% of odd/corner cases.
Not to say that I am afraid of CFGs -- more afraid of regexps with 16
backslashes in a row!!

>  > So I guess I am asking: Emacs uses regular exps to fudge a
>  > semblance of context free structure. How does it do this?
>
> Either it uses semantic, or it mixes regexp "parsing" with use of
> regexps to match lexical tokens and custom lisp to parse.
>

Can you point me to somewhere to read as example?
I looked at C mode(s) but there is so much file-level structure I
could not figure out where the action is happening.

General note:
As a language, APL is probably quite simple if not trivial --
function definitions contain
lines contain
expressions.

No control structures, classes etc etc.

Rusi
-- 

http://blog.languager.org

Re: APL mode

[Stephen J. Turnbull]

Rustom Mody writes:

 > Not to say that I am afraid of CFGs -- more afraid of regexps with 16
 > backslashes in a row!!

XEmacsen have rawstrings (couldn't resist), but the real answer is to
use one of the regexp constructor packages if you don't feel like
dealing the the unfortunate consequences of the traditional use of the
same character to indicate string escapes and regexp constructs too.

 > Can you point me to somewhere to read as example?

css-mode, htmlize, nroff-mode, xpm-mode, xrdb-mode.  But you won't
find a Lispish parser in any of them IIRC.  Rather the parsing is
buried in movement functions and the like.  To find what you're
looking for, find the keymap, and then find the motion function.

Re: APL mode

[Rustom Mody]

On Sun, Oct 13, 2013 at 4:40 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Rustom Mody writes:
>
>  > Not to say that I am afraid of CFGs -- more afraid of regexps with 16
>  > backslashes in a row!!
>
> XEmacsen have rawstrings (couldn't resist), but the real answer is to
> use one of the regexp constructor packages if you don't feel like
> dealing the the unfortunate consequences of the traditional use of the
> same character to indicate string escapes and regexp constructs too.

Ok I find something called rx.
I think I need something like rx-inverse -- something which will give
me an sexp interpretation of an ugly re.

>
>  > Can you point me to somewhere to read as example?
>
> css-mode, htmlize, nroff-mode, xpm-mode, xrdb-mode.  But you won't
> find a Lispish parser in any of them IIRC.  Rather the parsing is
> buried in movement functions and the like.  To find what you're
> looking for, find the keymap, and then find the motion function.

Could not find many of these. Are they elisp files in the standard distribution?
Also any examples that use semantic?

Rusi

Re: APL mode

[Stephen J. Turnbull]

Rustom Mody writes:

 > >  > Can you point me to somewhere to read as example?
 > >
 > > css-mode, htmlize, nroff-mode, xpm-mode, xrdb-mode.  But you won't
 > > find a Lispish parser in any of them IIRC.  Rather the parsing is
 > > buried in movement functions and the like.  To find what you're
 > > looking for, find the keymap, and then find the motion function.
 > 
 > Could not find many of these. Are they elisp files in the standard
 > distribution?

I would think so, except for htmlize.

http://ftp.xemacs.org/packages/text-modes-1.98-pkg.tar.gz

has all of them and a number of other examples.


 > Also any examples that use semantic?

ecb and jde are the only ones I know of.  grep -rl "require 'semantic"
should give you a nice list.

Re: APL mode

[Ivan Andrus]

On Oct 13, 2013, at 8:04 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Sun, Oct 13, 2013 at 4:40 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>> Rustom Mody writes:
>> 
>>> Not to say that I am afraid of CFGs -- more afraid of regexps with 16
>>> backslashes in a row!!
>> 
>> XEmacsen have rawstrings (couldn't resist), but the real answer is to
>> use one of the regexp constructor packages if you don't feel like
>> dealing the the unfortunate consequences of the traditional use of the
>> same character to indicate string escapes and regexp constructs too.
> 
> Ok I find something called rx.
> I think I need something like rx-inverse -- something which will give
> me an sexp interpretation of an ugly re.

In the pcre2el package (available in MELPA or marmalade) you will find `rxt-elisp-to-rx' which does just that.  I've only used it a little but it seems to work well.

-Ivan

Re: APL mode

[Rüdiger Sonderfeld]

Hi,
I started working on some APL-mode stuff.  But I haven't gotten very far and I 
currently lack the time to continue working on it.

Feel free to improve/change it:

https://github.com/ruediger/apl-mode

Regards,
Rüdiger

On Saturday 12 October 2013 10:18:21 Rustom Mody wrote:
> Hello all!
> 
> As some of you may know Gnu Apl has been very recently released
> http://www.gnu.org/software/apl/
> 
> I feel in the modern unicoded world, APL may be more usable than it has
> ever been, so having a modern (unicode-based) Apl running on Gnu/Linux
> systems is quite a big thing. [Well at least for some old-fogeys :-) ]
> 
> I asked the author Juergen Sauermann if there was an emacs mode.
> He asked 'Whats a mode? " :-) . He agreed that if I provided one he would
> put it in.
> 
> Is anyone working on this??
> 
> For the time being Ive put together something minimal by
> a. taking scheme.el, cmuscheme.el
> b. search-replace-ing scheme by apl
> c. Do the minimal hacking required to make it work
> d. Throw out obviously unneeded parts (like DSSSL stuff)
> 
> Also looking at perl and ada modes for characters, fontlock etc.
> 
> Any preferable sources to study/copy from?
> I tried to study C-mode(s) but it was too vast to make sense :-(
> 
> About syntax:
> What does sexp mean for non-lisp languages like C etc?
> (Needed for functions like forward-sexp)
> 
> About Font lock:
> APL is notorious for being unreadable. This is related to having almost no
> keywords and only weird characters.
> Having a good coloration for different categories of characters will help a
> long way.
> 
> Is there somewhere I can 8-10 different faces ready?
> And how faces are used in programming modes?
> 
> Input methods:
> Current input method supplied by Juergen is xmodmap based.
> We need other more emacsy method(s). I'll write about that subsequently, if
> I can get the above working :-)
> 
> 
> Rusi

Re: APL mode

[Rustom Mody]

On Sun, Oct 13, 2013 at 6:12 PM, Rüdiger Sonderfeld
<ruediger@c-plusplus.de> wrote:
> Hi,
> I started working on some APL-mode stuff.  But I haven't gotten very far and I
> currently lack the time to continue working on it.
>
> Feel free to improve/change it:
>
> https://github.com/ruediger/apl-mode

Hi Rüdiger
Good to see someone else has interest in APL-under-emacs!

I have one general question for you: Did you try Gnu-Apl under emacs?
I personally find the xmodmap approach too invasive to be practicable
-- everything other than the emacs-apl modes stop working!  Not just
at the emacs level but even at the X level eg Alt-F2, Alt-F4 etc etc
So I feel we need to find an input-method approach which does not
disturb things too much outside the 2 buffers where its needed -- Apl
file, Apl interpreter.

-- 
http://www.the-magus.in
http://blog.languager.org

Re: APL mode

[Rüdiger Sonderfeld]

Hi,

On Sunday 13 October 2013 20:17:04 Rustom Mody wrote:
> I have one general question for you: Did you try Gnu-Apl under emacs?
> I personally find the xmodmap approach too invasive to be practicable
> -- everything other than the emacs-apl modes stop working!  Not just
> at the emacs level but even at the X level eg Alt-F2, Alt-F4 etc etc
> So I feel we need to find an input-method approach which does not
> disturb things too much outside the 2 buffers where its needed -- Apl
> file, Apl interpreter.

so far I only tried GNU APL with inferior-apl-mode.  Change `inferior-apl-
program' to point to the GNU APL executable and start `inferior-apl'.

I agree that the xmodmap approach isn't very practical.  apl-input.el contains 
an input method for APL characters.  You type $ followed by the name of the 
apl character unicode name.  (It currently lacks characters outside the APL 
FUNCTIONAL SYMBOL namespace).  This isn't very practical either.  That's why 
there is apl-input-x.el.  Which adds a variety of different names to the input 
method.

E.g.,

   ("<-" ?←)
   ("->" ?→)
   ("each" ?¨)
   ("&" ?∧)
   ("and" ?∧)
   ("nand" ?⍲)
   ("or" ?∨)
   ("nor" ?⍱)
   ("*" ?×)
   ("%" ?÷)
   ("/" ?÷)

But it requires some more additions and fine tuning to be really useful.

I'm not very well experienced with APL and only did some APL for fun.  That's 
why I might not be the best person to implement all of this.

Regards,
Rüdiger

Re: APL mode

[Rustom Mody]

On Sun, Oct 13, 2013 at 8:54 PM, Rüdiger Sonderfeld
<ruediger@c-plusplus.de> wrote:
> Hi,
>
> On Sunday 13 October 2013 20:17:04 Rustom Mody wrote:
>> I have one general question for you: Did you try Gnu-Apl under emacs?
>> I personally find the xmodmap approach too invasive to be practicable
>> -- everything other than the emacs-apl modes stop working!  Not just
>> at the emacs level but even at the X level eg Alt-F2, Alt-F4 etc etc
>> So I feel we need to find an input-method approach which does not
>> disturb things too much outside the 2 buffers where its needed -- Apl
>> file, Apl interpreter.
>
> so far I only tried GNU APL with inferior-apl-mode.  Change `inferior-apl-
> program' to point to the GNU APL executable and start `inferior-apl'.
>
> I agree that the xmodmap approach isn't very practical.

Heres a first cut attempt.
F8 and F9 are made to be like dead-keys by making them emacs prefix keys.
What do you think?

------------------------
;; (defvar apl-mode-map (make-sparse-keymap)) ;; defined elsewhere

(setq f9map (make-sparse-keymap))
(define-key apl-mode-map (kbd "<f9>") f9map)
(setq f8map (make-sparse-keymap))
(define-key apl-mode-map (kbd "<f8>") f8map)

(setq apl-key-table '(

;; top (number) row
"`◊⍨" "1¨¡" "2¯€" "3<£" "4≤⍧" "5= " "6≥ " "7> " "8≠⍂" "9∨⍱" "0∧⍲" "-×≡" "=÷⌹"

;; qwert row
"q?¿" "w⍵⌽" "e∈⍷" "r⍴ " "t∼⍉" "y↑¥" "u↓ " "i⍳⍸" "o○⍥" "p⋆⍟" "[← " "]→ "

;; asdf row
"a⍺⊖" "s⌈ " "d⌊ " "f_⍫" "g∇⍒" "h∆⍋" "j∘⍤" "k'⌺" "l⎕⍞" ";⊢ " "'⊣ "

;; zxcv row
"z⊂ " "x⊃ " "c∩⍝" "v∪ " "b⊥⍎" "n⊤⍕" "m|⌶" ",⌷⍪" ".⍎⍙" "/⍕⌿"

))

(dolist (k apl-key-table)
  (let ((kb-key   (string (aref k 0)))
    (apl-key1 (string (aref k 1)))
    (apl-key2 (string (aref k 2))))
  (define-key f8map kb-key apl-key1)
  (define-key f9map kb-key apl-key2)))
-----------------------------------------------------------
This is the 'ASCII-art though not ASCII' picture from gnu-apl that I have copied

╔════╦════╦════╦════╦════╦════╦════╦════╦════╦════╦════╦════╦════╦═════════╗
║ ~⍨ ║ !¡ ║ @€ ║ #£ ║ $⍧ ║ %  ║ ^  ║ &  ║ *⍂ ║ (⍱ ║ )⍲ ║ _≡ ║ +⌹ ║         ║
║ `◊ ║ 1¨ ║ 2¯ ║ 3< ║ 4≤ ║ 5= ║ 6≥ ║ 7> ║ 8≠ ║ 9∨ ║ 0∧ ║ -× ║ =÷ ║ BACKSP  ║
╠════╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦══════╣
║       ║ Q¿ ║ W⌽ ║ E⍷ ║ R  ║ T⍉ ║ Y¥ ║ U  ║ I⍸ ║ O⍥ ║ P⍟ ║ {  ║ }  ║  |⍀  ║
║  TAB  ║ q? ║ w⍵ ║ e∈ ║ r⍴ ║ t∼ ║ y↑ ║ u↓ ║ i⍳ ║ o○ ║ p⋆ ║ [← ║ ]→ ║  \⍝  ║
╠═══════╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩══════╣
║ (CAPS   ║ A⊖ ║ S  ║ D  ║ F⍫ ║ G⍒ ║ H⍋ ║ J⍤ ║ K⌺ ║ L⍞ ║ :  ║ "  ║         ║
║  LOCK)  ║ a⍺ ║ s⌈ ║ d⌊ ║ f_ ║ g∇ ║ h∆ ║ j∘ ║ k' ║ l⎕ ║ ;⊢ ║ '⊣ ║ RETURN  ║
╠═════════╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═════════╣
║             ║ Z  ║ X  ║ C⍝ ║ V  ║ B⍎ ║ N⍕ ║ M⌶ ║ <⍪ ║ >⍙ ║ ?⌿ ║          ║
║  SHIFT      ║ z⊂ ║ x⊃ ║ c∩ ║ v∪ ║ b⊥ ║ n⊤ ║ m| ║ ,⌷ ║ .⍎ ║ /⍕ ║  SHIFT   ║
╚═════════════╩════╩════╩════╩════╩════╩════╩════╩════╩════╩════╩══════════╝

Re: APL mode

[Rustom Mody]

Ive made the earlier code standalone-executable (without rest of
apl.el) and more readable.
Once the following code is executed, f8 and f9 should work as prefixes
for entering Apl characters, irrespective of mode.
----------------------------------------

;; Following 2 lines needed for the rest to work
;; Assumed defined elsewhere (apl.el)
(defvar apl-mode-map (make-sparse-keymap))
(use-local-map apl-mode-map)


;; Data Structure representing keyboard with APL layout
;; Keys separated from its  neighbour by a ¶
;; Each key is a triplet of 3 characters:
;; 1st is the usual key as seen on a normal keyboard
;; 2nd and 3rd are APL specific variants

(setq apl-keyboard '(

;; top (number) row
"`◊⍨¶1¨¡¶2¯€¶3<£¶4≤⍧¶5= ¶6≥ ¶7> ¶8≠⍂¶9∨⍱¶0∧⍲¶-×≡¶=÷⌹"

;; qwertyuiop row
"q?¿¶w⍵⌽¶e∈⍷¶r⍴ ¶t∼⍉¶y↑¥¶u↓ ¶i⍳⍸¶o○⍥¶p⋆⍟¶[← ¶]→ "

;; asdfghjkl row
"a⍺⊖¶s⌈ ¶d⌊ ¶f_⍫¶g∇⍒¶h∆⍋¶j∘⍤¶k'⌺¶l⎕⍞¶;⊢ ¶'⊣ "

;; zxcvbnm row
"z⊂ ¶x⊃ ¶c∩⍝¶v∪ ¶b⊥⍎¶n⊤⍕¶m|⌶¶,⌷⍪¶.⍎⍙¶/⍕⌿"

))


(setq apl-map1 (make-sparse-keymap))
(define-key apl-mode-map (kbd "<f8>") apl-map1)
(setq apl-map2 (make-sparse-keymap))
(define-key apl-mode-map (kbd "<f9>") apl-map2)

(dolist (line apl-keyboard)
  (dolist (key (split-string line "¶"))
    (let ((kb-key   (string (aref key 0)))
      (apl-key1 (string (aref key 1)))
      (apl-key2 (string (aref key 2))))
      (define-key apl-map1 kb-key apl-key1)
      (define-key apl-map2 kb-key apl-key2)))
)

Re: APL mode

[Stefan Monnier]

> (setq apl-keyboard '(

`setq' is for modifying a pre-existing variable: you want to use
`defvar' or `defconst' here (same for apl-map[12]).


        Stefan "who prefer an actual input-method"

Re: APL mode

[Xue Fuqiao]

On Mon, Oct 14, 2013 at 1:00 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> F8 and F9 are made to be like dead-keys by making them emacs prefix keys.

FYI in (info "(elisp) Key Binding Conventions"):

   * Function keys <F5> through <F9> without modifier keys are also
     reserved for users to define.

   * Sequences consisting of `C-c' followed by a control character or a
     digit are reserved for major modes.

   * Sequences consisting of `C-c' followed by `{', `}', `<', `>', `:'
     or `;' are also reserved for major modes.

-- 
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: APL mode

[Rustom Mody]

On Mon, Oct 14, 2013 at 1:51 PM, Xue Fuqiao <xfq.free@gmail.com> wrote:
> On Mon, Oct 14, 2013 at 1:00 PM, Rustom Mody <rustompmody@gmail.com> wrote:
>> F8 and F9 are made to be like dead-keys by making them emacs prefix keys.
>
> FYI in (info "(elisp) Key Binding Conventions"):
>
>    * Function keys <F5> through <F9> without modifier keys are also
>      reserved for users to define.
>
>    * Sequences consisting of `C-c' followed by a control character or a
>      digit are reserved for major modes.
>
>    * Sequences consisting of `C-c' followed by `{', `}', `<', `>', `:'
>      or `;' are also reserved for major modes.
>

Thanks Xue and Rüdiger

So we can change
(setq apl-map1 (make-sparse-keymap))
(define-key apl-mode-map (kbd "<f8>") apl-map1)
(setq apl-map2 (make-sparse-keymap))
(define-key apl-mode-map (kbd "<f9>") apl-map2)

to

(setq apl-map1 (make-sparse-keymap))
(define-key apl-mode-map (kbd "C-c 1") apl-map1)
(setq apl-map2 (make-sparse-keymap))
(define-key apl-mode-map (kbd "C-c 2") apl-map2)

In fact I dont think that either is very convenient anyway.
Ideally it should be a modifier key like AltGr or WinMenu(?).
Something that will be minimally intrusive on rest of emacs and rest
of X and be reasonably portable.

However I could not wrap my head round xmodmap so consider this as an
interim emacsy solution.



On Mon, Oct 14, 2013 at 4:10 PM, Rüdiger Sonderfeld
<ruediger@c-plusplus.de> wrote:
> F8/F9 might be a bad choice because they are user keys.  But overall you
> approach seems like a good idea.  APL programmers are certainly likely to use
> the keyboard approach.  I personally prefer the quail input method though.
> But then again I use M-x quite often in Emacs as well instead of keybindings.

How does that work??

Ive used quail like so:
(quail-defrule ".." ?॥)
(quail-defrule "." ?।)

for entering sanskrit text (those two characters are two kinds of
'full-stops' in sanskrit)  But then you cant enter a normal English
fullstop.
This is fine for entirely sanskrit texts.

However here we need the w key to generate sometimes plain ol w ,
sometimes ⍵ sometimes ⌽ .  So some kind of modedness is inevitably
required no??

Rusi

--
http://blog.languager.org

Re: APL mode

[David De La Harpe Golden]

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

On 14/10/13 12:08, Rustom Mody wrote:

> However here we need the w key to generate sometimes plain ol w ,
> sometimes ⍵ sometimes ⌽ .  So some kind of modedness is inevitably
> required no??


Well, C-\ quickly toggles the last input method on and off. It's not 
entirely unusable, bit like "sticky keys".

But maybe a good alternative is a prefix or postfix character. See 
attached stab at input methods I just threw together.

They work a bit differently to Rüdiger's: these just follow gnu apl 
1.0's documented keyboard layout in particular, whereas Rüdiger's are 
more logical/semantic (i.e. his say 'pick' -> ⊃, not '/x' -> ⊃). If you 
want to run with them, feel free, anyway.

I chose '/' for a prefix/postfix with the vague rationale other input 
methods such as latin-* seemed to use it a lot for miscellaneous 
symbols, although OTOH apl code itself uses '/' quite a lot (reduce...).
Could just use another prefix/postfix, but some are more awkward than
others, particularly on non-US keyboards.

With a "M-x comint-run apl" and a "C-x RET C-\ apl-kb-prefix" they're 
...actually not bad for interactive use.

(P.S. beware you may want to build gnu apl without color for now if
doing that - its color support apparently isn't adaptive currently. Took 
me far too long to work out that my first build was working, just 
showing black-on-black...)


[-- Attachment #2: apl-kb.el.gz --]
[-- Type: application/x-gzip, Size: 2813 bytes --]

Re: APL mode

[Stefan Monnier]

Why don't you guys add a packages/apl-mode directory to the `elpa'
branch, and work there?


        Stefan

Re: APL mode

[Rustom Mody]

On Fri, Oct 18, 2013 at 12:56 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> Why don't you guys add a packages/apl-mode directory to the `elpa'
> branch, and work there?

Hi Stefan,
Was trying to read up on this to figure out what it entails.
There's not  too much stuff (I can find) regarding this and most that
I can get is 'from-the-outside' view -- different package lists,
managers etc

Can you point me to some more internal architecture links/pointers about this?
[Or whatever is relevant]

In case its not obvious, Ive used emacs24 for only a few days :-) and
never used the package-manager(s).

Thanks
Rusi

Re: APL mode

[Xue Fuqiao]

On Sun, Oct 20, 2013 at 9:57 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Fri, Oct 18, 2013 at 12:56 AM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>> Why don't you guys add a packages/apl-mode directory to the `elpa'
>> branch, and work there?
>
> Hi Stefan,
> Was trying to read up on this to figure out what it entails.
> There's not  too much stuff (I can find) regarding this and most that
> I can get is 'from-the-outside' view -- different package lists,
> managers etc
>
> Can you point me to some more internal architecture links/pointers about this?
> [Or whatever is relevant]
>
> In case its not obvious, Ive used emacs24 for only a few days :-) and
> never used the package-manager(s).

You can see:

  (info "(emacs) Packages")
  (info "(elisp) Packaging")
  admin/notes/elpa[fn:1]
  elpa.gnu.org
  git://bzr.sv.gnu.org/emacs/elpa/README

Footnotes:

[fn:1] http://git.savannah.gnu.org/cgit/emacs.git/plain/admin/notes/elpa

-- 
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: APL mode

[Stefan Monnier]

>> Why don't you guys add a packages/apl-mode directory to the `elpa'
>> branch, and work there?
> Was trying to read up on this to figure out what it entails.

git clone git://bzr.sv.gnu.org/emacs/elpa.git
cd elpa/packages
mkdir apl-mode
...

> There's not  too much stuff (I can find) regarding this and most that
> I can get is 'from-the-outside' view -- different package lists,
> managers etc

`elpa' is a Git branch where we keep the source code of the packages
distributed via GNU ELPA.  GNU ELPA is auto-built from that branch.

So the main thing you need to know is that this `apl-mode' would then be
distributed via GNU ELPA and that new packages would be released
whenever you bump the "Version:" header.
There's also the fact that these file should follow some coding
conventions (mostly, the apl-mode.el file in there should have the
usual ";;; apl-mode.el --- <description>" first line, and it needs to
have a "Version:" header).


        Stefan

Re: APL mode

[Rustom Mody]

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

On the help emacs list Stefan made some elisp suggestions for the apl mode.
Since its about nitty-gritties of elisp I think this may be the more
suitable list.

So heres some code to input apl. (attached)
Currently there is no major-mode stuff.
Just in any mode if you run this (and you have a scroll-lock key
working) then scroll-lock behaves like a toggle for an apl keyboard.
[If scroll-lock is not there as on laptops, you will need to pick some
other key and change that line]

If there is something fundamentally wrong with this line please let me know

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ap3.el --]
[-- Type: text/x-emacs-lisp; name="ap3.el", Size: 2238 bytes --]

(defvar apl-keyboard '(
;; number row
"`◊   1¨   2¯   3<   4≤   5=   6≥   7>   8≠   9∨   0∧   -×   =÷  \⍝  |⍀" 

;; number row SHIFTed
"~⍨   !¡   @€   #£   $⍧   %    ^    &    *⍂   (⍱   )⍲   _≡   +⌹"

;; qwert row
"q?   w⍵   e∈   t∼   y↑   r⍴   u↓   i⍳   o○   p⋆"

;;  qwert row shifted
"Q¿   W⌽   E⋸   T⍉   Y¥   I⍸   O⍥   P⍟   [←   ]→"

;;  asdf row
"a⍺   s⌈   d⌊   f_   g∇   h∆   j∘   k'   l⎕   ;⊢   '⊣"

;;   asdf row shifted
"A⊖   S    D    F⍫   G⍒   H⍋   J⍤   K⌻   L⍞"

;; zxcv row
"z⊂   x⊃   c∩   v∪   b⊥   n⊤   m∣   ,⌷   .⍎   /⍕"

;; zxcv row shifted
"Z    X    C⍝   V    B⍎   N⍕   M⌶   <⍪   >⍙   ?⌿"

)
"APL keyboard is a list of keyboard rows
For structure see \\[kb-block-defrules]
"
)

(defun kb-block-defrules (kb)
  "kb is a list of keyboard rows
Each row is a space delimited string
The elements of the rows apart from spaces are a pair of characters
the first is a keyboard and the second is a translation (which could be absent)
See apl-keyboard above for example.
This function converts that list of strings 
into a lisp list of (key .translation) pairs
"
  (let ((kbl nil))
    (dolist (row kb (reverse kbl))
      (let ((key-trans-list (split-string row "[ \t]+" t))
	    (key) (trans))
	(dolist (key-trans key-trans-list)
	  (when (= (length key-trans) 2)
	    (setq key    (aref key-trans 0) 
		  trans  (aref key-trans 1)
		  kbl    (cons (cons key trans) kbl)
	     )))))))
    
(defvar apl-input-mode nil)

;; obviously this will not be global when the rest of apl mode
;; are in shape. Just a hack for now
(global-set-key (kbd "<Scroll_Lock>") 'toggle-apl-input-mode)

(defvar mode-name-aplized "απλ")
(defvar mode-name-ascii "APL")
(defvar apl-translation-table (make-translation-table 
			       (kb-block-defrules apl-keyboard)))

(defun toggle-apl-input-mode ()
  (interactive)
  (setq apl-input-mode (not apl-input-mode))
  (if apl-input-mode
      (setq keyboard-translate-table apl-translation-table
	    mode-name                mode-name-aplized)
    (setq keyboard-translate-table nil
	  mode-name                mode-name-ascii))
   (force-mode-line-update))

Re: APL mode

[Stefan Monnier]

> If there is something fundamentally wrong with this line please let me know

I'm still wondering why a plain old normal well-supported quail
input-method is not a good solution.


        Stefan

Re: APL mode

[Rustom Mody]

On Sat, Oct 26, 2013 at 7:10 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> If there is something fundamentally wrong with this line please let me know
>
> I'm still wondering why a plain old normal well-supported quail
> input-method is not a good solution.

Obviously I know very little about quail -- so consider this as
thoughts for our comments.

In quail you need (as far as I understand) some kind of 'herald'
character like the  '\' for tex input method.

In APL programming you need a preponderance of non ASCII characters
Some egs from the apl-keyboard in the code I attached:

The a-key needs to send a and A and ⍺ and ⊖
The g-key needs to send g and G and ∇ ⍒
and so on for most of the keys. [All need to send at least 3, majority
need to send 4]

Using a modifier key like the normal use of shift makes this palatable
Having to use a herald key means having to keep heralding -- a PITA.

The original solution from Juergen was to use xmodmap and use alt as
the modifier key -- quite normal in the APL world.
However with Alt (=M) gone we lose M-p M-n and above all M-x which
makes emacs close to useless

My initial attempts were to figure out xmodmap in order to add (rather
than to replace) one more modifier key. My findings:
1. I could not make head or tail of xmodmap
2. Even if I did it would be a very X-specific solution ie would not
work outside gnu-linux (maybe unix) systems
3. Keyboards are inherently very variable, in particular from 'normal'
desktop to laptop

All these things considered a low-level but inside emacs (rather than
X/OS) solution seems to be most optimal.

Finally, my feeling is that if APL is to regain some popularity (which
it enjoyed 4-5 decades ago), a variety of input methods would be good
-- for different hardware, OSes, usage-profile, tastes.  So far I can
see these possibilities:
1. Juergen's xmodmap -- use ESC for Alt
2. David's quail-based one
3. Markus Triska's quail-based one (more tex-like than David's)
4. An intermediate one which I am trying to explore

Will be happy to hear your thoughts and experiences on this
Rusi

Re: APL mode

[Juergen Sauermann]

Hi Rustom,

maybe you want to reconsider your old proposal of using the
AltGr key for APL and Alt for emacs.

With xmodmap you can make Alt and Alt-Gr different modifiers, e.g.

add Mod1 = 108

I also believe that it is important to have the same method inside and
outside emacs. As a user I would be very irritated if I would need to type,
for example, ESC G inside emacs and CTRL-G when running APL from
a shell.


  Jürgen



On 10/26/2013 06:38 AM, Rustom Mody wrote:
> On Sat, Oct 26, 2013 at 7:10 AM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>>> If there is something fundamentally wrong with this line please let me know
>> I'm still wondering why a plain old normal well-supported quail
>> input-method is not a good solution.
> Obviously I know very little about quail -- so consider this as
> thoughts for our comments.
>
> In quail you need (as far as I understand) some kind of 'herald'
> character like the  '\' for tex input method.
>
> In APL programming you need a preponderance of non ASCII characters
> Some egs from the apl-keyboard in the code I attached:
>
> The a-key needs to send a and A and ⍺ and ⊖
> The g-key needs to send g and G and ∇ ⍒
> and so on for most of the keys. [All need to send at least 3, majority
> need to send 4]
>
> Using a modifier key like the normal use of shift makes this palatable
> Having to use a herald key means having to keep heralding -- a PITA.
>
> The original solution from Juergen was to use xmodmap and use alt as
> the modifier key -- quite normal in the APL world.
> However with Alt (=M) gone we lose M-p M-n and above all M-x which
> makes emacs close to useless
>
> My initial attempts were to figure out xmodmap in order to add (rather
> than to replace) one more modifier key. My findings:
> 1. I could not make head or tail of xmodmap
> 2. Even if I did it would be a very X-specific solution ie would not
> work outside gnu-linux (maybe unix) systems
> 3. Keyboards are inherently very variable, in particular from 'normal'
> desktop to laptop
>
> All these things considered a low-level but inside emacs (rather than
> X/OS) solution seems to be most optimal.
>
> Finally, my feeling is that if APL is to regain some popularity (which
> it enjoyed 4-5 decades ago), a variety of input methods would be good
> -- for different hardware, OSes, usage-profile, tastes.  So far I can
> see these possibilities:
> 1. Juergen's xmodmap -- use ESC for Alt
> 2. David's quail-based one
> 3. Markus Triska's quail-based one (more tex-like than David's)
> 4. An intermediate one which I am trying to explore
>
> Will be happy to hear your thoughts and experiences on this
> Rusi
>

Re: APL mode

[Rustom Mody]

On Sat, Oct 26, 2013 at 4:05 PM, Juergen Sauermann
<juergen.sauermann@t-online.de> wrote:
> Hi Rustom,
>
> maybe you want to reconsider your old proposal of using the
> AltGr key for APL and Alt for emacs.
>
> With xmodmap you can make Alt and Alt-Gr different modifiers, e.g.
>
> add Mod1 = 108
>
> I also believe that it is important to have the same method inside and
> outside emacs. As a user I would be very irritated if I would need to type,
> for example, ESC G inside emacs and CTRL-G when running APL from
> a shell.
>
>
>  Jürgen

That was of course my first choice.
However trying that one line in a file does not do anything -- emacs
still sees M- for both Alt's

Instead my 'l'  has stopped working!!!
Im typing this with cut-paste!!

Re: APL mode

[David De La Harpe Golden]

On 26/10/13 11:35, Juergen Sauermann wrote:
> Hi Rustom,
>
> With xmodmap you can make Alt and Alt-Gr different modifiers

Okay, seems like there may be wheels being reinvented in them thar hills:

xmodmap is _old_, xkb [1] exists. Though xkb is perhaps confusing and 
baroque, it's now clearly important to note that current xkb packages 
ubiquitous on gnu+linux systems _already include_ several variations of 
apl symbols [2], and you can use them [3].

They already look vaguely suitable for use with GNU APL, though there 
might be some different choices made, I didn't exhaustively verify.

I'm afraid I personally tend to just "muddle through" xkb stuff right 
now, I'm not the right person to ask for in-depth support and advice 
with xkb. Perhaps you could contact the relevant xkb apl layout 
devs/maintainers named in [2] itself to discuss meeting your GNU APL 
keyboard needs.  If, of course, they're not already met - and maybe it's 
early enough that GNU APL might also make changes if it indeed picked 
some different symbols to other unicode apls, there are a lot of 
lookalike unicode symbols...

> I also believe that it is important to have the same method inside and
> outside emacs.

I think it's not such a problem if some intra-emacs quail input method 
works a bit differently, such input methods are more for people who 
either don't want to have a desktop-wide apl layout as above enabled 
and/or use emacs on a text terminal or with a peculiar input device or 
something.

IMO an emacs apl mode for editing apl sources (and presumably a related 
inferior-apl for interactive apl interpreters under emacs) shouldn't 
need to get into handling actual apl symbol input, that's more of a job 
for xkb as above outside/over emacs, with quail input method(s) inside 
emacs being nice to have.

[1] http://www.x.org/wiki/XKB/

[2] http://cgit.freedesktop.org/xkeyboard-config/tree/symbols/apl

Already present on my Debian 7.x system:
$ dpkg -S /usr/share/X11/xkb/symbols/apl
xkb-data: /usr/share/X11/xkb/symbols/apl


[3] 
http://aplinquisition.blogspot.com/2013/07/configuring-apl-keyboard-with-i3-window.html

Re: APL mode

[Rustom Mody]

On Sat, Oct 26, 2013 at 9:10 PM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> On 26/10/13 11:35, Juergen Sauermann wrote:
>>
>> Hi Rustom,
>>
>> With xmodmap you can make Alt and Alt-Gr different modifiers
>
> Okay, seems like there may be wheels being reinvented in them thar hills:
>
> xmodmap is _old_, xkb [1] exists. Though xkb is perhaps confusing and
> baroque, it's now clearly important to note that current xkb packages
> ubiquitous on gnu+linux systems _already include_ several variations of apl
> symbols [2], and you can use them [3].
>

Hey David you're a whiz!
One look at that reference and I tried:
$ setxkbmap -layout "us,apl" -option "grp:ralt_rshift_toggle"

And now if I type abcdefghijkl after Ralt-Rshift I get
⍺⊥∩⌊∊_∇∆⍳∘'⎕

Some problems are there:
in this mode now Alt-x gives me:
M-⊃ is undefined
[x maps to ⊃ !!]

More important I cant seem to find a '3rd level' -- note the standard
apl layout needs upto 4 characters from a key. ie in addition to the
usual ASCII and upcase ASCII there could be two more

Re: APL mode

[Rustom Mody]

On Sat, Oct 26, 2013 at 10:18 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> More important I cant seem to find a '3rd level' -- note the standard
> apl layout needs upto 4 characters from a key. ie in addition to the
> usual ASCII and upcase ASCII there could be two more

Small update:

Dunno about 3rd level in the X sense, however this line
$ setxkbmap -layout "us,apl" -variant ",sax" -option "grp:ralt_rshift_toggle"

gives the 3rd character per key with a shift

Re: APL mode

[David De La Harpe Golden]

On 26/10/13 17:48, Rustom Mody wrote:

> Hey David you're a whiz!

hah, well, thanks. I'm really not when it comes to xkb in particular 
though, I rapidly devolve to trial-and-error.

> Some problems are there:
> in this mode now Alt-x gives me:
> M-⊃ is undefined
> [x maps to ⊃ !!]

Yes, I think you really want -option "grp:switch"

Then (I think) you'll have to hold down RAlt to type the apl character 
(more like a traditional apl keyboard really), but you can still just 
hit M-x with LAlt-x

>
> More important I cant seem to find a '3rd level' -- note the standard
> apl layout needs upto 4 characters from a key. ie in addition to the
> usual ASCII and upcase ASCII there could be two more
>

You just selected a pretty basic one I think, try e.g.

setxkbmap -layout "us,apl(sax)" -option "grp:switch"


Then try ralt+letter vs. ralt+shift+letter...

`1234567890-=
qwertyuiop[]
asdfghjkl;'\
zxcvbnm,./

~@#$%^&*()_+
QWERTYUIOP{}
ASDFGHJKL:"|
 >ZXCVBNM<>?

⋄¨¯<≤=≥>≠∨∧×÷
?⍵∊⍴~↑↓⍳○*←→
⍺⌈⌊_∇∆∘'⎕⊢⊣⍝
<⊂⊃∩∪⊥⊤|⍞⍎⍕

⋄¡¯<¢=≥>⍂⍱⍲≡⌹
¿⌽⍷⍴⍉↑↓⍸⍥⍟←→
⊖⌈⌊⍫⍒⍋⍤⌻⍞⊢⊣⍀
 >⊂⊃⍝∪⍎⍕⌶⍪⍙⌿

Re: APL mode

[Stefan Monnier]

>>> If there is something fundamentally wrong with this line please let me know
>> I'm still wondering why a plain old normal well-supported quail
>> input-method is not a good solution.
> Obviously I know very little about quail -- so consider this as
> thoughts for our comments.
> In quail you need (as far as I understand) some kind of 'herald'
> character like the  '\' for tex input method.

I'm not sure what you mean by "herald key".  AFAIK the only constraint
is that the input keys don't/can't use modifier keys, so you have to use
key sequences rather than key chords.

While I agree that it might sounds unEmacsish, key-sequences aren't that
bad compared to key-chords.


        Stefan

Re: APL mode

[Xue Fuqiao]

On Sun, Oct 27, 2013 at 1:08 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> key-sequences aren't that bad compared to key-chords.

Agreed.  "Key sequences are better than key chords" is one of the design
principles of ergoemacs-mode.

-- 
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: APL mode

[Stephen J. Turnbull]

Stefan Monnier writes:

 > While I agree that it might sounds unEmacsish, key-sequences aren't
 > that bad compared to key-chords.

Not in my experience ... but I only use key-sequence-based input
methods for Spanish (<5% non-ASCII characters) and Japanese (80% of
characters requires multiple keystrokes no matter what input method
you use, and in the very popular "romanized phonetic" methods, all
characters do).

I cannot say I'd not be unhappy if the ratio got to 50% or so.

Steve

Re: APL mode

[Rustom Mody]

On Mon, Oct 28, 2013 at 9:39 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Stefan Monnier writes:
>
>  > While I agree that it might sounds unEmacsish, key-sequences aren't
>  > that bad compared to key-chords.
>
> Not in my experience ... but I only use key-sequence-based input
> methods for Spanish (<5% non-ASCII characters) and Japanese (80% of
> characters requires multiple keystrokes no matter what input method
> you use, and in the very popular "romanized phonetic" methods, all
> characters do).
>
> I cannot say I'd not be unhappy if the ratio got to 50% or so.
>
> Steve

For the specific case at hand (apl-input):

I think that we have got (thanks David) to a solution.
$ setxkbmap -layout "us,apl" -variant ",sax" -option "grp:switch"
gives exactly (as far as I can tell) Juergen's solution -- a
chord-based one using alt -- so not nice for emacs users
With
$ setxkbmap -layout "us,apl" -variant ",sax" -option "grp:rswitch"
lalt works as before in emacs and ralt switches to apl layout

With
$ setxkbmap -layout "us,apl" -variant ",sax" -option "grp:alt_shift_toggle"
we can have a sequence based one -- alt-shift switching to apl and back

For the more general discussion: Is a key-seq preferable or a chord:
My general preference is to type as little as possible :-)
Combine that with the fact that a chord is bit more work than a single
key and a bit less than 2, we have:
single-key better than chord better than sequence

Clearly if we had to type-in ALLCAPS the capslock would be good.
Since mostly we never use allcaps, shift is better.

The same principle applies here: if I need to keep on giving some
input-method herald like '\' I would much rather give it once.

If one would look at typical APL code
eg http://aplwiki.com/FinnAplIdiomLibrary
one would quickly see why!

Rusi
-- 
http://www.the-magus.in
http://blog.languager.org

Re: APL mode

[Juergen Sauermann]

Hi,

setxkbmap -layout "us,apl" -variant ",sax" -option "grp:switch"

gives me "Error loading new keyboard description" while

setxkbmap -layout "us,apl" -variant "sax" -option "grp:switch"

seems to work better.

However, I am getting ∊ for both rAlt and shift-rAlt (the latter should give, for example,
⍷ = U2377 instead). so the sax variant seems not to be understood.


/// Juergen


On 10/28/2013 01:21 PM, Rustom Mody wrote:
> setxkbmap -layout "us,apl" -variant ",sax" -option "grp:switch"

Re: APL mode

[Rustom Mody]

On Mon, Oct 28, 2013 at 10:54 PM, Juergen Sauermann
<juergen.sauermann@t-online.de> wrote:
> Hey, cool !
>
> it worked on my box. Thanks a lot!
>
> /// Juergen

Great!

For the others: some context below.
David, Juergen and I had some off-list mails to make this work on Juergen's box.




> On 10/28/2013 05:53 PM, David De La Harpe Golden wrote:
>>
>> On 28/10/13 15:12, Juergen Sauermann wrote:
>>>
>>> Hi,
>>>
>>> I renamed my symbols/extra/apl to something else so that it was not used
>>> accidentally.
>>> Then I put your file as /symbols/apl and tried various combinations of
>>> Shilft, Ctrl,  leftAlt and rightAlt.
>>
>>
>> Probably not that simple I'm afraid, e.g. though I confess I'm not 100%
>> sure it's actually used, did you also amend the variants table in
>> rules/base.extras.xml ?
>>
>> Another perhaps dubious (may involve trusting me) thing that might work
>> (no warranty or liability accepted, preferably have a command or gui tool
>> ready to copy-paste to restore your layout):
>>
>> Background:
>>
>> While a lot of traditional X11's interesting network-transparency
>> facilities are kind of bitrotting/withering-on-the-vine, XKB was after all
>> originally architected for a very diverse range of networked gui clients and
>> servers. So the whole thing is designed to allow you to make a layout on the
>> client that the server doesn't know about, then tell the server all about
>> it. We can perhaps use/abuse that here if your system isn't too different to
>> mine, which it probably isn't, the days of trying to get a fujitsu sparc box
>> working with an Amiga or whatever are gone.
>>
>> Approach:
>>
>> Soo... Take the attached compiled .xkm file generated on my system, and
>> try applying it to yours!  I just used my setxkbmap and xkbcomp to generate
>> it, you could also have someone you trust with a similarly new system
>> recreate it with a similar command [1]
>>
>> gunzip apl-gen-xkb2.5.1-3.xkm.gz
>> xkbcomp apl-gen-xkb2.5.1-3.xkm :0
>>
>> NOTE: you don't have to blindly trust me. If you do a
>>
>> xkbcomp apl-gen-xkb2.5.1-3.xkm apl-gen-xkb2.5.1-3.xkb
>>
>> it should decompile it for your inspection, and you can then recompile it
>> with:
>>
>> xkbcomp apl-gen-xkb2.5.1-3.xkb apl-gen-xkb2.5.1-3.xkm
>>
>> Unfortunately it doesn't seem to round-trip byte-identically when
>> you do that, but it may not matter functionally.
>>
>>> What concerns me more is that rightAlt and Shift-rightAlt produce the
>>> same
>>> character.
>>
>>
>> Well, they produce different characters on my system with the newer
>> version...
>>
>> eeeEEE∊∊∊⍷⍷⍷
>>
>>
>>
>> [1]
>> setxkbmap -layout 'us,apl(sax)' -option 'grp:switch' -option
>> 'grp_led:scroll' -print | xkbcomp - apl-gen-xkb2.5.1-3.xkm
>
>



-- 
http://www.the-magus.in
http://blog.languager.org

Re: APL mode

[David De La Harpe Golden]

On 28/10/13 17:42, Rustom Mody wrote:
> On Mon, Oct 28, 2013 at 10:54 PM, Juergen Sauermann
> <juergen.sauermann@t-online.de> wrote:
>> Hey, cool !
>>
>> it worked on my box. Thanks a lot!
>>
>> /// Juergen
>
> Great!
>
> For the others: some context below.
> David, Juergen and I had some off-list mails to make this work on Juergen's box.


Uh. Though that text was missing the important bit of information 
leading up to that workaround:

Pre- late-2011 xkb apl layouts different/less-complete, you want 
xkeyboard-config (a.k.a. xkb-data) 2.5+ to get the "good" xkb-bundled 
apl layouts working, Juergen's machine still had older xkb definitions.

Re: APL mode

[Rustom Mody]

On Fri, Oct 18, 2013 at 12:24 AM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> (P.S. beware you may want to build gnu apl without color for now if
> doing that - its color support apparently isn't adaptive currently. Took me
> far too long to work out that my first build was working, just showing
> black-on-black...)

I got this from Juergen (author of gnu-apl) a few days ago:
Other points and your attachment and Stefan's suggestion look promising.
Will study and get back in a bit

---------- Forwarded message ----------
From: Juergen Sauermann
Date: Sat, Oct 12, 2013 at 9:20 PM
Subject: Colors for GNU APL
To: ...


Hello,

I have updated GNU APL which now supports a config file where you
can store some frequently used settings , in particular related to colors
(disabling colors and colors for terminals with e.g. black backgrounds).

See "info apl.info" for details.

An example file containing  (commented out) settings for black backgrounds
is now installed with GNU APL. See e.g. /etc/gnu-apl.d/preferences (or whatever
your system configuration directory might be instead of /etc).

⍝ Jürgen

Re: APL mode

[Rüdiger Sonderfeld]

On Monday 14 October 2013 10:30:42 Rustom Mody wrote:
> Heres a first cut attempt.
> F8 and F9 are made to be like dead-keys by making them emacs prefix keys.
> What do you think?

F8/F9 might be a bad choice because they are user keys.  But overall you 
approach seems like a good idea.  APL programmers are certainly likely to use 
the keyboard approach.  I personally prefer the quail input method though.  
But then again I use M-x quite often in Emacs as well instead of keybindings.

Regards,
Rüdiger

Re: APL mode

[David De La Harpe Golden]

On 12/10/13 05:48, Rustom Mody wrote:
 > Is anyone working on this??

FWIW, for completeness, I can think of some other related work: A+ 
(another APL derived language, also GPL*) has long bundled an XEmacs 
mode for A+ in its source tarball.  However, you may well be better off 
going your own way, IIRC it doesn't really adhere to emacsy conventions
and I don't think it was GNU Emacs compatible anyway.

http://www.aplusdev.org/APlusRefV2_52.html#HEADING605

(As it happens, J, a powerful ASCIIfied APL language, also went GPL 
recently. No Free APL for ages than 3 come along at once, etc. (well, A+ 
has been free for a fairly long time))


* and bear in mind "GPL" doesn't mean "copyright assigned to FSF" - 
relevant for emacs contribs.

Re: APL mode

[Stefan Monnier]

BTW, we'd be happy to host an apl-mode, J-mode, or aplus-mode in
GNU ELPA.


        Stefan

Re: APL mode

[Rustom Mody]

On Mon, Oct 14, 2013 at 10:33 PM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> On 12/10/13 05:48, Rustom Mody wrote:
>> Is anyone working on this??

> No Free APL for ages than 3 come along at once, etc. (well, A+ has
> been free for a fairly long time))

Another: see https://github.com/dlaurie/lua-apl
So 4 (at least)

>
> FWIW, for completeness, I can think of some other related work: A+ (another
> APL derived language, also GPL*) has long bundled an XEmacs mode for A+ in
> its source tarball.  However, you may well be better off going your own way,
> IIRC it doesn't really adhere to emacsy conventions
> and I don't think it was GNU Emacs compatible anyway.
>
> http://www.aplusdev.org/APlusRefV2_52.html#HEADING605

Years ago I got APlus working with Xemacs (its clearly stated: not
compatible with gnu-emacs)
Then it stopped working (with xemacs that is -- some X issues?) and so
I hacked up something to make it work with gnu-emacs.
My work-in-progress page: http://www.emacswiki.org/emacs/AplInDebian

FWIW recently Xemacs is getting so bitrotten that debian has
unfortunately removed it:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670292
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725883

This does not mean it is unavailable or uninstallable but just much harder.
Multiply that by
- APlus is also getting obsolescent
- most people (in 2013) know little/nothing about APL
and clearly the barriers to entry (on the APlus-avenue) are only increasing.

Note for a super-ace programmer (which means not me!) all these
different APLs could be supported under one umbrella in (gnu)emacs.
This entails:
1. Completing a unicode-based set of modes for Apl and inferior Apl
2. Making an latin-ish encoding for APlus
3. Having some configuation flags so that the base unicode encoding
can be converted if necessary on file-saving/process-sending
[My WIP http://www.emacswiki.org/emacs/AplInDebian basically tries to
do this but without making a new latin-ish encoding -- needless to say
it works sometimes and fails many times :-) ]

So... APL seems to be making a mini resurgence.
Anyone wanting to give a helping hand in putting emacs into the
picture will be gratefully accepted :-)

Rusi
-- 
http://www.the-magus.in
http://blog.languager.org