When using emacs, I occasionally get the error Terminal 7 is locked, cannot read from it. What does this error mean?
Currently, I am receiving the error while I try to connect to an IRC server using erc, but I have received it before, though I don't remember for what. When it happened before, I was able to retry and eventually it worked, but now I get the same error every time.
I'm running a server session with emacs --daemon and have connected various clients with emacsclient -t.
I have searched for this online, but the only thing I can find is this. Aside from not being the exact question I have, it has no accepted answer. :(
This error means that some Elisp code is trying to read from the minibuffer (for example) while in the middle of some other command in another "terminal" (e.g. another tty). "In the middle" here means for example that you're using a minibuffer in that other terminal, or that you've hit a prefix key.
I suggest you try to come up with a reproducible way to trigger this error and then send it via M-x report-emacs-bug.
Related
First, before someone flags this questions as "out of topic" I will say that first I intended it to post it at stack exchange Meta. But at doing so it clearly says: "Ask your question in Stack Overflow if your question is about programming" and the use of programming tools such as Vscode is about programming
That being said, I use vscode for coding, and lately I have started to use its terminal (before I used the linux terminal). So far everything ok but I have noticed that after using it, and leaving it for some time (and sometimes closing the PC) the terminal becomes unusable, the messages invisible and even if I type, the letters are not visualized.
Why would this be happening and is there a way to avoid this. Right now there is no way and I have to just lose my work there and open another terminal
This is what I am doing:
Make a file or use an existing file.
Emacs filename.txt.
Type some new text into the file.
Save file.
After step 2, I receive an error after the emacs editor window pops up.
Here is the error:
2022-01-19 22:11:53.935 Emacs-x86_64-10_14[33893:994906] It's not
legal to call -layoutSubtreeIfNeeded on a view which is already being
laid out. If you are implementing the view's -layout method, you can
call -[super layout] instead. Break on void
_NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future.
I have already tried updating emacs and that didn't help, and googling didn't give me an answer. Currently, I have GNU Emacs 27.1 version.
How do I fix this error?
As far as I know you shouldn't need to "fix" the error at all and it won't cause any problems while you're actually running Emacs. In fact I'm somewhat surprised you see it at all.
I was only able to see the error (in both Emacs 27 and in pretest-28.0.90) only by running the Emacs binary (eg. ./Emacs-27.app/Contents/MacOS/Emacs) directly from a terminal, which isn't the normal way of starting Emacs on macOS. If you just run Emacs by starting it from Finder, the Dock, or via the "open" utility then you shouldn't see the error at all, and it shouldn't cause any problems.
The whole point of keyboard interaction (and emacs in particular) is that there's no need to touch the mouse. It's possible to log in (using e.g. ssh) and edit remotely, with no gui (so no way to drag and drop), and this is the 'normal' way of invoking emacs. Run 'emacs --help' from the command line to see a bunch of options. In particular see 'emacs --no-window-system' which uses a raw terminal even when a gui is available (no error message appears when it's run this way).
The gui however adds font and image support, which can be useful if you're sitting at the machine. The error message you get when you invoke 'emacs' from the command line in its default mode, with no arguments, is a diagnostic describing a bug in the mac gui implementation.
The error's still there if you start emacs through the finder; you can see that by running (e.g.)
$ open /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
which both opens an emacs gui and a terminal window containing the program's text output.
As it says in the message, 'this may break in the future'; it's not helpful to say 'you're using it wrong.'
I am using a new server that when sshing into requires me the press "return" in order to see my shell prompt. I believe this is causing my emacs tramp to get hung up. When I tried to open a file through tramp on the new server I am repeatedly asked for the password. I read that this could be due to tramp not recognizing the prompt. The prompt is the same as on other servers that work, which makes me think it is this that is causing issues.
I'm thinking the solution would be to add carriage return to the variable tramp-shell-prompt-pattern. How would I do this?
maybe something like:
(setq tramp-shell-prompt-pattern "\r\(?:^\|\)[^]#$%> ]*#?[]#$%>] *\(\[[0-9;]*[a-zA-Z] *\)*")
adding \r to the front of the default?
Also, I don't know if it will be possible to remove this behavior on the server side. I tried creating a .hushlogin file in my home directory, but it had no effect.
I came across this question which addresses the problem of the shell requiring user input. The solution didn't work
(setq tramp-shell-prompt-pattern "^[^$>\n]*[#$%>] *\\(\[[0-9;]*[a-zA-Z] *\\)*")
Thanks for your help. Clearly I'm a novice.
I have been using haskell-mode for some time now with no problems.
Recently emacs has started to hang for quite a while whenever I type in something in haskell-mode, say 10-15 seconds, and then returns to "normal". I can navigate around and switch buffers normally, but typing (in the haskell buffer) somehow halts emacs completely.
I don't recall changing anything, haskell- or emacs-wise, before this started occuring.
Moreover, it seems very difficult to track down. I have the following error message, but I'm not even sure that it related to this issue:
Error during redisplay: (jit-lock-function 1285) signaled (error
"Error in syntax_table logic for to-the-end intervals")
The freezes/hangs only occur in haskell-mode, everything else seems to act normally.
Is there a way I can find out what is blocking, and from there probably get closer to figuring it out?
I think it could be the same as this bug. It has been fixed (in this commit) but I don't think any released versions have the fix, so you'll have to either download the latest source from git or apply the patch manually.
When I use emacs, I often meet some errors in my code.
When there are some errors in my code, emacs ask me whether I want to "abort" or "terminate-thread".
I want to know what the difference is between "abort" and "terminate-thread" in emacs.
Which one should I choose that will be better?
I don't think this question comes from Emacs. So please give us more information (OS in which you run Emacs, which processes you might be running within Emacs, what kind of error happens, where is the actual question displayed (within Emacs's minibuffer, or some popup dialog), ...
Are you using SLIME?
In that case, "abort" will just stop your program, whereas "terminate-thread" will also kill the Lisp thread that SLIME is talking to.