krobelus

these have been fixed as of 4.4.0

Kakoune has network-transparency - you can run the editor server on a remote system and run editor clients locally, communicating only via Unix socket.

> You can effectively run whole development (LSP, docker, compiler, files) on remote like it is on your local machine.

the same is possible with any other editor that implements a client/server model, and it can be done without giving the server the ability to execute code on the client

Amazing project, very useful

you're probably using an old version

I use git autofixup; it was much better than git absorb last time I checked

> it doesn’t say anything when there was no match

that's what it should do

> it can be quite slow as things grown

How? All the slowness (on large repos) I've seen has been fixed.

> The main problem is that Git was built so that the commit message is the _email body_, meant to be read by everyone in the project.

I find this very hard to believe. Isn't it "everyone who is interested in the commit subject/files touched should read the body". Why would anyone else read immutable historical documentation?

> Even if you're _very good_ at Git, finding the correct invocation of "git blame" (is it "-w -C -C -C"? Or just _two_ dash C's?) to even find the right messages that are relevant to the code blocks you care about is not widely known and even if you find them, still only show the first line. Then you need to "git show" the identified commit SHA to get this long form message. There is just no good way to find this information, even if it's well written.

This sounds like you are joking. Any good IDE will be able to annotate each line with blame info, and show the diff at the press of a button. On such diffs, the IDE should allow recursive blaming on context/deleted lines. Tools like Tig allow exactly that.

GitHub certainly does make it hard to see commit messages, I give you that :)

> Hundreds of hours of amazing documentation from a true genius that almost nobody will ever appreciate. It's horrifying.

?? It's not like it was written for fun. This documentation attached to a commit exists to reduce the risk of accepting the patch from someone who might not be around in future, to fix any problems introduced. By disclosing all their relevant thoughts, the author shows their good intentions: they enable others to build on top of their work. If the author kept their thoughts to themselves they would gradually build up exclusive ownership of the code, which is often not a good idea. Also a commit message serves as proof of work, which can be important when there's too many patches. For commercial projects some of this is less important.

> Notice that both fzf and fzy ranked source/blender/makesdna/DNA_fileglobal_types.h higher than GNUMakefile. I believe this is because /make and _file in that path are on word boundaries and are ranked higher than UMakefile that is not on a word boundary.

The reason for prioritizing word boundaries is so that you can type "sln" to match "SomeLongName". So while you are improving one use case you are probably breaking another one. I'm not sure how VSCode ranks GNUmakefile first, maybe they prioritize exact substring matches. It's still a heuristic that can fail. The ugly part is that it's not part of the "best match" algorithm that finds a global optimum.

> It first attempts a match on the filename. If there is no match, it retries on the full candidate string

Kakoune does the same, see https://github.com/mawww/kakoune/blob/019fbc5439ad884f172c32...

> Strict path matching means that the path segments of the query token cannot overlap between path segments in the candidate.

nice

all the time. I use a terminal text editor (Kakoune) which works great. For some tools I needed to disable colors to improve contrast

A notable new feature: inside diff buffers (as created by ":git diff" for example) you can press Enter to jump to the source file.

The equivalent to "hg absorb" for Git is https://github.com/torbiak/git-autofixup

How about an external e-ink screen for your laptop? I do almost all my programming on a Dasung Paperlike.

> I don’t yet love how history works. Four months in, I still can’t get used to not having ctrl-r.

I think it's worth getting used to but there are plugins like fzf that implement ctrl-r

> `BROWSER=otherfunc aws sso login`

Aliases/functions are generally not visible in child processes. I guess it worked if the "aws" tool invoked BROWSER via a bash process that either sources aliases from a bashrc, or reads exported functions ("export -f otherfunc"). It would work for fish too if "aws" invoked BROWSER via fish (though fish doesn't need exporting, since functions are also loaded in non-interactive shells).

I recommend that you make otherfunc a script, then it will work everywhere (also with arbitrary wrappers like strace, gdb).

There are several tools for stacking patch series, here is a list: https://github.com/epage/git-stack/blob/main/docs/comparison...

The lack of canonicalization has caused us tons of trouble on an Angular app. Check out https://symflower.com/en/company/blog/2021/path-independent-... - you'll be laughing (or crying)

Sounds like a sensible mix. There is really no single silver bullet.

We at https://symflower.com/ are working on a product to generate unit tests. Unlike quickcheck/proptest we promise to find errors, even if they are unlikely (for example [this input](https://github.com/AltSysrq/proptest/blob/master/proptest/RE...) would be trivial for Symflower). Also, unlike fuzzing our technology is deterministic.

Here's one of our blog posts that explains the approach: https://symflower.com/en/company/blog/2021/symflower-finds-m...

200ms just for loading completions? :( fish avoids this with lazy-loading

> I want to be able to rebase the entire stack and have the tools work correctly.

<plug> https://github.com/krobelus/git-branchless/ </plug>

> resolving BS conflicts multiple times

For identical conflicts you can enable git rerere

I use https://git.sr.ht/~krobelus/git-branchless

> does its own analysis of your previous commits

Not really; you can pass any commit ref to git-autofixup, and it will create commits only for commits since that ref. So it's for the user to decide :)

I have looked at both but only used git-autofixup. Some observations:

- git-autofixup has a changelog

- git-autofixup includes sober, technical documentation that actually explains how it works. OTOH, git-absorb has a great elevator pitch for users that are not so familiar with Git.

- git-autofixup does not have unresolved bugs, unlike git-absorb

- git-absorb creates fixup commits for the last 10 commits, which seems really odd. It's better to use symbolic references like @{upstream}, but it looks like they dont' support this yet?

- git-autofixup is stable and mostly done software, while git-absorb has a sizeable list of todos

- git-autofixup is written in Perl (like some tools in Git itself), making it easier to install than git-absorb which uses Rust.

Then again, as author of this article, I'm obviously biased ;)