tag:blogger.com,1999:blog-11788780.post113506477013899407..comments2023-12-29T13:22:33.104-08:00Comments on JJinuxLand: Emacs: The Straw that Broke the Camel's Backjjinuxhttp://www.blogger.com/profile/03270879497119114175noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-11788780.post-1142908235722271482006-03-20T18:30:00.000-08:002006-03-20T18:30:00.000-08:00Concerning tabs in Vim, I use the minibufexpl plug...Concerning tabs in Vim, I use the minibufexpl plugin. In my .vimrc, I have:<BR/><BR/>let g:miniBufExplMapWindowNavVim = 1<BR/>let g:miniBufExplMapWindowNavArrows = 1<BR/>let g:miniBufExplMapCTabSwitchBuffs = 1<BR/>let g:miniBufExplModSelTarget = 1<BR/>map <C-PageUp> :bprev<CR><BR/>map <C-PageDown> :bnext<CR><BR/><BR/>It's not pretty, but it's very useful. I also recommend:<BR/><BR/>" Don't require that you save when switching to another buffer.<BR/>set hiddenjjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-1142904354623060392006-03-20T17:25:00.000-08:002006-03-20T17:25:00.000-08:00I think I fulfill the requirements, so I'll throw ...I think I fulfill the requirements, so I'll throw in my € 0,02.<BR/><BR/>I actually love Emacs' keybindings. That's because I use a custom keyboard layout (kind of like Dvorak, but designed for the German language), which makes Vim's h/j/k/l navigation completely useless (it would be u/p/y/e on a QWERTY keyboard). They're also consistent, which makes them easy to remember: C-f = forward-char, M-f = forward-word and so on. Even if you don't know some particular keybinding, you can use M-x to run the command by name or use tab-completion to discover new features.<BR/><BR/>That said, Vim's syntax highlighting really is a whole lot better than Emacs'. But what really annoys me is Emacs' complete lack of proper text rendering. I mean, which century <I>is</I> this? Antialiased text is a <B>must</B> for my bad eyes, and Emacs doesn't provide it (except in Mac OS X, of course, but regarding font rendering that's in a whole different league altogether, anyway).<BR/><BR/>I find both editors' handling of multiple buffers horrible, by the way. I'd love to have a nice, graphical tab bar as well as a tree view of my project. I know of Speedbar and tabbar-mode for Emacs, but they're ugly and not really usable. Do you know of a good solution for Vim, by chance?<BR/><BR/>jEdit has got tabs and a graphical tree view, but its keybindings are terrible, there are no keybinding sets to choose from, <I>and</I> it consumes much more RAM than it should. Its syntax-highlighting support isn't as good as Vim's and Emacs', either. Not to mention the fact that its startup time is even worse than that of Emacs.<BR/><BR/>Oh well... maybe I should go back to using EDLIN.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11788780.post-1135228658749637632005-12-21T21:17:00.000-08:002005-12-21T21:17:00.000-08:00Yes, I've heard good thing about jEdit. It's open...Yes, I've heard good thing about jEdit. It's open source, so that's good (actually, a requirement). It even has Haskell support ;) It doesn't have Cheetah support, but I could probably use the Velocity support as a guide to do it myself. It does have a plugin infrastructure. Perhaps the two things that are unfortunate are: 1) there's no console mode. I really like and use this feature in Vim. 2) It won't be fun trying to get this to run on my remote FreeBSD 4.7 system and use it over remote X. Of course, that situation is doable. I may give it a shot since I've heard good things about it. I have a suspicion it will require more actual (i.e. including shift, ctrl, etc.) keystrokes (count them!) than Vim to perform various tasks since it's modeless (consider silly tasks such as replacing 5 characters with a new word "5xi", deleting a blank line "dd", opening up a blank line "o", etc.), but I can almost guarantee it's easier to use (as I mentioned however, I'm *not* looking for an easy to use editor). I hope it doesn't force me to use the arrow keys ("hjkl" in Vi) or mouse (probably won't) since that involves moving my hand. By the way, I've come to the conclusion that it's a good idea to use an editor that makes sense for your programming language: Lisp->Emacs, Java->Eclipse, Visual Basic->Visual Studio, etc., but there's still room for weirdos like me who code in a ton of various languages for the simple joy of it. Gees, I guess I gotta go install Java now ;)jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-1135176065989191752005-12-21T06:41:00.000-08:002005-12-21T06:41:00.000-08:00All the stuff you mentioned I noticed JEdit alread...All the stuff you mentioned I noticed JEdit already has. And JEdit is much easier to use since it has a GUI.<BR/>Just download some plugins like buffertabs, jython/jruby addins, console addin, jdiff, etc.Doughttps://www.blogger.com/profile/01046323436983602488noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-1135157461816875632005-12-21T01:31:00.000-08:002005-12-21T01:31:00.000-08:00> I am pretty experienced at both > Emacs and Vim....> I am pretty experienced at both <BR/>> Emacs and Vim...<BR/><BR/>Quite helpful. Thanks!jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-1135135685843197012005-12-20T19:28:00.000-08:002005-12-20T19:28:00.000-08:00I am pretty experienced at both Emacs and Vim. I ...I am pretty experienced at both Emacs and Vim. I tend to prefer Emacs for development, and Vim for configuration files and system administration.<BR/><BR/>Emacs does have multi-mode support, but it's a pain to set up; vim clearly wins in that area. However, for me, multi-mode files are a code smell; if an HTML file has more than one expression worth of Python in it, or a Python file has more than one tag worth of HTML, I find that there is some kind of design mistake happening.<BR/><BR/>The real killer feature of Emacs that makes it the clear winner for development is the ability to asynchronously run processes and interact with buffers. Being able to jump between an active PDB session and the real editor for the source files involved is really helpful for visualization. Also, my unit tests take a looong time to run. I really like being able to whack the "unit test" key and keep coding.<BR/><BR/>In some absolute sense, Emacs is more powerful and Vim is faster. It depends on what you need - if your code involves editing groups of small files, in different languages, on different systems, then Vim is far better; working with Emacs in that environment leaves you spending most of your time waiting for the editor to start. In the opposite case, where you are working with large numbers of large files, in a big system, the implied workflow you noticed (wanting to keep lots of files open at once, wanting to keep the editor running) is a help rather than a hindrance.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11788780.post-1135115088798262852005-12-20T13:44:00.000-08:002005-12-20T13:44:00.000-08:00It turns out my diff wasn't highlighted because I ...It turns out my diff wasn't highlighted because I hadn't turned on syntax highlighting.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-1135108317306649832005-12-20T11:51:00.000-08:002005-12-20T11:51:00.000-08:00Ben Bangert said (roughly):* You absolutely must s...Ben Bangert said (roughly):<BR/><BR/>* You absolutely must swap Ctrl and Caps Lock.<BR/><BR/>* I do use c-[npbf].<BR/><BR/>* Use mmm-mode for multi-lingual syntax highlighting. I wrote the mode for Myghty.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11788780.post-1135107785250784552005-12-20T11:43:00.000-08:002005-12-20T11:43:00.000-08:00From: Jesse MontroseOn Tue, Dec 20, 2005 at 03:13:...From: Jesse Montrose<BR/><BR/>On Tue, Dec 20, 2005 at 03:13:04PM +0000, JJinuxLand wrote:<BR/>> - The syntax highlighting in Emacs cannot compare to that of Vim,<BR/>> especially in multi-mode files such as Cheetah. Here's a screenshot<BR/>> of Vim (see below). Notice that it's able to handle Cheetah,<BR/>> Python, HTML, and JavaScript all in the same file.<BR/><BR/>That would kill it for me too. I just don't have to edit multimode<BR/>files.<BR/><BR/>> - I found myself with my pinky permanently glued to the control key<BR/>> when I was editing existing code. Does everyone else ignore the<BR/>> tutorial and use the arrow keys instead of C-[npfb]?<BR/><BR/>I use the arrows, but I also have caps-lock mapped to ctrl. Don't you?<BR/><BR/>> - I'm stuck with FreeBSD 4.7 in a certain programming environment,<BR/>> and Emacs there didn't come with Python support at all! In contrast,<BR/>> with the exception of brand-new languages like Io, there's a mode in<BR/>> Vim _already installed_ for almost every programming language I've<BR/>> ever used (e.g. Haskell, OCaml, etc.).<BR/><BR/>That's just an old version, it's there in emacs CVS (and at<BR/>python.org, I think). Installation is pretty easy, but you have to be<BR/>open to configuring, as there are a lot of these little things that<BR/>require tweaking to get the way you like them.<BR/><BR/>> - When committing a CVS file, it didn't make use of my CVS/Template,<BR/>> which is a must for my programming situation.<BR/><BR/>I've never understood that. I have it registered, so I get the<BR/>template with ^xgt, but I still don't know why the author didn't add<BR/>that.<BR/><BR/>> - Being compulsive obsessive, it was a bit irritating having a<BR/>> buffer in my buffer list for everything. I far prefer just having a<BR/>> buffer shown for each file that I'm actually editing. I like to<BR/>> permanently close buffers, but this seems to be discouraged in<BR/>> Emacs. I'm sure this is just a matter of workflow, and it doesn't<BR/>> really matter. To be fair, I've customized Vim to show my open<BR/>> buffers along the top, like tabs.<BR/><BR/>I suppose most emacs users keep lots of buffers open, but I don't see<BR/>anything in the design that discourages you from permanently closing<BR/>buffers.<BR/><BR/>> - The thing that broke the camel's back was when I noticed how<BR/>> nicely Vim syntax highlighted a diff I was reading. I then tried the<BR/>> same thing in Emacs, and it didn't syntax highlight at all. I'm sure<BR/>> it _can_ do it, but it didn't by default.<BR/><BR/>Yeah, mine does it. For what it's worth, emacs has a mode called<BR/>ediff that I believe to be the best diff in existence (I don't make<BR/>that claim about emacs in general). I'll give you a demo sometime.<BR/><BR/>> As an aside, it's fair to say that neither Emacs nor Vim is<BR/>> especially user friendly. That's true. However, _for me personally_,<BR/>> since I edit text all day, everyday, I'll choose whatever is _most<BR/>> powerful_ for the type of editing I do. Since I do this everyday,<BR/>> the initial learning curve is less important to me.<BR/><BR/>I'm strongly in that camp myself. I'd much rather spend time up front<BR/>learning a tool than spend a lifetime suffering for the sake of an<BR/>"easy to use" tool :)<BR/><BR/>> I'll keep my further comments to myself. To prevent a flamewar,<BR/>> please only respond if:<BR/>> <BR/>> - You know at least 20 hotkeys in each editor you're arguing about.<BR/>> - You approach the argument with an open mind.<BR/>> - You have coded for at least 2 months in each editor you're arguing about.<BR/><BR/>I think I still (barely) meet the requirements, although I'm not<BR/>arguing, I think you *should* use vi.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11788780.post-1135071786168878252005-12-20T01:43:00.000-08:002005-12-20T01:43:00.000-08:00This comment has been removed by a blog administrator.Chriswabhttps://www.blogger.com/profile/01271323473469913808noreply@blogger.com