diff-hl and folded org headings

[Martinsos]

Hi, thanks for this great package!

I am using diff-hl in org buffers, and when heading is collapsed / folded, and there is a diff hunk in it, the following is true:

1. There is no visual mark of diff on the left fringe/margin, if there is a diff under the heading, in its content / subtree.
2. If I jump to it with diff-hl-next-hunk, I will end up at the end of the folded heading: heading won't unfold. If I want to get to hunk, I need to unfold the heading, do diff-hl-next-hunk again, and repeat that as many times needed to get to the correct depth.

I am guessing these are not bugs, just behaviour that was never implemented? Would it be interesting to implement it?

For (1), I guess we would have to aggregate changes below and show blue if it is a mix of them. I don't know difficult is this with the current implementation?

And for (2), I would assume we need to check if we are in a foldable thing, and unfold it if we are? Ideal if there is a general concept of this in emacs that org follows with its implemetnation, if not, I still think it might be worth implementing org-specific logic where we check if we are in org buffer and then unfold if needed, due to how prevalent org is in emacs.
Although, I do guess this one could be implement also by users as advice on diff-hl-next-hunk and also prev, where we expand the whoel subtree to the place where they jumped -> still sounds nicer to have it working out of the box.

Thanks a lot, curious what you think!

EDIT: I just realized that behaviour (2) is not diff-hl specific -> it is default behaviour in org mode when you jump to a char inside of a folded heading! So nothing to do here. As for solution for it, it seems reveal-mode is the best clean solution. Still curious about (1) though!

[dgutov]

Hi!

For (1), I guess we would have to aggregate changes below and show blue if it is a mix of them. I don't know difficult is this with the current implementation?

Might be not too difficult, but are you requesting or offering assistance? One needs to consult how code usually interacts with org headings. Then you iterate across its contents, decide on the color, and paint a new hunk marker over the fold.

Fair warning: contributions to Emacs frown on LLM generated code, and anything above 15 meaningful new lines requires signing copyright assignment to FSF.

As for solution for it, it seems reveal-mode is the best clean solution.

reveal-mode seems reasonable. Any specific issues with it?

[Martinsos]

are you requesting or offering assistance?

Not sure myself yet, was just trying to access the situation! I wasn't asking as much about the basic algorithm, that seems pretty straight forward (although thanks), instead the feature itself seemed as something obviously useful/missing to me, so I kind of half-assumed there is a reason why it wasn't implemented (be it problematic UX, or technical side) and was curious to find out what it might be. But sounds like there is no specific obstacle. I might give it a try if I feel again like I need it, but wouldn't promise anything yet, I am new to the codebase and would need to invest some proper time.

Fair warning: contributions to Emacs frown on LLM generated code, and anything above 15 meaningful new lines requires signing copyright assignment to FSF.

Makes sense! I am not one to come with slop PRs for now, still care quite a bit about the code I produce.

reveal-mode seems reasonable. Any specific issues with it?

Above in my message it was an EDIT because I found out about it while writing this issue itself. I have been using it now for a week or so and it does the job of opening the subtree you jump to, so that is great, but it also behaves a bit weird when you leave it and it suddenly closes, and some behaviour around that. There are some options to tweak so maybe that helps, I have to yet try. In any case, it is not diff-hl specific behaviour but a general thing, so nothing we should be considering here (although I am always curious how are others handling this).

[dgutov]

I am not one to come with slop PRs for now, still care quite a bit about the code I produce.

LLM might produce slop, or might produce something good, with appropriate guidance. The FSF and GNU projects aren't accepting either at the monent. Until the relevant internal discussions conclude and some people come to a decision.

So - good old bespoke code for us.

[Martinsos]

LLM might produce slop, or might produce something good, with appropriate guidance.

Yeah I agree, I didn't mean that I don't use AI at all, but that I don't let the slop become part of final result -> if I am using it, I make sure I fully understand what is happening + polish it to the state where I would arrive without AI.

The FSF and GNU projects aren't accepting either at the monent.

Ok thanks, I actually didn't catch that on the first read, makes sense!

So - good old bespoke code for us.

Hah yes, finally an excuse we have been looking for to not feel bad for writing it by hand.