A vi-style editor for Scheme
Nils M Holm
ARSE is a Recursive[1] Scheme Editor modeled after vi. While it is
certainly not too useful as a general-purpose text editor, it has
some features that facilitate editing Scheme code, like
- an interaction buffer for evaluating expressions
- a help buffer for looking up keywords and procedures
- a built-in pretty-printer
- short cuts for re-defining individual procedures or
re-loading entire files
It also has unlimited undo/redo, and multi-buffers, and some other
little features that make Scheme programming even more fun. It is
written to cooperate with Scheme systems other than S9.
ARSE is not yet stable. Although it has not crashed or behaved
eratically here in the past days, even under heavy use, YMMV.
If you want to give it a try: it's in the S9 package on my homepage.
[1] or redundant, rotten, ... whatever you find appropriate.
--
Nils M Holm | http://t3x.org
Vitaly Magerya
> ARSE is a Recursive[1] Scheme Editor modeled after vi.
That is actually quite awesome.
Except for the name of course. Editing my code with my arse?
> While it is
> certainly not too useful as a general-purpose text editor
Do you plan to make it a useful general-purpose editor? Extensible a la
EMACS maybe? Or what's the general plan? Will there be such features as
autoindent and key remapping?
> ARSE is not yet stable. Although it has not crashed or behaved
> eratically here in the past days, even under heavy use, YMMV.
Is there a way to evaluate "(display 123)" and see the output, without
the REPL stalling?
Also the highlight-expression mode is weird. Highlight an expression and
insert text in the middle of it: the left part of the expression stays
highlighted, the right one does not. Or move over a parenthesis in a
highlighted expression: it's matching paren looses the highlight.
Nils M Holm
> That is actually quite awesome.
Thanks!
> Except for the name of course. Editing my code with my arse?
I tried to come up with something that is worse than SLIME. ;-)
> Do you plan to make it a useful general-purpose editor? Extensible a la
> EMACS maybe? Or what's the general plan? Will there be such features as
> autoindent and key remapping?
Autoindent is there and should be enabled by default (autoindent option).
Key mapping is currently not on the to-do list. Extensibility? That would
require a Scheme-in-Scheme, wouldn't it? At this point I am definitely
not planning that far ahead. (Not that I am planning at all.)
> Is there a way to evaluate "(display 123)" and see the output, without
> the REPL stalling?
Yes: (begin (display 123) (newline))
To see whether the REPL responds, ARSE sends it some magic identifier
and then waits for the echo. (display 123) without the newline turns
the identifier into 123identifier, which is not recognized (see the
GET-REPL-OUTPUT procedure for details). Maybe there is a better way
to to this, but I could not come up with one.
> Also the highlight-expression mode is weird. [...]
Yes, it is. It was originally intended to highlight expressions
automatically while you move the cursor, but that mode burned too
much CPU time on my 600MHz machine[1], so I turned it into something
less demanding. In a future release, it will probably un-highlight
the entire expression as soon as you move the cursor.
[1] Yes, I know it's 2010.
Nils M Holm
> Is there a way to evaluate "(display 123)" and see the output, without
> the REPL stalling?
Should be fixed now.
Vitaly Magerya
> I tried to come up with something that is worse than SLIME. ;-)
What an odd goal to have.
> Autoindent is there and should be enabled by default (autoindent option).
No, the other autoindent. The one which follows the expression structure
and tries to properly indent DEFINEs, LAMBDAs, etc.
> Extensibility? That would require a Scheme-in-Scheme, wouldn't it?
I'm sure S9 could support EVAL with suitable semantics. LOAD can also do
the trick.
>> Also the highlight-expression mode is weird. [...]
>
> Yes, it is. It was originally intended to highlight expressions
> automatically while you move the cursor, but that mode burned too
> much CPU time on my 600MHz machine[1], so I turned it into something
> less demanding.
Is that because of a slow implementation, or is S9 not fast enough?
> [1] Yes, I know it's 2010.
Is it already? Then I guess I'll need to upgrade *my* dev machine.
In another message Nils M Holm wrote:
>> Is there a way to evaluate "(display 123)" and see the output,
>> without the REPL stalling?
>
> Should be fixed now.
Verified.
Aaron W. Hsu
it yet, this is a very cool program from the looks of things, and I'm glad
someone is doing something like this. I've wanted to get something like
this going (not a Vi-style, though) for a while, but I haven't had the
time.
Good work!
Aaron W. Hsu
Štěpán Němec
> Nils M Holm wrote:
>> Extensibility? That would require a Scheme-in-Scheme, wouldn't it?
>
> I'm sure S9 could support EVAL with suitable semantics. LOAD can also do
> the trick.
What would be the point? IIUC the editor itself is written in Scheme, so
it should be extensible easily enough -- why would you want another
layer?
Vitaly Magerya
>> I'm sure S9 could support EVAL with suitable semantics. LOAD can also do
>> the trick.
>
> What would be the point? IIUC the editor itself is written in Scheme, so
> it should be extensible easily enough -- why would you want another
> layer?
Do you mean by modifying the source? It's not practical, since you'll
need to remake all your modifications on each new release.
Basically, all that's needed for a simple "extensible" Scheme editor, is
a .rc file which the editor will LOAD on startup, and a stable set of
functions which you can use from that .rc to extend the editor.
But don't get me wrong, I'm not demanding a feature. I'm just asking if
Nils is planning it -- which as I understand he isn't, so no point in
discussing further unless someone(tm) will send the patches.
Pascal J. Bourguignon
> Štěpán Němec wrote:
>>> I'm sure S9 could support EVAL with suitable semantics. LOAD can also do
>>> the trick.
>>
>> What would be the point? IIUC the editor itself is written in Scheme, so
>> it should be extensible easily enough -- why would you want another
>> layer?
>
> Do you mean by modifying the source? It's not practical, since you'll
> need to remake all your modifications on each new release.
>
> Basically, all that's needed for a simple "extensible" Scheme editor, is
> a .rc file which the editor will LOAD on startup, and a stable set of
> functions which you can use from that .rc to extend the editor.
Do you mean:
1- an editor to edit scheme code?
2- an editor written in scheme?
3- and editor that you can customize by writting scheme code?
In the cases 1 or 3, you can use emacs.
For 3, you would need to add a scheme layer to emacs, perhaps porting
pseudo or improving Cheezy Scheme. For Pseudo, you could try to make
it run on emacs-cl.
In either case, (after perhaps a couple of patches), you will be able
to call emacs lisp function from scheme and thus customize emacs using
scheme.
In the case 2, you could use EdWin. There are probably several others.
> But don't get me wrong, I'm not demanding a feature. I'm just asking if
> Nils is planning it -- which as I understand he isn't, so no point in
> discussing further unless someone(tm) will send the patches.
Also, while writting and ed or vi is a nice exercise for a newbie
programmer, I would really advise them to read first "The Craft of
Text Editing", it's not harder to write an emacs than a vi.
pseudo: http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/scheme/impl/pseudo/0.html
cheeze: http://www.splode.com/~friedman/software/emacs-lisp/
emacs-cl: http://www.lisp.se/emacs-cl/
edwin: http://www.emacswiki.org/emacs/EdwinScheme
craft: http://www.finseth.com/craft/
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nils M Holm
> No, the other autoindent. The one which follows the expression structure
> and tries to properly indent DEFINEs, LAMBDAs, etc.
*That* autoindent. This is unlikely to happen, because it is not the
way I edit code. To format your code in the current version, just go to
the opening parenthesis and press [=][p].
> > [auto-highlighting is too slow]
>
> Is that because of a slow implementation, or is S9 not fast enough?
Both, I guess. I did not optimize it too much and then S9 is an
interpreter. It is not too slow for an interpreter, but still...
Nils M Holm
> it's not harder to write an emacs than a vi.
But it is impractical if the goal is to write a vi.
Pascal J. Bourguignon
> Pascal J. Bourguignon <p...@informatimago.com> wrote:
>> it's not harder to write an emacs than a vi.
>
> But it is impractical if the goal is to write a vi.
That's what I'm saying: wrong goal, change goal :-)
Aaron W. Hsu
>In the case 2, you could use EdWin. There are probably several others.
For me, if I wanted to run an Emacs in Scheme, I wouldn't even hesitate:
Edwin would be it. The idea of layering more things onto the obscene
code base that is Emacs repels me.
Aaron W. Hsu
Aaron W. Hsu
>Nils M Holm <news...@t3x.org> writes:
>> Pascal J. Bourguignon <p...@informatimago.com> wrote:
>>> it's not harder to write an emacs than a vi.
>>
>> But it is impractical if the goal is to write a vi.
>That's what I'm saying: wrong goal, change goal :-)
My personal goal is to take NEdit and integrate it into a Scheme
environment, so that you can script NEdit with Scheme and also open
Scheme REPLs from inside NEdit.
Aaron W. Hsu