301–310 of 424 posts
My 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…
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…
I do the same - both commenting out and viewing the file in parallel at different spots - vim vertical splits are great for that. In fact, one of my colleagues remarked that he never thought to view the same file alongside itself when he saw me do that when we were pairing.
Earlier quoted context omitted.
> 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`.
[0]: https://www.autodesk.com/products/fusion-360/blog/wp-content...
My 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…
Personally I just use git for that. Even if I'm not 100% happy with some solution, I put it into a commit and then do subsequent improvements, or just remove it again entirely.
Clipboard manager allow you to store all clipboard history.
Thats not the best solution, but at least for me with it I able to copy some original and intermediate states of code few times and return to it anytime in the future.
Sad to see so much judgement in this thread from developers who can't fathom why others would need this. "Sounds like trial an error." "Develop a better memory." Programming is not black and white, there is no right or wrong way to do it. OP discovered a problem they had and wrote a solution for it, believing that others might need to solve the same problem. Clearly they were correct based on plenty of others chiming…
> the wrong way is not constructive. Well, open minded people can try other ways. Mine is sitting back and thinking instead of racing the keyboard to try out stuff until it works. Both ways (as I compare to my exclusively younger colleagues) reap results in about the same timespan, but I hardly type more than the actual code I need to type while my colleagues write and delete books ('iterate fast') in that time. It b…
Earlier quoted context omitted.
I used to work like that. Now I don't. (And I would advise against it.) Use version control, do lots of small of commits, use diff. Have a fast edit, build, test/run cycle. If you don't have it then spend the time setting it up.
My employer told me a 23-step code submission process, across five tools, that takes four days to run all the tests is fast enough. Is that fast enough?
> 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…
> > (3) There is no visual indicator of where you are are in your undo/redo history. > There might be plugins that somehow present this info in the interface. The undotree vim plugin [1] does this, and gives both the file at the time as well as a diff of what changed. [1]: https://github.com/mbbill/undotree
I was going to mention this plugin. I haven't fully mastered quickly jumping around in it, but it's one of those things that when it's useful, it's VERY useful.
