1

I've had this error for a while, and I've attempted to solve it multiple times (a few other people have had similar errors). However, I've never been able to figure it out and it's becoming a nuisance. Every time I open a file in emacs using mobaxterm, 0;136;0c appears at the top of the file and I have to manually delete it. I've gleaned that the problem probably lies within the .init file. I'm not very experienced with emacs, so some help would be great, thanks!

NickD
  • 29,717
  • 3
  • 27
  • 44
adamruehle
  • 11
  • 1
  • @NickD Not quite, a clear answer was never provided in the other question. – adamruehle Nov 02 '22 at 16:55
  • Do you have an xterm-extra-capabilities variable that has the default value check in your emacs instance? If so, the answer provided is clear: set it to nil (or an explicit list of capabilities). But I said "possible" duplicate because I don't know whether mobaxterm looks like an xterm to Emacs, so I don't know if that variable exists in your emacs, what its value is and whether it makes any difference. Only you or another mobaxterm user can check that (and I am not such a user). – NickD Nov 02 '22 at 18:15
  • 1
    I figured out how to set the value to nil and that seems to have fixed the problem, thanks. Sorry, the answer to the other person's question was a bit confusing. – adamruehle Nov 02 '22 at 18:31
  • No problem - since it seems to be a duplicate, I voted to close it as such. That will help future (moba)xterm-ers find all the necessary information if they find this question. – NickD Nov 02 '22 at 20:21
  • Ok, I appreciate it! – adamruehle Nov 03 '22 at 01:22

1 Answers1

1

If the problem goes away when you run emacs -Q, then the problem probably is in your init file. In that case you can bisect your init file; comment out half of it. If the problem goes away, then the problem was in that half that you commented out, otherwise it was in the half that you didn’t comment out. Repeat until you have narrowed it down to one statement or expression, then ask again.

You might also check to see if you are adding or removing a key binding for M-[.

db48x
  • 17,977
  • 1
  • 22
  • 28
  • 2
    The problem does not go away when I run emacs -Q. Also, the problem only occurs sometimes. After running emacs -Q about fifty times, it seems that the problem occurs about 1/3 of the time and the buffer takes considerably longer to open when the problem does occur. – adamruehle Nov 02 '22 at 16:19
  • 1
    That’s progress. It sounds like a problem with mobaxterm then. It looks like a reply from the terminal may be getting interpreted as typed characters rather than as an escape sequence. That could happen if you have an unusual keybinding for M-[, or possibly for other reasons. – db48x Nov 02 '22 at 16:31
  • I don't think I have a keybinding for M-[. I opened emacs and tried M-[. It seems that it is only a keybinding for escape. – adamruehle Nov 02 '22 at 16:37
  • 1
    I'm not sure if this will help, but when I type the bash command echo -e "\e[>0c" , 0;136;0c is the output. – adamruehle Nov 02 '22 at 16:40
  • 2
    Yes, that’s what I expected. Emacs is sending the escape sequence to query the secondary device attributes, and your terminal is sending some attributes back. It is claiming to be a VT100 with firmware version 136. XTerm usually claims to be a VT420 and uses its own version number in place of the firmware version. What is important is that Emacs is not recognizing the reply from your terminal. – db48x Nov 02 '22 at 16:57
  • Is this causing a bug where Emacs pastes the terminal attributes into the file? How would I prevent XTerm from claiming to be a VT100. I'm not well-versed at all in how XTerm processes work. – adamruehle Nov 02 '22 at 18:12
  • Like I said, the value reported by your terminal is not important, merely interesting. – db48x Nov 02 '22 at 19:03