Coding without a code editor or IDE is unimaginable unless you use notepad.
Why not?
Run a program to write code, run a program to lint/fix code, run a program to compile/execute code, and run a program to debug code.
To elaborate:
Editor: vim
Terminal: Any terminal emulator available on my system (e.g. Terminal.app, GNOME Terminal, Windows Terminal, Blink.sh, Google Chrome Secure Shell, ...etc). I personally like cool-retro-term purely for aesthetics.
Theme: None (:syntax off in vim)
Font: Input Mono
Icon Theme: None (I have used exa --icons in the past)
Extensions: Any program in the terminal or shell scripts I write, like:
Shell aliases & scripts (to tie all of them together), for example:
I have a shell wrapper around grep, called gw, that allows me to store common patterns (e.g. URLs, IP addresses, ...etc) in a YAML config file so that I don't have to remember long regex patterns. This allows me to compose the functionality in any workflow (e.g. use it in tmux shortcuts, use it in other programs/scripts).
I have a script that uses gw to filter tmux buffers for any URL through fzf and open the selected URLs in the default browser. This script is also wired up to a tmux keyboard shortcut : Ctrl-b + Ctrl-u to quickly open any url from the terminal without having to manually copy/paste.
I have a project management workflow where I store all my projects in ${HOME}/Projects/ and a shell script open-project that enumerates through all the projects, filter them through fzf (command-line fuzzy finder), and open selected projects in new tmux windows. This script is wired up to a tmux keyboard shortcut: Ctrl-b + Ctrl-w to quickly open and start working on any project.
And so on...
And I am not excluded from enjoying modern dev-tooling, like LSP (via any number of vim plugins), auto-completion (via any number of vim plugins), or even GitHub Co-Pilot, if I want to.
And I get to bring all of this with me to any remote system, if I need to, either by scping my ${HOME}/.dotfiles to a remote server or by git cloning my dotfiles, which is convenient because all I need when I am out and about is an iPad (or iPhone) and Blink.sh to remote into my home servers, cloud servers, docker containers, or raspberry pi's.
Hopefully, this demonstrated that "code editor" or "IDE" is only 1 productivity tool in a toolkit and often times it is more restricted since tweaking the behavior is limited to the product or adding new functionality/capability comes with a high barrier-to-entry.
Run a program to write code, run a program to lint/fix code, run a program to compile/execute code, and run a program to debug code.
sounds quite tedious to me as I am quite used to using editors, though I occasionally use vim too, I agree with your last statement though, in the end they are just a productivity tool and depends on the editor itself to how much extent it can be customized/configured according to the user's wish.
sounds quite tedious to me as I am quite used to using editors
I certainly didn't start out my engineering career with Vim. I started with Atom, then Sublime, then VS Code, then IntelliJ IDEA Ultimate.
What led me to Vim was not Vim itself, but it was the flexibility of the terminal and how easy it was to compose programs to create new functionality and workflows that allowed me to be more productive than I was.
Slowly, over time, I started doing more in Vim and less in VSCode/IDEA.
Slowly, over time, I started creating scripts, CLIs, programs that improve my workflow and productivity.
It's fine if anyone prefers Code Editors and IDEs over text editors.
My goal was to demonstrate that coding without a code editor or IDE is somewhat imaginable.
Why not?
Run a program to write code, run a program to lint/fix code, run a program to compile/execute code, and run a program to debug code.
To elaborate:
:syntax offin vim)exa --iconsin the past)tmuxvimgo,cargo,node,python, ...etc.go fmt/goimports,cargo clippy,rustfmt,prettier,eslint, ...etc.gdb,delve,node --inspect, ...etc.curl,wuzz,httpie,curliejq,yq,dasel,xsvfind,ripgrep,fdddgrgit,gh,lazygit,pre-commitfzfterraform,kubectl,docker,devcontainers(from vscode)jira,gh issue,gh-i(ghextension)grep, calledgw, that allows me to store common patterns (e.g. URLs, IP addresses, ...etc) in a YAML config file so that I don't have to remember long regex patterns. This allows me to compose the functionality in any workflow (e.g. use it in tmux shortcuts, use it in other programs/scripts).gwto filter tmux buffers for any URL throughfzfand open the selected URLs in the default browser. This script is also wired up to a tmux keyboard shortcut : Ctrl-b + Ctrl-u to quickly open any url from the terminal without having to manually copy/paste.${HOME}/Projects/and a shell scriptopen-projectthat enumerates through all the projects, filter them throughfzf(command-line fuzzy finder), and open selected projects in new tmux windows. This script is wired up to a tmux keyboard shortcut: Ctrl-b + Ctrl-w to quickly open and start working on any project.And I am not excluded from enjoying modern dev-tooling, like LSP (via any number of vim plugins), auto-completion (via any number of vim plugins), or even GitHub Co-Pilot, if I want to.
And I get to bring all of this with me to any remote system, if I need to, either by
scping my${HOME}/.dotfilesto a remote server or by git cloning my dotfiles, which is convenient because all I need when I am out and about is an iPad (or iPhone) and Blink.sh to remote into my home servers, cloud servers, docker containers, or raspberry pi's.Hopefully, this demonstrated that "code editor" or "IDE" is only 1 productivity tool in a toolkit and often times it is more restricted since tweaking the behavior is limited to the product or adding new functionality/capability comes with a high barrier-to-entry.
sounds quite tedious to me as I am quite used to using editors, though I occasionally use vim too, I agree with your last statement though, in the end they are just a productivity tool and depends on the editor itself to how much extent it can be customized/configured according to the user's wish.
I certainly didn't start out my engineering career with Vim. I started with Atom, then Sublime, then VS Code, then IntelliJ IDEA Ultimate.
What led me to Vim was not Vim itself, but it was the flexibility of the terminal and how easy it was to compose programs to create new functionality and workflows that allowed me to be more productive than I was.
Slowly, over time, I started doing more in Vim and less in VSCode/IDEA.
Slowly, over time, I started creating scripts, CLIs, programs that improve my workflow and productivity.
It's fine if anyone prefers Code Editors and IDEs over text editors.
My goal was to demonstrate that coding without a code editor or IDE is somewhat imaginable.
Yes, I totally got your stand here, even I want to get deep into vim as its extensibility and customizability is literally endless.