(untitled)

> Try learning CL because its cool > Finishes a really small project, made in vim (TM) > "Hmmm... vim kinda is like kicking dead whales down the beach for lisp..." > Try Emacs > Instantly gave up I know that Emacs is the way to go, but this thing is compatible with me, how can I write decent lisp code with (Neo)Vim or other editors? Just spawn a sbcl in a quick lisp project and that's it? I just want some tips, I don't know if using Makefiles is weird or not (but it still works, I'll keep using it if any better option appears)(USER WAS WARNED FOR THIS POST, You should always elaborate on your opinions rather than just spilling the soykaf.)

Seems like you give up too easily

>>40756 What part of emacs did you struggle with? If it's the keybindings, you might want to rebind them with evil mode https://github.com/emacs-evil/evil If you have a problem with Elisp then read An Introduction to Programming in Emacs Lisp https://www.gnu.org/software/emacs/manual/eintr.html and the GNU Emacs Lisp Reference Manual https://www.gnu.org/software/emacs/manual/elisp.html You don't have to read it inside out but it's a good starting point, I've also recently started using Emacs and these are my sources (along with some Emacs distributions that I skim through, e.g doom, spacemacs)

>>40760 Forgot to link this https://github.com/emacs-tw/awesome-emacs Just play around with packages and don't take it too seriously, if I would've I know I would've quit by now Emacs is really fun and also a good time killer (almost too good of a time killer, I play with my init.el during company time

If it doesn't work for you, give up; your time is better spent somewhere you could be productive in instead of forcing yourself to learn something you cannot comprehend for hundreds of hours. At the end of the day, you need a tool that fits you and your needs and don't let other nerds on this board tell you otherwise.

>>40756 Use a real IDE, like vscode. Stop falling for memes. Especially lisp, drop that soykaf asap LMAO and learn something that's actually used in the industry

>>40780 Emacs has a highly dedicated community so about everything that VSCode has, Emacs also does.

>>40780 I think you are too pragmatic about this. Sure, if you see programming only as a means to getting a job, it's probably better to learn the newest Javascript framework and work in VSCode and dare you to spend on a second on your time on personal project, that you actually like. However, if you have a genuine interest in programming and computers and do learn things out of curiosity and interest, I think Lisp is a good thing to learn. Common Lisp in particular with it's meta-programming and REPL, surely different to say C, Python or Java, and thus beneficial as a learning experience at worst and fun to program with if it's your thing, at best.

>>40783 This is not quite my experience. While it is true that the community is very dedicated, and that there are solutions for almost any problem, the community is nowhere as large or as active as VS Code. It can't. It's like saying NetBSD can support everything Windows can because it has a very dedicated community. The fact is, they don't even WANT to support everything Windows can. Having tried to migrate to Emacs from VS Code many times over the last 10 years, I always end up wanting to do something that the Emacs community considered "the wrong way", and facing the dilemma of altering my workflow, or going back to VS Code. My workflow wasn't even shaped by VS Code, by the way, but by Vim, which is what I used for many years.

>>40792 >the community is nowhere as large Obviously. >or as active as VS Code. lol. The average VSC (l)user is purely a consumer simply clicking "install" in the marketplace and wrangling some JSON config, while hacking Emacs even a little bit is done by most long term users at some point. I get that VSC is a good editor for most people, even with the startup time or all-around jankiness (my colleagues use it and the builtin terminal emulator soykafs itself constantly, compared to Emacs' eat/vterm), but modern Emacs is really good; definitely not perfect, but much better than what outsiders may think.

>>40780 >Get an AutoCAD license for your own use. Pen and paper is a meme. Drop that soykaf now, stop drawing whenever you want. Learn the tools that are actually used in the industry. This is what you sound like.

I would suggest reading through the vim docs on lisp, as it has support for the language dating all the way back to vi: https://vimdoc.sourceforge.net/htmldoc/options.html . we're not going to be able to give you a precise idea of what feels good to write lisp on vim with because we aren't you. but I can provide you with some ideas. If you want a complete IDE situation for writing lisp, i would suggest vlime ( https://github.com/vlime/vlime ). it's basically SLIME (a lisp REPL) for vim. another, similar solution might be slimv - https://www.vim.org/scripts/script.php?script_id=2531 . its another lisp REPL for vim. there's also a multi-language repl that seemingly attempts to be more vim-native called neoterm, that you could look into if it interests you. some smaller things you can do include adding a rainbow parentheses script to vim that makes parenthetical matching much easier. here is one script that's popular: https://github.com/junegunn/rainbow_parentheses.vim.git but you can find others. you can also add the paredit script although it's a part of slimv so there is no need if you choose to use that plugin. https://www.vim.org/scripts/script.php?script_id=3998 . a script that is NOT compatible with slimv, that provides auto-indentation is https://www.vim.org/scripts/script.php?script_id=2951 . it's very old though, and probably not worth it to use. A better idea might be to look into parinfer ( https://shaunlebron.github.io/parinfer/ ) which has a lot of useful, dynamic parenthesis adjustment based on indentation. you can set the following keybindings to highlight text inside matching parentheses (instead of simply the matching paren): vim nmap <a-key> m[%v%:sleep 350m<CR>`[ imap <a-key> <Esc>m[%v%:sleep 350m<CR>`[a there is also an old plugin to do this here: https://www.vim.org/scripts/script.php?script_id=1753 also, here's an ftplugin/lisp.vim i copied from a slimv user, some of the settings might be useful to you. vim set lw-=if set lw+=set-macro-character set lw+=set-dispatch-macro-character set lw+=block set lw+=defsetf set lw+=define-symbol-macro set lw+=prog inoremap <buffer> <C-\> lambda nnoremap <buffer> <Space> <C-w>p nmap <buffer><silent> == :call Scheme_indent_top_sexp()<cr> let g:slimv_browser_cmd = "firefox" " Indent a toplevel sexp. fun! Scheme_indent_top_sexp() let pos = getpos('.') silent! exec "normal! 99[(=%" call setpos('.', pos) endfun in other useful things, somebody made a ,hyperspec' (interactive access to the common lisp spec) for their nvim that is probably adaptable to your version of vim: https://aliquote.org/post/vim-and-lisp/ and finally, make sure to :set lisp. >>40780 >be me, vim user >hate lisp >be tired of the endless wars of emacs and vim >find thread about write lisp on vim >emacs users awaken and gather >decide to quickly step in >"now listen up lain. this emacs/vim soykaf isn't for professionals. if you want a real text editor for have job purposes, you should be using a REAL IDE like VS Code or BlueJ" >wagies who use VSCode come out of woodwork to wage slave >emacs users battle with VSCode glitterboys >thread has been completely derailed into general text editor war >OP question remains unanswered >no mention of vim because us vim users are above such immature conflict >mfw i have no face

>>40800 Wow, you're so kind. I wasn't expecting to start an editors wars right now, that wasn't my intention. I'll definitely take a look at your recommendations and try everything out. I'm currently using the commonlisp Tree Sitter plugin for the syntax, and the parenthesis doesn't scare me that much (I'm only beginning with the language, so I only have small problems/projects to deal with). Thanks again! >>40780 That was just childish, some of us still code for fun. And yeah, VS Code is a solid IDE (mine is customized from head to toe), but I still prefer Neovim because I can put anything that I really need, it's just a matter of figure out how to do that (which is the fun part of ricing/customization in general) >>40760 Thank you so much for the references. Thanks to the other Emacs hackers as well. I really respect the editor, it still confusing for me some of the configurations steps, there's a bunch of steps to setup Doom Emacs and with Neovim I just need to edit one file to get everything I want (at least with the lazy.nvim plugin manager). My point with the post was that I was having a "Lisp on Vim" problem, not a "Emacs's hard" one. I think I need to learn how my editor works in order to understand how to solve some plugin problems or customize further, maybe my skill issues with Emacs is just because I'm thinking with my rotted VS Code / Neovim / Vim brain, and Emacs is just too different. I don't know if really need to take the time to learn Emacs, because Neovim suits me for everything that I need and I'm not jealous for the Emacs hackers as well, so meh. That's my point with this small editor wars. But thanks again for the kindness.

>>40756 the Common Lisp Cookbook has pointers for setting up Vim or NeoVim >https://lispcookbook.github.io/cl-cookbook/editor-support.html I don't know if using emacs + evil + sly would be better approach, though?

>>40796 If you replaced "get an autocad" license with "go download blender", then yes, that is what I would sound like, and it'd be correct. >>40780 >>40783 >>40792 >>40794 I've switched to Helix since making that post and I prefer it to vscode but downloading dozens of plugins for emacs/vim just to match half of either's functionality is still a meme.

>>40843 neovim has one good use: laptops. Its far superior when you dont have a mouse. Downside is you need to invest time initially to learn keybinds.

>>40844 Helix and Kakoune have better keybinds/control schemes than Vim.

>>40850 you can setup any custom keybind config you want on vim/emacs. Though Im intentionally using vim default because that allows me to navigate any linux system. Learning multiple setups is too much mindfuck to bother with.

>>40844 I for one am an Emacs + Evil kind of person.

I didn't read this post but I just want to say I love emacs sm bros...

>>40806 >I don't know if using emacs + evil + sly would be better approach, though? It would be a win. I've created a small config that sets up Emacs for Common Lisp development. https://git.vern.cc/gg/me One of my favorite things about this config is its installation method. To install it, you load up the README.org and then `M-x org-babel-tangle`. That'll install everything into ~/.config/me/ and leave your default Emacs config alone. It also installs ~/.local/bin/me which will start Emacs using this config. Once you have this, you can just: M-x sly ...and you'll have a very good SBCL REPL avaiable to you. It is so much better than `rlwrap sbcl`. Also, being able to `C-c C-c` to evaluate the current top-level sexp is great. If you're writing CL, don't mess around. Just get on Emacs. Learn your way around paredit. Use sly. If you need vim keybindings, the README.org has instructions at the end to set that up also.

stop being such a sissy and learn to use GNU Emacs WITH the default keybindings. ;) keyboard has modifiers, so modes / modal editing is pointless. Keeping your hands together on homerow is unnatural!

>>40756 This was a while back, it would be neat with an update on how your setup ended up OP. >>42795 When I tried out emacs I ran into issues of some basic functionality being impossible to use with a non-US keyboard because of how some keys are entered with a modifier key rather than a plain keypress. Was a couple years ago so I don't remember what it was. Sure I could probably rebind it to something else, but then I'd also have to know what keys are already bound and all that so I don't bind it to something already configured. >>40852 It's not just a matter of basic keybinds though. Kakoune does (visible) selection then action to perform so you already know what'll be changed, while in vim you do action then what to do it onto YOLO mode. Can you configure vim to work like so? It also does away with visual mode, moving/extending selection being done in normal mode.

>>42815 >but then I'd also have to know what keys are already bound and all that so I don't bind it to something already configured. This is a legitimate problem many Emacs users deal with, but fortunately there's a good solution. https://melpa.org/#/free-keys https://github.com/Fuco1/free-keys ;; Install by adding this to your init.el (use-package free-keys :ensure t) When you want to know what keys are available to you at any given moment, `M-x free-keys`.

>>40794 >even with the startup time help me understand the startup time argument. i use both (n)vim and codium at work. i prefer the latter for big projects with many files i need to cross-reference and navigate between as it's less cumbersome. and that's why i never understood people's issue with its startup time. not only is it just like 5 seconds on my work machines, but once i opened it to work on a large project i don't need to open another instance for quite a while.

>>42818 >help me understand the startup time argument A typical old school unix developer's vim workflow started and stopped vim frequently, because it was so cheap to do. I don't think this is a good workflow for larger projects, but it was adequate for a long time back in the day. I think Emacs solved this problem sufficiently well with emacsclient. People who want to use that ephemeral start/stop workflow can still do it if you start Emacs as a daemon and then connect to it with emacsclient. (When you get sufficiently proficient with emacsclient, you don't even need tmux anymore, because Emacs can fulfill a similar long-lived role that can survive logouts).

>>40756 >>40800 I gave up on trying to make vim works for Lisps. I used a lot Chicken Scheme, then gave up on vim, because it isn't fit for that, even when you use vim8.1 stuff to spawn terminal next to the code inside a tmux session. I believe what made me change my mind was these simple facts that some consider obvious or common sense, but other don't. You pick your own tools. You should learn how to use them without complaining. Vim is a line editor, with plugins that allows you to manage other stuff like git and so on, so you don't loose your focus. But all it understands is lines. VSCode/IntelliJ is a GUI text editor, with all the bells and whistles to make you feel confortable in clown town. It is a tool, which comes with a lot of plugins, but you have to learn it, because that's what your coworkers are using, and you may have to use someone else's computer to do your job one day. It is valuable from some perspective: it can run on browsers, and browsers are everywhere nowadays. Still, I don't recall if they just took Tree Sitter and called the day. In the end, I see Emacs as a REPL that happens to have a way to write buffers to file and load files to buffer, but it still executes commands, and interprets Emacs Lisp functions in an effective way that allows you to process th buffer as certain data. For example, your CL sourcecode is seen as S-expressions not as lines of code, and allows you to move inside that code with meaningful jumps not just vim movements. But don't force youself into learning it. Read about it and understand how it works, before using it. Practice, and you will learn it.