0

NOTE: I was careless in evaluating this problem, and the data I posted here is not correct and does not reflect the actual issue that I am facing.

Since there are already answers to this question, I cannot delete it.

Please see the following question for the updated and corrected version of my query:

query-replace{-regexp} fails in linux in a non-X terminal when I am in anything other than text mode

Please ignore the rest of this. Thank you.

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, buffer-substring is failing when I run it 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 buffer-substring still works 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 (buffer-substring 0 1) works. However, if I run (elisp-mode) and then do a (buffer-substring 0 1), I get this error: args-out-of-range #<buffer test.txt> 0 1

This occurs no matter what arguments I pass to buffer-substring. However, if I leave off -nw and do all the same things in an X-Window instance of emacs, buffer-substring always works.

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

This is not only specific to elisp-mode. The error with buffer-substring 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:

I set debug-on-error and re-ran (buffer substring 0 1) in one of the cases that fails. Here is what I got:

Debugger entered--Lisp error: (args-out-of-range #<buffer test.txt> 0 1)
  buffer-substring(0 1)
  eval((buffer-substring 0 1) nil)
  eval-expression((buffer-substring 0 1) nil nil 127)
  funcall-interactively(eval-expression (buffer-substring 0 1) nil nil 127)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)

FURTHER UPDATE:

This error does not occur when I am running from my system console (with 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.

Improve this question
5
  • The first thing to do in situations like this is to enable debug-on-error and then cause the error to happen again. That will give you a backtrace that you should add to your question. You can enable debug-on-error with M-x toggle-debug-on-error RET (assuming that it was disabled before - if not, just toggle it again. The echo area should say Debug on Error enabled globally.)
    – NickD
    Feb 24, 2020 at 0:35
  • See UPDATE above. The stack trace gives no useful information
    – HippoMan
    Feb 24, 2020 at 0:38
  • ~ $ emacs -Q --batch --eval '(buffer-substring 0 1)' => Args out of range: #<buffer *scratch*>, 0, 1
    – xuchunyang
    Feb 24, 2020 at 0:56
  • This is because *scratch* is an empty buffer in your example. However, when running in a non-empty buffer as I have outlined above, (buffer-substring 0 1) works, except in the error cases I mentioned.
    – HippoMan
    Feb 24, 2020 at 0:59
  • What is elisp-mode ?
    – phils
    Feb 24, 2020 at 1:54

1 Answer 1

Reset to default
1

Buffer positions are 1-based, not 0-based.

You asked for buffer position 0:

Debugger entered--Lisp error: (args-out-of-range #<buffer test.txt> 0 1)
  buffer-substring(0 1)

You say:

If I run emacs -nw test.txt, then (buffer-substring 0 1) works.

Are you sure? I don't see that.

Improve this answer
5
  • 2
    And people usually should use (point-min) instead 1.
    – xuchunyang
    Feb 24, 2020 at 0:54
  • You are correct. I now realize that was misrepresenting my problem. It's actually related to query-replace and query-replace-regexp. They each generate the buffer-substringout-of-range error under the cases I described. I will discard this incorrectly described problem and repost something more accurate (tomorrow, since it's past my bedtime now). Thanks to all.
    – HippoMan
    Feb 24, 2020 at 1:08
  • @xuchunyang: It depends what the intention is - whether to take narrowing into account.
    – Drew
    Feb 24, 2020 at 15:34
  • 1
    @Drew That was my thought too, that's why I use the word "usually", but I just notice (buffer-substring 1 10) will signal an error if [1, 10] is not showing because of narrowing. Thus, you still need widen first, then, it seems point-min is always preferred.
    – xuchunyang
    Feb 24, 2020 at 20:42
  • @xuchunyang: The point is that if you want it to work also with a narrowed buffer then the positions you give it need to either (a) be within the current buffer restriction or (b) be determined by sexp evaluation (e.g., position relative to point-min, point-max, not relative to 0 and buffer-size).
    – Drew
    Feb 25, 2020 at 0:45

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.