emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]