When 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…
Why is it so hard to see code from 5 minutes ago?
341–350 of 424 posts
Re: Why is it so hard to see code from 5 minutes ago?
#342Re: Why is it so hard to see code from 5 minutes ago?
#343Earlier quoted context omitted.
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…
Re: Why is it so hard to see code from 5 minutes ago?
#344Earlier 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…
These are usually called feature branches.
> "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c".
These are very poor commit messages that don't add anything of value; any diff viewer will tell you the same immediately, so you might as well leave it blank.
> Commiting frequently also has a substantial cost of needing to think of a commit message.
In larger, private feature branches I'll use loads of "asdf" commits that I will later squash together. These are my "ok, so far so good" points to make figuring out where I broke something easier.
Re: Why is it so hard to see code from 5 minutes ago?
#345When 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…
Re: Why is it so hard to see code from 5 minutes ago?
#346My favorite IntelliJ feature is that it tracks the full history of the files in your project, losslessly and independently from your VCS. You can just go and pull source from Local history, from 5 minutes or 5 days ago (I'm not sure how far back it goes, I've never needed more than a week). Not something I use often but as a last ditch effort to find code that I've spent hours or days on and subsequently lost to a gi…
Re: Why is it so hard to see code from 5 minutes ago?
#347Earlier 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…
Re: Why is it so hard to see code from 5 minutes ago?
#348Earlier quoted context omitted.
Newb emacs user here. Heavily reliant on spacemacs and tutorials and copy-paste, but I use it often. The undo-tree terrifies me.
I was too at first, until I learned the shortcut keys (to move to the next branch specifically), then everything was fine.
More generally, for anyone new to Emacs and struggling as I once did, I can't recommend strongly enough that you learn how to use the help system (C-h C-h) and the built-in manual (M-x info). Emacs can teach you a great deal about itself, and these are the ways it does so.
Re: Why is it so hard to see code from 5 minutes ago?
#349Earlier 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.
In C, you can wrap the 'commented' code with #if 0 ... #endif
//*
old_code();
/*/
new_code();
//*/
And remove the first slash from the first line to switch between blocks.Re: Why is it so hard to see code from 5 minutes ago?
#350I think the issue is that the undo/redo concept is inadequate. The author's solution of a persistent, read-only history seems like a step in the right direction, but that seems like it's much too slow of a workflow to beat out CTRL+Z/Y/Shift+Z, which is muscle memory for most.
Maybe we need something like a hyper lightweight git that can be controlled via keystrokes.
It's really disappointing how so many interfaces have been stagnant for so long. It sometimes feels like the only software difference between a computer from 2021 and 2001 is that the graphics and animations look nicer, but otherwise is just more of the same stuff.