1) VSCode is very UI heavy and doesn’t allow consistent keyboard and text navigation. I want my text editor to be text-based, and it slows me down to have different types of windows (some of which seem impossible to hide permanently) with inconsistent forms of navigation.
2) The terminal window is its own thing, even if you open it in an editor window, which is then ignored by anything that interacts with the terminal. This is more what I want but is very limited and immature:
https://marketplace.visualstudio.com/items?itemName=jeffgran...
The lack of an infrastructure like Emacs comint mode also means there’s no good text-based database mode either. I want the same navigation, search and editing functions in every single window I have to interact with.
3) Where analogues to Emacs modes exist, they are universally less featureful, often because of fundamental limitations of the VSCode extension API. REPLs do less and offer less programmability. Edamagit is a fine and welcome effort but not as good as Magit.
If people want an editor with a little bit of auto completion and some squiggly lines to tell them they’ve typed something wrong VSCode is great. I have many mostly happy VSCode users within my organisation. But I think every individual programmer, like every team, should have a regular little retrospectives with themselves. What work did I do today, what would have made it flow better? In every case, I can build that in Emacs, but it’s much more friction in VSCode. This is partly immaturity and partly the APIs not offering as much. Long term I’m rooting for VSCode because it’s snappy and has undeniable market share. But it’s never quite been there for me yet.
The only time I ever had to use vscode working with other programmers was for pair programming, using the vscode sharing thing. Apart for that, not being able to use emacs would be a deal breaker - using other editors is like wading through quicksand for me.
It's not just the code, we'd want everyone on the team to use the appropriate toolsets including debugging and error checking support. They can set it up in Vim and Emacs if they want but it saves time for the team as a whole if we all use a standardized set of tools.
It takes weeks (at least) using emacs/vim until text editing/movement starts to pay off. There's no learning curve for `M-x package-install`, but if there is some variable that needs to be customized, like the path to an executable or something, that's a whole rabbit hole to go down, and at some point you need to learn lisp or you'll waste a lot of time being confused by errors.
During the only programming course I took in college, one in which emacs was required, I spent as much time learning emacs as anything else (it was also the most valuable thing I learned so I'm grateful in the long run).
Completely agree: the entire company should be on a common, future-proof, extensible, free platform: Emacs!
I honestly don’t understand why anyone bothers wasting effort on any other editor.
Then again, I might pre-date the which editor to use and how to configure it era.
My point is you could configure all this stuff in Vim or Emacs but it's not as straightforward plus it wastes time when onboarding. We'd rather have an IDE like experience.
Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival.
Great tools are obvious in their base functionality and have optional additional layers that can be discovered if necessary. When you have to search the web to find out how to close the editor you just opened, because it works differently than every other program running on your system, you know you're using a bad tool.
It’s wonderful and beautiful that we can get real work done with a heavy thing on a stick, but pretending every tool can be as simple as a hammer is not really arguing in good faith.
You mean like a nail gun? The kind that all professional roofers use?
And even the hammer metaphor falls apart pretty quickly: compressor driven nail guns are commonly used.
VSCode is obviously has something going for it, else so many people wouldn't be using it. Vi and Emacs are also extremely popular and have been for decades.
> Wrong. Good tools don't require that.
No, good tools absolutely require learning how to use them.
To think that they don't is a maddening take because it has led to the infantilization of applications in so many areas of the software world.
There is definitely a place for simplistic tools that have no customization, no configuration, a single limited way to do anything and no hooks/APIs to modify their internal behavior. Yes, such tools are easiest to pick up and casually use in the limited way they can be used and that's often all that is needed.
But, the world also need professional tools. In the non-software world this is obvious and such tools exist in every profession. Even your hammer example is wrong as the sibling post noted, there are "professional hammers" (nail guns) that require a bit more care to use but are much better.
There is a place for test lights (that anyone can touch to a wire to see if there's voltage). But we can also buy voltage meters of increasing complexity and capabilities. They start to require a little bit of understanding of volts and amps and ohms, but they are so much more useful. But yes you need to learn a little to use them. There are also things like oscilloscopes which an untrained person wouldn't stand a chance to know how to use at first sight. But of course they are vastly more useful once you learn the tool.
Just one random example of thousands. Yes, good tools absolutely require training.
And that’s before you go into all the other technologies invented that are evolutions of the hammer, from nail guns to jackhammers.
I use spectrum analyzers to identify partial discharges in high voltage equipment. Sometimes I use a hammer. One of them require deep knowledge, with the other one I just give the equipment a whack with to see where the fault lies.
> Wrong. Good tools don't require that.
So any tool that is complicated enough to use that it requires more than 5 minutes to understand can't be a good tool? That is just false.
Obviously vim is not the tool for you (and emacs probably isn't either). You don't like the way they work, so don't use them. They are not bad tools. They are both very good tools. They are just not tools that fit your preferences. They do fit other people's preferences.
I tried editing a txt document in vim one time. After gazing at the UI for much to long I had to ask for help because it wouldn't let me edit the txt.
I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.
They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.
I could certainly learn some of vim's functionality but there would be very little disk space left to write the software. I'm seriously more productive using MS notepad or nano. I can totally see myself forget how to engage edit mode in a week or 2. I'm having visuals of picard ordering enterprise to engage
All i need is a shuttle!
The edit mode feels like a child safety feature where I'm the child.
Human children flying Vulkan space ships, think about it.
If non of this makes sense, that is the whole point.
Have you considered that their tool is not necessarily made for you? You'd shudder at emacs yet there's still people there that really want it over vim and are more productive with it than most vim and vscode users.
>I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.
it's 1 key. It's not intuitive by default tho that's very much true.
>They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.
If you use a tool every day you're often expected to know a bit about it regardless of which one you use. The previous poster compared it to a hammer and someone else mentioned a nailgun. Similarly a an ax is simple but a chainsaw used more plenty by my father...but he knows how to replace and fix the chain, And even beyond that a nailgun and chainsaw are simple simple machines compared to the tooling you'll find in many workshops. If you processed wood professionally you'd use room filling machinery instead to make boatloads of planks and whatnot in no time.
The thing is. Much of these issues one would encounter with em and things to know them are relatively simple and easy on their own... But seem difficult if you don't know. They're pretty easy to forget if you do it once. But if you've done it dozens of times you just know. Knowing these things doesn't impact the person's ability to learn other related things much. How a new kind of wood to cut behaves or whatever in the same way that remembering that new face and name doesn't obviously directly makes me forget my existing coworkers.
of course it could always be more conplex but there is no need to expose that in the ui by default
I don't feel like i have proficiency in a language until i have forced myself to speed run a few projects in it. The ideas are important, but it is the ingrained habits that keep the code clean and consistent.
I mean if you don't want to spend so much time studying a given profession, of course. But the neural positioning of generating this text, or transform this text' is different than the neural positioning of 'should this call to this new to me gRPC server be blocking? Timeout? Retries?'
The latter takes thorough focus. the former can be done by muscle memory with practise, and the limit is more on how many new things your fingers can learn in a month, the total of learned things can be quite high.