Why is it so hard to see code from 5 minutes ago? • Hacker News Board

Re: Why is it so hard to see code from 5 minutes ago?

#331

Post by wodenokoto » Fri, Feb 19, 2021, 2:27 PM UTC

caillou wrote: post #288

wodenokoto wrote: post #195

Earlier quoted context omitted.

There is a navigational back command, that moves your cursor back in time, just like a webbrowsers back button. cmd+-, if I remember correctly.

`ctrl + -` is a good short-cut. But, often times I have jumped around many times, or only scrolled. It doesn't work in these situations. Whereas `undo` `redo` reliably brings me back to the place of last input.

What ever works for you. To return to scroll position I click up then down or left then right.

You can use `ctr + -` to also jump between documents. So if you’ve jumped to a function definition in another document the back shortcut can take you there.

Re: Why is it so hard to see code from 5 minutes ago?

#332

Post by thunderrabbit » Fri, Feb 19, 2021, 2:31 PM UTC

dflock wrote: post #210

Before Microsoft bought GitHub and killed Atom, they were working on Xray[1] & Memo[2]: > Memo is an operation-based version control system that tracks changes at the level of individual keystrokes and synchronizes branches in real time. [1] https://github.com/atom-archive/xray [2] https://github.com/atom-archive/xray/tree/master/memo_core So, it would fix this problem, and also enable real-time collaborative editing…

M$ killed Atom??

It ostensibly seems fine, updated today. https://github.com/atom/atom

Re: Why is it so hard to see code from 5 minutes ago?

#333

Post by mthwsjc_ » Fri, Feb 19, 2021, 2:34 PM UTC

vim has a very versatile undo function, including undo the last n minutes/hours/days of edits. it also has undo branches. e.g. `:earlier 5m`

Re: Why is it so hard to see code from 5 minutes ago?

#334

Post by caymanjim » Fri, Feb 19, 2021, 2:35 PM UTC

wting wrote: post #71

stephen272 wrote: post #6

For anyone that uses emacs, there is an excellent plugin "undo-tree" that solves this problem in a slightly different way. Everytime you undo a series of actions and then perform a new action, it creates a branch in the "tree". You can then visualize the tree and move through it quickly your entire buffer history.

For those that use vim, gundo.vim visualizes the "undo-tree" and allows you to preview / jump to any revision: https://github.com/sjl/gundo.vim

Came here to post this. The undo tree is actually built into Vim, but I didn't know about it until I discovered Gundo a decade or so ago. I rarely use it, but it's still installed and has saved me hours of work on a few occasions.

Re: Why is it so hard to see code from 5 minutes ago?

#335

Post by cbm-vic-20 » Fri, Feb 19, 2021, 2:37 PM UTC

strken wrote: post #299

pharke wrote: post #253

Earlier quoted context omitted.

That's an insane approach, eslint solves this just fine and is fully configurable for almost any style preference.

All Go code everywhere never has unused variables, never has unused imports, and is formatted similarly. But, when you're debugging a function, you can't leave unused variables or imports lying around. It's a tradeoff. I don't think either side of the tradeoff is insane.

Sounds like a good argument for a --relax-im-just-trying-something flag for the go compiler, and taint the resulting code with it so if anyone else tries to use the code without the same flag, then the compiler/linker will complain.

Re: Why is it so hard to see code from 5 minutes ago?

#336

Post by samb1729 » Fri, Feb 19, 2021, 2:37 PM UTC

londons_explore wrote: post #328

sdevonoes wrote: post #320

Earlier quoted context omitted.

I do the same. Many people comment about commiting frequently but that doesn't work for me: delete code + commit => I don't see the code anymore and my brain magically forgets about it. I need the quick feedback loop: commented code + uncommented code (all in one screen) => new code is going to look like a mix of both. If I have to use git to see commented code then the feedback loop is broken.

Commiting frequently also has a substantial cost of needing to think of a commit message. If you don't think of a commit message, you'll never be able to find this version again. If you think up a message every 2 minutes, you'll quickly find you spend more time thinking of commit messages than writing code. I wish there was some kind of auto generated commit message. Things like: "Added function xyz()" or "Adjusted c…

> I wish there was some kind of auto generated commit message. Things like:

> "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c".

I would argue that these are not good commit messages as they do not add information not already provided by the diff itself. Commit messages should communicate the intended effect of a change that has been made, rather than being a lossy compression of a sequence of keystrokes.

Re: Why is it so hard to see code from 5 minutes ago?

#337

Post by [deleted] » Fri, Feb 19, 2021, 2:37 PM UTC

jfk13 wrote: post #265

jonnycomputer wrote: post #151

Earlier quoted context omitted.

As an aside, I think I wouldn't mind if a programming language would include two commenting syntaxes, one for ordinary comments, and another for commenting out. These are two very different use-cases, and distinguishing them syntactically might facilitate certain kinds of work-flows.

It's not a formal distinction, but in C++ code where all the ordinary comments use //, it can be handy to use /* ... */ to comment out a block. (Of course, if there's a stray /* ... */ comment already in the area to be commented out, this will fail. But an editor with appropriate syntax colouring can make that immediately apparent.)

[deleted]

Re: Why is it so hard to see code from 5 minutes ago?

#338

Post by FroshKiller » Fri, Feb 19, 2021, 2:43 PM UTC

londons_explore wrote: post #328

sdevonoes wrote: post #320

Earlier quoted context omitted.

I do the same. Many people comment about commiting frequently but that doesn't work for me: delete code + commit => I don't see the code anymore and my brain magically forgets about it. I need the quick feedback loop: commented code + uncommented code (all in one screen) => new code is going to look like a mix of both. If I have to use git to see commented code then the feedback loop is broken.

Commiting frequently also has a substantial cost of needing to think of a commit message. If you don't think of a commit message, you'll never be able to find this version again. If you think up a message every 2 minutes, you'll quickly find you spend more time thinking of commit messages than writing code. I wish there was some kind of auto generated commit message. Things like: "Added function xyz()" or "Adjusted c…

If you don't already know the commit message before you start writing the code, maybe you should wait to write the code.

Re: Why is it so hard to see code from 5 minutes ago?

#339

Post by zrobotics » Fri, Feb 19, 2021, 2:48 PM UTC

CobsterLock wrote: post #326

sdevonoes wrote: post #320

Earlier quoted context omitted.

I do the same. Many people comment about commiting frequently but that doesn't work for me: delete code + commit => I don't see the code anymore and my brain magically forgets about it. I need the quick feedback loop: commented code + uncommented code (all in one screen) => new code is going to look like a mix of both. If I have to use git to see commented code then the feedback loop is broken.

I get this for tracking down a bug or working on speeding a block up. But why does the unused code need to be committed? Yes it helps you with your one problem but it clutters the document with extra information for others. So I guess I phrased my question a little accusatory, commented out code is a pet-peeve of mine, but I'm still genuinely interested why the two different blocks need to be committed. Or i guess mo…

Maybe I misread the parent, but I don't think it was stated that the commented out code is committed.

FWIW, I also sometimes work this way; however I delete the commented out block when I'm finished. This is also a pet peeve of mine, the only time commented out blocks of code are acceptable is if the obvious way to write something introduces a bug or ignores an edge case. In that case, I also leave a note explaining not to refactor this section and explain why.

But especially while refactoring or fixing certain issues, I really find it helpful to have the prior version still present to compare against. If I have to commit while that commented code is still present, invariably my last commit message is along the lines of "removed commented code" or "cleaned comments for function XYZ". Especially since for these cases I also typically end up writing a comment once finished anyway. If there was something tricky enough happening that I was comparing against older code, likely there is something confusing enough happening that whoever is in the file next could also use some additional explanation that can only really be written once finished.

Re: Why is it so hard to see code from 5 minutes ago?

#340

Post by apocolyps6 » Fri, Feb 19, 2021, 2:50 PM UTC

jolmg wrote: post #16

> Why is it so hard to see code from 5 minutes ago while in the middle of a change? In vim you can do: :earlier 5m to see the code you had 5 minutes ago. > (1) If you go to a prior state and then make a new change, you can no longer redo and all those changes are lost. Vim makes a tree, so that doesn't happen with it. When you undo and make a new change, you're just making a new branch. u/Ctrl-r goes from leaf to tru…

> In vim, only stuff that changes the buffer is added to the undo tree.

There is also a command history, and jumplist (movement cursor position history) for things that don't go in the diff tree.