[OT] org and diff

[OT] org and diff

[Samuel Wales]

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

Re: [OT] org and diff

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> 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?

Most likely, the default git's grouping of chunks is not good enough for
your case.

I have the following in my ~/.gitconfig:

[diff "org"]
  xfuncname = "^(\\*+ +.*)$"

[core]
	attributesfile = /home/yantar92/.gitattributes

And ~/.gitattributes:

*.org   diff=org

This will help grouping changes under the same heading.

Source: https://protesilaos.com/codelog/2021-01-26-git-diff-hunk-elisp-org/

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [OT] org and diff

[Samuel Wales]

On 11/12/22, Ihor Radchenko <yantar92@posteo.net> wrote:
> I have the following in my ~/.gitconfig:
>
> [diff "org"]
>   xfuncname = "^(\\*+ +.*)$"
>
> [core]
> 	attributesfile = /home/yantar92/.gitattributes
>
> And ~/.gitattributes:
>
> *.org   diff=org

this looks interesting.  i thought this stuff was just for configuring
the helper text on the hunk headers that tell you what function the
hunk is in, kind of thing.  [which i thought there wasn't much you
could do with for org even in principle.]

however, i will try it to see if it actually changes the diff hunk contents.

>
> This will help grouping changes under the same heading.

i think this is what i want.

at least probably.

>
> Source: https://protesilaos.com/codelog/2021-01-26-git-diff-hunk-elisp-org/

idk why but this page is blank for me.  then if i try to disable
noscript restrictions, noscript says "This is a privileged page, whose
permissions cannot be configured".  so i guess the blog, or whatever
it is, is incompatible with my firefox-esr.


in addition, i encountered a broken org-capture extension problem with
your email post in gmail.  first i selected text, and i didn't get the
"captured" notification from the org-capture extension.  well, that's
probably firefox-esr's weird selection something or other.  selection
color and my black bg are simiar so i couldn't tell.  but nothing got
captured.

but then i selected it accurately and i /did/ get the captured
notification.  but nothing was captured to emacs.

and that is precisely the problem that is being discussed on a couple
of other ml threads: getting notified that capture from firefox
worked, reliably.  [the org-capture extension notifies you, but it
doesn't really know whether capture worked.]

>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [OT] org and diff

[Max Nikulin]

On 13/11/2022 13:06, Samuel Wales wrote:
> On 11/12/22, Ihor Radchenko wrote:
>> I have the following in my ~/.gitconfig:
>>
>> [diff "org"]
>>    xfuncname = "^(\\*+ +.*)$"

Thank you for sharing this. I was sure it should be possible, but I was 
not motivated enough to configure hunk headers for elisp and org. It 
seems even a shorter regexp works well
	xfuncname = "^\\*+ .*"

>> [core]
>> 	attributesfile = /home/yantar92/.gitattributes

Git may find ~/.config/git/attributes without explicit configuration

> this looks interesting.  i thought this stuff was just for configuring
> the helper text on the hunk headers that tell you what function the
> hunk is in, kind of thing.

I am unsure that it affects diff as well. Once I have experienced noisy 
diff on attempt to refile a subtree. Finally I did it by moving headings 
by small portions. It allowed to confirm changes during each steps.

>> Source: https://protesilaos.com/codelog/2021-01-26-git-diff-hunk-elisp-org/
> 
> idk why but this page is blank for me.  then if i try to disable
> noscript restrictions, noscript says "This is a privileged page, whose
> permissions cannot be configured".

Perhaps you were unlucky to fetch the page during server maintenance. 
Firefox-106 renders the page with active NoScript.

The approach is documented in the "Defining a custom hunk-header" 
section of gitattributes(5).

The value of the page is that it has a recipe for elisp (indented 
`cl-defstruct' is not handled though).

Re: [OT] org and diff

[Samuel Wales]

ugh.  i left out a probably significant fact that means i'd have to
rework the whole post which i can't do atm.

in /this particular example/ the file will actually still be there
after staging.  i forgot there are other changes in this concrete
example.  i am trying to clean up a set of magit changes that has this
kind of mingling, but not in the plain list.  as part of doing so, i
had the idea of getting this plain list out of the file entirely.
merely because i edit the plain list and don't want to make the diff
more complex by doing so.  the plain list is not part of the diff, and
i wanted to have it not re-enter the diff when i edit it.

when refiling the plain list entry created the same kind of chaos i
was trying to reduce, i thought to move it /within/ the file.  chaos.
so i moved it to near the beg.  chaos.  then at the end.  chaos.

so you can take the post as, not a specific example, but what causes
mingling in org with diff?  or something like that.

On 11/12/22, Samuel Wales <samologist@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

Re: [OT] org and diff

[Marcin Borkowski]

On 2022-11-13, at 06:15, Samuel Wales <samologist@gmail.com> wrote:

> But something drives me crazy.  Probably not too Org-related, but it
> might be.  I just want to know why, is all.
> [...] diff goes insane.

I think this is a known problem with diff, which is inherently
line-based and knows nothing about actual syntax of the underlying
language.

FWIW, if things like this happen to me (and they do happen a lot,
especially when I'm doing code review), I abandon diff and use
difftastic (https://difftastic.wilfred.me.uk/) instead.

Surprisingly, difftastic seems not to support Org syntax.

One question I'd ask is: how important a legible diff is to you?  I keep
my Org files in Git, too, but if /I/ know what was changed, I just don't
care about diff going nuts and I treat it as (more or less) Git's
internal implementation detail.

Just my 2cents (not too helpful, I'm afraid...)

-- 
Marcin Borkowski
http://mbork.pl

Re: [OT] org and diff

[Samuel Wales]

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 <samologist@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

Re: [OT] org and diff

[Samuel Wales]

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 <samologist@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 <samologist@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

Re: [OT] org and diff

[Samuel Wales]

marcin> One question I'd ask is: how important a legible diff is to
you?  I keep my Org files in Git, too, but if /I/ know what was
changed, I just don't care about diff going nuts and I treat it as
(more or less) Git's internal implementation detail.

for org, i mostly use git for reviewing changes.  it is only one step
more sophisticated than saving old and diffing.

i have lots of tools for improving diff, but this intermingling
problem is a showstopper in some cases, like right now where i have
spent months trying to make sense of months of changes to org files
that have not been entered into git.  i.e. i did not enter every few
days as normal.  i find reviewing changes to be valuable.  every once
in a while i discover data corruption or something that i forgot etc.

i wonder if diff, or difftastic, could be taught or postprocessed to
do merely one thing: try to preserve stuff between "^\\*+ ".  that is
probably too optimistic, but imagine a --preserve-between option.


On 11/21/22, Samuel Wales <samologist@gmail.com> wrote:
> 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 <samologist@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 <samologist@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
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [OT] org and diff

[Marcin Borkowski]

On 2022-12-17, at 03:06, Samuel Wales <samologist@gmail.com> wrote:

> marcin> One question I'd ask is: how important a legible diff is to
> you?  I keep my Org files in Git, too, but if /I/ know what was
> changed, I just don't care about diff going nuts and I treat it as
> (more or less) Git's internal implementation detail.
>
> for org, i mostly use git for reviewing changes.  it is only one step
> more sophisticated than saving old and diffing.
>
> i have lots of tools for improving diff, but this intermingling
> problem is a showstopper in some cases, like right now where i have
> spent months trying to make sense of months of changes to org files
> that have not been entered into git.  i.e. i did not enter every few

Well, "months of changes" seems tough.  I sometimes (rarely) have to
enter 2 days' worth of changes...  It requires discipline, but
discipline pays off in /so many areas of life/...

> days as normal.  i find reviewing changes to be valuable.  every once
> in a while i discover data corruption or something that i forgot etc.

Yes, same here.

> i wonder if diff, or difftastic, could be taught or postprocessed to
> do merely one thing: try to preserve stuff between "^\\*+ ".  that is
> probably too optimistic, but imagine a --preserve-between option.

I afraid so.  Difftastic does not support Org mode format.  However, the
tree-sitter page claims that Org parser is under way, so there's hope
(AFAIK difftastic uses tree-sitter under the hood).

Best,
mbork

-- 
Marcin Borkowski
http://mbork.pl

Re: [OT] org and diff

[Ihor Radchenko]

Marcin Borkowski <mbork@mbork.pl> writes:

> Well, "months of changes" seems tough.  I sometimes (rarely) have to
> enter 2 days' worth of changes...  It requires discipline, but
> discipline pays off in /so many areas of life/...

I have implemented several helpers that filter out uninteresting changes
from magit diff. See
https://github.com/yantar92/emacs-config/blob/master/config.org#auto-commit-trivial-changes-in-org-files

`yant/magit-org-hide-boring' and `yant/magit-autocommit'.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [OT] org and diff

[Samuel Wales]

hi marcin,

thanks for your blog post on my crash-proof editing idea.

more below

On 12/17/22, Marcin Borkowski <mbork@mbork.pl> wrote:
>
> On 2022-12-17, at 03:06, Samuel Wales <samologist@gmail.com> wrote:
>
>> marcin> One question I'd ask is: how important a legible diff is to
>> you?  I keep my Org files in Git, too, but if /I/ know what was
>> changed, I just don't care about diff going nuts and I treat it as
>> (more or less) Git's internal implementation detail.
>>
>> for org, i mostly use git for reviewing changes.  it is only one step
>> more sophisticated than saving old and diffing.
>>
>> i have lots of tools for improving diff, but this intermingling

[n.b. i have an still unpubolished package for 30 years that
postprocesses diff and is extremely powerful, and it can if you are
reviewing an ientire repo changes, to some degree nullify the
intermingling issue, but its integration with magit, and magit's bugs
with intra-hunk staging [2 bugs ime], make the intermingling an issue.
with no bugs, less of an issue, mnerely because it is desirable to use
magit instead of merely reviewing it and intra-hunk staging [and
killing] is part of that.  but i use old magit, with --- +++, istead
of new magit, which does not supply headers.  idk if new magit fixes
the bugs.

so really i was askig about the intermingling issue and whetehr it
could be mitigated at the magit/git level.]

> Well, "months of changes" seems tough.  I sometimes (rarely) have to
> enter 2 days' worth of changes...  It requires discipline, but
> discipline pays off in /so many areas of life/...

not sure what you men to say in this case about discipline.  my
circumstances if i told you about you'd be surprised.  my physical
survival is very much at issue and i have no  support for dalin with
it.

i.e. not sure if this was aimed at me or a general comment, and the
emphasis i wasn't sure what it was referring to.

>
>> days as normal.  i find reviewing changes to be valuable.  every once
>> in a while i discover data corruption or something that i forgot etc.
>
> Yes, same here.
>
>> i wonder if diff, or difftastic, could be taught or postprocessed to
>> do merely one thing: try to preserve stuff between "^\\*+ ".  that is
>> probably too optimistic, but imagine a --preserve-between option.
>
> I afraid so.  Difftastic does not support Org mode format.  However, the

huh.  so it's a hard problem [i.e. parser needed rather than merely
kluydging with entries].  :[

> tree-sitter page claims that Org parser is under way, so there's hope
> (AFAIK difftastic uses tree-sitter under the hood).

great.

>
> Best,
> mbork
>
> --
> Marcin Borkowski
> http://mbork.pl
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [OT] org and diff

[Samuel Wales]

well well.  my habit of always hitting reply to all bit me.  it was
meant for the poster only, not for the list.  apologies.

it bites me once every 12 years or so.

list members please disregard the message.

Re: [OT] org and diff

[Marcin Borkowski]

On 2022-12-28, at 03:30, Samuel Wales <samologist@gmail.com> wrote:

> hi marcin,
>
> thanks for your blog post on my crash-proof editing idea.

You're welcome! :-)  In fact, it was an interesting exercise.

>
> more below
>
> On 12/17/22, Marcin Borkowski <mbork@mbork.pl> wrote:
>>
>> On 2022-12-17, at 03:06, Samuel Wales <samologist@gmail.com> wrote:
>>
>>> marcin> One question I'd ask is: how important a legible diff is to
>>> you?  I keep my Org files in Git, too, but if /I/ know what was
>>> changed, I just don't care about diff going nuts and I treat it as
>>> (more or less) Git's internal implementation detail.
>>>
>>> for org, i mostly use git for reviewing changes.  it is only one step
>>> more sophisticated than saving old and diffing.
>>>
>>> i have lots of tools for improving diff, but this intermingling
>
> [n.b. i have an still unpubolished package for 30 years that
> postprocesses diff and is extremely powerful, and it can if you are
> reviewing an ientire repo changes, to some degree nullify the
> intermingling issue, but its integration with magit, and magit's bugs
> with intra-hunk staging [2 bugs ime], make the intermingling an issue.
> with no bugs, less of an issue, mnerely because it is desirable to use
> magit instead of merely reviewing it and intra-hunk staging [and
> killing] is part of that.  but i use old magit, with --- +++, istead
> of new magit, which does not supply headers.  idk if new magit fixes
> the bugs.
>
> so really i was askig about the intermingling issue and whetehr it
> could be mitigated at the magit/git level.]
>
>> Well, "months of changes" seems tough.  I sometimes (rarely) have to
>> enter 2 days' worth of changes...  It requires discipline, but
>> discipline pays off in /so many areas of life/...
>
> not sure what you men to say in this case about discipline.  my
> circumstances if i told you about you'd be surprised.  my physical
> survival is very much at issue and i have no  support for dalin with
> it.
>
> i.e. not sure if this was aimed at me or a general comment, and the
> emphasis i wasn't sure what it was referring to.

General comment.  I meant that committing my changes (almost) every day
requires serious discipline, and I worked pretty hard to acquire it.
Also, I do not claim that everyone can learn it like me - people are
/very/ different...

OTOH, you might consider "outsourcing the discipline".  One way would be
to set up some kind of reminder to review/commit the changes every day.
(That's more or less what I did, though I used a heavy-weight type of
reminder: https://www.beeminder.com/ .)  Another could be to use some
tool to do the committing for you (see
e.g. https://stackoverflow.com/q/420143/1181665), though then you lose
the "review" part.  (Still, with tools like `git log --grep' and/or `git
blame' you might find that this is good enough.)

Hth,

-- 
Marcin Borkowski
http://mbork.pl