Other Vim config for a specific task

doul

doul

Hello đź‘‹

Warning: this is the first time I’ve used Vim, so please be indulgent if my configuration looks basic or a bit odd. Thank you.

I use Geany to write C code and I’m very happy with it, but I ran into a task that Geany can’t handle: correcting spelling mistakes in comments and string literals. I tried some shell scripts, but they quickly became too complicated for me, so I thought I should find a tool that can do this properly — ideally in an interactive way.

That’s how I ended up with Vim + Hunspell.

Normally I work a lot with the mouse (around 80%), both in text editors and in CAD work, but for spell checking I find a keyboard-driven interface faster and more productive.

Attached file my `.vimrc` config for spell checking, ChatGPT5.2 generated ( 2 iterations ) + slightly modified by me.

My workflow is :
  • go to target directory
  • run vim
  • :args **/*.c **/.h to open all needed files
  • F9 to display bottom window with buffers list
  • ctrl-w + UP key go to code window
  • F5 toggle spell check on
  • :wqa when work is done
Left hand : navigation
  • F2 :bnext next buffer
  • shift-F2 :bprev previous buffer
  • F3 [s previous misspelled word
  • F4 ]s next misspelled word
Right hand : correction
  • F10 suggest word
  • F11 add to dictionary
  • F12 mark wrong
  • numpad select suggested word
Feel free to comment and share your .vimrc configurations for a specific task on editing, refactoring, ...

image(1).png
 

Attachments

May I slow you down a second and stear you down a more proper method for setting yourself up?

This is taken from my .vimrc and trimmed out a lot to show you how to set things up for yourself in a more organized fashion.

Any entry prefixed with a "-X- please stop and evaluate before uncommenting otherwise, please read over the settings and see if these make sense.

Next question: do you use Vim and GVim? if yes, then we need to also start you creating a .vimrc and a .gvimrc file.

Code: 
"---[ C / Cpp ]
    "--------------------------------------------------------------------
    " SetCCodingSettings()
    "  Sets style based settings like brace and paren settings.
    "--------------------------------------------------------------------
    function! SetCCodingSettings()                              "{{{
            " text width
            set tw=68

            " Manpages
            runtime ftplugin/man.vim
            nmap K <Plug>ManPreGetPage<CR>

            " Clang-Format
            "-X- map <C-L> :pyf $HOME/bin/clang-format.py<cr>
            "-X- imap <C-L> <c-o>:pyf $HOME/bin/clang-format.py<cr>
    endfunction "}}}
    "--------------------------------------------------------------------
    " SetCMakeSettings()
    "  Sets style based settings for CMakeLists.txt files.
    "--------------------------------------------------------------------
    function! SetCMakeSettings()                                "{{{
            set tabstop=4
    endfunction "}}}
    "--------------------------------------------------------------------
    " SetMakeSettings()
    "  Sets style based settings for makefiles.
    "--------------------------------------------------------------------
    function! SetMakeSettings()                                 "{{{
            set tabstop=4
            set noet
            set tw=69
    endfunction "}}}
    augroup CProgramming                                        "{{{
       " Establish some C programming language settings.
       autocmd BufNewFile,BufRead,BufEnter *.c,*.cc,*.cpp,*.h,*.hpp call SetCCodingSettings()
    
       " Establish some cmake file settings.
       autocmd BufNewFile,BufRead,BufEnter CMake*.txt,*.cmake call SetCMakeSettings()
    
       " Establish some makefile settings.
       autocmd BufNewFile,BufRead,BufEnter makefile,Makefile call SetMakeSettings()
    
       "-X- EXAMPLE TEMPLATES ...
       "-X- " For new files, we should use some basic templates
       "-X- autocmd BufNewFile readme.md 0r $HOME/.vim/templates/readme.md
       "-X- autocmd BufNewFile .gitignore 0r $HOME/.vim/templates/.gitignore
    
       "-X- autocmd BufNewFile *.c 0r $HOME/.vim/templates/c/main.c
       "-X- autocmd BufNewFile *.cpp 0r $HOME/.vim/templates/cpp/main.cpp
    augroup END     "}}}
 
The " is a comment prefix in Vim configs The {{{ is the start of a "fold" (the }}} is the end of a fold). So in a shell script it would be: #{{{ ... #}}} in C it would be //{{{ //}}}.

I have many, many vim things. My .vimrc is over a thousand lines. I have many functions and a few plugins I've written myself so I can't share it all.
 
Do you want to code in Vim? ...I think you're going to need some ctags stuff so you can bounce around the code files easier.
What build system do you use?

I don't really have enough information to make a next suggestion so the above is a guess. Does what I provided so far make sense?
 
doul said:
this is the first time I’ve used Vim
Click to expand...
What I wonder: Why did you not checked out emacs first?
Don't get me wrong: I am a Vim guy, and for sure I will not talk anyone out of Vim.
But before you even bother to setup your own .vimrc - copy a existing one, or a template from the internet, get one by AI, write it yourself - to work efficiently with Vim, you first need to learn its pretty different kind of usage.
You may decide to switch to vi/Vim, anyway. Okay. Good choice. But just because it provides a module you miss in Geany I find it a large step, even put the cart before the horse. If I had used Geany before, my first choice had been emacs, because its usage is way more like it, and even if I don't know really I bet emacs provides at least one module, that does what you want/need. :-/
 
Code: 
" --- Basic Settings ---
set number              " Show line numbers
set relativenumber      " Relative numbers for easy jumping
set shiftwidth=4        " Indent by 4 spaces
set tabstop=4           " Show tabs as 4 spaces
set expandtab           " Use spaces instead of tabs
set smartindent         " Auto-indent new lines
set termguicolors       " Enable 24-bit RGB colors
syntax on               " Enable syntax highlighting

" --- Plugins (vim-plug) ---
call plug#begin('~/.local/share/nvim/plugged')

" LSP and Completion
Plug 'neovim/nvim-lspconfig'            " Core LSP support
Plug 'williamboman/mason.nvim'          " LSP/DAP manager
Plug 'williamboman/mason-lspconfig.nvim'
Plug 'hrsh7th/nvim-cmp'                 " Completion engine
Plug 'hrsh7th/cmp-nvim-lsp'             " LSP source for nvim-cmp
Plug 'L3MON4D3/LuaSnip'                 " Snippet engine

" Treesitter for advanced highlighting
Plug 'nvim-treesitter/nvim-treesitter', {'do': ':TSUpdate'}

" Utility
Plug 'nvim-lua/plenary.nvim'            " Required for Telescope
Plug 'nvim-telescope/telescope.nvim'    " Fuzzy finder
Plug 'stevearc/conform.nvim'            " Auto-formatting

call plug#end()

" --- Lua Configuration Block ---
lua << EOF
-- 1. Setup Mason to manage clangd automatically
require("mason").setup()
require("mason-lspconfig").setup({
    ensure_installed = { "clangd" }
})

-- 2. Setup Completion (nvim-cmp)
local cmp = require('cmp')
cmp.setup({
  snippet = {
    expand = function(args) require('luasnip').lsp_expand(args.body) end,
  },
  mapping = cmp.mapping.preset.insert({
    ['<C-Space>'] = cmp.mapping.complete(),
    ['<CR>'] = cmp.mapping.confirm({ select = true }),
  }),
  sources = cmp.config.sources({
    { name = 'nvim_lsp' },
  })
})

-- 3. Setup C/C++ LSP (clangd)
local capabilities = require('cmp_nvim_lsp').default_capabilities()
require('lspconfig').clangd.setup({
    capabilities = capabilities,
    cmd = { "clangd", "--background-index", "--clang-tidy" }
})

-- 4. Setup Treesitter Highlighting
require('nvim-treesitter.configs').setup({
    ensure_installed = { "c", "cpp", "lua", "vim" },
    highlight = { enable = true },
})

-- 5. Auto-format on save using clang-format
require("conform").setup({
  formatters_by_ft = {
    cpp = { "clang-format" },
    c = { "clang-format" },
  },
  format_on_save = { timeout_ms = 500, lsp_fallback = true },
})
EOF

" --- Keybindings ---
nnoremap <leader>ff <cmd>Telescope find_files<cr>
nnoremap <leader>fg <cmd>Telescope live_grep<cr>
nnoremap gd <cmd>lua vim.lsp.buf.definition()<CR>
nnoremap K <cmd>lua vim.lsp.buf.hover()<CR>
 
JohnK said:
Do you want to code in Vim? ...I think you're going to need some ctags stuff so you can bounce around the code files easier.
Click to expand...
For the moment, I use Geany for writing and Vim for special tasks. In the future, I think I’ll use Vim more and Geany less. I’d like to use ctags to navigate through the code, for example to jump from a function call to its declaration or definition.

JohnK said:
What build system do you use?
Click to expand...
It's custom makefile that fully manages dependencies and workflow (backup, build, configuration, utility)

Maturin said:
What I wonder: Why did you not checked out emacs first?
Click to expand...
So yes, I did take a look at it, but only briefly as I don’t have much time. I started by using Vim a little, then I looked at Emacs, but it didn’t really appeal to me — I prefer Vim, which feels more "Unix minded" or "command line interface" for me. Maybe I’m wrong, but I had to make a choice when looking for an editor to complement Geany, I have to move forward with my project.

Maturin said:
But before you even bother to setup your own .vimrc
Click to expand...
I’m afraid it may already be too late. I did set up only a very basic Vim configuration, but it got the job done: around 100 source and documentation files processed quickly and with small issues due to my lack of experience. I think I picked up the basics of Vim fairly quickly; of course, better usage will come with more time and practice.
 
To use ctags, you navigate to the project root directory and call the program (simple syntax) to generate a tags file. You sound like you already know what you're doing with C and make so, I'll stop with the questions and let you adapt an example for your case.

In my setup I have this:
ACME
ACME/makefile
ACME/GNUmakefile <--(because I'm writing on my MacBook mostly)
ACME/doc
ACME/src

In my makefile I have the typical build targets.
In my GNUmakefile I have my ctags.
Code: 
.PHONY: tags
tags:
    @ctags -R .
the only reason I say is to stop you from creating a viml script to generate the tags. I did it that way for a while but its easier to use your build to do it.

I also showed you above so that I can say (you may also be interested in): I also created a version of the BSD ctags to produce a "hints" file for my code. the hints file is full of lines like:

inorea <expr> add_node Hints#ShowHint('add_node','static void add_node(NODE *node, NODE *cur_node) { - src/tree.c - 94 ')

This was before LSP and allowed me to show the function signature in Vim's command line when I typed "add_node" (in this example). Now you should know, my code works but I coded it fast and didn't account on all the things like "escaping escape chars" but if this sounds like something you want in the future let me know (but this gets into workflow--and also LSP may be better for you).
 
Here is a post where I carved out some of my C/Vim settings which I use. I made this so when I open a projects file "main.c" I can type " :make " in Vim. This code will locate the build (make, cmake, xmake) and adjust the Vim environment for building.

J

Solved Post in thread 'Neovim as an IDE/IDE alternatives for C, C++, C#, Python programming languages'

Below is some code to create a plugin for Vim that sets enviroment (better) for a C project. I have made this very modular so you can adopt this for different languanges or situations. This should work for simple makefile type projects as well as "out-of-source-build" projects like CMake.

To make this a plugin, place this in a file (assuming you set vim's `packpath` variable like I said above):
~/.vim/pack/plugins/start/cpp-devel-vim/plugin/cpp-devel-vim.vim

This code will:
1. When a file of ".c" is opened we search for a makefile (upwards from the current location).
If we do not...
  • Thanks
 
doul said:
So yes, I did take a look at it, but only briefly as I don’t have much time. I started by using Vim a little, then I looked at Emacs, but it didn’t really appeal to me — I prefer Vim, which feels more "Unix minded" or "command line interface" for me. Maybe I’m wrong, but I had to make a choice when looking for an editor to complement Geany, I have to move forward with my project.
Click to expand...
Good.
Vim is for sure not a bad choice.
To me by principle there are just two kinds of texteditors: vi[like] or somehow emacs-like. To me any editor can be assigned to either one of this families. Both differ strongly by their principal concept of usage. One cannot really say, one is better than the other. It's just the question, which concept suits one's work style best. But according to "move forward with projects" any editor needs to be learned well enough first before it can be used efficiently, and switching between those both families is a large step. When you first need both learning new habits while unlearning the others, a project's progress may slow down until I'm in - at least for me. :cool:
That's all I asked myself.
Keep on!
Enjoy Vim!
Good choice!
 
I've primarily been using GUI text editor for my programming tasks. You bet I knew about vi[m] and have for sure seen people talking about it here (and not only here) for years. But I never really decided to try it. I just didn't want to for whatever reason.

I don't know exactly why, but exactly after reading this post I finally decided to try and switch to it. After just about 1-2-3 days of practicing it, I now can do all the things I need to do (regarding text editing) and even more. That's a completely different approach and I like it. doul Thank you so much for writing this post, mate!
 
tembun said:
doul Thank you so much for writing this post, mate!
Click to expand...
Yes, that's cool. Honestly, I was reluctant for a long time to use a keyboard-driven text editor, but the more I use Vim, the more I want to learn it and keep using it. Thanks as well to JohnK for all the useful information đź‘Ť
 
I spent a full day testing a few IDEs and editors, and in the end I came back to Geany + Vim.

I realised I was actually looking for an “integrated environment”, but that was the wrong approach for me — my workflow is deliberately decomposed:
  • build: make in xterm
  • editing: Geany + plugins
  • focused editing: Vim (spell-checking, refactoring)
  • AI: ChatGPT in Firefox
  • version control: git (local) + Codeberg (remote)
By adding a few plugins to Geany (CodeNav, ctags, Project Organizer), I can navigate my whole codebase just as efficiently as in Vim — files, variables, functions, everything is reachable quickly.

I also use Make to launch Vim with the specific set of files I want to work on, which fits nicely into this toolchain-style workflow.

Code: 
################################################################################
# editors
################################################################################

# Generate tags
${TAGS_STAMP}: ${SRCS} ${SRCS_H} ${AUTOCODE_SRCS} ${AUTOCODE_SRCS_H}
    @ctags -f .tags ${SRCS}
    @ctags -f .tags -a ${SRCS_H}
    @ctags -f .tags -a ${AUTOCODE_SRCS}
    @ctags -f .tags -a ${AUTOCODE_SRCS_H}
    @touch ${TAGS_STAMP}

vim_all: ${TAGS_STAMP}
#@ [global] open Vim with all TaskMate sources files .c .h .mk (no autoCode)
    vim ${SRCS} ${SRCS_H} Makefile ${MK_FILES}
.PHONY: vim_all

vim_doc:
#@ [global] open Vim with all documentation files .md .txt
    vim ${DOCS}
.PHONY: vim_doc
 
doul said:
I spent a full day testing a few IDEs and editors, and in the end I came back to Geany + Vim.
Click to expand...
That's good.
There are two ways to go:
1. Pick something predefined.
Pro: No, or almost no effort for configuring is needed.
Con: You need to feel into and stick with the predifitions other chosen.
2. Pick something highly configurable.
Pro: You get the things suited to your needs exactly.
Con: You need to learn how to configure things, and configure them.

I also built my own "IDE":
A small script starts three terminal windows in my directory I'm currently working:
One on the right 90° turned monitor (see my setup a bit lower in the post) it starts automatically with an ls showing the files, and doing the compilation in, on the left turned one is Vim, horizontally splitted to edit the source file, and the lldb script, and on the center I run lldb. (I work in terminal, only; no gvim, just vim.)
But that's just as an example idea.
It's also recommandable to spend some time on chosing the right terminal font, and colorsettings for the terminal and the syntax highlighting in vim ~/.vimrc:
Code: 
[...]

" colorschemes under /usr/local/share/vim/vim91/colors/
" useful (to me): torte, industry, desert, lunaperche, sorbet, unokai, zaibatsu, catppuccin
colorscheme torte

[...]

You not only know what you want, but have specific ideas how things have to be exactly, while you checkout other things, and are not afraid to configure the things.
FreeBSD is absolutely your choice! :cool:
 
Maturin said:
You not only know what you want, but have specific ideas how things have to be exactly, while you checkout other things, and are not afraid to configure the things.
FreeBSD is absolutely your choice! :cool:
Click to expand...
Yes, clearly Unix is our IDE, it’s the toolchain spirit.

Far be it from me to criticise other approaches. I fully understand that for different projects or teams my setup wouldn’t be suitable at all, maybe especially for large “enterprise-style” object-oriented codebases where dedicated IDEs make perfect sense.

I’ve also been experimenting a bit with colours. I quite like the old-school green-on-black look of phosphor screens, though with a touch of colour here and there to keep things more modern and readable. My Vim window is dark green on a light grey background. I might even try a slightly heavier font, in any case, bright yellow TODOs are impossible to miss!

image(2).png
 
THAT'S an exemplary working environment. đź‘Ť

doul said:
Yes, clearly Unix is our IDE, it’s the toolchain spirit.

Far be it from me to criticise other approaches.
Click to expand...
That's the point exactly.

You either have a "one size fits all", a boilersuit, which actually suits nobody really.
Or you need something individually tailored for you.
Both is okay, and both have advantages and disadvantages.
And I like the idea one has a choice.
And I hate the idea there have to be as many boilersuits produced until everybody found the perfect match, which simply is impossible.
That's the core idea of Unix, as far as I see it: To provide 'modules', which can be combined for a higher task, so anybody can tailor their own solution, fitting the task, because that's the only way to get your working environment fitting perfectly your indiviual needs, so can work most efficiently.

Yeah, dark backgrounds with light text is less tireing for texteditors. I also figure that out myself everytime when I need to do some writing/reading on white BG. As you see most of the pros work with dark BGs.
Also dont use white FG on black BG, but add a bit color, not just syntax highlighting, I mean to use #060014 for background instead #000000 - reduce contrast is the idea.
For fonts first thing I look at is, if I can easily tell 1 from l, 0 from O, have cleary distinct paranthesis, etc, so I don't need to polish my glasses, and creep into the monitor every third line.🤓
(But obviously you already knew and did that.)🥸
 
You must log in or register to reply here.
Back
Top