yas--original-auto-fill-function can end up nil unexpectedly
#919
Labels
Comments
|
If you are running Emacs 26+, could you try adding this to your init: #873 (comment) Hopefully that could catch where this thing gets set to
I think (dolist (buf (buffer-list))
(with-current-buffer buf (setq auto-fill-function nil))) |
|
@npostavs #873 is exactly what I'm experiencing. I just triggered it again (somehow). Neither of those commands recovered it, but the following did the trick (setq-default yas--original-auto-fill-function 'do-auto-fill)I'm not running Emacs 26 unfortunately, so I can't do the variable watcher. I might upgrade to 26, but in the mean time, let me know if you have any other thoughts. |
|
I'm puzzled that the loop wouldn't do the trick, or have you set the default-value of Meanwhile, I've updated yasnippet to give a warning instead of an error in this case, so hopefully it will be less painful to deal with.#920. |
|
After last update the debugger is fired up with this message when exporting org file in Latex. Before it never happend. |
Good :-). Now you should report the backtrace.
Because we didn't have this diagnostic code in place before |
|
This is (last part of) backtrace: |
@npostavs, looks legit though |
|
No, it's a false positive (but a new one), New update in #922. |
Closed
|
UPDATE: I'm now running Emacs 26 so I tried the variable watcher described in #873 and was able to catch the issue in the debugger: Debugger entered: ("yas--original-auto-fill-function unexpectedly nil!")
(progn (debug nil "yas--original-auto-fill-function unexpectedly nil!"))
(if (and (null newval) (eq auto-fill-function 'yas--auto-fill)) (progn (debug nil "yas--original-auto-fill-function unexpectedly nil!")))
(lambda (sym newval op where) (if (and (null newval) (eq auto-fill-function 'yas--auto-fill)) (progn (debug nil "yas--original-auto-fill-function unexpectedly nil!"))))(yas--original-auto-fill-function nil makunbound #<buffer file.py>)
kill-all-local-variables()
normal-mode(t)
after-find-file(nil nil t nil nil)
revert-buffer--default(nil t)
revert-buffer(nil t)
ask-user-about-supersession-threat(#("/ssh:some_server:/some/file.py" 1 4 (tramp-default t)))
userlock--ask-user-about-supersession-threat(#("/ssh:some_server:/some/file.py" 1 4 (tramp-default t)))
self-insert-command(1)
newline(nil t)
#f(compiled-function () (interactive "*") #<bytecode 0x400ba03f>)()
ad-Advice-newline-and-indent(#f(compiled-function () (interactive "*") #<bytecode 0x400ba03f>))
apply(ad-Advice-newline-and-indent #f(compiled-function () (interactive "*") #<bytecode 0x400ba03f>) nil)
newline-and-indent()
funcall-interactively(newline-and-indent)
call-interactively(newline-and-indent nil nil)
command-execute(newline-and-indent) |
|
@nevsan Ah, that's the false positive mentioned above. If you are running an updated yasnippet on a recent enough Emacs, it will add a variable watcher which avoids false positives (I hope). Unfortunately, so far it seems nobody has hit the true positive case... |
It's been almost a year, and still no reports. Perhaps it's dependent on a bug/quirk in some other package that has meanwhile been fixed. I don't think there is any use keeping this open. The code to check for the condition is still present, so we can always open a new issue if anyone hits it. |
|
i'm a new user of yasnippet and of various other "completion" packages. i seem to be running into this fairly consistently. for example [M-x the code in '(yas--auto-fill)' to produce a debug message calls at the risk of being very verbose, i'll post some details. first, the debug message code seems to want to print two variables: the stack on the initial entry to and, here is a selection from the stack during the recursion: |
|
oh, and by the way, i tried moving the call to also, i don't really know the protocol w.r.t. commenting on a closed issue. please let me know if i should open a new issue, or what i might try in terms of debugging. |
|
sorry. i rebuilt, and re-launched emacs. and, my "consistent" problem does not exhibit itself. false alarm? |
|
Hello there, The second paragraph shows the strange emacs behaviour that I believe is responsible. |
|
Thanks, @hardenedapple. I don't want to discourage you from investigation, but this repository has been without a maintainer for many months, so you're unlikely to get a useful reply here. |
|
Ah, ok -- thanks for the heads-up. |
|
For anyone who comes across this in the future: |
monnier
added a commit
that referenced
this issue
Oct 27, 2023
Instead of using `setq` and storing the old value in `yas--original-auto-fill-function`, use `add-function`. This makes it virtually impossible for a bug like #873/#919 to appear. Remove the left-over debug code we had added to try and track down #873/#919. This requires bumping the dependency on Emacs≥24.4. (yas--original-auto-fill-function, yas--watch-auto-fill-backtrace): Delete variables. (yas--watch-auto-fill): Delete function. Don't add it to variable watchers. (yas--auto-fill-wrapper): Use `add-function`. (yas-minor-mode): Use `remove-function`. (yas--auto-fill): Adjust its calling convention for use with `:around` in `add-function`. Remove left-over debug code. (yas--post-command-handler): Remove left-over debug code.
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is an issue that keeps showing up intermittently. Unfortunately, I cannot create an easy way to reproduce the issue since it shows up every other day after many hours of using Emacs, but I want to share it in case anyone has an idea. If it's important, I spend a lot of time using TRAMP to edit remote Python files.
The symptom is that my emacs session will suddenly get into a state where certain operations (like saving a buffer, or auto-completing a command in M-x with ivy) will get killed with an error saying
'Symbol’s function definition is void: nil'and I can't recover without restarting emacs.After much debugging, I traced it to this line:
(funcall yas--original-auto-fill-function)For whatever reason,
yas--original-auto-fill-functionended up becomingnil. Even if I set it back to something likedo-auto-fillfor the buffer, it will still cause the error. In order to fix the error without restarting emacs, I found that I have to executeIf anyone more familiar with the inner workings of these functions has an idea how and why this would happen, I'm willing to try some things to see if they get rid of the problem.
Thank you!
=====================
Some info about my setup.
I'm running
GNU Emacs 25.3.1 (x86_64-apple-darwin16.7.0, Carbon Version 157 AppKit 1504.83) of 2017-10-09from the emacs-mac distribution with spacemacs.The text was updated successfully, but these errors were encountered: