incidentally, if you want empty hunk headers, you can do this at least in my version of git:
xfuncname = " " but idk why it works and i had had it commented out. On 11/21/22, Samuel Wales <samolog...@gmail.com> wrote: > p.s. hunk header munging does not unmingle [i.e. group changes by org > header in magit status buffer diffs] :(. but it is true that what i > want is some kind of preference given by magit to org entries as > demarcated by org headings. > > idk if what i want is in principle possible or not in standard diff or > git diff. that is, idk if they could be patched to accept an arg that > would allow you to specify that org entries should be preserved if > possible or something like that. > > great to know difftastic can in principle be coded to do what i want, > however. so maybe soetime you could tell git to use. > > org hunk headers are rather nice looking. on the other hand, it gets > the previous header, even if not the parent header. i think this is > why i had the impression that git was in principle incapable of org > hunk header text of the type i wanted. but hunk header text is not > something i use a lot. it's rather nice looking, but in some cases i > prefer empty hunk headers. > > On 11/12/22, Samuel Wales <samolog...@gmail.com> wrote: >> i have a very old version of Magit, for reasons I won't get into. >> Fancier diff settings might be differnet or not available. >> >> But something drives me crazy. Probably not too Org-related, but it >> might be. I just want to know why, is all. >> >> I have a 24k line org file, and it's not that complex wrt levels. 2 >> or 3 levels with odd stars only. various types of content. >> >> someplace in it, is an entry with a 234-item plain list. if i try to >> move this entry, and make no other changes, diff goes insane. if i >> try to refile this entry to a different org file, diff similarly goes >> insane, with the - part. only that change. >> >> ok, what it does is, intersperse or mingle entries. so suppose i want >> to stage this one tiny little change, namely moving one entry [the one >> with the large plain list] to a different location in the same file. >> even if i move it really distantly. >> >> i.e. i want to put the - and the + of the move to the staging area in >> magit. unstaged changes should then not have this file in it at all >> after the staging operations. >> >> then, basically, staged changes will have this move. >> >> as a user, i want diff to make this two hunks, a big - and a big +. >> but diff mingles parts of another entry or entries with this list, so >> that it is scattered all over the diff. to get the result i want >> requires tons of intra-hunk stage operations. at best. >> >> so, what aspect of diff or org is triggering this kind of behavior? >> what is it that diff needs to understand about org, or what minimality >> etc. settings does it want to create a better diff? >> >> i know org has lots of similar lines [e.g. planning headers with >> scheduled dates that are identical]. but still, this is a nontrivial >> size org file, with no other changes that i made. diff's insanity >> still occurs even if i move the entry distantly. >> >> i am of course aware of histogram, patience, etc. and that git diff >> has a few experimental choices of options. also long ago i read diff >> manual with its discussion of end of file beg of file and minimality >> with --minimal and all that stuff. >> >> however, here, though, i am mostly interested in specifically what >> diff's, or git diff's, or magit's, /deal/ is. in /this/ case. >> >> where does it get off doing that? everything else is the same, so why >> is it keying on the wrong thing? >> >> does it think i made the changes as it presents them, or does it go >> for some other goal like minimality or speed and not really care what >> i did? is it because it e.g. ignores end or beg of file or so? or is >> it getting confused by some line? >> >> i have of course heard of merge something or others. which presumably >> tell diff about the structure of files or so. like, the fact that the >> planning line always follows the header. or perhaps i am imagining >> this kind of tool. >> >> now, whether i can mitigte it is interesting /after/ that. my >> paleolithic magit version might not be capable, but still. >> >> -- >> The Kafka Pandemic >> >> A blog about science, health, human rights, and misopathy: >> https://thekafkapandemic.blogspot.com >> > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com