I'm using an emacs-lisp script that has a minor bug which causes it to sometimes choke with an error message, and then execution proceeds without problem. The error itself does not bother me, what annoys me is that Emacs remains 10-15 seconds blocked after that and I must wait for what I believe to be some timer (designed to ensure I see the error message before it disappears) to end before I can resume my editing.
Is there a simple way to reduce this delay? I couldn't find where this timer is defined in order to change its value.
Some additional information:
I'm using Emacs 23.2, but I tried recompiling and using 23.4, it didn't change anything;
I tried Emacs 24.1 and the error disappeared, but I had a huge performance impact (the script has been designed for Emacs 23.2), so the "wait for error" is still a better option than using 24.1;
The script in question will be updated by its author sometime in the future, but I'm looking for a quick and dirty solution meanwhile.
The error message is: "error in process filter: Attempt to delete minibuffer or sole ordinary window".
as already said, it's a bug. Please report it to the maintainer.
Beside you may look into the code for a form like
(accept-process-output &optional PROCESS SECONDS
MILLISEC JUST-THIS-ONE)
Allow any pending output from subprocesses to be read by Emacs.
It is read into the process' buffers or given to their filter functions.
Non-nil arg PROCESS means do not return until some output has been received
from PROCESS.
Non-nil second arg SECONDS and third arg MILLISEC are number of seconds
and milliseconds to wait;
;;;
Related
I usually encounter situation when I enter minibuffer command such as open file or change buffer and instead of completing it in a minibuffer, I start doing something else, usually editing the buffer. I would like that minibuffer simply forget the command if it was not completed after some period of inactivity in a minibuffer. Is it possible?
If it would be possible to make the minibuffer simply flush itself after losing focus it would be great too. Now frequently I get the queue of minibuffer commands waiting for me and it is annoying as hell, since when I C-g them, emacs changes the buffers in the frames.
I wouldn't really advise doing anything of the sort, but would suggest instead that you provide a visual clue to yourself when the minibuffer is active. But since you asked for it...
You can put a function to exit the minibuffer on a suitable hook or in a timer. The function could check the value of (active-minibuffer-window) and call, say, (top-level) to return to the top level whenever it is nil. (Function abort-recursive-edit will exit the current minibuffer, but that can return to a parent (shallower) minibuffer, not necessarily `top-level'.
What hook or timer to use? You could use `post-command-hook', which is run after each command (e.g., each key press). That is perhaps overkill, but it won't miss a chance. There is perhaps another, more pertinent hook; dunno.
You could use an idle timer, which kicks in only after Emacs has been idle for a specified time. Or you could use a regular timer, just checking periodically. A timer could be started on minibuffer-setup-hook and then canceled on minibuffer-exit-hook.
I've been fooling around with comint-mode lately and I'm noticing some weird behaviors. Its very poorly documented, so I'm wondering if anyone has any insight on this.
In some modes, comint-send-string causes whatever is sent to be inserted into the comint buffer and then sent to the associated process, whereas in others, the input is send directly to the process without being placed into the buffer. For example, do run-python with the new (24.3) python.el and then do (comint-send-string "*Python*" "x=3\n"), the string x=3 is inserted into the buffer and then executed. If you do M-x shell, however, and then (comint-send-string "*shell*" "x=3\n"), no text is inserted into the buffer, the input is simply sent to the shell process directly to be executed.
Does anyone know why this difference in behavior exists or how I can change it?
I observe identical behavior on linux (emacs-version == "24.3.50.7", both GUI and emacs -Q -nw): neither
(comint-send-string "*Python*" "x=3\n")
nor
(comint-send-string "*shell*" "x=3\n")
insert anything in the comint buffer (i.e., the next prompt appears
right after the previous prompt - without even a newline between them).
I eventually figured it out. For some reason the system python on OSX causes this behavior, installing python from homebrew fixed it.
I get this warning in my matlab-shell buffer when I print alot to stdout:
Warning (undo): Buffer `*MATLAB*' undo info was 12268000 bytes long.
The undo info was discarded because it exceeded `undo-outer-limit'.
This is normal if you executed a command that made a huge change
to the buffer. In that case, to prevent similar problems in the
future, set `undo-outer-limit' to a value that is large enough to
cover the maximum size of normal changes you expect a single
command to make, but not so large that it might exceed the
maximum memory allotted to Emacs.
My emacs looks like this:
I really don't need any undo in the matlab-shell which is the right buffer. Is there a way to disable this warning? Note that the left buffer is a MATLAB script which means that the major mode is MATLAB, and certainly undo should not be disabled there.
As that warning message says (or used to say?):
You can disable the popping up of this buffer by adding the entry
(undo discard-info) to the user option warning-suppress-types,
which is defined in the warnings library.
That is:
(add-to-list 'warning-suppress-types '(undo discard-info))
(That will of course just disable the warning, not the undo data collection itself.)
Your question is a little ambiguous, but assuming you're saying that you have no need to undo things in this buffer, then you can disable the undo system on a per-buffer basis:
buffer-disable-undo is an interactive compiled Lisp function in `simple.el'.
(buffer-disable-undo &optional BUFFER)
Make BUFFER stop keeping undo information.
No argument or nil as argument means do this for the current buffer.
So you can call M-x buffer-disable-undo RET interactively, or if you're sure about it, you could add this to a hook function for the mode in question.
Edit:
So based on the extra information in the question comments, I would suggest this:
(add-hook 'matlab-shell-mode-hook 'buffer-disable-undo)
I've tried to figure the problem myself, and will probably continue, but due to poor error reporting it's just too time consuming. So, perhaps, if anyone had encountered this problem before, please share.
What happens: after flymake-jshint encounters an error, no matter what the error is, it could be a missing semicolon for example. It will get stuck in an infinite loop. I can C-g the loop, but this is very annoying, and will happen multiple times on the same line, making it absolutely impossible to write anything.
When I then look into the *Messages* buffer, it reveals something like:
missing ; after statement [NNNN times]
i.e Flymake was requested to perform the check many times. The timer interval is set to 2 seconds, but it clearly overdoes, because it will do hundreds of checks in two seconds. Trying to increase the flymake-log-level reveals no additional information.
I have customized these variables:
(flymake-no-changes-timeout 2)
(flymake-start-syntax-check-on-newline nil)
but no more additional customizations.
EDIT:
This seems to be related to auto-complete mode. Disabling this minor mode "solved" the problem, but now I'm getting hundreds of "Invalid face reference: nil [NNNN times]" kinds of messages. sigh
I think, I finally found the problem. It was the highlight-current-line minor mode. Whenever Flymake would detect an error and needed to paint the error location it tried to read the overlay, but got confused by the overlay created by the highlight. I haven't yet gotten to trying to fix it, but simple disabling of the highlight made it at least possible to work.
I'm having a problem with an Emacs lisp package that I pulled down from the ubuntu distribution. The package is JDEE, and it complains of Args out of range: "63", 0, 4 in the mini buffer and the *Messages* buffer whenever I open a file. This bug appears to have been reported last September but no action has been taken. I'm not an emacs newbie, having written some Elisp code myself, but I've never attempted to debug anything like this. I would like to stop the file load in a debugger when this error happens to at least get an idea of where the problem is coming from. I've read section 18.1.1 of the Elisp manual on "Entering the debugger on error" but trying to load the file after playing with various combinations of values for debug-on-error, debug-ignored-errors, and debug-on-signal appears to have no effect. Has anybody got any suggestions for my next step?
If debug-on-error isn't working, I'd start with the source itself. Find the keybinding/event that is causing the problem, and locate the function.
C-h k <keystrokes>
M-x find-function <function-name-from-above>
Now, once you are at the source
M-x edebug-defun
And the next time you hit the key, you should be able to step through the program. At that point, you can see which portion causes an error - and drill down that way.
You can also try setting the variable 'stack-trace-on-error to see if you can find the culprit (though 'debug-on-error usually works for me, not sure why it doesn't for you).
As a last resort (if edebug-defun doesn't work), you can redefine the routine with a call to (debug) in it, sort of does the same.
I suppose JDEE is somehow inhibiting debug-on-error. Perhaps grep through its files for the error message "Args out of range". While debugging, make sure to load the uncompiled .el files, not the byte-compiled .elc files (you will notice it in the debugger if you are running byte-compiled code) by entering commands like (load "foo.el") instead of (load "foo").
I got the same error when using find-grep after accidentally redefining (current-time-string) in one of my own scripts.
Using the M-x edebug-defun tip posted above I managed to find the issue when I stepped through the code giving the error seeing the call to (current-time-string).
Not sure how helpful this is in your case.