Vim on ¬ just serendipity 🍀

★ neovim: inline git hunk control

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 03 Jan 2026 15:41:21 -0300

♠ What is a hunk?

When comparing two files, diff finds sequences of lines common to both files, interspersed with groups of differing lines called hunks¹.

There are various ways to treat git hunks as first-class citizens, manipulating them one at a time – staging, unstaging, or reverting them.

The classic one is git add [-p | --patch]. Hit yes or no for each hunk, one by one:

% git add -p
diff --git a/Justfile b/Justfile
index bbb3779a9..70840a008 100755
--- a/Justfile
+++ b/Justfile
@@ -175,3 +175,6 @@ update-pre-commit:
 # Update JSON schemas
 update-json-schemas:
     pre-commit run -a update-json-schemas --hook-stage manual
+
+hello:
+    echo world
(1/1) Stage this hunk [y,n,q,a,d,e,p,P,?]?

There’s also git add [-i | --interactive]:

% git add -i

*** Commands ***
  1: status       2: update       3: revert       4: add untracked
  5: patch        6: diff         7: quit         8: help
What now>

It’s also possible to manage hunks via git TUIs (=from the terminal) such as:

…or graphically with IDEs with as VSCode.

An honorable mention also goes to git-crecord, which I originally discovered by looking for an open source alternative to Google’s Fig² interactive commit and split commands.

Now that you see how my mind is overloaded with many possibilities to manipulate git hunks, the natural follow-up question is: how to do so right from within our favorite text editor (vim)?

With classic vim, Tim Pope’s vim-fugitive is often touted as best-in-class (paired with vim-gitgutter). I use it occasionally. The workflow is as follows:

From an open file with modifications, run :GDiff (:GDiffsplit).
Proceed as you normally would in vimdiff. Use :diffget (do) and :diffput (dp) for each hunk. Use [c and ]c to navigate to the previous / next hunk.

Finally, we get to the meat of the post. Is there any workflow improvement in neovim, which I have recently switched to?

First of all, the familiar vim-fugitive workflow still works there.

Its evolution is gitsigns.nvim:

Git integration for buffers

Given the config below, the following becomes possible:

-- Git integration
{
'lewis6991/gitsigns.nvim',
config = function()
  require('gitsigns').setup({
    on_attach = function(bufnr)
      local gs = require('gitsigns')
      -- ]c / [c: next/prev hunk (falls back to default in diff mode)
      -- like git-gutter in vim
      vim.keymap.set('n', ']c', function()
        if vim.wo.diff then return ']c' end
        vim.schedule(function() gs.nav_hunk('next') end)
        return '<Ignore>'
      end, { expr = true, buffer = bufnr, desc = 'Next hunk' })
      vim.keymap.set('n', '[c', function()
        if vim.wo.diff then return '[c' end
        vim.schedule(function() gs.nav_hunk('prev') end)
        return '<Ignore>'
      end, { expr = true, buffer = bufnr, desc = 'Prev hunk' })
      vim.keymap.set('n', '<leader>s', gs.stage_hunk, { buffer = bufnr, desc = 'Stage hunk' })
      vim.keymap.set('n', '<leader>u', gs.reset_hunk, { buffer = bufnr, desc = 'Reset hunk' })
    end,
  })
end,
},
'tpope/vim-fugitive',

Use ]c and [c to navigate hunks (compatible with vim-gitgutter)
Use <leader>s (comma + s in my setup) to toggle staging/unstaging hunks.
Use <leader>u to do the equivalent of git checkout -- file for a single hunk.

The last two shortcuts are wherein the magic lives.

It is VERY convenient to choose what to stage/unstage/revert right from the nvim buffer I am currently editing. For fine-grained control, I can always use :Gdiff to perform hunk microsurgery.

Not to confound with hook. ↩︎
Internal mercurial VCS porcelain on top of Piper / google3. ↩︎

— § —

Reply via email

#bestof #dev #git #vim

★ vim → nvim

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 23 Dec 2025 12:14:33 -0300

♠ I am piloting a transition from vim to nvim.

Here is the least disruptive way I found to accomplish that.

First, install neovim.

brew install neovim

Now, create ~/.config/nvim/init.lua. I decided to populate it based on my original ~/.vimrc, without attempting to share configuration settings between the two.

Multiple iterations with a LLM agent helped it achieve a decent shape, removing redundant settings and replacing some native VimL plugins with Lua ones.

The result: init.lua.

Some notable changes:

switch the package manager from vim-plug to lazy.nvim
remove vim-sensible
rewrite just_one_space in Lua
use nvim native OSC52 for yanking text
vim-signify -> gitsigns
add autopairs
add telescope (fuzzy finder), replace fzf
add oil (file manager), incorporates some functionality of vidir from moreutils
remove vim-commentary, given native support for gc in neovim
lightline -> lualine
highlight yanked text natively, replace vim-highlightedyank
automkdir upon saving a file whose parent directory does not exist, replace vim-mkdir

Now make it frictionless to use nvim instead of vim:

commit 058433b9503477c8c162cac5eba191c704cb9361
Author: Thiago Perrotta <{redacted}>
Date:   Tue Dec 23 12:13:54 2025 -0300

    nvim

diff --git profile/.profile.d/env.sh profile/.profile.d/env.sh
index 1c6507e..c6117a9 100644
--- profile/.profile.d/env.sh
+++ profile/.profile.d/env.sh
@@ -10,4 +10,6 @@ path_munge "$HOME/.bin" "$HOME/bin" "$HOME/.local/bin"
 export CLICOLOR=1

 # Set preferred text editor.
+# nvim should be preferred to vim if it is installed.
 hash vim >/dev/null 2>&1 && export EDITOR="vim" VISUAL="vim"
+hash nvim >/dev/null 2>&1 && export EDITOR="nvim" VISUAL="nvim" && alias vim=nvim

We can still access vim with \vim (or unalias vim if needed).

Now let’s evaluate whether the nvim switch is worth it.

— § —

Reply via email

#bestof #dev #vim

j,k for navigation

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 21 Dec 2025 02:31:10 -0300

♠ I just added vim-style keybindings to this site.

Press j to go to the previous post (chronologically, going down the list ⬇️) and k to go to the next post (going up the list ⬆️)¹.

The boundary between general vs coding posts is respected.

I also added arrow keys (⬅️ for the previous post and ➡️ right for the next one). ↩︎

— § —

Reply via email

#dev #meta #vim

vim: spellchecker suggestions

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 02 Nov 2025 11:37:57 +0100

♠ Previously:

When you have the spellchecker from vim turned on (:set spell), it highlights words that are not in the dictionary.

It turns out vim¹ can also suggest corrections to these words.

:h z=:

z=   For the word under/after the cursor suggest correctly
     spelled words.  This also works to find alternatives
     for a word that is not highlighted as a bad word,
     e.g., when the word after it is bad.
     In Visual mode the highlighted text is taken as the
     word to be replaced.
     The results are sorted on similarity to the word being
     replaced.
     This may take a long time.  Hit CTRL-C when you get
     bored.

For example: take the word exampl. When pressing z=:

Change "exampl" to:
 1 "example"
 2 "example" < "exampl."
 3 "exam pl"
 4 "exempt"
 5 "exam Pl"
 6 "exam"

Upon pressing 1<Enter> it is automatically replaced.

Alternatively we can skip the suggestions and simply pick the first one right away with 1z=.

vim never ceases to amaze me. ↩︎

— § —

Reply via email

#dev #vim

vim: reflow current paragraph

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 08 Oct 2025 18:03:57 +0200

♠ Problem statement: Given a paragraph (lorem_ipsum.txt):

"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."

Reflow it in such a way each line does not exceed a certain number of characters, say, in the 72-80 range. The number is not important, so long as it is applied consistently and uniformly within a single file.

In the terminal we can achieve that with fmt(1):

% cat lorem_ipsum.txt
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."
thiago@thiagoperrotta-MacBook-Pro /tmp/thiago.perrotta-2025-10-08-eOaLRg
% fmt lorem_ipsum.txt
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
cupidatat non proident, sunt in culpa qui officia deserunt mollit anim
id est laborum."

We can also do it in-place (sponge(1) from moreutils):

% fmt lorem_ipsum.txt | sponge lorem_ipsum.txt
% cat lorem_ipsum.txt
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
cupidatat non proident, sunt in culpa qui officia deserunt mollit anim
id est laborum."

Can we do it within vim? Yes, with the following mapping:

nnoremap <silent> W <Esc>!ipfmt<Enter>

Translation:

<silent>: does not echo the mapping in the vim command line
<Esc>: switch to normal mode
!: !{motion}{filter} Filter {motion} text lines through the external program {filter}. (via :h !). — Not to confound this with :!: :!{cmd} Execute {cmd} with the shell. See also the 'shell' and 'shelltype' option. For the filter command, see |:range!|. (via :h :!)
ip: “inner paragraph” motion
fmt: the filter command
<Enter>: execute the command

Alternatively:

nnoremap <silent> Q gwip

Wherein :h gw:

gw{motion}	Format the lines that {motion} moves over.  Similar to
			|gq| but puts the cursor back at the same position in
			the text.  However, 'formatprg' and 'formatexpr' are
			not used.

One difference is that gw accounts for comment characters, whereas fmt does not. Example, given a .py (python) file:

# "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."

gw does:

# "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
# tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
# quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
# consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
# cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
# proident, sunt in culpa qui officia deserunt mollit anim id est laborum."

Whereas fmt does:

# "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip
ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur
sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt
mollit anim id est laborum."

— § —

Reply via email

#dev #vim

vim: remove trailing whitespace

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 16 Sep 2025 14:27:55 +0200

♠ A simple addition to remove all trailing whitespace from the current buffer by pressing ,t¹ (via):

% GIT_PAGER=cat git show
commit 1c22fcbc12ffd2cb3c40152d152d099c9a9b7f85 (HEAD -> master, origin/master, origin/HEAD)
Author: Thiago Perrotta <{redacted}>
Date:   Tue Sep 16 14:26:46 2025 +0200

    vim: remove trailing whitespace

diff --git vim/.vim/vimrc vim/.vim/vimrc
index 8cf33d8..004beda 100644
--- vim/.vim/vimrc
+++ vim/.vim/vimrc
@@ -60,6 +60,9 @@ nnoremap J gJ
 " Reflow current paragraph
 nnoremap <silent> Q gwip

+" Remove all trailing whitespace
+nnoremap <leader>t :let _s=@/<Bar>:%s/\s\+$//e<Bar>:let @/=_s<Bar><CR>
+
 " Always use vertical diff splits.
 set diffopt+=vertical

My leader key is mapped to ,. ↩︎

— § —

Reply via email

#dev #vim

vim: add word to spellchecker

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 26 Jul 2025 12:13:42 +0200

♠ When you have the spellchecker from vim turned on (:set spell), it highlights words that are not in the dictionary.

False positives will occasionally be flagged.

To add the current word under the cursor to the dictionary, hit zg. From the vim manual:

To add words to your own word list:

zg

Add word under the cursor as a good word to the first name in ‘spellfile’. A count may precede the command to indicate the entry in ‘spellfile’ to be used. A count of two uses the second entry.

Once you do so, you’ll see feedback text in the status bar:

Word 'hacky' added to ~/.vim/spell/en.utf-8.add

This file can be easily tracked in your dotfiles.

Word 'dotfiles' added to ~/.vim/spell/en.utf-8.add

— § —

Reply via email

#dev #serenity #vim

vim: join lines without producing a space

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 22 Jul 2025 11:50:28 +0200

♠ Here’s a common issue I have when blogging, when inserting a markdown link with vim. The edit progression is as follows, wherein | represents the cursor:

First, blank:

Then, type out the hyperlink label and prepare to insert the link:

[example](|
)

Now go to another buffer (window) and copy the link (with y + motion).

Go back to the original buffer and paste it with p:

[example](
|https://example.com/
)

Press kJ:

[example](| https://example.com/
)

Press J again:

[example](| https://example.com/)

J is for “join lines” (:help J).

Do you see the issue above? The first J inserts a space, the second one does not. This inconsistency is frustrating.

This vi stack exchange question seeks to address it:

The standard J command for joining lines replaces the newline character(s) with a space. It’s useful when editing ’literature’ but can be troublesome if I, say, edit a hex dump by hand if I forget to remove the superfluous space.

Is there a quick & easy method to join two lines without producing a space between them?

The standard recommendation is to use gJ to do so. From :help gJ:

Join [count] lines, with a minimum of two lines. Don’t insert or remove any spaces.

But it’s harder to memorize than simply J. Plus, it’s an extra keystroke. I’d rather unconditionally use J.

It turns out it’s possible to do so with a simple config setting, added to ~/.vimrc:

nnoremap J gJ

When repeating the original link insertion sequence, it yields the following result, as desired (no spaces anywhere!):

[example](|https://example.com/)

— § —

Reply via email

#dev #vim

pre-commit + vim integration

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 05 Jan 2025 01:46:06 -0300

♠ Is it possible to transparently invoke pre-commit in the background upon saving in vim (:w)?

Initially I found this Stack Overflow question, but it had no answer.

Digging a bit deeper I realized that I could do it with an autocmd:

autocmd BufWritePost * execute '! if [ -e $(git root)/.pre-commit-config.yaml >/dev/null 2>&1 ]; then pre-commit run; fi'

That trashes the screen upon completion. This can be resolved by invoking :redraw! afterwards:

autocmd BufWritePost * execute '! if [ -e $(git root)/.pre-commit-config.yaml >/dev/null 2>&1 ]; then pre-commit run; fi' | redraw!

We can be less intrusive by prepending silent! so that, even if the command fails, it doesn’t get in the way:

autocmd BufWritePost * silent! execute '! if [ -e $(git root)/.pre-commit-config.yaml >/dev/null 2>&1 ]; then pre-commit run; fi' | redraw!

And last but not least, ideally pre-commit should run only on the file associated with the current buffer. Pass --files to pre-commit with the % argument:

autocmd BufWritePost * silent! execute '! if [ -e $(git root)/.pre-commit-config.yaml >/dev/null 2>&1 ]; then pre-commit run --files %; fi' | redraw!

This approach works as intended. There’s a brief period in which you can see pre-commit running in the background. It’s arguable whether that’s a feature or a bug.

Ah, and git root is simply an alias in my ~/.gitconfig:

root = rev-parse --show-toplevel

Whenever there are pre-commit violations (e.g. end-of-file-fixer) they are applied inplace. There’s no need to run :e!.

This is bare, but I am happy.

Perhaps the only missing piece is to extend it in such a way it’s only executed in the repositories I opt into.

If this turns out to be too intrusive, I am thinking to switch to using a vim keymap e.g. <leader>p instead of an autocmd.

— § —

Reply via email

#dev #pre-commit #vim

Vim shortcuts everywhere

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 13 Nov 2014 12:03:07 -0300

♠ Recently I’ve been switching my mind and workflow from emacs keybindings to vim ones, so there is nothing better than being able to use those shortcut keys on as many applications as possible. Currently ones I’m trying include:

vim itself
emacs with evil-mode
firefox with vimperator (there’s an Arch package for it)
chromium with vimium
luakit (KISS web browsing)
tmux
i3 window manager

Edit: forgot this one:

zathura (PDF/PS/DJVU viewer)

And I’m pretty sure there is plenty more to find out.

— § —

Reply via email

#dev #legacy #vim

From Emacs to Vim – Chapter #2 – Philosophy

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 18 Oct 2014 23:47:21 -0300

♠ Previous post. Oh man, up to this point I am slightly disoriented about emacs shortcuts. It has been probably one month since I am using vim almost exclusively. I just use emacs to blog here and to use orgmode. Yes, I still know so many of Emacs shortcuts and keybindings that I can even recite them to you while I am dream. However, I am not practicing them so much as before, so they will probably fade away some time.

But I have used emacs for two years, so I won’t forget the basic commands, terminologies, functions and shortcuts, so no problem at all. Okay, so I’ve just finished reading Practical Vim. I super encourage you to buy the book and support its author, because this was (is!) a fantastic book! I also thanks Jason Ryan, forums and wiki admin from the Arch Linux community, for recommending the book. It is one of the reasons that made me commit myself to learn (and stick to) vim.

Now, in this post I’ll talk a little about the differences between emacs and vim. This is supposed to be an informal post, with information coming out of my head on-the-fly, so don’t expect much consistency or formality here. I’ll list a couple of topics/categories and tell you what text editor I most like in each of them.

IDE vs text editor #

Vim is not an IDE. I’ll repeat that. Vim is not an IDE. Vim is just a text editor. Don’t even try to make it a IDE. If you want a solid text editor to behave like an IDE, use and stick to Emacs. Emacs is not just a text editor; it is a full-featured text editor. Theoretically, it might be anything you want. There are no limits about the customizations you can do to extend emacs. The limit is the sky (actually, the memory of your current hardware).

I prefer vim here. For two years I tried to make emacs the perfect IDE. You can achieve good results with it (yeah, good ones!), however, it is best when you keep it simple. I like this aspect in vim, and now I understand why almost everyone of the Arch Linux community that I know prefer vim rather than emacs.

Vim is KISS. It is kiss in text editing. For example, vim defaults are very good; I can survive without a .vimrc. However, emacs defaults are terrible (from my point of view, and considering that I know it can be better). I simply cannot use emacs for much time without my .emacs file.

Emacs shortcuts mostly involve pressing <Control> or <Meta>, plus a letter or number key. Sometimes you have to do this (which I’ll call a chord) two or three times. For example, to quit emacs you press <C-x C-c>. Vim shortcuts usually involve only a few chars, but you have to switch to normal mode to activate them (most of the time, at least).

Now, which is better? That depends. From my point of view, emacs win in respect to speed. I usually issue a command faster in emacs than in vim. However, vim commands are better to navigate through text than emacs ones, because they are well integrated.

Furthermore, an extensive use of Emacs can lead to RSI (repetitive strain injury). Even Richard Stallman had it once. Vim commands are slightly less aggressive (in respect to the keyboard), so the health of your hands and fingers will benefit from them.

Some people also recommend the mapping of the caps lock key to <Esc> in vim, or to <Control> in Emacs. They claim that the caps lock key is not much used, so it is more useful when mapped to <Esc>/<Ctrl>. Well, I personally never accustomed myself to this convention. It has a natural problem of compatibility: every new computer you use won’t be configured this way. So I don’t find this very portable, and I don’t want to bring a .Xmodmap file everywhere.

So, who wins here? Emacs. However, remember what I’ve said: Emacs is faster, but it will hurt your fingers if you use it for prolonged hours.

Command-line #

Emacs command line wins. Sorry vim, that’s it. Short and clear. It is even more powerful with smex, ido and icomplete. At this point I don’t know any enhancement for the vim command line, but I have to say it is pretty good also. For now, I’m only using wildmenu. But emacs wins, period.

Movement of the cursor through a buffer #

Vim is better. Period. Like I’ve said before, it is very well integrated in this respect. You can switch your cursor to almost anywhere in your buffer with just a couple of keystrokes.

Now, in Emacs I am usually mechanical, and keep repeating myself. For example, if I want to go a few lines above, I’ll probably hit <C-u C-p> a couple of times. In vim, currently I press k a few times too, but this is due to lack of practice. There are faster ways of moving in vim than I am used to.

Buffer management #

The two editors are very decent in this regard. Since I am more used to Emacs, nowadays I find easier to manage emacs buffers; however, the vim way of navigating through them is pretty decent, so I won’t declare a winner in this category.

GUI (graphical user interface) #

It is almost impossible to use emacs for a couple of minutes if you are not using its X version. Its console version is just awful. In contrast, vim is perfect on the console, but I find gvim pretty bad (well, at least, I feel like I am editing the console when I used it: no relevant differences).

So the emacs GUI is better. It is probably even better on OS X, however I cannot confirm that right now.

Books #

Emacs books will usually teach you emacs lisp. It is very hard to learn about emacs without learning what is actually happening under its hood. When you realize that everything you do in emacs is just Emacs Lisp, you really find that very beautiful. A functional language being used for the greater good.

But this is also a problem: if you don’t care about elisp, you will probably get bored. Fast. Very fast.

Now, vim books usually teach you how vim commands are integrated with themselves and with vim itself. At least the books I’ve read up to today. This is better on a practical basis, when you want to quickly become good with it (you see, I already feel fluent in vim with just one month usage – I felt fluent in emacs only about a couple of months, and part of this reason was bad out-of-the-box defaults).

The point is: you don’t need to know about vimscript to actually get work done on vim. Therefore, vim books are better in respect to being pragmatic; buuuuut emacs books are better regarding teaching the inner workings of the editor, and how to program and extend it.

Out-of-the-box, better defaults #

Vim. vim. vim.

Ubiquity #

Vim. vim. vim. And vi. However, “micro emacses” such as mg (the program that Linus Torvalds uses) and zile are very good. But they are very basic, they are just micro text editors with emacs keystrokes; not much features.

One-line answers #

Color themes / colorschemes #

Emacs!

Plug-ins and extensibility #

Emacs is more extensible, but vim plug-ins give you less headache.

Communities #

There are more people using vim than emacs, but the emacs community is still good today. …and my creativity ran away now. Which additional topics do you believe that vim or emacs is better than its counterpart in? Comment.

— § —

Reply via email

#dev #legacy #vim

From Emacs to Vim - Chapter #1 - Vim plug-ins

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 06 Oct 2014 01:50:00 -0300

♠ This is the continuation of the first post. As you get the feeling and overview of vim, the first thing you’ll probably miss as a probable-soon-to-be-emacs-orphan (actually, not really, I’ve already told you I’m not going to abandon emacs – for example, this post is being written within it, with org2blog – (too many level of parenthesis, please help me!!)) are your customizations and custom plug-ins and extensions. A couple of google searches would bring me to projects like janus and vim bootstrap. Those look nice and I would probably appreciate them if I were a beginner. However, as a super user – if you read this statement as bragging, then you are probably not understanding the purpose of this mini series –, I like to be in control of the personalization and settings of my text editor. Right? So, I’ve chosen to control my own plug-ins. In other words: bottom-up instead of top-down. Now, the two state-of-the-art plug-in managers you’ll find out there to manage your vimscripts are vundle and pathogen. I began using Vundle, but after a few hours I realized that pathogen was KISS and superior. Period. Not that Vundle is bad. It looks (works) okay too; in this case it was simply a matter of personal choice. The way Vundle works is as follows: your .vimrc will be populated with several lines such as:

Plugin 'tpope/vim-surround'
Plugin 'username-from-github/repository-name'
Plugin 'matchit'
Plugin 'vimscript-name-from-vim-dot-org'
Plugin 'git://www.absolute-path-to-my-site-here.com/repository-name.git'

Then, you just have to install those plug-ins with a simple command:

:Plugin Install

Done. It is simple, yes, but I liked more the approach of pathogen: you maintain a git repository with your plug-ins. Each new plug-in is a git submodule within your repository. Yay, this means it is super-easy to set up and share your plug-ins with other people. This is exactly what I’ve done: you can peek out my vim repository here. Now, there is one super good advantage here over emacs. The cost of adding a new plug-in is practically zero. This has two meanings, actually:

vim start-up time is ridiculously fast. Even with a dozen plug-ins, I still don’t notice it. With emacs, if I don’t run it as a daemon, it is a nightmare: a couple of seconds (yeah, a couple of seconds is really a nightmare, not kidding) of start-up time.
I don’t even have to touch my .vimrc to add a new plug-in. I just have to clone a new repository into my $HOME/.vim/bundle folder. Period. With emacs, I have to continuously poke my .emacs file to add, remove and constantly tweak my extensions. Yeah, I’ve been doing that for a while, and it does provoke a lot of stress and anxiety. You already have to tolerate a little bit of RSI with emacs, so you don’t need more problems.

Now, don’t undermine my (our) dear Emacs! Emacs Lisp will (and will always be) superior to vimscript. I have no doubt of this fact and therefore I won’t even discuss it here. Emacs is much more extensible than vim. Okay, then what? You have to find a few plug-ins, right? In Emacs, most plug-ins with decent quality you might find will be available either on MELPA or Marmalade and, of course, on GitHub too. In vim, it looks like the home of scripts is the vim website itself ((1) and (2)) and GitHub. I couldn’t find a central repo or website hosting the majority of its plug-ins, as with emacs. However, there is vim-awesome, which indexes existing ones (this concept is like the ruby toolbox, godoc.org and Emacs paradox extension by Bruce Connor. I won’t discuss the plug-ins I’m using right now, however here is a snapshot of my $HOME/.vim/bundle directory at the time of this post (19 plug-ins, yay):

You Complete Me
ack.vim
ag.vim
ctrlp.vim
delimit Mate
nerdtree
syntastic
tagbar
vim-airline
vim-bufferline
vim-commentary
vim-easytags
vim-fugitive
vim-gitgutter
vim-markdown
vim-misc
vim-repeat
vim-sensible
vim-surround

Most of those have an emacs equivalent. Okay, I’m stopping here for now, until the next post :) Update: next post.

— § —

Reply via email

#dev #legacy #vim

From Emacs to Vim - Chapter #0

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 04 Oct 2014 15:55:56 -0300

♠ Hi there. This will probably become a new mini series. I begin by quoting Vanessa Da Mata:

É só isso Não tem mais jeito Acabou, boa sorte Não tenho o que dizer São só palavras E o que eu sinto Não mudará Tudo o que quer me dar É demais É pesado Não há paz Tudo o que quer de mim Irreais Expectativas Desleais

That’s it There’s no way It’s over, good luck I’ve nothing left to say It’s only words And what I feel Won’t change

[…]

Tudo o que quer me dar / Everything you want to give me É demais / It’s too much É pesado / It’s heavy Não há paz / There’s no peace

Upstream URL with lyrics. Now, a little bit of context. Two or three weeks ago I began learning vim. This is due to a lot of reasons: one of them is that vim is actively used by a lot of members of the Arch Linux community, and I usually am influenced about their tastes — what doesn’t mean that I will comply with everything, it is just a matter of trying new things.

Another reason is that I am actively learning new open source tools, and vim is definitely one of the most widespread and ubiquitous ones. I don’t need to provide statistical sources for that, do you agree? Vi is present everywhere, even on my Android. (Now, almost nobody uses vi anymore, however vi and vim are too much similar that for simple and rapid tasks usually annoying differences won’t even be noticed).

Another reason is that I never became 100% satisfied with Emacs. Hey, I like emacs very much, don’t get me wrong, however there were always some piece of completeness missing in it, so this puzzle never got finished. In particular, orgmode (an emacs task-manager-note-taker-and-everything mode) is a tool that I felt in loved with, and thanks to it I won’t completely remove emacs from my system; you should notice that orgmode is something very specific to emacs.

Although there are some tentatives on vim implementations, as far as I read, they are not very good (at least not compared to a vanilla, emacs orgmode). Okay, those are sufficient for now, but there are more reasons that will reveal themselves along the next posts.

Now, we should go back to the lyrics. I really love how this music is related to emacs; in particular:

Tudo o que quer me dar / Everything you want to give me É demais / It’s too much É pesado / It’s heavy Não há paz / There’s no peace

That’s is right. Emacs always was regarded to as the dinosaur, as the operating system of your computer, as the I-want-to-rule-all-your-workstation program. This has both its advantages and disadvantages, of course. The point with vim is that is tries to Keep it Simple. It will never be everything: it is only your text editor. Nothing more.

Well, although people will always try to write a Twitter Client for it and similar things, I feel it is not natural. No, IT IS NOT!! Now, with emacs, those things are pretty natural. It was created to be extended! (Emacs is described as the extensible text editor.)

Along the last two years, I’ve tested more than a hundred of add-ons and customizable pieces and bits for it: it is so cool how a functional language (Emacs Lisp) can improve a text editor. 2048 game, flappymacs, twitter client, mediawiki client, xkcd browser, RSS reader, calendar application (built-in), calculator (built-in), mail client … Yeah, emacs is everything! Maybe too much for me.

Now, this is the part that makes me feel a little sad: There’s no peace. Yeah, this is a problem. If you browse through my dotfiles repository on Github, more specifically, through its commit history, you’ll see that my _.emacs_ file is one of the files that most changed through the days. I am always editing something of it, and I am never completely 100% satisfied with the outcome.

Because it is to easy to tweak and customize almost every aspect of Emacs, this means it is also possible to customize some aspects that I should probably not even be bothering to (and I should probably not touch those ones). Now, this proved to be a problem…

Planned topics #

PROGRESS Emacs
- PROGRESS introduction, motivations, and so on
- TODO org2blog
- TODO functional programming, REPL and Emacs Lisp
- TODO keybindings, keystrokes and hotkeys paradise (or nightmare)
- TODO more org-mode goodness
- TODO lessons and overall learned discipline
- TODO about the awesome emacs community
- TODO emacs blogs and RSS out there?
- TODO evil-mode
- TODO Emacs on X vs Emacs on Console
- TODO Books and study sources on Emacs
TODO Vim
- TODO how a emacs user feels after being introduced to a modal text editor
- TODO keybindings and maps in different modes
- TODO gvim vs vim
- TODO vim community and resources?
- TODO editing text at the speed of thought, really?
- TODO books and study sources on vim
TODO Conclusions
- TODO Are text editors still relevant today, in a world of full-featured IDEs?

Whoa. I hope you might like this mini series and want to see some (or all!) of the above topics discussed. During it (please notice this comment won’t be repeated further on), feel free to leave out any comments about your specific experiences about vim or emacs. Also, you are encouraged to suggest me additional topics about my experience with emacs (and my soon-to-be-born experience with vim too), and even choose one of the above topics to I write about next. Until the next post! (For now, read this.) Update: next post.

— § —

Reply via email

#dev #legacy #vim

Vim on ¬ just serendipity 🍀

★ neovim: inline git hunk control

★ vim → nvim

j,k for navigation

vim: spellchecker suggestions

vim: reflow current paragraph

vim: remove trailing whitespace

vim: add word to spellchecker

vim: join lines without producing a space

pre-commit + vim integration

Vim shortcuts everywhere

From Emacs to Vim – Chapter #2 – Philosophy

IDE vs text editor #

Shortcuts / keystrokes / chords / modal text editor #

Command-line #

Movement of the cursor through a buffer #

Buffer management #

GUI (graphical user interface) #

Books #

Out-of-the-box, better defaults #

Ubiquity #

One-line answers #

Color themes / colorschemes #

Plug-ins and extensibility #

Communities #

From Emacs to Vim - Chapter #1 - Vim plug-ins

From Emacs to Vim - Chapter #0

Planned topics #