Haskell community members on IRC are quite proud of John.
And worried we’ll have to share him :)
Incidentally, I was talking to him about best practices / good design in prog-lang modes for Emacs a couple weeks ago. Maybe I should do something about that for Hac-Phi? So hard to pick side projects to work on.
I wasn’t surprised people used this as an opportunity to bring Guile back up.
I don’t think we need much from Emacs core itself for that. The improvements I have in mind for haskell-mode are mostly about scope shrink, cleanup, getting indenting to be more reliable.
It’s just unnecessary and it changes too much for that to make sense. I’d be opposed to trying to make haskell-mode or any other Haskell mode part of Emacs core and I imagine John would too. There’s a lot of stuff coming down the pipe (haskell-ide-engine) and it’s not a good idea.
John seems to be a lot more in touch with the wider community of Emacs users than past maintainers have been. He’s level-headed, approachable, and hangs out on Freenode.
He has written a lot of code that has been included in Emacs itself, but has also maintained a lot of code that lives outside Emacs, so he understands the tension that can have on upgrade cycles.
He is also a lot less ideologically-driven than maintainers have historically been, to the extent that he runs a non-free operating system on his own machine. It says a lot about his character that rms would overlook that problem and still give John his blessing.
I am the wrong person to ask that, I have used the regular cocoa emacs port forever. With occasional forays into the macport carbon version, which does work much better than the cocoa version. But lacks the one key feature I need which is multiple tty support. Aka, emacsclient doesn’t work with it.
Are you referring to this issue? I found the visual artefacts went away when turning off visual bell, and you can separately silence the audible bell by setting ring-bell-function to 'ignore. (Relevant section of my init.el.) I would like my visual bell back sharpish though—no feedback is not great; just barely better than audible-only :-)
Nope, so what I see is that with the cocoa port of emacs what will eventually happen is the redraw of a screen with many fontified characters/lines etc… will eventually cause emacs to spin at 100% for sometimes up to a minute doing nothing.
What is supposed to be happening is the font rendering is pushing out too many needless redrawings and you get to watch paint dry until it catches up. It can happen in linux too but needless to say it gets really frustrating when your text editor behaves like something from the mid 90’s.
Haskell community members on IRC are quite proud of John.
And worried we’ll have to share him :)
Incidentally, I was talking to him about best practices / good design in prog-lang modes for Emacs a couple weeks ago. Maybe I should do something about that for Hac-Phi? So hard to pick side projects to work on.
I wasn’t surprised people used this as an opportunity to bring Guile back up.
On the plus side, maybe you’ll finally get the improvements to
haskell-modethat you’ve been clamouring for. :-)I don’t think we need much from Emacs core itself for that. The improvements I have in mind for haskell-mode are mostly about scope shrink, cleanup, getting indenting to be more reliable.
Why couldn’t it be distributed with Emacs? Too many contributors already to do the copyright assignments?
It’s just unnecessary and it changes too much for that to make sense. I’d be opposed to trying to make haskell-mode or any other Haskell mode part of Emacs core and I imagine John would too. There’s a lot of stuff coming down the pipe (haskell-ide-engine) and it’s not a good idea.
What does this mean, for those of us that are not intimately familiar with emacs-devel?
John seems to be a lot more in touch with the wider community of Emacs users than past maintainers have been. He’s level-headed, approachable, and hangs out on Freenode.
He has written a lot of code that has been included in Emacs itself, but has also maintained a lot of code that lives outside Emacs, so he understands the tension that can have on upgrade cycles.
He is also a lot less ideologically-driven than maintainers have historically been, to the extent that he runs a non-free operating system on his own machine. It says a lot about his character that rms would overlook that problem and still give John his blessing.
You’re pleased now, just you wait until he replaces elisp with Haskell ;P
I just hope this means osx emacs can get faster/better process handling in the cocoa port and the screen redraw issues addressed.
Had to ditch using the gui entirely it was getting really bad.
What about Aquamacs, does that still enjoy any popularity?
I am the wrong person to ask that, I have used the regular cocoa emacs port forever. With occasional forays into the macport carbon version, which does work much better than the cocoa version. But lacks the one key feature I need which is multiple tty support. Aka, emacsclient doesn’t work with it.
Are you referring to this issue? I found the visual artefacts went away when turning off visual bell, and you can separately silence the audible bell by setting
ring-bell-functionto'ignore. (Relevant section of my init.el.) I would like my visual bell back sharpish though—no feedback is not great; just barely better than audible-only :-)Nope, so what I see is that with the cocoa port of emacs what will eventually happen is the redraw of a screen with many fontified characters/lines etc… will eventually cause emacs to spin at 100% for sometimes up to a minute doing nothing.
What is supposed to be happening is the font rendering is pushing out too many needless redrawings and you get to watch paint dry until it catches up. It can happen in linux too but needless to say it gets really frustrating when your text editor behaves like something from the mid 90’s.
Is this meant in a bad or good way? I’m having trouble understanding what you mean by that. ;)