Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim Creep (2011)

rudism.com

Post reply on HN
Print view View original

151–160 of 169 posts

Re: Vim Creep (2011)

#151

Post by dmitriid »

lancebeet wrote: post #122
dmitriid wrote: post #92

Earlier quoted context omitted.

This was about three years ago, and the codebase was a huge Symfony project, in PHP. - IDEA understands bindings to Symfony's sprawling YAML configuration files. So jumping between PHP code using a config value and the YAML file defining the value is one shortcut/click away. And more, and more: https://www.jetbrains.com/help/phpstorm/symfony-support.html - Refactoring: even a small thing like renaming a variable, a m…

Thank you for taking the time. Regardless of what tools we choose ourselves I think it's very valuable to know what features are available and appreciated elsewhere. IDEA certainly has some impressive features.

No problem. IDEs quite deservedly have the reputation of bloated monstrosities, so people might be put off by them. Hoewver, these monstrosities often have a plethora of tools that you might not even know can exist unless you use one of those monstrosities :)

Re: Vim Creep (2011)

#152

Post by davesque »

pasabagi wrote: post #150
YesThatTom2 wrote: post #15

Truly a great story! Reminds me of this story... Two years ago I was collaborating with a coworker. Most of our time was in his office. I would look over his shoulder as he typed. He had recently adopted a new IDE and spent considerable time configuring it and learning its features. He was very proud of how productive it made him. Then one day we collaborated in my office instead. I use plain Unix tools, all independ…

I tried this approach for a while, and the thing I couldn't get my head around, is how do you undo mistakes? Like, you write a messed up sed command - are you supposed to revert your changes to the last git commit? Not make mistakes? If I could work out a way to make undo as seamless and full featured as undo in, say, vim, then I'd be a total convert. Is there such a way?

In all fairness, is there ever really a water tight abstraction for undoing things at the file system level like you're talking about? If I'm ever trying to do some magic in a Unix-like environment, I usually always make sure that I'm using "dry run" mode if it's available or running the command against files that are in version control. On top of that, it's also essential to invest a reasonable amount of time into ensuring that the command won't run amok and start following symlinks or something like that. These are habits you have to develop if you want to operate at the command line level. IDEs often don't offer similar levels of power or control or the ability to cleanly undo large sets of changes like that.

Re: Vim Creep (2011)

#154

Post by hiq »

arendtio wrote: post #36
lunchladydoris wrote: post #26

Earlier quoted context omitted.

In case anyone else hasn't heard of or used :x > Like “:wq”, but write only when changes have been made. https://til.hashrocket.com/posts/2fdb6afb66-difference-betwe...

Some time ago, I read, that the usage of :x is discouraged, as the typo :X is easy to make and leads to encrypting the file accidentally.

Use neovim instead to solve this problem, :X has been removed (and you shouldn't use it in vim either anyway).

Re: Vim Creep (2011)

#155

Post by 0x008 »

DavidWoof wrote: post #83
barbs wrote: post #75

Earlier quoted context omitted.

I don't understand - how is using a debugger a waste of time? I don't often use a debugger, but they have proven to be useful in a lot of cases.

Not OP, and I think never using a debugger is silly, but IMO if I need a debugger to figure out a problem then I'm missing either sufficient unit tests or sufficient logging, and spending my time on that rather than in the debugger will aid future devs as well. I do think the write/debug/edit cycle is a very, very slow way to program, and I have to admit I'm suspicious when somebody tells me they spend 90% their time…

I work with big data and have to solve a lot of problems in integration or by debugging again at the a live Systeme, which you simply cannot reproduce in local unit tests.

And sometimes running a single test takes like 7 minutes so I have to reduce the times I run it to save time which is why I tend to fix code in an interactive REPL in the debugger.

Re: Vim Creep (2011)

#156

Post by 0x008 »

enriquto wrote: post #69
0x008 wrote: post #62

Earlier quoted context omitted.

Yeah I always wonder who these people are for which the editor is a bottleneck and how they work or what they work on. 90% of my time is spent debugging, understanding legacy code and drawing trees or writing pseudo code on my notepad. The actual time I type stuff into an editor is like 10minutes per day.

Just a single data point, but as a matter of principle I never use a debugger. Any time spend inside the debugger is 100% lost and useless to other people. To study a code, it is best to copy it, run it, and keep adding assertions, comments, and logging infrastructure. Besides helping you to understand what the code does, all these changes are useful for other people who may need to understand the code in the future.

I feel like you and I work on very different types of code. If I tried to do what you suggest, I would be adding comments and assertions for days. Also I follow the school of thought that code should be self explanatory and comments should make statements about the trade offs you made from a business or systems design standpoint, not explain what the code is doing.

I feel like the approach you are taking is impossible with the I inherent complexity of the systems I work with and for me the only chance is to follow a trail of a data point through the system like in Hansel and Gretel and see what effects it has on certain objects in a debugger.

I don’t use the debugger to understand code, I use it to find out why my tests are failing, where in the system the faulty data point comes from and if the values in each step behave in a way that is acceptable.

The second big use case for me is exploring in the debugger REPL what would happen if I change value x to y or test lines of code before I put them in the unit test, because I can only run the test a limited number of times per day since it takes like 5 minutes to boot up. I have to be very careful not to waste computer cycles.

Re: Vim Creep (2011)

#157

Post by _0w8t »

ysavir wrote: post #43
_0w8t wrote: post #27

Earlier quoted context omitted.

Without plugins Visual Studio Code in principle is just an editor. Yet even without any plugins or language-specific support it still a better tool for development out-of-the-box than Vim or Emacs. It can quick open and search across a development tree with thousands of files with no configuration. So as an editor for config files and small projects Vim without plugins is OK. But that basic Vim experience just does n…

> One does need plugins with Vim for anything big. When a fresh shell tab is just a command-T/ctrl-T away, you don't need Vim to do any of these things in the first place. The point of Vim is that it's a text editor that lives in an environment where you can already accomplish everything other than text editing. VSCode is a text editor that uses plugins to bring other programs into VSCode. Vim is a text editor plugin…

The problem with basic Vim is that it does not support out-of-the-box tools that can run longer than an invocation of a single command, like language servers, project indexers, tree synchronizers etc. ctags etc. just does not scale. And on Windows and to lesser extent on Mac one needs that even for medium-sized projects.

Re: Vim Creep (2011)

#158

Post by horsawlarway »

antoineMoPa wrote: post #117
horsawlarway wrote: post #94

Earlier quoted context omitted.

I feel like your understanding of a debugger is very limited. To me - A debugger is the instrumentation you're talking about, but created by the language/runtime developers instead of having to be remade by you, poorly, for each new project. A good watch statement is a hell of a lot more useful than an assert - even though they both try to do the same thing. Not even touching the places where a debugger solves a prob…

It's weird to write the test after solving the problem. You should write the test before solving the problem to get the most benefit. You can then edit + compile + run test until the test pass and normally this is shorter than the "edit+compile+start app+replicate bug manually in application+debug" loop.

Depends on the bug - most times I'm breaking out the debugger it's because I have a timing/race condition somewhere, or an unexpected interaction with some other service/component.

Basically - the debugger is not a tool I use if the issue is clear and reproducible.

Those are also issues where it can be hard to write a correct test up front. Typically - tests are passing already, but we're seeing intermittant problems somewhere. Once we understand the interaction and the root of the problem, it's much easier to put a test in place.

Re: Vim Creep (2011)

#159

Post by pasabagi »

davesque wrote: post #152
pasabagi wrote: post #150

Earlier quoted context omitted.

I tried this approach for a while, and the thing I couldn't get my head around, is how do you undo mistakes? Like, you write a messed up sed command - are you supposed to revert your changes to the last git commit? Not make mistakes? If I could work out a way to make undo as seamless and full featured as undo in, say, vim, then I'd be a total convert. Is there such a way?

In all fairness, is there ever really a water tight abstraction for undoing things at the file system level like you're talking about? If I'm ever trying to do some magic in a Unix-like environment, I usually always make sure that I'm using "dry run" mode if it's available or running the command against files that are in version control. On top of that, it's also essential to invest a reasonable amount of time into e…

I don't know of one - that's kind of why I'm asking. I don't think it's at all unfeasible (I think ZFS might do it, never tried it out) and I think it would be an amazing development. I think the unix model of one-purpose programs helps collaboration, maintenance, and produces higher quality programs. I just also think that because they're working in an environment that allows pretty simplistic interop (streams of bytes) and generally provides no history of changes, they tend to be fragile when used in concert, and brutally unforgiving when used alone.

If you could undo stuff easily, suddenly the 'brutal, unforgiving' part goes away, and it would enable a much more relaxing, explorative atmosphere, while also meaning people don't have to do stuff like 'alias rm=mv -t ~/.Trash' or whatever.

Re: Vim Creep (2011)

#160

Post by dmitryminkovsky »

JNRowe wrote: post #138
dmitryminkovsky wrote: post #129

Earlier quoted context omitted.

Do you know if it’s possible in vim to show hover for an arbitrary selection? A visual selection?

Like many things in vim it depends on whether you wish to write it ;) You can define your own popup(:h bexpr) however you feel, including per-filetype or buffer. Instead of simply operating on the variables it defines to you can also work upon the selection by querying the register(:h quotestar) instead. As an example, I like displaying wordnet¹ popups when writing prose. Occasionally, I'll also dump diction² output…

Thank you! Will add this to my Vim to-do.
Post reply on HN