0

I am running emacs 26.1 under linux. It has been working fine for over a year. Recently, I upgraded a lot of packages on my machine, but I did not upgrade nor alter emacs in any way. Now, query-replace and query-replace-regexp are failing when I run either of them in a non-X terminal with the -nw emacs command-line flag when not in text-mode. This failure never used to occur before my system upgrades. And it turns out that query-replace{-regexp} still work fine in all cases when I start emacs in an X window.

For example, suppose I have the following data in a file called test.txt ...

AAAA
BBBB
CCCC
DDDD

If I run emacs -nw test.txt, then position to the top of the file and run (query-replace "AAAA" "XXXX"), it works. However, if I run (emacs-lisp-mode) and then run (query-replace "AAAA" "XXXX") in the same way, I get this result (with debug-on-error set) ...

Debugger entered--Lisp error: (args-out-of-range #<buffer test.txt> 0 1)
  buffer-substring-no-properties(0 1)
  perform-replace("AAAA" "XXXX" t nil nil nil nil nil nil nil nil)
  query-replace("AAAA" "XXXX")
  eval((query-replace "AAAA" "XXXX") nil)
  eval-expression((query-replace "AAAA" "XXXX") nil nil 127)
  funcall-interactively(eval-expression (query-replace "AAAA" "XXXX") nil nil 127)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)

However, if I leave off -nw and do all the same things in an X-Window instance of emacs, (query-replace ...) always works.

In other words, with emacs test.txt (i.e., no -nw flag), I never get this problem with query-replace, no matter what mode I am running in.

This is not only specific to emacs-lisp-mode. The error with query-replace in a non-X terminal buffer also occurs for sh-mode and some other modes.

Does anyone know what could be causing this error and what I have to do to fix it?

Thank you in advance.

UPDATE:

This error does not occur when I am running from my system console (i.e., no X services running at all). The errors I saw did occur in xterm and urxvt windows under my X desktop manager, even when I have explicitly unset DISPLAY.

It seems like there is something about running within an X desktop manager which is confusing emacs with regard to buffer attributes when running with -nw, even with DISPLAY unset.

And again, this problem only started happening a short time ago after updating a number of software components, but with no changes to emacs, at all. I have rebooted a few times since then, to no avail.

FURTHER UPDATE:

This error does not occur when I run (replace-string "AAAA" "XXXX").

Improve this question
3
  • I cannot replicate this in GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars) of 2018-10-23 Commented Feb 25, 2020 at 0:42
  • OOPS: I meant that I can edit an *.el file where major-mode gets set to emacs-lisp-mode, and I then get this error behavior. Also, I know this is nearly impossible to reproduce. I am running emacs-26.1 on two other machines, and this behavior doesn't occur. Commented Feb 25, 2020 at 2:04
  • For what it's worth, this seems to be related to the font-lock command when running it in an emacs -nw session. If I comment out all (font-lock ...) code in all my startup files, then this error behavior goes away. Commented Feb 25, 2020 at 2:07

2 Answers 2

Reset to default
1

FWIW (this isn't an answer; just more context)

In 26.3, the only call to buffer-substring-no-properties in perform-replace is:

(setq search-string-replaced (buffer-substring-no-properties
                              (match-beginning 0)
                              (match-end 0))
      ...)

So to get buffer-substring-no-properties(0 1) in the backtrace, we need (match-beginning 0) to return zero.

We're well into C code at that point, and establishing whether anything can ever set search_regs.start[0] to zero.

perform-replace does plenty with the match data, so I've not tried to figure out how that might happen.

Improve this answer
5
  • Thank you for all this! It turns out that if I do NOT set font-lock-keyword-face, the problem goes away. All other font-lock face settings work fine. So perhaps the matching code can sometimes get confused when it sees whatever emacs puts into a non-X-based buffer (i.e., when running with -nw) for keywords when I'm running in my particular X environment. I'll keep digging through the C and elisp code to try to figure out more about this. Commented Feb 25, 2020 at 8:31
  • If you're able, I would recommend trying/compiling an Emacs 27 build and seeing whether the problem still manifests. Commented Feb 25, 2020 at 8:41
  • Thank you. I couldn't quickly find 27, but I did find version 28 on github. However, some things in the language have changed, and a few of my startup files don't work under 28. I'll work through this later, when I have some time. One of the non-emacs packages I upgraded was qt5, and it has lots of dependencies with fonts, X resources, etc., which had to be rebuilt as part of the upgrade. I'm thinking that this is somehow related to my problem. Also, I have installed 26.3 now, and my problem continues. I'll keep digging in my spare time. Commented Feb 25, 2020 at 11:14
  • If you're compiling it from git sources, then the emacs-27 branch is for Emacs 27. Commented Feb 25, 2020 at 13:22
  • It turns out that version 28 fixes my problem. See my answer, below. Thank you again for all your help! Commented Feb 26, 2020 at 1:10
1

I ended up fixing the issue by building and starting to use emacs-28.0.50: https://github.com/emacs-mirror/emacs

I had to update some ancient, deprecated constructs in some of my old startup files so that this version of emacs would run. But in any case, this problem with query-replace{-regexp} doesn't exist in 28.0.50.

I still don't understand how making system changes outside of emacs could have caused this problem to suddenly appear in my stable-for-over-a-year emacs-26.1, but ...

Mine not to make reply,
Mine not to reason why,
Mine but to do and die.

(Apologies to Alfred, Lord Tennyson)

PS: emacs-27.0.60 also works fine for me, without this problem.

Improve this answer
2
  • I do recommend testing with the emacs-27 branch if you've not already done so -- if that also works, then it would be a good idea to be using that instead of master, as there should be a stable 27.1 release sometime within the next few months, at which point you could switch to that. 28.0.50 is at a very early stage of development, and might be less stable. Commented Feb 26, 2020 at 1:51
  • Thank you. I have cloned and built the emacs-27 branch, and it also fixes my problem. Commented Feb 26, 2020 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.