emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [OT] org and diff
Date: Mon, 21 Nov 2022 20:06:23 -0700	[thread overview]
Message-ID: <CAJcAo8s2eDbAWC8K7NKEaLgN_yThPJOPHKh9EsoS_gRkeH1bXQ@mail.gmail.com> (raw)
In-Reply-To: <CAJcAo8vJ8DXDgJzr15ESXQ3s0ifZja3vJ7wTFDu9x-TguWOiMg@mail.gmail.com>

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


  parent reply	other threads:[~2022-11-22  3:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-13  5:15 [OT] org and diff Samuel Wales
2022-11-13  5:32 ` Ihor Radchenko
2022-11-13  6:06   ` Samuel Wales
2022-11-15 16:58     ` Max Nikulin
2022-11-13  5:38 ` Samuel Wales
2022-11-13  9:32 ` Marcin Borkowski
2022-11-22  3:06 ` Samuel Wales [this message]
2022-11-22  3:17   ` Samuel Wales
2022-12-17  2:06     ` Samuel Wales
2022-12-17  8:36       ` Marcin Borkowski
2022-12-17  8:41         ` Ihor Radchenko
2022-12-28  2:30         ` Samuel Wales
2022-12-28  2:32           ` Samuel Wales
2022-12-28  6:35           ` Marcin Borkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJcAo8s2eDbAWC8K7NKEaLgN_yThPJOPHKh9EsoS_gRkeH1bXQ@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).