-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"function provided already compiled" and Emacs freezes #601
Comments
I confirm that I have the same issue, and deactivating |
I could not reproduce the issue. The backtraces would help for troubleshooting. Please try Two quick questions
So far, I think the workarounds are below. One of these should work.
|
Thanks for the input! For your quick questions:
(@maxecharel , is it also the case for you?) I'll have to investigate a bit further to try your suggestions (thanks again, btw!). I can't try right now, but will ping you back later. ;) |
I have the same issue with freezing on Windows, but I do not seem to get the "function provided already compiled" message, so that may be a red herring. Some further info I have found: if I run the same config lines after Emacs is started, it appears to work, but the freeze reproduces if I create a new frame.
|
@seagle0128 thx for feedback; concerning your questions
Concerning the backtraces with I will try the workarounds ASAP and will get back to you, thx again for your feedback @seagle0128 |
To be more precise, when doing this, I get the same thing as @make-all : everything does seem to work well, but Emacs freezes when I open a new frame, or do other specific actions. For instance, I have an instant freeze when I try But all of us seem to have slightly different behaviors... not very easy for @seagle0128 😓 |
I am also having this issue after a package update today. For me, it appears to only occur when opening a .org file. It can also be temporarily fixed by resizing window (but only to some sizes, specifically when taking up 1/3 of the screen). Commenting out modeline fixes it. All was working prior to update. Edit: I have since rolled back to an older version of doomline and it is still breaking. This leads me to believe the issue is caused by some other commonly used package update breaking doomline rather than a commit in doomline itself. |
I just upgraded to the latest melpa version |
I am having the same issue with version 20230106.1427. There is my minimal init file https://pastebin.com/pJs82g1n The same behavior. Emacs is freezing. Emacs version 28.2 on Windows and Linux. |
I am also having the same issue with version 20230106.1427. It works when running Emacs version 28.2 on OS X. |
Same kind of problem for me with Emacs 28.2. It seems to be related to the recent update of The problem can be highlight with the following minimal (defvar bootstrap-version)
(let ((bootstrap-file
(expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
(bootstrap-version 6))
(unless (file-exists-p bootstrap-file)
(with-current-buffer
(url-retrieve-synchronously
"https://raw.githubusercontent.com/radian-software/straight.el/develop/install.el"
'silent 'inhibit-cookies)
(goto-char (point-max))
(eval-print-last-sexp)))
(load bootstrap-file nil 'nomessage))
(straight-use-package 'use-package)
(setq straight-use-package-by-default t)
(use-package doom-modeline
:init (doom-modeline-mode 1)
:custom (doom-modeline-height 30)) Changing With last version of all packages, Emacs freezes at startup. But with straight, we can easily rollback to an old version of a package.
7ca7d300d1d256f674f83932d2918d8e70cd28f6 is the last version of |
Commenting out the |
I have this same issue on Windows too. |
Hi, I have just bisected the issue down to this commit:
Here's the full bisection log:
Attempting to revert that commit on today's HEAD results in a non-trivial conflict, but hopefully this gives enough information to reproduce and fix the issue. I have also verified that hard resetting to the commit right before the offending commit results in a working setup. As a workaround, we can all force UPDATE: This change makes the problem go away: diff --git a/doom-modeline-core.el b/doom-modeline-core.el
index 8f5cc2864271..c2db56a3699a 100644
--- a/doom-modeline-core.el
+++ b/doom-modeline-core.el
@@ -1088,7 +1088,7 @@ Example:
(- (+ right right-fringe right-margin scroll-bar)
,(let ((rhs-str (format-mode-line (cons "" rhs-forms))))
(if (fboundp 'string-pixel-width)
- (/ (string-pixel-width rhs-str)
+ (/ (string-width rhs-str)
(doom-modeline--font-width)
1.0)
(* (string-width rhs-str) |
Oh, I see. |
) These functions seem to hangup from time to time on 28.2 (seagle0128/doom-modeline#601). By dropping the functions the hangup in doom-modeline is resolved, since doom-modeline contains a runtime check for string-pixel-width. The compatibility function implementations do not contain any loops, this means there is an underlying bug in `window-text-pixel-size' in 28.2 exposed by the compatibility function. Either the compatibility function must be written in a different form or we cannot provide them at all.
It seems like we could close this issue after |
Perfect, thanks a lot @felipebalbi . I've seen that @minad directly handled the problematic function in |
@felipebalbi You are right! The root cause is IMO It's not easy to improve |
What if you explicitly check for the emacs version instead of checking for the existence of the In any case, minad's change is already removing the implementation from compat-29 |
Thank you all. Generally my recommendation is to avoid using UNTESTED definitions from Compat just yet. Unfortunately there are still around 52 untested definitions there as of now. For comparison, 144 definitions have test coverage, which is ensured also by CI. In other words, as soon as a package author intends to use an UNTESTED function, a PR adding tests to Compat would be greatly appreciated. In this particular case, doom-modeline is not to blame since it had a dynamic @seagle0128 In case you figure out a possible implementation of @felipebalbi Yes, an explicit Emacs 29 check would have helped. I also considered that. However it is safer to not provide the broken and untested |
if there's confirmation of a bug in |
@felipebalbi See my correction above. As @seagle0128 pointed out it may be very hard or even impossible to backport this function. |
@seagle0128 Just for me to understand fb516af - so you say that |
@felipebalbi Anyway I check the emacs version in In 29 ;;;###autoload
(defun string-pixel-width (string)
"Return the width of STRING in pixels."
(if (zerop (length string))
0
;; Keeping a work buffer around is more efficient than creating a
;; new temporary buffer.
(with-current-buffer (get-buffer-create " *string-pixel-width*")
;; `display-line-numbers-mode' is enabled in internal buffers
;; that breaks width calculation, so need to disable (bug#59311)
(when (bound-and-true-p display-line-numbers-mode)
(display-line-numbers-mode -1))
(delete-region (point-min) (point-max))
(insert string)
(car (buffer-text-pixel-size nil nil t))))) |
Could we use the something similar to what
|
@minad Yes. In my testing, the behavior is correct, but the performance is poor. Caching should be helpful, but I don't think it's a good idea. The solution may be complicated, but you can try. |
@felipebalbi No, that is more or less what Compat used. Due to the window buffer switching and |
@felipebalbi If you look into a1411d5, you will find out the codes are same, and obviously I failed to backport. |
There has to be something else going on. If I define Any easy way to extract the exact string |
@minad Correct. It depends on how often it's called. |
@minad I see now. The problem is that doom calls it on redisplay. Calling it once is not an issue. Understood :-) |
@felipebalbi I also assume that Emacs has a bad time to handle |
Compat 29.1.1.0 has been released yesterday, which should fix this and related issues by removing the problematic |
Just updated both compat and doom modeline and I can confirm it works fine on my setup without modifications. Thanks @minad and @seagle0128 for providing fixes. |
@felipebalbi Thanks for confirming and thanks again for helping out with this issue! |
Same as @felipebalbi; just updated both packages and now it works perfectly. Thanks @seagle0128, @minad and @felipebalbi for you work! |
@seagle0128 You were mistaken that DEFUN ("buffer-text-pixel-size", Fbuffer_text_pixel_size, Sbuffer_text_pixel_size, 0, 4, 0,
doc: /* Return size of whole text of BUFFER-OR-NAME in WINDOW.
BUFFER-OR-NAME must specify a live buffer or the name of a live buffer
and defaults to the current buffer. WINDOW must be a live window and
defaults to the selected one. The return value is a cons of the maximum
pixel-width of any text line and the pixel-height of all the text lines
of the buffer specified by BUFFER-OR-NAME.
The optional arguments X-LIMIT and Y-LIMIT have the same meaning as with
`window-text-pixel-size'.
Do not use this function if the buffer specified by BUFFER-OR-NAME is
already displayed in WINDOW. `window-text-pixel-size' is cheaper in
that case because it does not have to temporarily show that buffer in
WINDOW. */)
(Lisp_Object buffer_or_name, Lisp_Object window, Lisp_Object x_limit,
Lisp_Object y_limit)
{
struct window *w = decode_live_window (window);
struct buffer *b = (NILP (buffer_or_name)
? current_buffer
: XBUFFER (Fget_buffer (buffer_or_name)));
Lisp_Object buffer, value;
specpdl_ref count = SPECPDL_INDEX ();
XSETBUFFER (buffer, b);
/* The unwind form of with_echo_area_buffer is what we need here to
make WINDOW temporarily show our buffer. */
/* FIXME: Can we move this into the `if (!EQ (buffer, w->contents))`? */
record_unwind_protect (unwind_with_echo_area_buffer,
with_echo_area_buffer_unwind_data (w));
set_buffer_internal_1 (b);
if (!EQ (buffer, w->contents))
{
wset_buffer (w, buffer);
set_marker_both (w->pointm, buffer, BEG, BEG_BYTE);
set_marker_both (w->old_pointm, buffer, BEG, BEG_BYTE);
}
value = window_text_pixel_size (window, Qnil, Qnil, x_limit, y_limit, Qnil,
Qnil);
unbind_to (count, Qnil);
return value;
}
(defun string-pixel-width (string)
"Return the width of STRING in pixels."
(if (zerop (length string))
0
;; Keeping a work buffer around is more efficient than creating a
;; new temporary buffer.
(with-current-buffer (get-buffer-create " *string-pixel-width*")
;; `display-line-numbers-mode' is enabled in internal buffers
;; that breaks width calculation, so need to disable (bug#59311)
(when (bound-and-true-p display-line-numbers-mode)
(display-line-numbers-mode -1))
(delete-region (point-min) (point-max))
(insert string)
(car (buffer-text-pixel-size nil nil t))))) Could you investigate what actually causes the problem here? Maybe we can backport string-pixel-width as part of Compat after all. Is the problem that |
@minad I didn't say |
@seagle0128 I don't understand. Do you think a backport is possible or not? See what you wrote here: #601 (comment). This is incorrect. buffer-text-pixel-size IS implemented based on window-text-pixel-size in C. |
@minad It's possible if
Here "it" represents the implementation of (defun doom-modeline--string-pixel-width (string)
"Return STRING pixel width.
See `shr-pixel-column'."
(if (fboundp 'string-pixel-width)
(string-pixel-width string)
(let ((pt (point)))
(prog1
(with-temp-buffer
(insert string)
(if (not (get-buffer-window (current-buffer)))
(save-window-excursion
;; Avoid errors if the selected window is a dedicated one,
;; and they just want to insert a document into it.
(set-window-dedicated-p nil nil)
(set-window-buffer nil (current-buffer))
(car (window-text-pixel-size nil (line-beginning-position) (point))))
(car (window-text-pixel-size nil (line-beginning-position) (point)))))
(goto-char pt))))) |
Thank you for the bug report
doom-modeline
related packages.the command
emacs -Q
.Bug description
I guess just after an update of doom-modeline (I batch-updated packages 10 minutes ago), when I restarted Emacs I got the message "function provided already compiled" and Emacs froze. I had to kill the process (no way to even enter a command). Commenting out doom-modeline in my init file solved the issue, so I conclude the problem comes from it. (Thx for your work with this really classy package BTW ;) )
Kubuntu 22.04
Emacs 28.2
Last version of doom-modeline on Melpa
Steps to reproduce
Expected behavior
Emacs not to freeze
OS
Linux
Emacs Version
28
Emacs Configurations
No response
Error callstack
No response
Anything else
No response
The text was updated successfully, but these errors were encountered: