This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-23
Channels
- # announcements (1)
- # aws (13)
- # babashka (31)
- # beginners (102)
- # calva (46)
- # cider (16)
- # clj-kondo (1)
- # cljs-dev (3)
- # clojars (1)
- # clojure (396)
- # clojure-argentina (1)
- # clojure-australia (4)
- # clojure-europe (64)
- # clojure-nl (2)
- # clojure-uk (8)
- # clojurescript (20)
- # conjure (5)
- # cursive (4)
- # datomic (15)
- # emacs (48)
- # graalvm (69)
- # graalvm-mobile (1)
- # jobs (4)
- # jobs-rus (1)
- # lsp (6)
- # malli (15)
- # meander (2)
- # observability (11)
- # off-topic (10)
- # pathom (2)
- # portal (4)
- # re-frame (19)
- # reitit (1)
- # remote-jobs (3)
- # sci (1)
- # shadow-cljs (51)
- # tools-deps (11)
- # vim (12)
- # xtdb (13)
Does anyone know if there’s a way to get emacs to open with very basic functionality in order to get a quick startup time for quick terminal text editing?
Just finding that replacing vim with emacs for this workflow is a bit jarring but ultimately would like to stick with emacs if I can
It should be fast enough as long as you don't do (package-refresh-contents)
in your init file. If not, use Emacs server and maybe you want to compile Emacs 28 (the development branch) with the native-compilation
feature (which is on master now).
@U028TA3H3PA Pretty considerably. Still – network requests in the init file is what kills the performance more than anything.
ive seen a lot of people use https://github.com/troglobit/mg for this purpose, maybe that helps?
Yeah think it’s partially slight differences I have between vim and emacs at the moment and would be less muscle memory to just use one or the other
Also EVIL is very good Vim emulator, the best one I worked with probably.
You can start Emacs as a server process for this: https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html
Then running emacsclient
will just start a new client on the already-running server instead of launching and initialising a new server
Do you not have any issues? I know it’s mainly minor things but I just value consistency
I very rarely use vim for anything more than quickly editing shell scripts when I’m already in a shell, or for viewing and searching through large log files (which Emacs seems to struggle with). It hasn’t annoyed me enough to want to setup an Emacs server process
Ah fair enough, with regard to the project searching have you tried ripgrep? I’ve heard it’s much faster but haven’t tried it myself
Yeah I use ripgrep for project search in Emacs. But when I have a single large log file I don’t want to open it in an Emacs buffer, so I just switch to a shell and open it in vim to search through
I’m sure that Emacs is better at handling large files than I give it credit for but I’ve just had it crash too many times, and it happens rarely enough, that I find it easier to just use vim temporarily. There is a mode for tailing log files into a buffer
Opening in fundamental mode will be a lot faster and better at handling large files, but vim is probably better at this aspect at the moment
Maybe opening read-only and calling fundamental-mode
is the way to go. I will try it the next time I need to look at a big file 🙂
There is https://www.emacswiki.org/emacs/LongLines mode Using Spacemacs, it also warns about opening big files and can be set to open files over a certain size in a specific mode, i.e fundamental
Think if I can’t use emacs vim would be the way to go for me. I’m only just coming to emacs after a long time with vim so pretty comfortable with it
+1 on using vim for those use cases
Yeah I’m on doom, figured it was easier to start with doom and strip back when I start to get comfortable and definitely seems to be working out
Makes sense, did you use emacs for something other than clojure? I imagine I’ll use it much more for other development more than clojure initially
Yeah that’s an interesting perspective. I figure if anything is going to come close to replace all other editor for me it’s emacs. Just to do it will require a lot of investment..