> Hello Guillaume e.a.,

> is it possible to get a Jazz repl without Jedi? bin/kernel is more or
> less a gambit repl and jazz.debuggee seems to contain the code that is
> used within Jedi, but i have no idea how to use it outside Jedi.

> The reason for this wish is probably obvious: I am addicted to
> Emacs :-)

> Regards, Marco

> - navigation using c-a, c-b, ...
> - incremental search
> - syntax coloring
> - tab completion
> - code indentation
> - clipboard stack
> - textual macro recording
> - c-x c-f to find files
> - ...

> and when you launch Jedi and create a new profile, if you choose Bindings: Emacs, then pretty much
> all basic Emacs bindings should work.

> (sorry for the late reply)

> > Jazz was designed so it can be used independently of Jedi. As for a
> jazz.exe that implement's a
> > Jazz REPL, I started work on that but it is really low priority as it
> would be a pale substitute
> > for Jedi (one big thing for instance that a console-based REPL will never
> be able to handle well
> > is debugging multiple threads / processes).

> Nice to hear that you work on a jazz.exe, sad that it is low
> priority. Threads are currently not an issue here, but I think there are
> ways to handle it in a somewhat blown up REPL, e.g. Common Lisp + SLIME.

> > I'd say the best thing for you is to edit in Emacs and debug using Jedi.
> Note that Jedi when
> > activated checks the modification time of all its edited files and
> proposes reload if some have
> > changed.

> That's mainly the way I use Jazz right now, but it is not that
> satisfactory: what I enjoy most when programming in any kind of Lisp is
> the possibility to try things out fast, i.e. use a REPL.

> > Also, note that if you decide to give Jedi a spin, it implements a large
> subset of Emacs
> > functionality like :

> > - navigation using c-a, c-b, ...
> > - incremental search
> > - syntax coloring
> > - tab completion
> > - code indentation
> > - clipboard stack
> > - textual macro recording
> > - c-x c-f to find files
> > - ...

> > and when you launch Jedi and create a new profile, if you choose
> Bindings: Emacs, then pretty much
> > all basic Emacs bindings should work.

> Yep, I know and use all (almost) of it in Jedi, but:

> 1. there is no Paredit mode:

>   I was very surprised to see how much one can get used to such a tool,
>   in fact I did not close a parenthesis in Lisp for about two years now
>   - that is before using Jedi :-)

> 2. Linux

>   But more important is Jedi's performance on Linux: in the mail
>   archive someone described that the redraw is more or less pixel-wise,
>   and this is also the case here. Being not an expert in programming
>   Cairo, I only can give you two vague hints:

>   a) AFAIK Cairo does *not* support any kind of double buffering out of
>      the box

> Btw, I managed to compile Jazz/Jedi with gambit --enable-cplusplus and
> could provide a patch which is not directly applicable (hard coded 'g++'
> and the like), but could give you an idea where some (minor) changes
> could be made to support c++. Most are explicit casts from int to some
> enum type in the ffi, which are necessary in c++ and do not hurt in c.

> Regards, Marco

> I'm open to any suggestions. But seeing that the Gambit REPL's support for threads is
> minimal and that various discussions with Marc Feeley ended in him reiterating that it is
> not possible to fully support threads in a pure console based REPL, I'm doubtful.

> What do you mean? Jedi's console is a full-fledged REPL! What are you missing from it?

>     1. there is no Paredit mode:

>       I was very surprised to see how much one can get used to such a tool,
>       in fact I did not close a parenthesis in Lisp for about two years now
>       - that is before using Jedi :-)

> Various people mentioned Paredit. I had a quick look at the documentation and Jazz
> already supports most of it but bound to other keys. I'd guess creating a full Paredit
> module for Jazz would be a couple hours work. Any takers?

>       But more important is Jedi's performance on Linux: in the mail
>       archive someone described that the redraw is more or less pixel-wise,
>       and this is also the case here. Being not an expert in programming
>       Cairo, I only can give you two vague hints:

>       a) AFAIK Cairo does *not* support any kind of double buffering out of
>          the box

> I totally agree!  Linux / X11 performance is the big killer and main reason I never
> announced Jazz publicly. Unfortunately my macbook pro died on me twice and Linux / X11 is
> low priority for us at the moment. This is unfortunate as I'm pretty sure somewhat with
> expert knowledge of X11 would probably be able to fix the performance problem in no time.

> This is exactly what I happen to be working on at the moment. :) I'll post a message when
> it's ready. Probably beginning of next week.

> Sure! I'll have a look at it. Thanks.