I don't wanna start any text editor wars here, but just wondered what everyone else was using for writing Nim?
And do certain editors offer better features than others, not just syntax highlighting but things like debugging support etc.
I'm using Emacs myself, and even though I find Emacs slow sometimes it is an editor that can do a lot of things.
I did try Vim, and yes its faster than Emacs but I could not get used to having to switch modes before editing text. With Emacs I can just press the same keys to do certain things without having to switch modes first.
Anyway, I digress :-)
What editor are you using with Nim?
Emacs here, using mostly the default key bindings.
About the slowness, you probably just need to disable the nimsuggest-mode. I haven't noticed any slowness when editing Nim code (or anything) in Emacs.
Emacs slows down when you have long lines so not just with Nim.
I am using version 25.1
Emacs slows down when you have long lines
I agree, but that would be a rare case where you have a single line unprettified JSON or something like that.
How long are your lines in Nim? I default to 80 chars per line. For Emacs, "too long" lines would be in the range of upper hundreds of chars per line.
I am using version 25.1
The latest stable release as of today is 26.2, which I would recommend upgrading to. I am on the latest master build of emacs (27.x).
I am reluctant to upgrade at the moment because I am using a lot of packages plus my own customizations. And I don't think the slowness with scrolling with long lines would have been fixed anyway, so no gains by upgrading.
Try emacs with lines like this, I also have one or two even longer....
let predefinedGlobals = ["about","and","animate","as","at","by","case","catch","collect","continue","coordsys","do","else","exit","fn","for","from","function","global","if","in","local","macroscript","mapped","max","not","of","or","parameters","persistent","plugin","rcmenu","return","rollout","set","struct","then","throw","to","tool","try","undo","utility","when","where","while","with","true","false","on","off","pi","e","red","green","blue","white","black","orange","yellow","brown","gray","x_axis","y_axis","z_axis","ok","undefined","unsupplied","dontcollect","noValue"]
vim.
I don't have long lines because I run nimpretty.
You are right; may be nim-mode is exacerbating the slowness issue.
I haven't come across this issue as I limit the number of chars per line to around 80.
Try using nimpretty that ships with Nim.
With a longlines.nim ( http://ix.io/1QnF ), running nimpretty longlines.nim modifies the same file to this ( http://ix.io/1QnG ).
And Emacs itself tends to be somewhat unresponsive, as evidenced by the very first posts in this thread.
That's a grossly incorrect generalization.
I agree that Emacs has a weak spot when handling long lines. I have been using Emacs for 14+ years, and I never came across that limitation, may be because I code in 2-window frames and thus limit line lengths to roughly 80 chars.
Obviously, editing time can be very different than start-up time, but it's easy to benchmark start-up time and it's somewhat indicative. In the early 1990s emacs with non-trivial .emacs configurations could take several to many seconds just to start up and load a file while vim would start-up in the blink of an eye (like < 100ms). These days, vim has become bloated (in default configs) while emacs has gotten faster (especially with emacsclient, and maybe even more so if this JIT compiler ever takes off). So,
$ utime vim -c quit nada
0.012548586 0 0 0.0%
$ utime emacs -q -nw --eval='(save-buffers-kill-terminal)'
0.017100606 0.01 0 58.5%
With vim -u /dev/null -c quit which is a little more fair since I had -q on the emacs you see more like 1.8 ms. (vim --startuptime doesn't show many hot spots, but a lot of miscellanous loads.) However, with emacsclient, its time goes down to a similar 2.9 ms, only you get a fully loaded environment. And the "busybox vi" start up is like 190 microseconds, but boy is that a spartan environment - more analogous to vim of the early 90s.
All these times, though, are "too fast to notice", as is the case with most everyday editing operations, unless there's some kind of loop. All probably have "scaling holes" they could patch up with some significant re-engineering. I mostly use vim and I've seen it grind to a halt with some really long lines in binary files. Developer time generally matters a lot more, though that often relies a lot on what one is "used to".
Anyway, I thought some numbers and command-lines that readers could try on their own configs might add some objectivity. (Well, that utime thing is a homebrew command of mine...Sorry. Needed the resolution. https://github.com/gsauthof/cgmemtime will do ms resultion anyway.)
I am a long time Smalltalker.
Smalltalk environments are actually the closest thing to Emacs. Imagine Pharo, but running on Lisp instead of Smalltalk and defaulting to a tiled WM: that's Emacs in a nutshell. If that sounds enticing to you, go for it.
If I were to learn Vim first, am I going to have to unlearn or relearn much should I at a later date move to Kakoune?
Nah, there are only about 10% of keybindings that change between Vim and kakoune. The reason I think it's best to start with Vim is because if you accidentally activate multiple selections in kakoune it may mess with your code and that may be pretty frustrating for someone not used to modal editors.
That's a grossly incorrect generalization.
Nah, it's a pretty known fact.
I suspect that people that insist that Emacs is just as fast as Vim at editing text don't actually know what is like to be proficient at Vim. If you compare it to obamanations like Eclipse or Electron-based editors, sure, Emacs is pretty fast. But when it comes to non-trivial editing commands, there is always a slight lag which breaks the "flow". Even if it's an hiccup of just half a second, that's still too much for people who're used to Vim. When I tried to switch to Emacs a few years ago, I tried everything to make it as responsive as Vim. I remember I even used custom settings for the GC, but it was all for nothing: every once in a while it would hang for a few split seconds. To some people that may be an acceptable trade-off for having a fully scriptable editor in Lisp. To me, it's not.
@cblake, you're right, start-up time is similar, but that's not the point. All the people I know who use Emacs launch it once in the morning and close it when they go to sleep. The problem is that in order to leverage its potential, you need to write (or download) pretty complex plugins, which are all written in Lisp, for better and for worse. You can do some pretty amazing things with it, but there is no getting around the fact that Lisp is slow.
Nah, it's a pretty known fact.
This is a case that Spiderman's uncle talked about: "With great power comes great responsibility".
With the possibility to tweak Emacs anyhow one likes, that also increases the chances of one badly tweaking Emacs.
One should not blindly paste configs from other users; one should know exactly what their config is loading.
Most of those search results will talk about using M-x profiler-start which allows a user to understand what in their Emacs config is causing it to slow down (this exercise, which many people do not do, and just complain about it being slow).
If people find their Emacs slow, they should compare with how fast the emacs -Q (stock emacs with zero user config, but still fully functional) sessions are.
Emacs allows users to customize every aspect of their editor experience and that can be too easy to shoot in one's foot too.
While I doubt I disagree at all with @amalek's editor recommendations (brief aside - kakoune actually distributes a nim.kak though I don't know how well it works), it's also worth pushing back on the idea that lisp needs to be slow. Interpreters do tend to be, and interpreters of dynamic languages even more so, and I don't think vimscript executes very quickly. Compiled lisp, like Nim (or even Cython), can with a little "(declare) care" be roughly on par with C, depending on what one is doing. Of course, different languages have more or less "performance fragility" for lack of a standard term.
In terms of people having emacs-extensibility with less steep performance tradeoffs, there is this nascent effort https://tromey.com/blog/?p=982 It would be nice to see that go forward someday. Taking some 500 ms pause time down to 150 ms might make all the end-user difference necessary to really improve that experience.
I should perhaps also have mentioned that if emacs' garbage collection behavior was the real pause-time culprit for @amalek then that may not be any better with a JIT since the problem may be about memory loads more expensive than interpreter CPU cycles. https://cse.buffalo.edu/~mhertz/bc-pldi-2005.pdf has some answers, but only for the "last level caching" hard disks/SSD data in RAM. It's possible deeper cache (like L3/TLB) thrashing is behind some emacs GC pauses. It's likely that much of the perceived "slowness of Lisp" is about such GC-(hw|OS) impedence mismatches. That's not fundamental, though. Nim's GC usually works fine.
In my limited experience almost no elisp packages (or users!) try to tune GC behavior, though maybe recently that's been different (http://bling.github.io/blog/2016/01/18/why-are-you-changing-gc-cons-threshold/). My personal guess is that optimal settings are probably dynamic, related to competition for L3, and should not be some fixed 800kB number. Maybe @Kaushalmodi knows? Anyway, editor performance tuning is a bit off the main thread topic.
Wasn't Vim the name of some detergent at one time?
My Emacs takes about 20 seconds to start up.... but when it does, its amazing..... better than detergent anyway ;-) Hehehe