[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: aplus mode
From: |
Stefan Monnier |
Subject: |
Re: aplus mode |
Date: |
Tue, 14 Aug 2012 10:47:59 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) |
>> > 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