unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: gnuist <gnuist@protonmail.com>
To: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: Newbie looking for a toy example of ediff-buffers demonstrating #f and #h
Date: Sat, 20 Jul 2024 20:05:43 +0000	[thread overview]
Message-ID: <M3cIFQCL8AHsl5hmEtZSGUTcVWZCwyBJP8WOYLcxxi26ckddvMqgaHdIFvymaBATeSGXmQKUtWk3m-uHQb3R-NVhhSXtSpX86lZw70_PtBw=@protonmail.com> (raw)

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



             reply	other threads:[~2024-07-20 20:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-20 20:05 gnuist [this message]
2024-07-21 12:51 ` Newbie looking for a toy example of ediff-buffers demonstrating #f and #h Michael Heerdegen via Users list for the GNU Emacs text editor

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.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to='M3cIFQCL8AHsl5hmEtZSGUTcVWZCwyBJP8WOYLcxxi26ckddvMqgaHdIFvymaBATeSGXmQKUtWk3m-uHQb3R-NVhhSXtSpX86lZw70_PtBw=@protonmail.com' \
    --to=gnuist@protonmail.com \
    --cc=help-gnu-emacs@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.
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).