He also has an IQueueFactory class, that seems like some nice antipattern to me ;) *Edit: also, use QuickFIX, don't write your own. Been there, done that, does not worth it.
He also has an IQueueFactory class, that seems like some nice antipattern to me ;) *Edit: also, use QuickFIX, don't write your own. Been there, done that, does not worth it.
Or at least if you can do that, I've got no idea how to enable it in IDEA.
Emacs does provide that feature using follow-mode: http://www.gnu.org/software/emacs/manual/html%5Fnode/emacs/F...
edit: it is apparently possible to do something very similar in vi/vim by using scrollbind.
To be fair I think Atom hides the split commands behind a View->Panes menu and IntelliJ (or PHPStorm at least) has the command in Window->Editor Tabs. (All on OSX). So it's not super clear where the split window functionality is, but it's also not hard to read the docs for your editor..
Edit: Ah I see what the OP is saying now. I'd be surprised if this functionality isn't covered by plugins, though.
What I find really interesting is that I seem to be in a _very_ tiny minority that wants this or even has given any thought to this. I expected that most other developers with modern monitors would want this. The comments here and on the blog show that isn't the case :)
Another thing I would like is the ability to inject multiple files into the same "edit buffer" so that "search" works over these related files as whole, transparently.
Regarding the anti-pattern. You may be right, I have't updated the code in a few years. I displayed it in the screenshot only because it is already open source. But I do need the option of writing files to disk, writing to some random data store or just keep the data in memory. Send me a note about your idea, the whole point of opening it up was to get feedback.
QuickFIX is pretty good, but doesn't hurt to experiment :)
Emacs might do all of this, but eclipse does this well enough.
Then again we have another service with four files over 1000 lines (1441 the biggest), and we experience significant pain: not because of the size of the files but because of what the size of the class means about its design. That's on a team that had significant pressure to meet some tight deadlines. They are now actively working on refactoring those classes - again, not because of the size, but because of the design.