But I think what's going wrong is a little different.Į.g., there's a mode that highlights the current line. † To be fair, not all bugs - some are just configuration issues I haven't figured out yet.įor sure. Probably the biggest source of issues is two different modes not playing well with each other, which is understandable, but also something it feels like a less freeform approach to an editor might reasonably be able to do a better job of avoiding. * if a shell command tries to open a file in emacs, and the active window is the minibuffer, the file will open into the minibuffer * subword mode doesn't think DEBUG_MEGA_GOLD is three words (in a. * tendency to identify buffers by name causes bugs when renaming buffers ("stringly typed") * highlight line mode doesn't work on most recent line in shell * line highlight doesn't work after jumping to a definition sadly might be a visual line mode bug, actually. * code-wrap is stupid with long separator lines (like "//-" for a long time) * piece of shit grep edit silently fails on spaces on file names * shell doesn't save history a lot of the time * «Error running timer `auto-revert-buffers': (wrong-type-argument number-or-marker-p nil)» ![]() * parens don't overwrite properly in go-mode ![]() * visual-line-mode jumps around on very long lines (like paragraph long) * grep-ed while buffer is in loccur mode fucks things up * emacs stopped automatically recompiling. * sometimes trying to launch a new shell just kills the old shell * the popup used by dumb-jump breaks when line wrapping is enabled and it's used on a wrapped line * vc-annotate doesn't properly restore window configuration * delete-horizontal-space doesn't work w/ iedit mode * "replace-match-maybe-edit: Match data clobbered by buffer modification hooks" * iedit substition starts just corrupting shit (e.g., try replacing \t with spaces) * after running ipython for a while, all terminal commands hang waiting for output * kill-word-sp cancels ioccur mode for some reason Here's my list of problems to solve on a rainy day†: If Emacs is that fragile, then its extensibility is really a moot point. In the article the author talks about how he's gone bankrupt three times with his config, maybe that's a sign that the problem isn't the author. I really wanted to like Emacs, and I've chalked up my bad experience to less people putting dev time towards it rather than actual negligence towards the user experience. Vim with all of my plugins, which has the same features as my Emacs config, starts up instantly and I've yet to encounter a single bug. Why does every user have to constantly reinvent the same config to work around all of the issues in Emacs? I don't know, but I wasn't going to stick around and find out. ![]() There's a lot of cargo culted config fragments like the ones you'll find in the article. which felt like Stockholm syndrome to me. While digging for answers I was told not to use certain platforms, don't use the GUI, use the GUI, don't turn Emacs off etc. I gave up on Emacs and went back to Vim because of the slowness and the bugs I was encountering while using the Emacs GUI (granted a lot of them were from lsp-mode and other heavy packages).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |