Fluid Dynamics <a2093...@trbvm.com> writes: > * i don't have to learn and use a distinct, possibly > resource-hungry, IDE[2] for every new programming language or > environment i need/want to work in. (When the Swift language was > released, for example, basic Swift support in the form of > `swift-mode` became available within less than a week.) > > Eclipse has plugins for a wide variety of languages.
My experience has been that many plugins except for the really major ones are frequently incompatible. I.e., some cool plugin appears and with the next eclipse release it won't work anymore because its maintainers have a hard time keeping it up-to-date. For that reason, it is not uncommon that people set up separate eclipse installations for each and every project which has the exact version required by the plugins needed for that project. > * Further to the resource-usage issue, i can more easily use Emacs > remotely over low-bandwidth links than i could use an IDE. > > Typical home and mobile connection speeds are multiple MBPS these days. Still, running Eclipse or some other IDE via X forwarding isn't too much fun even with X2Go. > * In my experience, Emacs tends to be less of a 'black box' than > some IDEs, in that i can more easily get a better sense of what's > going on "behind the scenes". This in turn means that i've got a > better sense of the relevant build system, and how to fix and/or > tune it in particular circumstances. > > Unfortunately, one MUST do all of that and CANNOT use it as a black > box, because it is the software analogue of a computer with no > keyboard or monitor or anything else resembling a user interface, so > one must toggle everything in and know the hardware internals > backwards and forwards to get anything done. :) That's nonsense. As soon as you have made yourself acquainted with the basic Emacs terminology and concepts, getting started with Clojure development is a piece of cake. Of course, knowing more than that will make it easier to make best use of its features and adapt it to your personal preferences but that's the same with IDEs, too. > And what kind of i18n corner cases tend to arise with a 7-bit 80x24 > character-based display (or emulation of same)? Emacs follows the unicode standard and represents characters as UTF8-encoded codepoints. > * Emacs is, in my experience, one of the best-documented pieces of > software i've encountered. Absent or poor documentation is > typically treated as a bug. > > The issue with its documentation isn't, of course, its existence or > comprehensiveness. No, but that's the issue many IDEs have. Usually, you have a button or a menu entry for some functionality possibly with some tooltip, and that's as much "documentation" as you get. > Rather, the last time I tried using emacs, I seem to recall always > ending up with this sequence of events: > > a) I am trying to do some task X, for which the obvious key combination bleeps > or does something weird but definitely doesn't do X for some reason. > b) Soon, I have a split pane with my document on the left and the help files > on > the right, with the latter open to a page on task X and the input focus in it. > c) A little bit later, I have a split pane with my document on the left, the > input focus in my document, and the help pane on the right open to a page on > how to switch focus between panes, and I don't remember the long and > complicated sequence of keystrokes needed to perform task X any more because > it > was deleted from my brain's short term memory to remember the long and > complicated sequence of keystrokes that is how one says "alt+tab" in the > obscure and archaic dialect known as emacsese. > d) Repeat b) and c) a few times, while experiencing an acute event of abnormal > pre-menopausal hair loss. > e) Give up and fire up Notepad, Eclipse, or whatever seems best suited to > current task. ;) I think with "help pane" you mean a window showing the Emacs info manual. You can have as many of them open as you like, say, one for "task X", and one for "switching focus between windows". > * The Emacs ecosystem is growing rapidly; http://melpa.org/ > currently lists ~2400 packages ("extensions" or "addons") > available for easy installation via Emacs' package.el UI. > > > I wonder how anyone can find anything in that mess. Searching might be a start. > The Java and Clojure IDEs are probably each sandwiched amongst > hundreds of consecutive entries Yes, of course. Hey, how to people use apt-get/packman/yum/whatever? The packages needed for "task X" are sandwiched between tens of thousands of unrelated packages. > all the rest of which are for languages nobody has ever heard of > outside of one obscure city near Bernhöfen, or that nobody has used > since 1987, or that nobody has used period because the whole thing was > invented as an obscure joke (e.g. Befunge). I don't see how support for niche languages is a bad thing. And "all the rest" is again nonsense. > Yes, there can be a steeper initial learning curve with Emacs than > with IDEs, > > This easily qualifies as a very strong candidate to be crowned > understatement of the century, and we're not even 1/6 of the way > through this one yet. Steeper? It's like comparing a gentle hill to > the part of a roller coaster track that's more than halfway up the > side of a loop-the-loop. The emacs learning curve is so steep it has > overhangs! Every newbie should run through the tutorial once (C-h t) in which all important concepts are discussed. After that, you are initiated and should be able to look up documentation yourself. > And now our fresh new candidate for understatement of the century > already has to accept also-ran status as there's a new contender in > town that now looks nearly certain to achieve victory. How do you define victory? I have no doubt that other alternatives for Clojure development might become more popular than Emacs. But why is that important, and why would that make Emacs a loser? I mean, everyone should use what suits him best. IDE X might serve the "work the way I'm already used to" fraction, Emacs might serve the "I want to tinker with anything and customize it to my very specific needs" fraction. > but i also feel it's something that developers - and Clojure > developers in particular - should perhaps at least give a second > look. > > Have they gotten around to adding a feature that makes it simple and > intuitive to switch between the help pane and a document pane without > having to navigate the help pane away from the thing you can't > memorize to some other, pane-switching thing you also can't memorize? `C-x o' is the standard key for cycling thru windows ("panes"). If that's to hard to type (to me it is), then define a better key for it. FWIW, Alt+<N> for N being an integer sets the input focus to the N-th window here. And to browse as many info manuals simultaneously so that you don't have to navigate away from one topic to read another, you can have as many open info buffers as you wish. The command that you invoke to open the documentation also tells you how, i.e., the solution is documented in `C-h k C-h i' ("Please Emacs, describe the command which gets executed by the key `C-h i'."). Bye, Tassilo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
