mawww / kakoune

mawww's experiment for a better code editor
http://kakoune.org
The Unlicense
9.85k stars 711 forks source link

[REQUEST] Make homemade git buffers actionable with <ret> #5049

Closed lobre closed 7 months ago

lobre commented 9 months ago

Feature

As of now rc/tools/git.kak helps interact with git commands by defining new Kakoune commands such as :git log, :git status, :git show, ... That is great.

One of the nice behaviors is that when doing <ret> on a diff part of one of the git-created buffers, the user can directly open the corresponding file.

I like workflows when I save my scratch buffers for specific grep searches or git commands directly to files.

Let's start with grep. Imagine a web application where I have multiple controller classes spread around multiple files. I can search them with :grep "class Controller" and the results are shown in *grep*. As I want to keep those results around (I might want to search for something else in the meantime), I like to save my search results in a file with :w *grep-controllers*. Then to reuse those results, I just open the file and assign it the grep filetype with set buffer filetype grep (or automatically in my kak config with a hook). The grep.kak module is nicely put together so when setting the filetype of a file to grep, it directly applies the highlighters and the <ret> mapping.

However, this is not the case for git.kak. Let's say I want save the *git* buffer after having run this command (to see the history of a single file): :git log -p -- my-custom-file.txt. If I open the file again and try to apply the filetype git-log, I can see the colors because the highlighters are correctly applied. But <ret> is not mapped.

And I think that is sad as it blocks from having those kinds of workflows which I think are useful.

Digging a little bit more, I see that there is this parameter map_diff_goto_source=true which will determine if the <ret> mapping is activated or not. And this parameter is defined directly when executing kakoune git commands.

https://github.com/mawww/kakoune/blob/7f49395cf931b2af8a75ffb5319a8aa8c395ed8d/rc/tools/git.kak#L112

And this is not used nor called when the user just sets the filetype of a file to git-log. If this is changed so that just setting the filetype to git-log is enough to have all git-related behaviors, that would allow more custom workflows.

Usecase

Allow workflows where you simply set the filetype git-log on a homemade git file.

krobelus commented 9 months ago

I think it makes sense to map <ret> depending on filetype, not based on which commands where executed to create the buffer. Note that for git diff we set filetype diff but override the generic diff <ret> mapping with one that always uses the Git toplevel dir (not terribly important though). In future, git commands might set buffer-local variables for the $PWD (so things work better when there are multiple Git worktrees). So hand crafting a buffer might have some minor downsides.

I like to save my search results in a file with :w grep-controllers. Then to reuse those results, I just open the file and assign it the grep filetype with set buffer filetype grep

you can use :rename-buffer on the *grep* buffer instead

lobre commented 9 months ago

you can use :rename-buffer on the grep buffer instead

That is a nice tip (as long as you don't want to persist it to disk.

I think it makes sense to map depending on filetype, not based on which commands where executed to create the buffer.

I feel like it would be good practice too.

krobelus commented 7 months ago

I'm working on finding a solution here. I think a sensible approach is to use filetype=git for diff buffers. We already use it for git show buffers which are not much different.

lobre commented 7 months ago

I think that could be effectively a good idea and could lead to a cleaner approach.

krobelus commented 7 months ago

proposed fix is at https://lists.sr.ht/~mawww/kakoune/%3C20240202232729.1255728-5-aclopte@gmail.com%3E (it serves a larger series but can be extracted)