aplus mode

aplus mode

[Rustom Mody]

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

Hello

Aplus (a gnu/linux APL variant) has been one of the languages that runs
only on Xemacs but not Gnu-emacs.
Recently Xemacs has been giving some trouble compiling under debian (it
seems).

I have hacked up something which makes Aplus run with Gnu-emacs:
http://www.emacswiki.org/emacs/AplInDebian

Is this a suitable forum for discussions towards cleaning up that code?

Thanks

Rusi

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

Re: aplus mode

[Rustom Mody]

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

On Fri, Jul 27, 2012 at 1:18 PM, Rustom Mody <rustompmody@gmail.com> wrote:

> Hello
>
> Aplus (a gnu/linux APL variant) has been one of the languages that runs
> only on Xemacs but not Gnu-emacs.
> Recently Xemacs has been giving some trouble compiling under debian (it
> seems).
>
> I have hacked up something which makes Aplus run with Gnu-emacs:
> http://www.emacswiki.org/emacs/AplInDebian
>
> Is this a suitable forum for discussions towards cleaning up that code?
>
> Thanks
>
> Rusi
>

Well I just discovered this is not exactly working.

Or rather the fonts are not fully working in new gnome3+emacs but working
in the old xfce+emacs.

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

Re: aplus mode

[Stefan Monnier]

> Aplus (a gnu/linux APL variant) has been one of the languages that
> runs only on XEmacs but not GNU-Emacs.  Recently XEmacs has been
> giving some trouble compiling under Debian (it seems).
> I have hacked up something which makes Aplus run with GNU-Emacs:
> http://www.emacswiki.org/emacs/AplInDebian
> Is this a suitable forum for discussions towards cleaning up that code?

Sure.  Especially if you intend to include it in GNU ELPA.
Since Markus has already signed the needed copyright paperwork,
and it doesn't look like the code has seen many external contributions,
inclusion in GNU ELPA should be fairly easy.

As for cleaning up the code, I suggest you start by defining a major
mode for APL code.  See sample-mode.el for an example.
This mode would most likely enable the apl input method by default.

BTW, I see that Markus's APL input method is very different from the one
used in the XEmacs code (I'm not talking about the way it works, which
is different for good reasons, but about the choice of what to type in
order to get a given symbol).  I think the two can live together.


        Stefan

Re: aplus mode

[Rustom Mody]

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

On Sat, Aug 11, 2012 at 3:27 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > Aplus (a gnu/linux APL variant) has been one of the languages that
> > runs only on XEmacs but not GNU-Emacs.  Recently XEmacs has been
> > giving some trouble compiling under Debian (it seems).
> > I have hacked up something which makes Aplus run with GNU-Emacs:
> > http://www.emacswiki.org/emacs/AplInDebian
> > Is this a suitable forum for discussions towards cleaning up that code?
>
> Sure.  Especially if you intend to include it in GNU ELPA.
> Since Markus has already signed the needed copyright paperwork,
> and it doesn't look like the code has seen many external contributions,
> inclusion in GNU ELPA should be fairly easy.
>
> As for cleaning up the code, I suggest you start by defining a major
> mode for APL code.  See sample-mode.el for an example.
> This mode would most likely enable the apl input method by default.
>

Ive defined inferior-apl-mode by copying from cmu-scheme like this:

(define-derived-mode inferior-apl-mode comint-mode "Inferior APL" ....

and then removing most of the stuff to keep it still working.

The current version at http://www.emacswiki.org/emacs/inferior-apl.el
is a still further cleaned up and cut-down version.
Of course the mode-ly stuff should be cleaned up -- I dont understand the
scoping rules for buffer-local variables.

I think however that there are more immediate questions before that.

The code was up there on the wiki and working as best as I knew until
someone informed me that it was not.  The immediate hack I found was that
starting emacs with
LANG=C makes it again work.  Evidently when the OS moved from defaulting to
latin-1 to utf-8 this broke.

Trying to make an 'inside-emacs' version of the same hack I discovered that
the following does the trick of removing the need for LANG=C.

(setq coding-system-for-write 'iso-latin-1)
(setq coding-system-for-read 'iso-latin-1)

Obviously this is not a proper solution.
Firstly these variables should not be globally assigned.  Whats the best
way of scoping these assignments or should some other variables be used I
am not sure.

The second point is that iso-latin-1 just works by saying so-to-speak
"Not-UTF" but it is obviously wrong.

So in short: How do I say "latinish" without saying latin-1.  And where
(scope) to say it?

Perhaps the best solution would be to define a new Aplus charset.
The tables are already there in Markus code.  Maybe just some tying some
ends together required?  Any pointers/docs on how one goes about converting
a restricted-charset-to-unicode data-table into an emacs charset?

Thanks

Rusi

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

Re: aplus mode

[Stefan Monnier]

>> > Aplus (a gnu/linux APL variant) has been one of the languages that
>> > runs only on XEmacs but not GNU-Emacs.  Recently XEmacs has been
>> > giving some trouble compiling under Debian (it seems).
>> > I have hacked up something which makes Aplus run with GNU-Emacs:
>> > http://www.emacswiki.org/emacs/AplInDebian
>> > Is this a suitable forum for discussions towards cleaning up that code?
>> 
>> Sure.  Especially if you intend to include it in GNU ELPA.
>> Since Markus has already signed the needed copyright paperwork,
>> and it doesn't look like the code has seen many external contributions,
>> inclusion in GNU ELPA should be fairly easy.
>> 
>> As for cleaning up the code, I suggest you start by defining a major
>> mode for APL code.  See sample-mode.el for an example.
>> This mode would most likely enable the apl input method by default.
> Ive defined inferior-apl-mode by copying from cmu-scheme like this:

Sure, I was referring to apl-mode.

> Of course the mode-ly stuff should be cleaned up -- I dont understand the
> scoping rules for buffer-local variables.

They're global variables.  It's just that when you access a `foo' which
is buffer-local, it's like doing (buffer-local-value 'foo (current-buffer)).

> The code was up there on the wiki and working as best as I knew until
> someone informed me that it was not.  The immediate hack I found was that
> starting emacs with
> LANG=C makes it again work.  Evidently when the OS moved from defaulting to
> latin-1 to utf-8 this broke.

Right, you need to tell Emacs what is the encoding that the a+
process expects.  Based on the XEmacs code I perused, I'd guess that it
might be some apl-specific coding-system.

> Trying to make an 'inside-emacs' version of the same hack I discovered that
> the following does the trick of removing the need for LANG=C.

> (setq coding-system-for-write 'iso-latin-1)
> (setq coding-system-for-read 'iso-latin-1)

> Obviously this is not a proper solution.
> Firstly these variables should not be globally assigned.  Whats the best
> way of scoping these assignments or should some other variables be used I
> am not sure.

You should let-bind them around the `start-process' call.

> The second point is that iso-latin-1 just works by saying so-to-speak
> "Not-UTF" but it is obviously wrong.

Yes, if it works, it's probably by accident.  It might be preferable to
create a proper `apl' coding-system (use define-charset and then
define-coding-system).


        Stefan

Re: aplus mode

[Rustom Mody]

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

On Tue, Aug 14, 2012 at 8:17 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

>
> > Trying to make an 'inside-emacs' version of the same hack I discovered
> that
> > the following does the trick of removing the need for LANG=C.
>
> > (setq coding-system-for-write 'iso-latin-1)
> > (setq coding-system-for-read 'iso-latin-1)
>
> > Obviously this is not a proper solution.
> > Firstly these variables should not be globally assigned.  Whats the best
> > way of scoping these assignments or should some other variables be used I
> > am not sure.
>
> You should let-bind them around the `start-process' call.
>
>
I now have

(defun run-apl()
  "Major mode for running APlus under emacs"
  (interactive)
  (if (not (comint-check-proc "*a+*"))
      (let ((coding-system-for-write 'iso-latin-1)
        (coding-system-for-read 'iso-latin-1))
    (set-buffer (make-comint "a+" "a+"))))
  (setq apl-buffer "*a+*")
  (inferior-apl-mode)
  (pop-to-buffer "*a+*"))

Is this (use of let) the appropriate way?




> > The second point is that iso-latin-1 just works by saying so-to-speak
> > "Not-UTF" but it is obviously wrong.
>
> Yes, if it works, it's probably by accident.  It might be preferable to
> create a proper `apl' coding-system (use define-charset and then
> define-coding-system).
>
>
Thanks. I was looking for such functions.  I will of course have to study
code that uses them.  Any suggestions where to start?

Thanks
Rusi

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

Re: aplus mode

[Stefan Monnier]

> I now have

> (defun run-apl()
>   "Major mode for running APlus under emacs"
>   (interactive)
>   (if (not (comint-check-proc "*a+*"))
>       (let ((coding-system-for-write 'iso-latin-1)
>         (coding-system-for-read 'iso-latin-1))
>     (set-buffer (make-comint "a+" "a+"))))
>   (setq apl-buffer "*a+*")
>   (inferior-apl-mode)
>   (pop-to-buffer "*a+*"))

> Is this (use of let) the appropriate way?

Yes, that looks fine.

>> > The second point is that iso-latin-1 just works by saying so-to-speak
>> > "Not-UTF" but it is obviously wrong.
>> Yes, if it works, it's probably by accident.  It might be preferable to
>> create a proper `apl' coding-system (use define-charset and then
>> define-coding-system).
> Thanks. I was looking for such functions.  I will of course have to study
> code that uses them.  Any suggestions where to start?

I think mule-conf.el is a good starting place.


        Stefan