What I usually do is make a copy of the function that I'm working with and give it another name. Then i can compare both the contents and the result of the two functions.
Why is it so hard to see code from 5 minutes ago?
281–290 of 424 posts
Re: Why is it so hard to see code from 5 minutes ago?
#282> 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…
> Emacs similarly doesn't lose changes in this scenario, but instead of making a tree, it has a ring and undo is an action that can be undone. Emacs default undo system is really, really bad. Like worse than the "standard" one. But after installing the emacs undotree it becomes sane.
What is bad about it? It always goes back to the previous state, and if you want to skip previous undo states (so you don't undo an undo) you can use `M-x undo-only`.
Re: Why is it so hard to see code from 5 minutes ago?
#283When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew. I might copy-paste existing code (just to avoid stupid transcription errors). If its too large to see both what I'm writing, and the old code, at the same time, I just use two windows on the same file. This is relevant to writing fiction or non-fiction as well. For example, I didn't like this, so I com…
I do this, though it can get messy when I'm experimenting with multiple changes.
As an experiment recently I've taken to keeping snapshots of active work areas using rsync every minute that there are changes present - an automated full-tree version of "keeping copies of the file" that works for everything (images, word processor docs, ...) not just my code editor, avoids an accidental change when doing undo-redo "breaking" the redo buffer, and it survives explicit file closes which undo/redo buffers usually do not. There are two significant caveats: it only works at all if I save regularly while tinkering (or the editor auto-saves regularly), and it doesn't work for files mmap-ed or otherwise open-locked by the editing process. Not terribly efficient IO wise, and still wouldn't be with the improvements I know I could make but haven't got around to, but it has proven helpful at times and takes very little space for several days of snapshots most of the time (identical versions of the same file in each snapshot are hard-linked not duplicated).
Re: Why is it so hard to see code from 5 minutes ago?
#284> 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…
This seems cool. Is there an equivalent feature in emacs ?
Re: Why is it so hard to see code from 5 minutes ago?
#285For me "Local History" feature in WebStorm solves the issue. https://www.jetbrains.com/help/webstorm/local-history.html
I've found Local History on these JetBrains IDEs to be really helpful too. Particularly when combined with "Put Label" command (which I assign to a keyboard shortcut). This lets you insert a descriptive label info the stream of your local history snapshots (such as before you attempt something), so you can go straight to one of those labels and diff against current. Useful when you're trying out an approach with part…
It has even saved me when I managed to delete a file not checked in yet. Just recreate the file with the same name, and then local history is available (or possibly local history on the parent folder would find it as well)
Re: Why is it so hard to see code from 5 minutes ago?
#286> Why is it so hard to see code from 5 minutes ago?
Because you aren't using Vim: ":earlier 5m"
Re: Why is it so hard to see code from 5 minutes ago?
#287Earlier quoted context omitted.
Indeed it’s one of the reasons why I’m staying with JetBrains products. It’s really efficient, we can compare side by side the local history to understand where it went wrong all while keeping the git history clean. Because while I could do the same manually with git, when I’m in the flow thinking about/building/debugging a particular piece of code, moving out to select files to add to git and then filling a message…
It has also been in stock Eclipse since at least around 2010, when I started using it.
True so did I, for web development though I prefer Webstorm. I was thinking of VSCode
Re: Why is it so hard to see code from 5 minutes ago?
#288In Sublime Text I actually use a quick Undo-then-Redo to navigate , of all things. I'll be typing some code and realise I need to check whether the imports at the top of the file are correct. So I'll Cmd+Up (go to the top of the file) and see that yes, they are correct. Now I have to get back to where I was. A quick Cmd+Z,Cmd+Shift+Z does the trick - Undo (takes me back to the code I was editing, and undoes some of i…
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.
Re: Why is it so hard to see code from 5 minutes ago?
#289Earlier quoted context omitted.
> productivity of an employee by keystrokes, screen changes and # of commits. Aaargh, that's the most quality destroying metric possible.
The most easily gamed as well... I have no idea how these people thinking about introducing a metric to measure others don't realise that whenever that happens it just becomes another game. It really isn't that hard to know that through experience and a little bit of forethought.
The other day I introduced this idea to a team member.
We have a separate budget for "development" and "hardening" - these two are actually stages - one starts only after the other ends and that moment is already precisely scheduled. No QA team so far.
So we play this little game of delivering something, anything and allow ourselves to leave some details behind.
I know of multiple problems in my code which made it past review, because there's no incentive to block merging on grounds other than code style, and maybe some glaring issues.
My gut feeling is that this approach is more expensive.
Re: Why is it so hard to see code from 5 minutes ago?
#290In Git you don’t have to actually commit, you can use the staging area. It’s something I do rather often. I’m going to make a non-trivial change and I’m not sure if it’s the right approach, so I `git add -A` first, make my change, and then `git diff —-cached` to review it. This is especially useful when doing things like running formatting tools, so I can see what the tool just did. And it doesn’t require making any…
Even commits are malleable until you push them somewhere. I do this a lot - create commits of any meaningful checkpoint, then rearrange/squash/remove commits later that I don’t want , to create a well-formed commit that I push. Git stash can handle your use cases too, but commits are more powerful as they let you compose multiple pieces together
Trivia for you: git stash is actually storing the changes as a set of stacked commits on a hidden branch. You can even do a git log or amend on your stash, although the stash abstraction is pretty complicated under the hood.