Probably because there is not a windows version :-)
Since only one person mentioned it, I thought I should give a plus one to howl.
I've been coding on my raspberry pi a lot lately, and it is perfect for that.
[https://howl.io](https://howl.io)/
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
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.
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
> 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
> 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
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
> 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,
I personally think vscode is nice
Thanks for the reply. I didn't know that their was a nim.kak.
Interesting story. I don't know how I would classify myself. I am a long time
Smalltalker. I have struggled entering the world of editors and have kind of
simply settled for a reasonable IDE/Editor rather than committing the time to
> Are you using the lsp plugin?
Nah, I'm going raw with just the
[nim.kak](https://github.com/mawww/kakoune/blob/master/rc/filetype/nim.kak)
file. The default "dirty" autocompletion of kakoune is good enough that you
don't really need intelligent completion.
As for whether you should learn
VSCode. There is a nice extension for Nim with debugging etc
I have been briefly exploring Kakoune. I like the idea of a less bloated
editor. Currently I have been using Atom. I have not yet really gotten into
Vim, or Emacs. I wish it were available for Android.
I don't see Nim support. Are you using the lsp plugin?
Thanks.
Neovim user here.
Unfortunately Kakoune is not available for Windows so that's not an option for
many users.
As for modal editors like vi being faster than Emacs...maybe, once you are in
the right mode... but having to check what mode you are in all the time (even
if you put mode changes on keys) will
> In Vim I have to press Esc to come out of Insert mode then Shift-; to get :
> then I have to enter w and finally press Enter then to carry on editing
> text I have to press I again is that right Vim users? WTF!
Ehm, no. You could just use the default shortcut: `ZQ`
Or, if you want to
Yep, but I can also map Ctrl-x Ctrl-s to just Ctrl-s in Emacs if I wanted...
but the default is fast enough... and Ctrl-s is mapped to search (another
common editing task) anyway.
And Emacs has macros that can be mapped to key strokes as well, so I cant see
any Vim advantage there. Emacs Lisp
You could map Ctrl-S to :w easily in your .vimrc But Space-W is faster, no
holding any keys down Space rules as leader
yea, but you can just map Ctrl-S to save if you save so much.
Typically vim keeps swap files and save the file state there periodically, so
you don't have to keep saving the file as you type. If the editor crashes, you
can re-open the file and the editor will ask to restore it.
The power of
Here is an example of Vim v Emacs.
Using default keys for both editors...
Saving the current file. something we do quite often
In Emacs I simply keep one finger on the Ctrl key and then press x followed by
s... file saved continue editing text
In Vim I have to press Esc to come out of
As I said at start of this thread ive been using Emacs for the past few months
and starting to get use to it... and ive just re-installed Vim to have another
look... and No, I still don't like this... press Esc then press I for
insert press Esc again blah blahcrazy... sometimes you
> I tried textadept but the autocompletion feature seems a litte bit buggy;
> notepad++ works fine but minimalistic; the intellij plugin seems not to be
> maintained so I still stick with vscode…
I tried Textadept myself a while back and didn't like it because as far as I
know it was only 32
I use VSCode but as luck would have it this week I tried Howl, Micro and Neovim
as well to find an alternative that exhaust less heat in my home? Unfortunately
they don't come close to VSCode when working on 2/3 codebases at the same time
(one with specs/tests, one with reference
I tried textadept but the autocompletion feature seems a litte bit buggy;
notepad++ works fine but minimalistic; the intellij plugin seems not to be
maintained so I still stick with vscode...
What does the Nim support in Geany cover?
Originally, I used a Nim plugin for Vim which gave me "only" syntax
highlighting, but now I don't want to miss completions and "go to definition".
I find this very helpful, especially since I'm rather new to Nim.
> what everyone else was using for writing Nim?
I think most people use [VScode](https://code.visualstudio.com), which has [a
great Nim
extension](https://marketplace.visualstudio.com/items?itemName=kosz78.nim).
The [Editor Support](https://github.com/nim-lang/Nim/wiki/Editor-Support) GH
wiki
> I used to use Vim, but @leorize made me change to nvim because he is still
> refusing to port his excellent nim.nvim plugin to vim8. (hint! hint!)
hahaha... that's definitely a good enough reason to stay with nvim! :-)
Keep them coming, its interesting to see what others are using.
I used to use Vim, but @leorize made me change to nvim because he is still
refusing to port his _excellent_ nim.nvim plugin to vim8. (hint! hint!)
I use the same combination. :-)
neovim with my own [nim.nvim](https://github.com/alaviss/nim.nvim).
Feature-wise, it should be on par with the VSCode plugin.
Oops, I was playing with the longlines.nim and did not run nimpretty on that
last modified version. But rest assured, that asdf was manually typed by me :D
VS Code with Nim Extension
I really like the git/diff tool in VS Code.
I don't usually customize much, all I really want is an easy to use editor
where I can type code and get auto completion. So for me it's sufficient.
VS Code with Nim Extension, never used any code editors before(i mostly dabble
into coding, was highly into game dev when i was 13, that died after 2 years, i
still dabble though Godot Engine another open source phenomenon). Whenever i
coded with a language i used an IDE, although i never
I did try VS Code, and I didn't like the JSON customisation files but mainly I
don't like its by Microsoft, because what do Microsoft do they update and
change everything and usually every week... not good if your trying to get used
to one editor.
VS Code with Nim plugin
Why, after using nimpretty longlines.nim do some of your lines have the extra
element ..."adsf" tagged onto the end the end of the array?
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](http://ix.io/1QnF) ), running
`nimpretty
kakoune. it has some lsp capabilities with 3rd party plugin, but both the
plugin and especially nimlsp are very underdeveloped.
That's cool... I don't like beautifiers myself, prefer to leave the code as I
have written it :-)
**vim**.
I don't have long lines because I run `nimpretty`.
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
> 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
Emacs slows down when you have long lines so not just with Nim.
I am using version 25.1
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.
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
48 matches
Mail list logo
