[Aquamacs-devel] Xiki and aquamacs

[Craig Muth]

Please watch this *very short* new Xiki screencast:

http://www.youtube.com/watch?v=bUR_eUVcABg

Xiki works great with Aquamacs 1.9.1, but is unusably slow in newer
Aquamacs versions. This is due to a bug where the process
communication that el4r is doing with the ruby process is 1000 times
slower. The same issue occurs in Carbon emacs versions 23 and 24, but
the problem doesn't happen with emacs 23 and 24 on ubuntu. Any
suggestions / ideas?

The way Xiki is evolving, it's accessible via the 'xiki' shell
command, via a web interface, and via editors. Currently the only
editor is emacs (not counting a very limited CodeMirror prototype).
There are plans to make it accessible via vim and other editors. But,
emacs will be the editor that supports the most Xiki features for a
long time in the foreseeable future. And Aquamacs is quickly becoming
the emacs of choice for Xiki on the mac, due to its awesome user
experience for mac users.

--Craig
_______________________________________________
Aquamacs-devel mailing list
Aquamac...@aquamacs.org
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[David Reitter]

On Aug 12, 2012, at 8:23 PM, Craig Muth wrote:
>
> http://www.youtube.com/watch?v=bUR_eUVcABg

Looks awesome!

> communication that el4r is doing with the ruby process is 1000 times
> slower. The same issue occurs in Carbon emacs versions 23 and 24, but
> the problem doesn't happen with emacs 23 and 24 on ubuntu. Any
> suggestions / ideas?

Yes, the problem is due to the Nextstep port that is used by Emacs 23/24. Aquamacs is based on this.

There is a development (AppKit "Mac" port) that has this issue solved, but it has other disadvantages. I am watching the development and may be able to move Aquamacs over to this port, though this will be a lot of work.

- David


--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and support the Aquamacs Project!

[Craig Muth]

>> http://www.youtube.com/watch?v=bUR_eUVcABg
> Looks awesome!

Thanks! It's gotten 1300 youtube views - kind of cool. Matz (the
inventor of Ruby) tweeted the screencast a few days ago which gave it
a lot of visibility on twitter. My favorite ensuing tweet was "@xiki
is the most innovative and useful application I've ever seen!" :)

I've been building Xiki for a long time, but only recently have made
adoption a priority. I just updated the docs to recommend Aquamacs as
the recommended editor for Xiki on the Mac. It's awesome to be able
to have anyone jump right in and edit the way they are used to (not to
mention some of the other great Aquamacs features).

>> communication that el4r is doing with the ruby process is 1000 times
>> slower.
>

> Yes, the problem is due to the Nextstep port that is used by Emacs 23/24. Aquamacs is based on this.

We've identified the problem as (accept-process-output) being slow.
Sometimes it takes 100 miliseconds, though sometimes it's sporadically
faster.

Is that related to the Nextstep issues you've seen?

I'm exploring some work-arounds - like just looping and rechecking
whether there's output from the ruby command in the process buffer,
instead of using (accept-process-output). If you have any other
ideas, I'd love to hear them.

> There is a development (AppKit "Mac" port) that has this issue solved, but it has other disadvantages. I am watching the development and may be able to move Aquamacs over to this port, though this will be a lot of work.

Let me know if I can do anything to help, maybe specifically related
to pulling out the (accept-process-output) implementation. It would
be nice to be able to roll just that code back to how it was
implemented with mac emacs 22, but I'm guessing it's not that simple.

--Craig

[Craig Muth]

Oh, another strange clue is that when we put (prin1 ...) lines before
and after the call to (accept-process-output), it speeds it up
significantly. This makes me hopeful there's a fix or workaround.

--Craig

[David Reitter]

On Aug 15, 2012, at 6:42 PM, Craig Muth wrote:
>>
>> Yes, the problem is due to the Nextstep port that is used by Emacs 23/24. Aquamacs is based on this.
>
> We've identified the problem as (accept-process-output) being slow.
> Sometimes it takes 100 miliseconds, though sometimes it's sporadically
> faster.
>
> Is that related to the Nextstep issues you've seen?

Yes, and it is a well-known issue with the way the event loop is designed.
Some people are working on it and there may be a patch available soon. So hang in there.

> I'm exploring some work-arounds - like just looping and rechecking
> whether there's output from the ruby command in the process buffer,
> instead of using (accept-process-output). If you have any other
> ideas, I'd love to hear them.

You can try that, but I don't think the process output will end up in the buffer any sooner than `accept-process-output' would terminate. So there may be a lag, during which Aquamacs is at least not unresponsive, by your method. Try if that improves things.

The solution is not that simple, and the problem has been known for some time. It affects flyspell (with aspell/ispell) as well, but in Aquamacs we've got a Mac-like replacement anyway.

- D

[Craig Muth]

> Yes, and it is a well-known issue with the way the event loop is designed.
> Some people are working on it and there may be a patch available soon. So hang in there.

Great to hear!

> You can try that, but I don't think the process output will end up in the buffer any sooner than `accept-process-output' would terminate.

When I don't using accept-process-output, the text appears in the
buffer right away with no delay.

I got the loop approach working - it's been largely successful so far:

(defun accept-process-output2 (process)
(save-match-data
(with-current-buffer (process-buffer process)
(while (or (eq (point-max) 1) (not (string-match "\0" (buffer-string))))
(sleep-for 0.00001)))))

With el4r, it is specifically waiting until there was a \0 in the buffer.

--Craig

[Craig Muth]

Just to close the loop on this, the workaround worked great, and Xiki
now runs on the new Aquamacs versions. The installer was a bit
painful, but I just made a bunch of improvements and pushed a new xiki
gem, in case any of you tried it before and failed.

--Craig

[David Reitter]

On Aug 28, 2012, at 4:05 AM, Craig Muth <craig...@gmail.com> wrote:

> Just to close the loop on this, the workaround worked great, and Xiki
> now runs on the new Aquamacs versions.

That's Great to hear.
Is there anything we can do to make your life easier? Provide a .el directly with Aquamacs, perhaps?

--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and support the Aquamacs Project!

[Craig Muth]

> That's Great to hear.
> Is there anything we can do to make your life easier? Provide a .el directly with Aquamacs, perhaps?

Hmm, let me get back to you on that after a while.

It could be pretty sweet to have el4r be part of the aquamacs
distribution, but at the moment el4r it spreads its files out to a few
different places a few .el files and some ruby files. We're exploring
maybe making it put files in one place.

It could be interesting to eventually explore having aquamacs include
xiki, but that would be a lot of files, and xiki is currently still
changing pretty rapidly.

--Craig