jesseduffield

9 ms·

31.
by jesseduffield 3y ago
Author here, this made my day! Sounds like you and I share similar experiences with motivation. I'm glad you like lazygit, hopefully I can continue to keep it in high esteem :)
32.
Hard vs. Soft Line Wrap(martin-ueding.de)
1 points by jesseduffield 3y ago|0 comments
33.
by jesseduffield 3y ago
Thanks!
34.
by jesseduffield 3y ago
Whoops! I should have fact-checked that: I had it in my head that it was recent based on there being so much recent discussion of it online. I've updated the post
35.
Lazygit Turns 5: Musings on Git, TUIs, and open source(jesseduffield.com)
211 points by jesseduffield 3y ago|69 comments
36.
by jesseduffield 3y ago
Maintainer here, thanks for the shoutout! A new version just came out today https://github.com/jesseduffield/lazygit/releases/tag/v0.39.... In the next release we're adding worktree support: if you
37.
by jesseduffield 3y ago
Thanks for the feedback, I've been slack on documentation as more features have been added. Do you have a preference for tutorials? e.g. video or text?
38.
by jesseduffield 3y ago
Lazygit maintainer here: I've found myself in your shoes quite a bit (without the commit signing part) and a few weeks ago I put up a draft PR where if a file is selected, it highlights the commits that touch that file. Typically you w
39.
(How) do you use Git worktrees?
2 points by jesseduffield 3y ago|0 comments
40.
by jesseduffield 4y ago
Author of the post here: I've written a follow-up that addresses some of the rebuttals made in these comments: https://jesseduffield.com/Unless-Responses/ If I've neglected to address your specific criticism
41.
by jesseduffield 5y ago
After some thinking, I now see what you were talking about wrt code coverage, however again the same argument can be applied to higher levels of encapsulation and it's not obvious private methods are special.
42.
by jesseduffield 5y ago
> Private methods by definition are not an abstraction. A private method is indeed an abstraction. If you take a chunk of code and extract it out into a method, that's an abstraction, regardless of whether it's private or not.
43.
by jesseduffield 5y ago
I address this point in the post but I'll summarise here: Your argument is equally applicable to higher levels of encapsulation. If you have a class which is private to a package, then code coverage tells you nothing about whether that
44.
by jesseduffield 5y ago
To be clear, I was responding to the combined argument of the above comments: that you should split the class but not expose the extracted class in the public API. I agree that there are cases where we don't need to extract the class,
45.
by jesseduffield 5y ago
I see this as the main tension in the extracting-class viewpoint. Assuming your language allows it, you can extract out a class that's still private to the current package, meaning that the public API is unchanged. But there are still
46.
by jesseduffield 5y ago
I completely agree. The post became longer than I would have liked even without examples and didn't want to make it any longer with examples, though it would be a good basis for a follow-up post.
47.
by jesseduffield 5y ago
I agree with your point about the dangers of right/wrong thinking, though when I wrote that line I was specifically thinking about people who say we should never test private methods vs people we say we should always test private metho
48.
by jesseduffield 5y ago
Thanks for adding the stack trace. I've made a bug issue to track this https://github.com/jesseduffield/lazygit/issues/1601 and I'll take a look into it tonight. I'll need to dig into why our w
49.
by jesseduffield 5y ago
One of the largest pieces of feedback I've had is around displaying the actual git commands that lazygit runs so now there's a new panel that does exactly that, displayed by default. I find that works well for demystifying what&#x
50.
by jesseduffield 5y ago
Yeah I regret using pgup/pgdown for regular scrolling in the beginning. I'm gonna add keybindings for paging up and down properly (so that a user can remap those to pgup/pgdown) and I think down the line I might change that t
51.
by jesseduffield 5y ago
I found this chapter to be a good primer on DOD and how OO runs into trouble whenever changes need to be made
52.
Data Oriented Design – first chapter (2018)(dataorienteddesign.com)
67 points by jesseduffield 5y ago|19 comments
53.
by jesseduffield 5y ago
I've thought about this too: different people have different values and I think I've found myself in a situation where Go simply doesn't align with my values. I'm not claiming that Go's values are therefore wrong, j
54.
by jesseduffield 5y ago
Thanks for the feedback: I've found that most of the learning I've done has been thanks to feedback from reddit/hackernews so I'm very much dependent on it to know whether I'm off the mark. In terms of authoritative
55.
by jesseduffield 5y ago
the article itself compares Go's error handling to Rust's, so mentioning Rust in the comments is quite appropriate. Even if the article did not mention Rust, it makes no sense to evaluate a language's feature in a vacuum: com
56.
by jesseduffield 5y ago
I'm not sure what you mean when you say closed: the proposal is clearly open, and the latest comment asking if anybody has issues with the proposal has no downvotes. That sounds promising to me. At the very least, it's clear that
57.
by jesseduffield 5y ago
I see value in wrapping the error at the source, but I don't see the value in wrapping it beyond that point, unless there's there's genuinely new context to add at some boundary.
58.
by jesseduffield 5y ago
You can still be explicit without being verbose, as we've seen with rust's `?` operator
59.
by jesseduffield 5y ago
That definitely sounds like Rob Pike. As for changing how Go does error handling, there is actually a proposal in motion to do exactly this, with support among both devs and the language maintainers: https://github.com/golan
60.
by jesseduffield 5y ago
wrapping the error at the source is sensible, but if you need to pass the error five levels up before reaching the function that's actually responsible for handling it (e.g. retrying after a period), I find the wrapping becomes superfl

More ›