Newbie looking for a toy example of ediff-buffers demonstrating #f and #h

Newbie looking for a toy example of ediff-buffers demonstrating #f and #h

[gnuist]

Hi - Newbie looking for a toy example SESSION of ediff-buffers demonstrating #f and #h.

You can put a small 2-3 lines file A and file B with lets say @ in first file and semicolon or hash in its place . Perhaps, also an empty brace in the first {} and a brace with some other text like {a b c} in the second.

I want to see how #f and #h is supposed to work.

Regarding two questions:

From: 	Michael Heerdegen
Subject: 	Re: Newbie: Merging buffer A with B using ediff-buffers
Date: 	Sat, 20 Jul 2024 08:44:23 +0200
User-agent: 	Gnus/5.13 (Gnus v5.13)

gnuist <gnuist@protonmail.com> writes:

> But when I use #f to focus using a regexp {.*} for both A and B, I am
> not seeing any special benefit.
> and when I use #h to hide using a regexp [;] for A and [tab] for B, I
> do not see any special benefit either.

You are aware that {, }, [ and ] are all special characters in regexps?
Did you quote them to let them match themselves?

My Reply:
Yes, I have tried both ways with and without escape and results do not make any sense or difference. Actually escaped did not even give any difference, forcing me to go against the convention and try brace without escape.

From: 	Michael Heerdegen
Subject: 	Re: BUG: ediff-buffers does not consistently show "differences" or "difference regions" within the "active region"

> You will immediately see that TAB is not highlighed in file A in its
> first line. This is *inconsistent* because in the second case c#d the
> hash is highlighted as the difference region within active region.

Just to be clear: You are talking about fine diff highlighting?
I think whitespace is ommitted when highlighting fine diffs to make the
result appear less distracting in the majority of cases.

My reply:
Yes, but the documentation does not state so. 

Either code has to be made consistent to documentation 
or documentation has to be made consistent with the code.

cheers

Re: Newbie looking for a toy example of ediff-buffers demonstrating #f and #h

[Michael Heerdegen via Users list for the GNU Emacs text editor]

gnuist <gnuist@protonmail.com> writes:

> Hi - Newbie looking for a toy example SESSION of ediff-buffers
> demonstrating #f and #h.
>
> You can put a small 2-3 lines file A and file B with lets say @ in
> first file and semicolon or hash in its place . Perhaps, also an empty
> brace in the first {} and a brace with some other text like {a b c} in
> the second.
>
> I want to see how #f and #h is supposed to work.

Maybe you should start experimenting with some simpler examples to get
familiar with these commands before trying stuff involving special
characters.  In particular, how to move between matches, and please also
get used to what it means that both sides match vs. only one.  Then
continue with more complicated use cases.


> You are aware that {, }, [ and ] are all special characters in regexps?
> Did you quote them to let them match themselves?
>
> My Reply:
> Yes, I have tried both ways with and without escape and results do not
> make any sense or difference. Actually escaped did not even give any
> difference, forcing me to go against the convention and try brace
> without escape.

You escape [] with _one_ backslash, e.g. you enter \[.*\].  {} parens
are special _when_ escaped, so, to match them literally, you don't escape
the characters, e.g. {.*}.


> > You will immediately see that TAB is not highlighed in file A in its
> > first line. This is *inconsistent* because in the second case c#d the
> > hash is highlighted as the difference region within active region.
>
> Just to be clear: You are talking about fine diff highlighting?
> I think whitespace is ommitted when highlighting fine diffs to make the
> result appear less distracting in the majority of cases.
>
> My reply:
> Yes, but the documentation does not state so. 
>
> Either code has to be made consistent to documentation 
> or documentation has to be made consistent with the code.

What exactly do you think is inconsistent, precisely?  The manual
doesn't tell the opposite of what I said (or does it?  where?), it maybe
somewhat leaves open some of your questions about special details.

For example, it says

| Since ‘diff’ may report fairly large chunks of text as being
| different, even though the difference may be localized to just a few
| words or even to the white space or line breaks, Ediff further
| _refines_ the regions to indicate which exact words differ.

Are whitespace only parts "words"?  Probably not.  I didn't read all of
the text, maybe being a bit more specific in some places could be
helpful, I don't know.


Michael.