all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Braun Gábor" <braungb88@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 70122@debbugs.gnu.org
Subject: bug#70122: 29.3.50; transpose-regions can crash Emacs
Date: Fri, 12 Apr 2024 11:39:34 +0200	[thread overview]
Message-ID: <8400498.NyiUUSuA9g@gabor> (raw)
In-Reply-To: <86frw191ht.fsf@gnu.org>

Hi Eli,

Sorry for answering late.

> Can we lift that restriction by augmenting the len1_byte == 
len2_byte
> branch so that the len1 == len2 condition is not needed?

I could only come up with one that has minimal difference to
to the other branches.  I've attached it.

I've tried to preserve the undo entries as changes in the two 
regions, but I couldn't make it (one of my tests failed),
so now it is a change in the large region as in the other 
branches, and the tests pass.

The issue I was unable to solve is that the functions
set_text_properties_1 and graft_intervals_into_buffer
record text property changes in undo history, but this is unwanted 
here as transpose-regions handles undo history itself.
These entries don't cause trouble because they happen to be 
followed by a deletion of the text where properties change,
and this applies to all branches of transpose-regions.

I'd really like to use a version of these functions with: "change 
text properties, but leave it to us to record it in undo history".

 
> This says the test that crashed was the one of the two new ones 
you
> added, and it is different from the one you presented at the 
beginning
> of this bug report.

OK, sorry for that.

> > With the tests I intended to test all the branches in the code
> > where the regions don't touch each other, catching mistakes
> > where the wrong length is used.
> 
> Can we also have a test where the byte lengths are equal, but 
the
> character lengths aren't?

There is already one there:
the test which loops over examples and adds characters
is meant to cover various cases for the byte lengths,
including when they are equal.

As mentioned above, 
I had this test failing in this case during patch development.

> > I hoped that byte length is not system dependent,
> 
> It isn't, not if you consider the internal representation of
> characters in Emacs buffers and strings.

OK, maybe the issue was that I've sent a different test,
as you mentioned.

> Last, but not least: with the added tests your patch becomes 
larger
> than what we can accept without your assigning the copyright to 
the
> FSF.  Would you like to start the legal paperwork of copyright
> assignment at this time

Let's start the paperwork.

Best wishes,

	Gábor Braun








  reply	other threads:[~2024-04-12  9:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-01 10:02 bug#70122: 29.3.50; transpose-regions can crash Emacs Braun Gábor
2024-04-01 11:55 ` Eli Zaretskii
2024-04-01 13:17   ` Eli Zaretskii
2024-04-03 18:52     ` Braun Gábor
2024-04-04  4:48       ` Eli Zaretskii
2024-04-12  9:39         ` Braun Gábor [this message]
2024-04-12  9:42           ` Braun Gábor
2024-04-13 10:34           ` Eli Zaretskii
2024-04-16 14:26             ` Braun Gábor
2024-04-20  7:50               ` Eli Zaretskii
2024-04-24 12:35                 ` Braun Gábor

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

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

  git send-email \
    --in-reply-to=8400498.NyiUUSuA9g@gabor \
    --to=braungb88@gmail.com \
    --cc=70122@debbugs.gnu.org \
    --cc=eliz@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.