From: Alan Mackenzie <acm@muc.de>
To: Jayden Navarro <jayden@yugabyte.com>
Cc: 36328@debbugs.gnu.org
Subject: bug#36328: 26.2; Args out of range on search-and-replace of *.cc file
Date: Sun, 23 Jun 2019 12:22:07 +0000 [thread overview]
Message-ID: <20190623122207.GA4736@ACM> (raw)
In-Reply-To: <CAEKiUEZmeWxAs7=D5NBAP8mRgreu30Xf13e1JDgoW7AssgDDPw@mail.gmail.com>
Hello, Jayden.
On Sat, Jun 22, 2019 at 15:38:25 -0700, Jayden Navarro wrote:
> I've figured out the trigger! I setup a CentOS 7 VM and installed Emacs
> 26.2.90 and couldn't repro on it. So I compared all the environment
> variables between Cygwin and the VM and performed some tests, and
> discovered the issue is triggered by my "TERM" environment variable being
> set to "xterm-256color".
Well done!
> I could reproduce on the clean VM using: TERM="xterm-256color" emacs -Q
> test.cc
In my X-Windows setup, an xterm has the setting of TERM anyway. So I was
able to reproduce the failure with emacs -Q -nw. -nw means "no windows",
i.e. run in the terminal, not as a GUI application. (Normally, I run
Emacs in a linux virtual terminal.)
> Launching Emacs in that way, and following the other steps given above,
> should allow you to reproduce.
Yes. It didn't take me too long to track down where it's going wrong.
`perform-replace' calls `replace-highlight' to highlight the "foo", and
this calls `isearch-lazy-highlight-new-loop'. This in its turn performs
a redisplay (which is probably where CC Mode affects things). It seems
too much to expect that the "match-data" will be preserved over all this
activity, but `perform-replace' does expect this.
To fix this will involve putting a `save-match-data' around some form
somewhere. Please allow us some time to decide where this would be best.
> On Sat, Jun 22, 2019 at 2:27 PM Jayden Navarro <jayden@yugabyte.com> wrote:
> > Hi Alan,
> > Yes, you are completely correct :-) Posted one thing but unintentionally
> > took a "shortcut" when producing the backtrace (not a smart thing to do
> > when trying to get people to repro...).
> > Here's the backtrace when doing doing M-% foo <RET> bar <RET> (note that
> > it's still 0, 1 not 0, 3!):
I still have no specific idea what's generating that 0 and 1. Will
probably never find out.
> > Debugger entered--Lisp error: (args-out-of-range #<buffer test.cc> 0 1)
> > buffer-substring-no-properties(0 1)
> > perform-replace("foo" "bar" t nil nil nil nil nil nil nil nil)
> > query-replace("foo" "bar" nil nil nil nil nil)
> > funcall-interactively(query-replace "foo" "bar" nil nil nil nil nil)
> > call-interactively(query-replace nil nil)
> > command-execute(query-replace)
> Best,
> Jayden
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2019-06-23 12:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-21 23:03 bug#36328: 26.2; Args out of range on search-and-replace of *.cc file Jayden Navarro
[not found] ` <mailman.612.1561158667.10840.bug-gnu-emacs@gnu.org>
2019-06-22 13:25 ` Alan Mackenzie
2019-06-22 14:25 ` Jayden Navarro
2019-06-22 14:51 ` Juanma Barranquero
2019-06-22 16:09 ` Jayden Navarro
2019-06-22 20:50 ` Alan Mackenzie
2019-06-22 21:27 ` Jayden Navarro
2019-06-22 22:38 ` Jayden Navarro
2019-06-22 23:02 ` Jayden Navarro
2019-06-23 12:22 ` Alan Mackenzie [this message]
2019-06-23 16:14 ` Jayden Navarro
2019-06-23 19:32 ` Alan Mackenzie
2019-06-23 21:19 ` Juri Linkov
2019-06-23 21:42 ` Jayden Navarro
2019-06-24 19:05 ` Juri Linkov
2019-06-24 20:03 ` Jayden Navarro
2019-06-24 7:52 ` Alan Mackenzie
2019-06-24 19:18 ` Juri Linkov
2019-06-25 9:47 ` Alan Mackenzie
2019-06-25 19:58 ` Juri Linkov
2019-07-04 21:09 ` Juri Linkov
2019-07-05 6:11 ` Eli Zaretskii
2019-07-05 19:12 ` Juri Linkov
2019-10-02 23:53 ` Stefan Kangas
2019-06-23 20:10 ` bug#36328: [jayden@yugabyte.com: Re: bug#36328: 26.2; Args out of range on search-and-replace of *.cc file] Alan Mackenzie
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=20190623122207.GA4736@ACM \
--to=acm@muc.de \
--cc=36328@debbugs.gnu.org \
--cc=jayden@yugabyte.com \
/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.