bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code
> From: Yuan Fu > Date: Sat, 7 Sep 2024 22:57:29 -0700 > Cc: m...@ssbb.me, > wkirschb...@gmail.com, > 72...@debbugs.gnu.org > > > > > On Sep 7, 2024, at 10:54 PM, Eli Zaretskii wrote: > > > >> From: Yuan Fu > >> Date: Sat, 7 Sep 2024 22:44:53 -0700 > >> Cc: Wilhelm Kirschbaum , > >> Eli Zaretskii , > >> 72...@debbugs.gnu.org > >> > >> Meanwhile, I want to push the fix for the other bug I discovered to > >> emacs-30. Eli, I wrote a debugging function that prints parser states, > >> naturally this function isn’t called anywhere so there’ll be a compiler > >> warning, what should I do in this case? > > > > Why would there be a compiler warning? What kind of warning? > > A function-not-used warning. Maybe it’s an lldb thing? If the function is not static, there should be no such warning.
bug#73050: 30.0.90; Empty tool tip when hovering over tab-bar separator
> From: Juri Linkov > Cc: Daniel Mendler , 73...@debbugs.gnu.org > Date: Sun, 08 Sep 2024 09:51:41 +0300 > > >> This is only a minor issue. After enabling `tab-bar-mode' when hovering > >> with the mouse over the `tab-bar-separator' space, an empty tool tip > >> will be shown after a short delay. > >> > >> To reproduce: > >> > >> 1. Start emacs -Q > >> 2. M-x tab-bar-mode > >> 3. Move the mouse pointer over the space right after the "*scratch*" tab > >> > >> Would it make sense to somehow prevent displaying blank tool tips, e.g., > >> via the following advice? Or maybe blank tool tips could be prevented on > >> the tab-bar level? > >> > >> (defun x-show-tip-adv (str &rest _) (string-blank-p str)) > >> (advice-add #'x-show-tip :before-until #'x-show-tip-adv) > > > > Juri, can we prevent such empty tooltips from being shown by tab bar? > > Maybe this unasked-for default fallback is not needed after all: > > diff --git a/src/xdisp.c b/src/xdisp.c > index f9a10267bad..18834c6b781 100644 > --- a/src/xdisp.c > +++ b/src/xdisp.c > @@ -15155,8 +15155,6 @@ note_tab_bar_highlight (struct frame *f, int x, int y) >help_echo_object = help_echo_window = Qnil; >help_echo_pos = -1; >help_echo_string = AREF (f->tab_bar_items, prop_idx + TAB_BAR_ITEM_HELP); > - if (NILP (help_echo_string)) > -help_echo_string = AREF (f->tab_bar_items, prop_idx + > TAB_BAR_ITEM_CAPTION); > } > > #endif /* HAVE_WINDOW_SYSTEM */ Do you remember why was this introduced?
bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code
> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii wrote: > >> From: Yuan Fu >> Date: Sat, 7 Sep 2024 22:57:29 -0700 >> Cc: m...@ssbb.me, >> wkirschb...@gmail.com, >> 72...@debbugs.gnu.org >> >> >> >>> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii wrote: >>> From: Yuan Fu Date: Sat, 7 Sep 2024 22:44:53 -0700 Cc: Wilhelm Kirschbaum , Eli Zaretskii , 72...@debbugs.gnu.org Meanwhile, I want to push the fix for the other bug I discovered to emacs-30. Eli, I wrote a debugging function that prints parser states, naturally this function isn’t called anywhere so there’ll be a compiler warning, what should I do in this case? >>> >>> Why would there be a compiler warning? What kind of warning? >> >> A function-not-used warning. Maybe it’s an lldb thing? > > If the function is not static, there should be no such warning. Ah, you’re right, I marked it static. Thanks! Yuan
bug#72986: Disabling menu-bar-mode changes size of new frames
>> -#if defined (USE_X_TOOLKIT) || defined (USE_GTK) >> +#if defined (USE_X_TOOLKIT) && !defined (USE_GTK) >> > > OK, so I applied this patch and ran `emacs -Q`, then did C-x 5 2 and got > the usual small window and error: > > (emacs:3159980): Gtk-CRITICAL **: 13:05:49.056: > gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed Do you get an assertion failure already before the C-x 5 2? >> Now set >> >> (setq default-frame-alist '((menu-bar-lines . 0))) >> >> and do C-x 5 2. How does that behave? >> > > That opens a small window with no error message. From what you've tested till now I can conclude the following. Your Emacs requests a frame size of 1328x1260 pixels and for some inexplicable reason your Emacs _always_ gets a ConfigureNotify notification that tells it that the frame has been shrunk to 400x340 pixels. Below, the values marked with XS are the requested values and show up as: xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260 ... ConfigureNotify, PS=1328x1260, XS=400x340, DS=1328x1260 The equivalent sequence on my system is xg_frame_set_char_size, invisible, PS=752x792, XS=752x792, DS=752x792 ... ConfigureNotify, PS=752x792, XS=752x792, DS=752x792 Now two things may happen on your system. In one scenario you get a second ConfigureNotify event, this time with the expected size: ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=400x322 Emacs complies and there are no further issues. This is the scenario with commit 24161683102 reverted. Note: The second ConfigureNotify event in this scenario seems to be a result of Emacs issuing two apparently identical requests as xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260 ... xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260 with maybe different menu bar sizes. We have yet to find out what causes the second request. In the other scenario Emacs complies with the sizes received in the ConfigureNotify event, re-issues a new resize request with the small sizes and the next ConfigureNotify event does not cause any change. xg_frame_set_char_size, visible, PS=1328x1260, XS=400x340, DS=400x340 ... ConfigureNotify, PS=1328x1260, XS=400x340, DS=400x340 The small frame size stays. This is the scenario with current master. There is no previous second request from the side of Emacs. One thing that we'd have to verify yet is whether the gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed can happen only when Emacs issues the xg_frame_set_char_size, visible, PS=1328x1260, XS=400x340, DS=400x340 request (which I'd expect) or already when we get the ConfigureNotify event (which I doubt). In either case, I think that the assertion failure is only a consequence of getting an unreasonable size and not the cause of it. Where could we go from here? (1) Try to find out why we always get a ConfigureNotify, PS=1328x1260, XS=400x340, DS=1328x1260 after requesting the larger size. For this purpose we would have to find out whether 400x340 is some built-in size used by the WM or GTK or something Emacs itself has used before. (2) Find out why Emacs in one scenario issues a second resize request and doesn't do that with the reverted commit. Maybe Po Lu can tell. I also suppose that the missing second resize request is also the reason why the menubar-less frame always shrinks. Maybe we should _always_ fake such a request - idempotent resize requests should never harm. (3) Do not flush events. Could gdk_flush (); #ifndef HAVE_PGTK x_wait_for_event (f, ConfigureNotify); #endif flush a ConfigureNotify event to which we should have reacted? (4) Look for other causes. Could scaling be involved? Do we calculate size hints correctly - mutter is very selective about these. Should we delay setting the frame's visibility? (5) Finally, the most important: Can other users observe the same or similar behavior as Reuben? martin
bug#69097: [PATCH] Add 'kill-region-or-word' command
Sean Whitton writes: > Hello, > > Thank you both for the feedback. Attached is an updated version. > > A few replies: > > On Fri 06 Sep 2024 at 04:32pm GMT, Philip Kaludercic wrote: > >> Won't there be an error here if the command is invoked with a negative >> argument? > > Do you mean that you think there should be an error? > I don't see any need for that. I had mistakenly assumed that (kill-region start (point)) would throw an error if (> start (point)), and that it would be better to catch that case earlier. But I just checked, and kill-region does the right thing, so forget about it. -- Philip Kaludercic on icterid
bug#73102: 29.4; `package-recompile-all' should skip packages installed by distro package manager
Zhengyi Fu writes: > When I try recompiling all packages installed by package.el with `M-x > package-recompile-all', I got the following error: > > Debugger entered--Lisp error: (permission-denied "Removing old name" > "Permission denied" "/usr/share/emacs/site-lisp/elpa/mu4e-1.10.8/mu4e-a...") > package-recompile(#s(package-desc :name mu4e :version (1 10 8) :summary > "the mu mail user agent" :reqs nil :kind nil :archive nil :dir > "/usr/share/emacs/site-lisp/elpa/mu4e-1.10.8" :extras nil :signed nil)) > package-recompile-all() > funcall-interactively(package-recompile-all) > command-execute(package-recompile-all record) > execute-extended-command(nil "package-recompile-all" "recom all") > funcall-interactively(execute-extended-command nil "package-recompile-all" > "recom all") > command-execute(execute-extended-command) > > This is possibly because the package `mu4e' was installed by the distro > package manager in a path where normal users don't have write access. > > I think `package-recompile-all' should either skip those packages that > are not installed by package.el or ignore such errors and continue to > recompile other packages. We have installed a patch in Bug#68678 on master (the commit is from last February, so you wouldn't see it yet on 29.4) that wraps the `package-recompile' call in a `with-demoted-errors' block. That would still emit a error message, but it wouldn't break the recompilation procedure. Do you think that is enough, or should be explicitly and additionally avoid re-compiling external packages? -- Philip Kaludercic on icterid
bug#72966: 30.0.90; [PATCH] php-ts-mode: custom php.ini config for the built-in php webserver
In data domenica 8 settembre 2024 08:48:09 CEST, Eli Zaretskii ha scritto: > > From: Vincenzo Pupillo > > Cc: 72...@debbugs.gnu.org > > Date: Thu, 05 Sep 2024 21:16:29 +0200 > > > > Hi Eli, I followed your suggestion and moved the CONFIG argument. I also > > added a new entry to the NEWS file. > > Thanks, installed on the master branch, and closing the bug. > > Please in the future try to adhere to our conventions of leaving two > spaces between sentences (I fixed that in this patch). Thank you Eli. Vincenzo.
bug#72701: eglot crash when project-files-relative-names t
On Sun, Sep 8, 2024 at 3:24 AM Dmitry Gutov wrote: > > On 07/09/2024 10:20, Eli Zaretskii wrote: > > Ping! Is this issue resolved and can be closed, or do we need to do > > anything else here? > > I suggest installing the following. Not a hard necessity, but seems like > an improvement: Let's not, for all the reasons enunciated up-thread. João
bug#73098: setopt float warning unexpected
Yessir. I was talking about users' likely expectations for type coercion. There are cases in elisp where numeric type coercion is the default, e.g., (= 2.0 2) is t. I expected it to be so here, too. If you feel this is moot, then so be it. On Sun, Sep 8, 2024 at 2:07 AM Eli Zaretskii wrote: > > From: Ship Mints > > Date: Sat, 7 Sep 2024 09:14:54 -0400 > > > > This one bit me yesterday on Emacs 29.3 as I was revising my init file > (for the thousandth time this week). > > > > As setopt becomes more widely recommended, people will likely encounter > situations like the below where they > > expect constant numeric types to be coerced. > > > > (defcustom temp-float "Float" > > "Float type." > > :type 'float) > > > > (setopt temp-float 2.0) ; works > > (setopt temp-float 2) ; Warning (emacs): Value '2' does not match type > float > > If you are going to allow integer values, shouldn't :type be 'number, > not 'float? The documentation of 'float says: > > ‘float’ >The value must be floating point. > > "Must be floating point." The value 2 isn't. >
bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
> #0 terminate_due_to_signal (sig=6, backtrace_limit=40) at > ../../src/emacs.c:432 > #1 0x0061b51b in emacs_abort () at ../../src/sysdep.c:2391 > #2 0x00541fc2 in cmcheckmagic (tty=0x1ebe0d0) at ../../src/cm.c:122 > #3 0x00546564 in tty_write_glyphs (f=0x1e7bb30, string=0x1e9afe0, > len=80) at ../../src/term.c:819 > #4 0x005508c9 in write_glyphs (f=0x1e7bb30, string=0x1e9a0e0, > len=80) at ../../src/terminal.c:164 > #5 0x0042a6d7 in update_frame_line (f=0x1e7bb30, vpos=4, > updating_menu_p=false) at ../../src/dispnew.c:5326 > #6 0x004298c5 in update_frame_1 (f=0x1e7bb30, force_p=true, > inhibit_id_p=false, set_cursor_p=true, > […] > so the original assertion violation is gone here. > We're dealing with two type of assertion violations / crashes / backtraces: - in update_frame_line, that causes chcheckmagic to fail - in build_frame_matrix_from_leaf_window, assertion violation With the same build I mentioned in the top post (that is, without any code change), I can see both, after following the same instructions I posted. The update_frame_line happens much more frequently, therefore I thought that the update_frame_line was fixed in 71289; but it's not: I just reproduced the update_frame_line issue. So you can't be sure that the original assertion violation is gone. Your build may have crashed with the update_frame_line crash, before reaching the build_frame_matrix_from_leaf_window crash. The best would be to solve both crashes :-) I don't know whether both crashes are related.
bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
> I noticed that causing this assertion to fail is not very easy. For > example, if I drag the terminal emulator window one line at a time, I > can never cause it, even if I get to frame sizes that are much smaller > than the minimum we need for 2 windows. Somehow, I need to drag the > frame so it resizes by several lines and/or columns. Not sure why. > I can cause the build_frame_matrix_from_leaf_window failed assertion ( glyph_row_slice_p(window_row, frame_row) is false ) when slowly resizing row by row (7→6→5 rows). The number of columns doesn't matter (can be a normal one). You can also try maximizing/unmaximizing“the window if you window manager supports it. That's a way of suddenly changing the number of rows from a normal value (e.g. 20) to a dangerous value (e.g. 4). After unmaximizing it immediately crashes (if you did the C-x 2 split).
bug#73098: setopt float warning unexpected
> From: Ship Mints > Date: Sun, 8 Sep 2024 06:59:31 -0400 > Cc: 73...@debbugs.gnu.org > > Yessir. I was talking about users' likely expectations for type coercion. > There are cases in elisp where numeric > type coercion is the default, e.g., (= 2.0 2) is t. I expected it to be so > here, too. > > If you feel this is moot, then so be it. Let's see if there are other opinions. But basically, you'd like 'float to be an alias for 'number, right?
bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
> I attach the patch now, sorry for not doing it earlier. > Please attach patches if I can help trying out things. I don't know this code so I may break it if I change the low-level behavior. But I can safely add many breakpoints and debug messages to research the bugs. Apparently we could use more assertions in other parts of the code, or move the existing ones (under glyph debug) to catch the problem earlier. In cmcheckmagic we have: if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1) emacs_abort (); Is this an assertion that needs to always hold? I have tried copy-pasting it at the beginning of tty_write_glyphs and I found that it fails continuously (e.g. it tests: 62 >= 63-1). Actually I used a breakpoint instead of emacs_abort. Are there useful places where I could trace that the assertion holds true?, earlier places than the current place.
bug#70968: 29.2.50; choose-completion on an emacs22-style completion deletes text after point
> Ping! How should we proceed with this bug report? I don't quite understand the question. After: Eli wrote: > Stefan wrote: > > I'm not sure it's terribly important to preserve this detail of the > > behavior of `Emacs-22`. The `emacs22` style does not aim to provide the > > illusion you're running an old Emacs. I named it that way because > > I couldn't come up with a good descriptive name for it. If it > > misbehaves, I don't see a need to be bug-compatible, especially since > > this doesn't affect ELisp code but users. > > I think it does, sorry. Suchj old behavior is a de-facto standard. > If we change that, we should at least have a knob to get back the old > behavior. I thought you had decided that the current behavior is not a bug. I'm fine with this choice and we can close it as such. Tho maybe we'd want to deprecate that `emacs22` style because of those odd cases. Stefan
bug#72819: [PATCH] Correctly include fixed strings before a prefix wildcard in PCM
> Ping! Stefan, any comments? Looks good to me. [ Maybe we could appoint Spencer as maintainer of that code :-) ] Stefan >> Cc: monn...@iro.umontreal.ca >> From: Spencer Baugh >> Date: Mon, 26 Aug 2024 10:17:05 -0400 >> >> Tags: patch >> >> >> In 63a48252306a631dc07d62d19311433c7877bd27 I fixed a bug with >> the PCM implementation of substring completion, relating to the >> handling of PCM wildcards. >> >> However, this fix was incomplete. This change completes the fix by >> also including a fixed string if it appears before a `prefix' >> wildcard, even if try-completion doesn't discover that fixed string >> grows to a unique completion. >> >> I discovered this bug while working on enhancements to PCM completion >> related to completion-pcm-leading-wildcard.
bug#73098: setopt float warning unexpected
I'm suggesting that there will be noise from people who convert from a working (setq some-package-option 2) to (setopt some-package-option 2). This is not a request to change the elisp type system, it is a request to consider if setopt's / customize internals should be relaxed to the equivalent of #'= for these simple cases. On Sun, Sep 8, 2024 at 7:09 AM Eli Zaretskii wrote: > > From: Ship Mints > > Date: Sun, 8 Sep 2024 06:59:31 -0400 > > Cc: 73...@debbugs.gnu.org > > > > Yessir. I was talking about users' likely expectations for type > coercion. There are cases in elisp where numeric > > type coercion is the default, e.g., (= 2.0 2) is t. I expected it to be > so here, too. > > > > If you feel this is moot, then so be it. > > Let's see if there are other opinions. > > But basically, you'd like 'float to be an alias for 'number, right? >
bug#72808: 30.0.90; editorconfig doesn't set tab_width to a default value
>> The problem is that the .editorconfig file can be shared across users of >> different editors for a given project. Emacs disagreeing with the >> standard means that Emacs users will now have to explain to their >> colleagues why they are introducing a change in a .editorconfig file >> that the standard says is unnecessary. This is putting me, at least, in >> an uncomfortable position with non-Emacs users in my team. Additionally, >> if other editors disagree with the standard for other reasons, we may >> quickly reach a situation where no content of .editorconfig will suit >> everyone. > Stefan, any further comments, or should we close this as wontfix? I think Damien's argument makes a lot of sense. I think mine makes sense as well. I can't really judge which one will work out more often right, but as the writer of the code I decided to try out my choice. But I don't have a really strong opinion about it (I do have a strong opinion that the EditorConfig standard's choice is wrong, but not whether we should follow it or not): if you think Damien's preference is better for Emacs, I'm fine to make the change. Otherwise, I suggest we leave it like that for Emacs-30 and see how things turn out. Stefan
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Suhail Singh writes: Hi Suhail, >> There's a new user option `dired-highlight-symlinks'. If non-nil (the >> default), symlinks are highlighted the same way as now. With a nil >> value, they aren't. > > I propose that the non-default behaviour be that `dired-symlink-face' is > applied to the entirety of the symlink. If you agree, it might be > better to additionally rename `dired-highlight-symlinks' accordingly to > reflect the updated behaviour. Good catch, see reworked patch below. The user option has been renamed to dired-check-symlinks. > TIL about connection-local variables. Yes, this would be helpful. > However, if so desired, I imagine that setting > `dired-highlight-symlinks' buffer-locally in the `dired-mode-hook' would > work as well. Is my understanding correct? Yes, connection-local variables are implemented as buffer-local variables. Best regards, Michael. diff --git a/lisp/dired.el b/lisp/dired.el index 0d526dfc376..bc984c3506d 100644 --- a/lisp/dired.el +++ b/lisp/dired.el @@ -738,6 +738,13 @@ dired-ignored-face ;;; Font-lock +(defcustom dired-check-symlinks t + "Whether symlinks are checked for validity. +Set it to nil for remote directories, which suffer from a slow connection." + :type 'boolean + :group 'dired + :version "31.1") + (defvar dired-font-lock-keywords (list ;; @@ -815,11 +822,13 @@ dired-font-lock-keywords ;; Broken Symbolic link. (list dired-re-sym (list (lambda (end) - (let* ((file (dired-file-name-at-point)) -(truename (ignore-errors (file-truename file - ;; either not existent target or circular link - (and (not (and truename (file-exists-p truename))) -(search-forward-regexp "\\(.+\\) \\(->\\) ?\\(.+\\)" end t + (when (connection-local-value dired-check-symlinks) + (let* ((file (dired-file-name-at-point)) + (truename (ignore-errors (file-truename file + ;; either not existent target or circular link + (and (not (and truename (file-exists-p truename))) + (search-forward-regexp + "\\(.+\\) \\(->\\) ?\\(.+\\)" end t) '(dired-move-to-filename) nil '(1 'dired-broken-symlink) @@ -829,10 +838,12 @@ dired-font-lock-keywords ;; Symbolic link to a directory. (list dired-re-sym (list (lambda (end) - (when-let* ((file (dired-file-name-at-point)) - (truename (ignore-errors (file-truename file - (and (file-directory-p truename) - (search-forward-regexp "\\(.+-> ?\\)\\(.+\\)" end t + (when (connection-local-value dired-check-symlinks) + (when-let* ((file (dired-file-name-at-point)) + (truename (ignore-errors (file-truename file + (and (file-directory-p truename) + (search-forward-regexp + "\\(.+-> ?\\)\\(.+\\)" end t) '(dired-move-to-filename) nil '(1 dired-symlink-face) @@ -841,12 +852,15 @@ dired-font-lock-keywords ;; Symbolic link to a non-directory. (list dired-re-sym (list (lambda (end) - (when-let ((file (dired-file-name-at-point))) - (let ((truename (ignore-errors (file-truename file - (and (or (not truename) - (not (file-directory-p truename))) - (search-forward-regexp "\\(.+-> ?\\)\\(.+\\)" - end t) + (if (not (connection-local-value dired-check-symlinks)) + (search-forward-regexp + "\\(.+-> ?\\)\\(.+\\)" end t) + (when-let ((file (dired-file-name-at-point))) + (let ((truename (ignore-errors (file-truename file + (and (or (not truename) + (not (file-directory-p truename))) + (search-forward-regexp + "\\(.+-> ?\\)\\(.+\\)" end t)) '(dired-move-to-filename) nil '(1 dired-symlink-face)
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Suhail Singh writes: Hi, >> I agree. But that only explains the time delay, no why Emacs is >> consuming 100% of CPU, right? Waiting for the network should not >> consume CPU, unless I'm missing something. >> >> Also, Suhail Singh says that there's a significant delay when there >> are valid symlinks, in which case I don't expect Tramp to issue the >> same command 15 times, right? > > Yes, while there are clearly inefficiencies in cyclic link detection, > that's not the situation for the reproducer I shared. Font-locking > symlinks (broken, not broken; to files, to directories) trigger the > issue even without introducing cyclic references. For what it's worth, > as I shared in an earlier exchange, the profiler-report seemed to point > the finger to `tramp-wait-for-regexp': > > | Func in font-lock check | TRAMP handler >| > |-+--| > | `file-truename' | `tramp-sh-handle-file-truename' -> ... -> > `tramp-wait-for-regexp'| > | `file-exists-p' | `tramp-sh-handle-file-exists-p' -> ... -> > `tramp-wait-for-regexp'| > | `file-directory-p' | `tramp-sh-handle-file-directory-p' -> ... -> > `tramp-wait-for-regexp' | > > Unless I misinterpreted the profiler output, something in/about > `tramp-wait-for-regexp' results in the 100% CPU usage. Tramp is in a loop, waiting for results from the remote side. I don't know how to implement this differently. Best regards, Michael.
bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
> From: Daniel Clemente > Date: Sun, 8 Sep 2024 11:08:14 + > Cc: martin rudalics , 73...@debbugs.gnu.org > > > I noticed that causing this assertion to fail is not very easy. For > > example, if I drag the terminal emulator window one line at a time, I > > can never cause it, even if I get to frame sizes that are much smaller > > than the minimum we need for 2 windows. Somehow, I need to drag the > > frame so it resizes by several lines and/or columns. Not sure why. > > > > I can cause the build_frame_matrix_from_leaf_window failed assertion ( > glyph_row_slice_p(window_row, frame_row) is false ) when slowly > resizing row by row (7→6→5 rows). The number of columns doesn't matter > (can be a normal one). I cannot. Slowly dragging the window never crashes. > You can also try maximizing/unmaximizing“the window if you window > manager supports it. That's a way of suddenly changing the number of > rows from a normal value (e.g. 20) to a dangerous value (e.g. 4). > After unmaximizing it immediately crashes (if you did the C-x 2 > split). This also never crashes here.
bug#72986: Disabling menu-bar-mode changes size of new frames
On Sun, 8 Sept 2024 at 09:42, martin rudalics wrote: > >> -#if defined (USE_X_TOOLKIT) || defined (USE_GTK) > >> +#if defined (USE_X_TOOLKIT) && !defined (USE_GTK) > >> > > > > OK, so I applied this patch and ran `emacs -Q`, then did C-x 5 2 and got > > the usual small window and error: > > > > (emacs:3159980): Gtk-CRITICAL **: 13:05:49.056: > > gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed > > Do you get an assertion failure already before the C-x 5 2? > No. Where could we go from here? > (I comment below where I think I may have useful input.) after requesting the larger size. For this purpose we would have to > find out whether 400x340 is some built-in size used by the WM or GTK > or something Emacs itself has used before. > Since this size crops up with emacs -Q, it doesn't seem to be related to something Emacs has used before. I did also grep through my ~/.emacs.d directory, but I couldn't find anything relevant there. (4) Look for other causes. Could scaling be involved? My GNOME desktop is scaled by 200%, so it could be. > (5) Finally, the most important: Can other users observe the same or > similar behavior as Reuben? > Several bugs were already reported of similar behaviour, no? Or maybe you meant something more specific. -- https://rrt.sc3d.org
bug#73098: setopt float warning unexpected
On Sep 08 2024, Ship Mints wrote: > There are cases in elisp where numeric type coercion is the default, > e.g., (= 2.0 2) is t. I expected it to be so here, too. That's because the function accepts a number, not a float. If you want to accept any kind of number, just say so. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
> From: Michael Albinus > Cc: Eli Zaretskii , 73...@debbugs.gnu.org > Date: Sun, 08 Sep 2024 13:30:00 +0200 > > Suhail Singh writes: > > > Unless I misinterpreted the profiler output, something in/about > > `tramp-wait-for-regexp' results in the 100% CPU usage. > > Tramp is in a loop, waiting for results from the remote side. I don't > know how to implement this differently. What kind of loop? Can you point me to the code which loops there?
bug#73098: setopt float warning unexpected
100% correct...when one controls the code base in question. For the many packages out there with strict types in their defcustom definitions and with many/most users using setq over customize, there will be lots of surprise for simple cases like this when they try setopt. Perhaps more vocal advisories for package authors to provide updates (though many seem fallow), and for users might be sufficient without resorting to monkey patching. Most, I suspect, will just revert to setq and ignore custom type validations. Most don't even check for the presence of setters and I've assisted many in my circles with their resulting heisenbugs. On Sun, Sep 8, 2024 at 7:39 AM Andreas Schwab wrote: > On Sep 08 2024, Ship Mints wrote: > > > There are cases in elisp where numeric type coercion is the default, > > e.g., (= 2.0 2) is t. I expected it to be so here, too. > > That's because the function accepts a number, not a float. If you want > to accept any kind of number, just say so. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different." >
bug#73117: 30.0.90; Imenu missing entries when flattening by group
On Sun, Sep 8, 2024 at 2:57 AM Juri Linkov wrote:
>
> > ```
> > ;; begin
> > (progn
> > (require 'imenu)
> > (dolist (flatten '(prefix group annotation))
> > (setq imenu-flatten flatten)
> >
> > (imenu-choose-buffer-index (format "(%s) Index item: " flatten)
> >`(("Bar" . (("Foo" . ,(point-min-marker
> > ("Baz" . (("Foo" .
> > ,(point-max-marker
> > ;; end
> > ```
>
> Sorry for leaving out of documentation an unapparent mention
> of `completions-group`. We are discussing this currently at
> https://mail.gnu.org/archive/html/emacs-devel/2024-08/msg00241.html
> So a prerequisite would be to use `(setopt completions-group t)`.
> But currently this should be mentioned in the docstring.
>
> Also in the same discussion we came to conclusion that
> `M-` can't be used to select imenu items for
> `annotation` and `group`. So this limitation was
> documented recently in the docstring of `imenu-flatten`:
>
> @@ -158,6 +158,9 @@ imenu-flatten
>with a suffix that is the section name to which it belongs.
>If the value is `group', split completion candidates into groups
>according to the sections.
> +Since the values `annotation' and `group' rely on text properties,
> +you can use them only by selecting candidates from the completions
> +buffer, not by typing in the minibuffer.
>
> Otherwise, `group` should work nicely when using ``
> with `minibuffer-visible-completions`.
Hi Juri,
I did see the text in the diff above. I assumed that was indicating
that you need to use the completions buffer to distinguish between the
identically named items (although after re-reading it, maybe it
affects the selection too). I was using M- to pop-up the
completions buffer so that I could see those distinctions. Maybe
using `(setopt completion-auto-help t)` and hitting TAB is a better
method. Either way, I'm just trying to display the completions
buffer. This does work for the "annotations" setting as I see both
entries with the suffix annotation in the completions buffer. Maybe
there is a different issue using M- for the selection, but my
issue is that I can't get the completions buffer to even display all
of the items.
Just to be clear I'm running "emacs -Q" on the latest in the emacs-30
branch as of yesterday. I ran the code snippet I posted in the
original email by running `eval-last-sexp` in the scratch buffer.
I did try adding your suggested settings to the above code snippet,
but they did not seem to improve anything with regards to what shows
up in the completions buffer:
```
(setopt completions-group t)
(setopt minibuffer-visible-completions t)
```
The following is what I see in the "*Completions*" buffer for all
three settings of `imenu-flatten` (i.e., "prefix", "group" and
"annotation"). Notice that the second output (which is the "group"
setting) only shows a single entry, the one for Bar/Foo. The "Bar"
group is displayed and the "Foo" entry under it is also displayed, but
the "Baz" group is completely missing (even though it says "2 possible
completions"). This is the issue I'm having.
--8<---cut here---start->8---
Click or type RET on a completion to select it.
Type , , , to move point between completions.
2 possible completions:
Bar:Foo
Baz:Foo
--8<---cut here---end--->8---
--8<---cut here---start->8---
Click or type RET on a completion to select it.
Type , , , to move point between completions.
2 possible completions:
Bar
Foo
--8<---cut here---end--->8---
--8<---cut here---start->8---
Click or type RET on a completion to select it.
Type , , , to move point between completions.
2 possible completions:
Foo (Bar)
Foo (Baz)
--8<---cut here---end--->8---
bug#72986: Disabling menu-bar-mode changes size of new frames
>> >> -#if defined (USE_X_TOOLKIT) || defined (USE_GTK) >> >> +#if defined (USE_X_TOOLKIT) && !defined (USE_GTK) >> >> >> > >> > OK, so I applied this patch and ran `emacs -Q`, then did C-x 5 2 and got >> > the usual small window and error: >> > >> > (emacs:3159980): Gtk-CRITICAL **: 13:05:49.056: >> > gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed >> >> Do you get an assertion failure already before the C-x 5 2? >> > > No. Thanks. Did you ever get an assertion failure for the original frame? If not, then we should try to understand why not. Please with pristine master replace the initial assignment of 'frame-size-history' in frame.c from frame_size_history = Qnil; to frame_size_history = Fcons (make_fixnum (100), Qnil); start Emacs -Q and tell me the contents of the *frame-size-history* buffer. The idea is that if the initial frame gets it right, what can we do to make subsequent C-x 5 2 calls get it right. >> find out whether 400x340 is some built-in size used by the WM or GTK >> or something Emacs itself has used before. >> > > Since this size crops up with emacs -Q, it doesn't seem to be related to > something Emacs has used before. I did also grep through my ~/.emacs.d > directory, but I couldn't find anything relevant there. Sorry. I meant something in the history of the frame creation 'frame-size-history' doesn't catch like the initial assignments in make_frame combined with the values of FRAME_COLUMN_WIDTH and FRAME_LINE_HEIGHT FRAME_COLS (f) = FRAME_TOTAL_COLS (f) = rw->total_cols = 80; FRAME_TEXT_WIDTH (f) = FRAME_PIXEL_WIDTH (f) = rw->pixel_width = 80 * FRAME_COLUMN_WIDTH (f); FRAME_LINES (f) = FRAME_TOTAL_LINES (f) = 25; FRAME_TEXT_HEIGHT (f) = FRAME_PIXEL_HEIGHT (f) = 25 * FRAME_LINE_HEIGHT (f); or what gui_figure_window_size concocts with the size hints. > (4) Look for other causes. Could scaling be involved? > > > My GNOME desktop is scaled by 200%, so it could be. Can you try not using any scaling experimentally? Jan always complained that GTK does not handle scaling orderly (that is, in our sense). >> (5) Finally, the most important: Can other users observe the same or >> similar behavior as Reuben? >> > > Several bugs were already reported of similar behaviour, no? Or maybe you > meant something more specific. I meant in the light of what I've written here. IIUC nobody so far has noticed the two idempotent xg_frame_set_char_size calls and how the second one sometimes magically fixes things. It would be interesting to find out whether such "fixes" happen all the time without being noticed. Also most people have identified natural allocation distribution as a possible culprit and not as a potential victim. And if the WM is the culprit, why does the same WM handle Lucid frames or those without toolkit correctly? Maybe the WM is a racist, maybe we are. Thanks, martin
bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
> We're dealing with two type of assertion violations / crashes / backtraces:
> - in update_frame_line, that causes chcheckmagic to fail
> - in build_frame_matrix_from_leaf_window, assertion violation
>
> With the same build I mentioned in the top post (that is, without any
> code change), I can see both, after following the same instructions I
> posted.
> The update_frame_line happens much more frequently, therefore I
> thought that the update_frame_line was fixed in 71289; but it's not: I
> just reproduced the update_frame_line issue.
Good to know.
> So you can't be sure that the original assertion violation is gone.
Right.
> Your build may have crashed with the update_frame_line crash, before
> reaching the build_frame_matrix_from_leaf_window crash.
Right again. But I think that with my initial patch, the likeliness of
the later has decreased.
> The best would be to solve both crashes :-)
>
> I don't know whether both crashes are related.
They are both caused by shrinking the frame size to something Emacs
doesn't like. Note the
if (width > 5 && height > 2)
check in handle_window_change_signal and the
/* Don't allow too small height of text-mode frames, or else cm.c
might abort in cmcheckmagic. */
if ((FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f)) && NILP (horizontal))
{
int min_height = (FRAME_MENU_BAR_LINES (f)
+ FRAME_TAB_BAR_LINES (f)
+ FRAME_WANTS_MODELINE_P (f)
+ 2); /* one text line and one echo-area line */
if (retval < min_height)
retval = min_height;
}
in frame_windows_min_size. People always were aware of the problem but
with split windows these values are of no use.
martin
bug#72870: [PATCH] Flow fill texts after the last hard newline
Eli Zaretskii writes: AFAICT, this function exists for the special case of decoding email messages. Can email messages have flowed-encoded text without a hard newline at the end? I think you meant "encoding"? Anyway, if I understand it correctly, an email message should always end with a newline, but it is not necessarily a hard newline. For example, 'message.el' inserts a normal newline: https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/message.el#n4944 I am not sure what other MUAs do, though. PS I have sent an email to ass...@gnu.org, but have not got a response yet. I think I have not finished the copyright assignment process? No. Please ping them and CC me, so we could get your paperwork process going. Will do. Thanks! Pengji
bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
> In cmcheckmagic we have: >if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1) >emacs_abort (); > > Is this an assertion that needs to always hold? I very strongly doubt so myself. And strangely it's _always_ an off-by-one error here just as you sketched below. > I have tried > copy-pasting it at the beginning of tty_write_glyphs and I found that > it fails continuously (e.g. it tests: 62 >= 63-1). Actually I used a > breakpoint instead of emacs_abort. > Are there useful places where I could trace that the assertion holds > true?, earlier places than the current place. I suppose in all those cases curX (tty) == FrameCols (tty) does not hold so the assertion does not trigger. martin
bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
> I can cause the build_frame_matrix_from_leaf_window failed assertion (
>glyph_row_slice_p(window_row, frame_row) is false ) when slowly
> resizing row by row (7→6→5 rows). The number of columns doesn't matter
> (can be a normal one).
>
> You can also try maximizing/unmaximizing“the window if you window
> manager supports it. That's a way of suddenly changing the number of
> rows from a normal value (e.g. 20) to a dangerous value (e.g. 4).
> After unmaximizing it immediately crashes (if you did the C-x 2
> split).
Please try the attached diff (from my heavily edited copy of master, if
it doesn't apply cleanly, complain immediately rather than messing up
your Emacs). It should fix two silly bugs in window.el that make a
frame's safe minimum size much too large and includes the fix I proposed
earlier here.
And it moves the assignment of FrameRows to handle_window_change_signal
in dispnew.c. Doing it in adjust_frame_size was silly (as Gerd Möllmann
noticed earlier). FrameRows should be the height of the tty which can
be smaller than the height of our frame. Emacs is supposed to store it
but not to modify it according to our capabilities.
The patch does not fix the cmcheckmagic problem but makes it much less
likely to occur. And redisplay of an insanely small tty window looks
much better here.
martin
diff --git a/lisp/window.el b/lisp/window.el
index f4226fa4428..e648ccb270a 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -1692,9 +1692,10 @@ window--min-size-1
0
(window-min-pixel-height window)))
(max (ceiling pixel-height char-size)
- (if (window--min-size-ignore-p window ignore)
- 0
- window-min-height))
+ (cond
+ ((window--min-size-ignore-p window ignore) 0)
+ ((window-minibuffer-p window) 1)
+ (t window-min-height)))
(defun window-sizable (window delta &optional horizontal ignore pixelwise)
"Return DELTA if DELTA lines can be added to WINDOW.
@@ -1888,7 +1889,7 @@ frame-windows-min-size
(mini (window-next-sibling root)))
(+ (window-min-size root horizontal ignore pixelwise)
(if (and mini (not horizontal))
- (window-min-size mini horizontal nil pixelwise)
+ (window-min-size mini horizontal ignore pixelwise)
0
(defun window--max-delta-1 (window delta &optional horizontal ignore trail noup pixelwise)
diff --git a/src/dispnew.c b/src/dispnew.c
index 1a243079e46..8a57866d3ed 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -6054,6 +6054,11 @@ change_frame_size_1 (struct frame *f, int new_width, int new_height,
adjust_frame_size (f, FRAME_PIXEL_TO_TEXT_WIDTH (f, new_width),
FRAME_PIXEL_TO_TEXT_HEIGHT (f, new_height), 5,
pretend, Qchange_frame_size);
+ if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
+ {
+ FrameRows (FRAME_TTY (f)) = new_height;
+ FrameCols (FRAME_TTY (f)) = new_width;
+ }
}
}
diff --git a/src/frame.c b/src/frame.c
index 7f4bf274ad9..9908ec307f7 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -827,14 +827,26 @@ adjust_frame_size (struct frame *f, int new_text_width, int new_text_height,
new_text_lines = dos_new_text_lines - FRAME_TOP_MARGIN (f);
#endif
+ /* Assign new sizes. Do it here to make sure that frame based
+ redisplay gets congruent sizes for the dimensions of the frame
+ matrix and the combined window matrices. */
+ FRAME_COLS (f) = new_text_cols;
+ FRAME_LINES (f) = new_text_lines;
+ FRAME_TEXT_WIDTH (f) = new_text_width;
+ FRAME_TEXT_HEIGHT (f) = new_text_height;
+ FRAME_PIXEL_WIDTH (f) = new_native_width;
+ FRAME_PIXEL_HEIGHT (f) = new_native_height;
+ FRAME_TOTAL_COLS (f) = FRAME_PIXEL_WIDTH (f) / FRAME_COLUMN_WIDTH (f);
+ FRAME_TOTAL_LINES (f) = FRAME_PIXEL_HEIGHT (f) / FRAME_LINE_HEIGHT (f);
+
if (new_inner_width != old_inner_width)
{
resize_frame_windows (f, new_inner_width, true);
/* MSDOS frames cannot PRETEND, as they change frame size by
manipulating video hardware. */
- if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
- FrameCols (FRAME_TTY (f)) = new_text_cols;
+/** if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f)) **/
+/** FrameCols (FRAME_TTY (f)) = new_text_cols; **/
#if defined (HAVE_WINDOW_SYSTEM)
if (WINDOWP (f->tab_bar_window))
@@ -867,22 +879,12 @@ adjust_frame_size (struct frame *f, int new_text_width, int new_text_height,
/* MSDOS frames cannot PRETEND, as they change frame size by
manipulating video hardware. */
- if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
- FrameRows (FRAME_TTY (f)) = new_text_lines + FRAME_TOP_MARGIN (f);
+/** if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f)) **/
+/** FrameRows (FRAME_TTY (f)) = new_text_lines + FRAME_TOP_MARGIN (f); **/
}
else if (new_text_lines != old_text_lines)
call2 (Qwindow__pixel_to_total, frame, Qnil);
- /* Assign new sizes. */
- FRAME_COLS (f) = new_text_cols;
- FRAME_LINES (f) = n
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Michael Albinus writes:
> ;; Symbolic link to a non-directory.
> (list dired-re-sym
> (list (lambda (end)
> - (when-let ((file (dired-file-name-at-point)))
> - (let ((truename (ignore-errors (file-truename file
> - (and (or (not truename)
> - (not (file-directory-p truename)))
> - (search-forward-regexp "\\(.+-> ?\\)\\(.+\\)"
> - end t)
> + (if (not (connection-local-value dired-check-symlinks))
> + (search-forward-regexp
> + "\\(.+-> ?\\)\\(.+\\)" end t)
> + (when-let ((file (dired-file-name-at-point)))
> + (let ((truename (ignore-errors (file-truename file
> + (and (or (not truename)
> + (not (file-directory-p truename)))
> + (search-forward-regexp
> + "\\(.+-> ?\\)\\(.+\\)" end t))
Minor nitpick: given the comment for this section (which seems to
suggest this only applies to symlinks to non-directories), wouldn't it
be "better" to simply have something like below instead for the if-then
case? I.e., a separate entry in dired-font-lock-keywords for the
failsafe.
#+begin_src emacs-lisp
;; Generic face for symbolic links
(list dired-re-sym
(when (not (connection-local-value dired-check-symlinks))
'(".+" (dired-move-to-filename) nil (0 dired-symlink-face
#+end_src
This is essentially what I have in my config today, and seems to behave
as expected.
--
Suhail
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Suhail Singh writes:
Hi Suhail,
>> ;; Symbolic link to a non-directory.
>> (list dired-re-sym
>> (list (lambda (end)
>> - (when-let ((file (dired-file-name-at-point)))
>> - (let ((truename (ignore-errors (file-truename file
>> - (and (or (not truename)
>> - (not (file-directory-p truename)))
>> - (search-forward-regexp "\\(.+-> ?\\)\\(.+\\)"
>> - end t)
>> + (if (not (connection-local-value dired-check-symlinks))
>> + (search-forward-regexp
>> + "\\(.+-> ?\\)\\(.+\\)" end t)
>> + (when-let ((file (dired-file-name-at-point)))
>> + (let ((truename (ignore-errors (file-truename file
>> + (and (or (not truename)
>> +(not (file-directory-p truename)))
>> +(search-forward-regexp
>> + "\\(.+-> ?\\)\\(.+\\)" end t))
>
> Minor nitpick: given the comment for this section (which seems to
> suggest this only applies to symlinks to non-directories), wouldn't it
> be "better" to simply have something like below instead for the if-then
> case? I.e., a separate entry in dired-font-lock-keywords for the
> failsafe.
>
> #+begin_src emacs-lisp
> ;; Generic face for symbolic links
> (list dired-re-sym
> (when (not (connection-local-value dired-check-symlinks))
> '(".+" (dired-move-to-filename) nil (0 dired-symlink-face
> #+end_src
>
> This is essentially what I have in my config today, and seems to behave
> as expected.
Possible, but I don't see that one version is "better" or "worse" than
the other. So I don't see a need to change it.
Best regards, Michael.
bug#72986: Disabling menu-bar-mode changes size of new frames
On Sun, 8 Sept 2024 at 15:21, martin rudalics wrote: > >> > >> Do you get an assertion failure already before the C-x 5 2? > > > > No. > > Thanks. Did you ever get an assertion failure for the original frame? > I don't think so, no. If not, then we should try to understand why not. Please with pristine > master replace the initial assignment of 'frame-size-history' in frame.c > from > >frame_size_history = Qnil; > > to > >frame_size_history = Fcons (make_fixnum (100), Qnil); > > start Emacs -Q and tell me the contents of the *frame-size-history* > buffer. There isn't one. > Can you try not using any scaling experimentally? Jan always complained > that GTK does not handle scaling orderly (that is, in our sense). > I changed scaling to 100%, and it doesn't make any difference. Thanks for the explanations of the other points. -- https://rrt.sc3d.org
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Eli Zaretskii writes: Hi Eli, >> Tramp is in a loop, waiting for results from the remote side. I don't >> know how to implement this differently. > > What kind of loop? Can you point me to the code which loops there? The umbrella function is tramp-send-command. It sends the command to remote via tramp-send-string, and waits then for a proper shell prompt via tramp-wait-for-output. The latter function calls tramp-wait-for-regexp, which loops using tramp-accept-process-output. Best regards, Michael.
bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
> Date: Sun, 8 Sep 2024 16:43:54 +0200 > Cc: Eli Zaretskii , 73...@debbugs.gnu.org > From: martin rudalics > > > In cmcheckmagic we have: > >if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1) > >emacs_abort (); > > > > Is this an assertion that needs to always hold? > > I very strongly doubt so myself. And strangely it's _always_ an > off-by-one error here just as you sketched below. I don't think it's an off-by-one. It's simply that Emacs draws the screen top to bottom, so the very first row that violates the assertion by exceeding FrameRows is the only one that is seen.
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Michael Albinus writes:
>>> ;; Symbolic link to a non-directory.
>>> ...
>>> + "\\(.+-> ?\\)\\(.+\\)" end t))
>>
>> Minor nitpick: given the comment for this section (which seems to
>> suggest this only applies to symlinks to non-directories), wouldn't it
>> be "better" to simply have something like below instead for the if-then
>> case? I.e., a separate entry in dired-font-lock-keywords for the
>> failsafe.
>>
>> #+begin_src emacs-lisp
>> ;; Generic face for symbolic links
>> (list dired-re-sym
>> (when (not (connection-local-value dired-check-symlinks))
>> '(".+" (dired-move-to-filename) nil (0 dired-symlink-face
>> #+end_src
>>
>> This is essentially what I have in my config today, and seems to behave
>> as expected.
>
> Possible, but I don't see that one version is "better" or "worse" than
> the other.
Understood.
> So I don't see a need to change it.
The comment ";; Symbolic link to a non-directory." should probably be
updated in that case, right? Apologies for the noise, in case I have
misunderstood the patch.
I should be able to test out the patch later this coming week. In case
that would be helpful, please let me know. Thank you for adding this.
--
Suhail
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
> From: Michael Albinus > Cc: suhailsingh...@gmail.com, 73...@debbugs.gnu.org > Date: Sun, 08 Sep 2024 17:26:40 +0200 > > Eli Zaretskii writes: > > >> Tramp is in a loop, waiting for results from the remote side. I don't > >> know how to implement this differently. > > > > What kind of loop? Can you point me to the code which loops there? > > The umbrella function is tramp-send-command. It sends the command to > remote via tramp-send-string, and waits then for a proper shell prompt > via tramp-wait-for-output. The latter function calls > tramp-wait-for-regexp, which loops using tramp-accept-process-output. Did you try either calling accept-process-output with a non-zero timeout of, say, 5 msec, or inserting a (sit-for 0.005) into the loop which calls tramp-accept-process-output? Waiting for a process to respond should try not to spin without sleeping for a few milliseconds between polling attempts.
bug#72765: Eglot + Clangd + Company + non-empty suffix = duplicate text
On Sun, Sep 8, 2024 at 3:41 AM Dmitry Gutov wrote:
>
> On 03/09/2024 16:43, João Távora wrote:
> > On Tue, Sep 3, 2024 at 2:20 PM Dmitry Gutov wrote:
> >> On 01/09/2024 17:28, Dmitry Gutov wrote:
> * the rust-analyzer test you added recently -- and which you said was
> very brittle -- is indeed very brittle: I cannot get it to pass. We
> should fix it, or just delete it and do those rust-analyzer tests
> manually each time we touch this area.
> >>> Could you give more details? It is indeed more brittle in theory, but on
> >>> my machine it's passing every time.
> >> Yeah, I see it now - it succeeds in an interactive session and fails in
> >> batch mode. Not sure it was the same when the patch was committed
> >> (hopefully not).
> >>
> >> Might be due to window configuration being different...
> > Yes, I was trying batch mode. make -C test eglot-tests or something
> > similar. Please fix it or delete it (or disable it).
>
> Looking at minibuffer-tests.el, the above might be a solution, but it
> gets me a core dump instead:
>
> diff --git a/test/lisp/progmodes/eglot-tests.el
> b/test/lisp/progmodes/eglot-tests.el
> index e0168baee54..fa3b63b38dc 100644
> --- a/test/lisp/progmodes/eglot-tests.el
> +++ b/test/lisp/progmodes/eglot-tests.el
> @@ -711,7 +711,8 @@ eglot-test-rust-completion-exit-function
> (search-forward "v.count_on")
> (let ((minibuffer-message-timeout 0)
> ;; Fail at (ding) if completion fails.
> -(executing-kbd-macro t))
> +(executing-kbd-macro t)
> +(redisplay-skip-initial-frame nil))
> (when (buffer-live-p "*Completions*")
> (kill-buffer "*Completions*"))
> ;; The design is pretty brittle, we'll need to monitor the
>
>
> Will follow up later if nobody beats me to it (can others reproduce the
> crash?)
This now aborts (segfault?). At least something different.
So, for the record, before this patch with the latest emacs-30, I get the
results in failure1.txt and with your last redisplay-skip-initial-frame patch
I get failure2.txt.
I've produced these files with
make -C test eglot-tests SELECTOR=\"rust-completion\" 2>&1 | tee failure1.txt
make -C test eglot-tests SELECTOR=\"rust-completion\" 2>&1 | tee failure2.txt
$ rust-analyzer --version
rust-analyzer 1 (0f7f68dad2 2024-08-27)
$ src/emacs --version
GNU Emacs 30.0.90
Development version 89c99891b2b3 on emacs-30 branch; build date 2024-09-08.
Copyright (C) 2024 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
make: Entering directory '/home/capitaomorte/Source/Emacs/emacs-30/test'
make[1]: Entering directory '/home/capitaomorte/Source/Emacs/emacs-30/test'
GEN lisp/progmodes/eglot-tests.log
Running 1 tests (2024-09-08 16:46:42+0100, selector ‘"rust-completion"’)
[eglot-tests] [eglot-test-rust-completion-exit-function]: test start
Creating binary (application) package
note: see more `Cargo.toml` keys and their definitions at
https://doc.rust-lang.org/cargo/reference/manifest.html
[eglot] Connected! Server `rust-analyzer' now managing `(rust-mode
rust-ts-mode)' buffers in project `cmpl-project'.
[eglot] Connected! Server `rust-analyzer' now managing `(rust-mode
rust-ts-mode)' buffers in project `cmpl-project'.
[eglot-tests] waiting for `(and (string= method $/progress)
rustAnalyzer/Indexing (equal params '(:token rustAnalyzer/Indexing :value
(:kind begin :title Indexing :cancellable :json-false :percentage 0'
[eglot-tests] detected: $/progress
No match
[eglot-tests] [eglot-test-rust-completion-exit-function]: FAILED
[eglot] Asking EGLOT (cmpl-project/(rust-mode rust-ts-mode)) politely to
terminate
[jsonrpc] (warning) Sentinel for EGLOT (cmpl-project/(rust-mode
rust-ts-mode))<1> still hasn't run, deleting it!
Warning (jsonrpc): Sentinel for EGLOT (cmpl-project/(rust-mode
rust-ts-mode))<1> still hasn't run, deleting it!
[jsonrpc] Server exited with status 9
[eglot-tests] Non-critical cleanup error: (cl-assertion-failed (memq id
track-changes--trackers))
[eglot-tests] contents of ` *EGLOT (cmpl-project/(rust-mode rust-ts-mode))
output*':
[eglot-tests] contents of ` *EGLOT (cmpl-project/(rust-mode rust-ts-mode))
stderr*':
Process EGLOT (cmpl-project/(rust-mode rust-ts-mode)) stderr<1> finished
[eglot-tests] contents of `*EGLOT (cmpl-project/(rust-mode rust-ts-mode))
events*':
[jsonrpc] D[16:46:42.609] Running language server: rust-analyzer
[jsonrpc] e[16:46:42.610] --> initialize[1]
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"processId":52775,"clientInfo":{"name":"Eglot","version":"1.17.30"},"rootPath":"/tmp/eglot--fixture-XCmCqo/cmpl-project/","rootUri":"file:///tmp/eglot--fixture-XCmCqo/cmpl-project","initializationOptions":{},"capabilities":{"workspace":{"applyEdit":true,"exe
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Suhail Singh writes: >> So I don't see a need to change it. > > The comment ";; Symbolic link to a non-directory." should probably be > updated in that case, right? Apologies for the noise, in case I have > misunderstood the patch. Sure. I changed it already in my master checkout, after you pointed me to this. > I should be able to test out the patch later this coming week. In case > that would be helpful, please let me know. Thank you for adding this. Yes, please do. I will also wait for Eli's OK, and then I will push it to the master branch. Plus little bit of doc in the Emacs and Tramp manuals. Best regards, Michael.
bug#73050: 30.0.90; Empty tool tip when hovering over tab-bar separator
>> >> This is only a minor issue. After enabling `tab-bar-mode' when hovering >> >> with the mouse over the `tab-bar-separator' space, an empty tool tip >> >> will be shown after a short delay. >> >> >> >> To reproduce: >> >> >> >> 1. Start emacs -Q >> >> 2. M-x tab-bar-mode >> >> 3. Move the mouse pointer over the space right after the "*scratch*" tab >> >> >> >> Would it make sense to somehow prevent displaying blank tool tips, e.g., >> >> via the following advice? Or maybe blank tool tips could be prevented on >> >> the tab-bar level? >> >> >> >> (defun x-show-tip-adv (str &rest _) (string-blank-p str)) >> >> (advice-add #'x-show-tip :before-until #'x-show-tip-adv) >> > >> > Juri, can we prevent such empty tooltips from being shown by tab bar? >> >> Maybe this unasked-for default fallback is not needed after all: >> >> diff --git a/src/xdisp.c b/src/xdisp.c >> index f9a10267bad..18834c6b781 100644 >> --- a/src/xdisp.c >> +++ b/src/xdisp.c >> @@ -15155,8 +15155,6 @@ note_tab_bar_highlight (struct frame *f, int x, int >> y) >>help_echo_object = help_echo_window = Qnil; >>help_echo_pos = -1; >>help_echo_string = AREF (f->tab_bar_items, prop_idx + TAB_BAR_ITEM_HELP); >> - if (NILP (help_echo_string)) >> -help_echo_string = AREF (f->tab_bar_items, prop_idx + >> TAB_BAR_ITEM_CAPTION); >> } >> >> #endif /* HAVE_WINDOW_SYSTEM */ > > Do you remember why was this introduced? It was copy-pasted from tool-bar code.
bug#73117: 30.0.90; Imenu missing entries when flattening by group
> Maybe using `(setopt completion-auto-help t)` > and hitting TAB is a better method. Or just using `(setopt imenu-eager-completion-buffer nil)` because otherwise with its default value you need to hit '?' (minibuffer-completion-help) instead of TAB to show the completions buffer with two identical completions in different groups. > I did try adding your suggested settings to the above code snippet, > but they did not seem to improve anything with regards to what shows > up in the completions buffer: > > ``` > (setopt completions-group t) > (setopt minibuffer-visible-completions t) > ``` I'm so sorry, I forgot to check with `emacs -Q`, and there is an additional important setting that affects the groups: ``` (setopt completions-group t) (setopt completions-format 'vertical) ``` The default value of 'completions-format' is 'horizontal' that doesn't support groups, and I don't know why. Maybe Daniel (Cc:ed) could help us understand why 'completion--insert-horizontal' doesn't display groups.
bug#73018: 31.0.50; wdired + replace-regexp only modifies the visible portion of the buffer
>> > Maybe this is reproducible only on very long Dired buffers?
>
> After following the recipe literally, I could reproduce that thing, too.
>
> Maybe this issue occurring depends on what exactly is replaced - symlink
> targets. In this case, (font-lock-ensure) does make a
> difference.
>
> Yesterday I had experimented with replacing in symlink names - in that
> case, the whole buffer had been considered.
I tried this:
(dired "/dev/char")
M-: (buffer-substring (- (point-max) 2) (- (point-max) 1))
=> #("7" 0 1 (fontified nil invisible dired-hide-details-link))
M-> ;; (end-of-buffer)
M-: (buffer-substring (- (point-max) 2) (- (point-max) 1))
=> #("7" 0 1 (face default dired-symlink-filename t fontified t invisible
dired-hide-details-link))
And indeed, after going to the end of the Dired buffer
the last file gets an additional property `dired-symlink-filename'
used by Isearch/Replace.
Also noticed that doing the first replacement always raises an error:
Debugger entered--Lisp error: (error "Match data clobbered by buffer
modification hooks")
replace-match("!" nil nil)
replace-match-maybe-edit("!" nil nil nil (672 673 #) nil)
perform-replace("7" "!" t t nil nil nil nil nil nil nil)
query-replace-regexp("7" "!" nil nil nil nil nil)
funcall-interactively(query-replace-regexp "7" "!" nil nil nil nil nil)
command-execute(query-replace-regexp)
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Eli Zaretskii writes: >> >> Tramp is in a loop, waiting for results from the remote side. I don't >> >> know how to implement this differently. >> > >> > What kind of loop? Can you point me to the code which loops there? >> >> The umbrella function is tramp-send-command. It sends the command to >> remote via tramp-send-string, and waits then for a proper shell prompt >> via tramp-wait-for-output. The latter function calls >> tramp-wait-for-regexp, which loops using tramp-accept-process-output. > > Did you try either calling accept-process-output with a non-zero > timeout of, say, 5 msec, or inserting a (sit-for 0.005) into the loop > which calls tramp-accept-process-output? > > Waiting for a process to respond should try not to spin without > sleeping for a few milliseconds between polling attempts. A constant delay busy-wait would be better than what's there today. A straightforward exponential back-off (start with something small like 0.005 and double on each "still-waiting" case till something larger like 0.5) could be even better. However, I thought you'd be proposing something like registering a "callback". Out of curiosity, since I am unfamiliar with the relevant Emacs internals, would it not be possible to add a function to the equivalent of `after-change-functions' that processes the output? -- Suhail
bug#72986: Disabling menu-bar-mode changes size of new frames
> If not, then we should try to understand why not. Please with pristine >> master replace the initial assignment of 'frame-size-history' in frame.c >> from >> >> frame_size_history = Qnil; >> >> to >> >> frame_size_history = Fcons (make_fixnum (100), Qnil); >> >> start Emacs -Q and tell me the contents of the *frame-size-history* >> buffer. > > > There isn't one. Silly me. You have to evaluate (frame--size-history) first. Then it should be there. > I changed scaling to 100%, and it doesn't make any difference. Another pipe dream gone. martin
bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
> I don't think it's an off-by-one. It's simply that Emacs draws the > screen top to bottom, so the very first row that violates the > assertion by exceeding FrameRows is the only one that is seen. You're right. martin
bug#73117: 30.0.90; Imenu missing entries when flattening by group
On Sun, Sep 8, 2024 at 12:42 PM Juri Linkov wrote:
>
> > Maybe using `(setopt completion-auto-help t)`
> > and hitting TAB is a better method.
>
> Or just using `(setopt imenu-eager-completion-buffer nil)`
> because otherwise with its default value you need to hit
> '?' (minibuffer-completion-help) instead of TAB
> to show the completions buffer with two identical
> completions in different groups.
>
Ah, thanks! Yes, I'm used to using Vertico so I'm not very familiar
with the default settings/bindings. In fact that's how I first ran
into this issue using Vertico and Imenu with `imenu-flatten` set to
"group".
> I'm so sorry, I forgot to check with `emacs -Q`, and there is
> an additional important setting that affects the groups:
>
> ```
> (setopt completions-group t)
> (setopt completions-format 'vertical)
> ```
>
> The default value of 'completions-format' is 'horizontal'
> that doesn't support groups, and I don't know why.
>
> Maybe Daniel (Cc:ed) could help us understand
> why 'completion--insert-horizontal' doesn't display groups.
No worries, at least I know I'm not going crazy, lol.
Indeed, when I set `completions-format` to "vertical" it does show all
entries. I then expanded this example to see what happens with 3
entries with both "horizontal" and "vertical" values for
`completions-format`. With a three section menu (see example below),
and format set to "horizontal", it does show multiple groups
vertically. However, even under this condition, the groups which had
identical entries only show up once (which seems like a bug).
The following example configures `imenu-flatten" to "group" and then
shows the menu, first with `completions-format` set to "horizontal"
and then "vertical".
```elisp
(progn
(setopt completions-group t)
(setopt imenu-eager-completion-buffer nil)
(setopt minibuffer-visible-completions t)
(setopt imenu-flatten 'group)
(require 'imenu)
(dolist (format '(horizontal vertical))
(setopt completions-format format)
(imenu-choose-buffer-index (format "(%s) Index item: " format)
`(("XYZ" . (("123" . ,(point-min-marker
("Bar" . (("Foo" . ,(point-min-marker
("Baz" . (("Foo" . ,(point-max-marker
```
--8<---cut here---start->8---
Click or type RET on a completion to select it.
Type , , , to move point between completions.
3 possible completions:
XYZ
123
Bar
Foo
--8<---cut here---end--->8---
--8<---cut here---start->8---
Click or type RET on a completion to select it.
Type , , , to move point between completions.
3 possible completions:
XYZ
123
Bar
Foo
Baz
Foo
--8<---cut here---end--->8---
bug#72986: Disabling menu-bar-mode changes size of new frames
On Sun, 8 Sept 2024 at 17:54, martin rudalics wrote: > > If not, then we should try to understand why not. Please with pristine > >> master replace the initial assignment of 'frame-size-history' in > frame.c > >> from > >> > >> frame_size_history = Qnil; > >> > >> to > >> > >> frame_size_history = Fcons (make_fixnum (100), Qnil); > >> > >> start Emacs -Q and tell me the contents of the *frame-size-history* > >> buffer. > > > > > > There isn't one. > > Silly me. You have to evaluate > > (frame--size-history) > > first. Then it should be there. > Yes, sorry, I didn't think of it either. Here's the output: Frame size history of # x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875, IS=80x25~>1296x875, MS=32x70 IH IV gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36, NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260, MS=160x175 scroll-bar-height (3), MS=160x175 menu-bar-lines (2), MS=160x175 x_create_frame_2 (0), MS=160x175 xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260 xg_frame_set_char_size (5), MS=32x70 IH IV x_make_frame_visible MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260 ConfigureNotify, PS=1328x1260, XS=1328x1260, DS=1328x1260 xg_frame_resized, unchanged, PS=1328x1260, XS=1328x1260 ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=1328x1260 xg_frame_resized, changed, PS=1328x1260, XS=1328x1258 change_frame_size_1, delayed, PS=1328x1260, XS=1328x1258, DS=1328x1260 change_frame_size (5), TS=1280x1260~>1280x1258, TC=80x36~>80x35, NS=1328x1260~>1328x1258, IS=1328x1260~>1328x1258, MS=32x70 IH IV tool-bar-lines (2), MS=160x175 xg_frame_set_char_size, visible, PS=1328x1258, XS=1328x1258 ConfigureNotify, PS=1328x1258, XS=1328x1258 xg_frame_resized, unchanged, PS=1328x1258, XS=1328x1258 ConfigureNotify, PS=1328x1258, XS=1280x1354 xg_frame_resized, changed, PS=1328x1258, XS=1280x1354 change_frame_size_1, delayed, PS=1328x1258, XS=1280x1354 change_frame_size (5), TS=1280x1258~>1232x1354, TC=80x35~>77x38, NS=1328x1258~>1280x1354, IS=1328x1258~>1280x1354, MS=32x70 IH IV set_window_configuration (4), MS=160x175 IH IV -- https://rrt.sc3d.org
bug#73050: 30.0.90; Empty tool tip when hovering over tab-bar separator
> From: Juri Linkov > Cc: m...@daniel-mendler.de, 73...@debbugs.gnu.org > Date: Sun, 08 Sep 2024 19:40:18 +0300 > > >> Maybe this unasked-for default fallback is not needed after all: > >> > >> diff --git a/src/xdisp.c b/src/xdisp.c > >> index f9a10267bad..18834c6b781 100644 > >> --- a/src/xdisp.c > >> +++ b/src/xdisp.c > >> @@ -15155,8 +15155,6 @@ note_tab_bar_highlight (struct frame *f, int x, > >> int y) > >>help_echo_object = help_echo_window = Qnil; > >>help_echo_pos = -1; > >>help_echo_string = AREF (f->tab_bar_items, prop_idx + > >> TAB_BAR_ITEM_HELP); > >> - if (NILP (help_echo_string)) > >> -help_echo_string = AREF (f->tab_bar_items, prop_idx + > >> TAB_BAR_ITEM_CAPTION); > >> } > >> > >> #endif /* HAVE_WINDOW_SYSTEM */ > > > > Do you remember why was this introduced? > > It was copy-pasted from tool-bar code. But on the tool bar there are no empty space between buttons. On the tab bar, there is. What I don't understand is why those empty spaces have tooltips. Because each tab-bar button has a valid, non-nil tooltip, so the problem is with the tooltips popped up when the mouse is between buttons. Do you understand why this happens?
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
> From: Suhail Singh > Cc: Michael Albinus , suhailsingh...@gmail.com, > 73...@debbugs.gnu.org > Date: Sun, 08 Sep 2024 12:46:39 -0400 > > Eli Zaretskii writes: > > > Waiting for a process to respond should try not to spin without > > sleeping for a few milliseconds between polling attempts. > > A constant delay busy-wait would be better than what's there today. It isn't a delay, or at least the delay is not the main point. The main point is to yield the CPU, and that usually has dramatic effect on CPU load. > However, I thought you'd be proposing something like registering a > "callback". Out of curiosity, since I am unfamiliar with the relevant > Emacs internals, would it not be possible to add a function to the > equivalent of `after-change-functions' that processes the output? accept-process-output already does that. Except that with a timeout of zero, it just checks whether any output arrived, and if not, returns immediately. Adding a timeout will AFAIU cause us to let the OS preempt our execution thread and reschedule it only if no output arrives during the timeout.
bug#73117: 30.0.90; Imenu missing entries when flattening by group
Juri Linkov writes: > Maybe Daniel (Cc:ed) could help us understand > why 'completion--insert-horizontal' doesn't display groups. If I remember correctly, I didn't add group titles to the horizontal formatting in order to keep the display more dense, with the goal of fitting as many candidates on the screen as possible. In my Vertico package, I am using a similar strategy, where group titles are not shown for the flat and grid display modes. In any case, there shouldn't be a technical reason which prevents us from showing the titles also for the horizontal display. Daniel
bug#70007: [PATCH] native JSON encoder
7 sep. 2024 kl. 17.52 skrev Eli Zaretskii : > OK, so let's go with unconditionally unibyte, as it seems to be the > consensus here. That change has now been pushed to emacs-30. Feel free to adjust as required.
bug#73117: 30.0.90; Imenu missing entries when flattening by group
On Sun, Sep 8, 2024 at 2:28 PM Daniel Mendler wrote: > > Juri Linkov writes: > > > Maybe Daniel (Cc:ed) could help us understand > > why 'completion--insert-horizontal' doesn't display groups. > > If I remember correctly, I didn't add group titles to the horizontal > formatting in order to keep the display more dense, with the goal of > fitting as many candidates on the screen as possible. In my Vertico > package, I am using a similar strategy, where group titles are not shown > for the flat and grid display modes. In any case, there shouldn't be a > technical reason which prevents us from showing the titles also for the > horizontal display. It appears to be this line in `completion--insert-horizontal` which is causing all the trouble. When I comment that out, I get the output I'm expecting. Looking at the difference between `completion--insert-horizontal` and `completion--insert-vertical`, that check happens after the check for `group-fun`. Maybe `completion--insert-horizontal` should be restructured similarly? ```elisp (unless (equal last-string str) ; Remove (consecutive) duplicates. ```
bug#72701: eglot crash when project-files-relative-names t
On 08/09/2024 13:56, João Távora wrote: On Sun, Sep 8, 2024 at 3:24 AM Dmitry Gutov wrote: On 07/09/2024 10:20, Eli Zaretskii wrote: Ping! Is this issue resolved and can be closed, or do we need to do anything else here? I suggest installing the following. Not a hard necessity, but seems like an improvement: Let's not, for all the reasons enunciated up-thread. Very well - I've just installed the docstring update. Thanks, closing.
bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines
Hello, Its seems that the function `buffer-text-pixel-size' is not working as described when there are newlines in the buffer. Here is a quick illustration (on my laptop (frame-char-width) returns 12 pixels): ;; As expected. (with-temp-buffer (insert "abcdef") (car (buffer-text-pixel-size nil nil t))) 72 ;; I suppose it is as expected because newline is not displayed. (with-temp-buffer (insert "\n") (car (buffer-text-pixel-size nil nil t))) 0 ;; ? (with-temp-buffer (insert "abcd\nef") (car (buffer-text-pixel-size nil nil t))) 48 The doc string of `buffer-text-pixel-size' mentions: "Return size of whole text of BUFFER-OR-NAME in WINDOW." So ,I expect that the last example will return 72px (6 x 12px) + 0px for the newline. But the result is 48px, which means that all the text after the first newline is not counted. This also impacts "string-pixel-width" which is supposed to return the pixel size of the passed string, not part of it: (string-pixel-width "abcdef") => 72 (string-pixel-width "\n") => 0 (string-pixel-width "abcd\nef") => 48 (string-pixel-width "abcd\nef\ngh") => 48 At least this limitation should be mentioned in the doc string? A possible fix for `string-pixel-width' could be to remove all the newlines from the passed string before to call `buffer-text-pixel-size'? Something like this: diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el index 4cdb065feeb..c68b3b37f9b 100644 --- a/lisp/emacs-lisp/subr-x.el +++ b/lisp/emacs-lisp/subr-x.el @@ -406,6 +406,11 @@ string-pixel-width face-remapping-alist)) (kill-local-variable 'face-remapping-alist)) (insert string) + ;; Remove newlines. + (forward-line 0) + (while (not (bobp)) +(delete-char -1) +(forward-line 0)) ;; Prefer `remove-text-properties' to `propertize' to avoid ;; creating a new string on each call. (remove-text-properties Thanks! In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) Repository revision: 2ce0d397b12cafcb3e1ac5630bc3fbca61bd6b87 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12014000 System Description: Fedora Linux 40 (KDE Plasma) Configured using: 'configure --with-x-toolkit=gtk3 --with-cairo-xcb --with-native-compilation=no PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LC_TIME: fr_FR.utf8 value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix
bug#73041: 30.0.90; track-changes-mode logs warnings (#70541 regression? not actually fixed?)
>> I wish I could describe exactly what happened. I found
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70541 which sounds
>> very much like what I'm seeing, but I don't use any input method.
Thanks for your description of the problem. A reproducible recipe is of
course better, but sadly, we can't always have what we want.
Let's hope we find that eventually we'll get what we need.
>> Eventually, this pops into *Messages*:
>>
>> #+begin_quote
>> cl--assertion-failed: Assertion failed: (or track-changes--before-no (<=
>> track-changes--before-beg (track-changes--state-beg track-changes--state)
>> beg end (track-changes--state-end track-changes--state)
>> track-changes--before-end))
>> #+end_quote
Hmm... this clearly points to a bug in track-changes.
>> #+begin_quote
>> ⛔ Warning (emacs): Missing/incorrect calls to
>> ‘before/after-change-functions’!!
>> Details logged to ‘track-changes--error-log’
>> #+end_quote
Barring bugs in track-changes, this points to a bug in some other part
of Emacs, which prevents track-changes from getting the info it needs.
Track-changes (and Eglot) are supposedly equipped to deal with such
problems, because we know we still have many of them.
>> Over time, they just keep repeating,
Hmm... `track-changes--recover-from-error` should (as the name suggests)
"recover" so they shouldn't just keep repeating, unless the source of
the problem keeps repeating as well. Or unless there's a bug in
track-changes.
>> although I think killing the
>> buffer and reopening the file makes it stop.
>>
>> If I have inspected ‘track-changes--error-log’ correctly, this is
>> what it contains (looks like some binary, hope it comes through
>> in some useful fashion or another):
It's a list of debug info, one per "recovery". Each debug info is made
of the buffer name, the inconsistency encountered, then a backtrace, and
an extract of (raw) `view-lossage`. Here's your data reformatted:
(("lib.rs" (buffer-size 5254 5218)
((t track-changes--recover-from-error ... nil)
(t track-changes-fetch ... nil)
(t eglot--track-changes-fetch ... nil)
(t eglot--signal-textDocument/didChange nil nil)
(t eglot--signal-textDocument/didSave nil nil)
(t run-hooks ... nil)
(t basic-save-buffer ... nil)
(t save-buffer ... nil)
(t funcall-interactively ... nil)
(t call-interactively ... nil)
(t command-execute ... nil))
[111 (nil . other-window)
103 (nil . recompile)
121 (nil . undefined)
24 96 (nil . next-error)
1 (nil . move-beginning-of-line)
11 ...])
("lib.rs" (buffer-size 5256 5254)
((t track-changes--recover-from-error ... nil)
(t track-changes-fetch ... nil)
(t eglot--track-changes-fetch ... nil)
(t eglot--signal-textDocument/didChange nil nil)
(t eglot--signal-textDocument/didSave nil nil)
(t run-hooks ... nil)
(t basic-save-buffer ... nil)
(t save-buffer nil nil)
(t #[257 "r\211q\210\300 )\207" [save-buffer] 2 ...]
(t map-y-or-n-p ... nil)
(t save-some-buffers ... nil)
(t recompile ... nil)
...)
[19 (nil . save-buffer)
24 24 (nil . exchange-point-and-mark)
23 (nil . kill-region)
24 19 (nil . save-buffer)
backspace (nil . delete-backward-char) ...])
("lib.rs" (buffer-size 5278 5256)
((t track-changes--recover-from-error ... nil)
(t track-changes-fetch ... nil)
(t eglot--track-changes-fetch ... nil)
(t eglot--signal-textDocument/didChange nil nil)
(t eglot--signal-textDocument/didSave nil nil)
(t run-hooks ... nil)
(t basic-save-buffer ... nil)
(t save-buffer ... nil)
(t funcall-interactively ... nil)
(t call-interactively ... nil)
(t command-execute ... nil))
[(nil . backward-word)
2 (nil . backward-char)
67108896 (nil . set-mark-command)
134217734 (nil . forward-sexp)
23 (nil . kill-region)
24 19 (nil . save-buffer)
...])
("lib.rs" (buffer-size 5324 5278)
((t track-changes--recover-from-error ... nil)
(t track-changes-fetch ... nil)
(t eglot--track-changes-fetch ... nil)
(t eglot--track-changes-signal ... nil)
(t #[771 "\211^BZ\211^HG^E] ...)
...)
...)
...)
This suggests the error is always detected "late" when we find that the
buffer-size is not the one we expected, so some buffer change presumably
happened without informing track-changes.
That doesn't explain the assertion failure.
Also, I don't see anything "unusual" in the view-lossage.
>> I wish I could reliably repeat it. Given that it occurs after
>> many hours of work, `emacs -Q` isn't an option.
Thanks.
I stared at the code for a bit trying to see how that assertion failure
can occur, but nothing came to mind yet. I think we'll need more data.
Can you try to install the patch below, then run with
`debug-on-er
bug#72696: Track-changes errors out when file is overwritten using Node.js's fs.writeFile (at least on macOS)
> As far as I can see, the testDocument/didChange request should not be > there. Either the `didClose/didOpen` should not be there, or the `didChange` should not be there. The problem is that we have both. Can you try the patch below, which I suspect should fix your problem? It should get rid of the `didChange` in your recipe. We could also change Eglot so it doesn't do `didClose/didOpen` upon `revert-buffer` (in which case it should/will do the `didChange`), but that should be a separate concern. Stefan diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index 82e99a2c920..a2c9f73fc73 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -2813,6 +2813,8 @@ eglot--signal-textDocument/didChange (defun eglot--signal-textDocument/didOpen () "Send textDocument/didOpen to server." + ;; Flush any potential pending change. + (eglot--track-changes-fetch eglot--track-changes) (setq eglot--recent-changes nil eglot--versioned-identifier 0 eglot--TextDocumentIdentifier-cache nil)
bug#72765: Eglot + Clangd + Company + non-empty suffix = duplicate text
On 08/09/2024 18:51, João Távora wrote: Looking at minibuffer-tests.el, the above might be a solution, but it gets me a core dump instead: diff --git a/test/lisp/progmodes/eglot-tests.el b/test/lisp/progmodes/eglot-tests.el index e0168baee54..fa3b63b38dc 100644 --- a/test/lisp/progmodes/eglot-tests.el +++ b/test/lisp/progmodes/eglot-tests.el @@ -711,7 +711,8 @@ eglot-test-rust-completion-exit-function (search-forward "v.count_on") (let ((minibuffer-message-timeout 0) ;; Fail at (ding) if completion fails. -(executing-kbd-macro t)) +(executing-kbd-macro t) +(redisplay-skip-initial-frame nil)) (when (buffer-live-p "*Completions*") (kill-buffer "*Completions*")) ;; The design is pretty brittle, we'll need to monitor the Will follow up later if nobody beats me to it (can others reproduce the crash?) This now aborts (segfault?). At least something different. So, for the record, before this patch with the latest emacs-30, I get the results in failure1.txt and with your last redisplay-skip-initial-frame patch I get failure2.txt. I've produced these files with make -C test eglot-tests SELECTOR=\"rust-completion\" 2>&1 | tee failure1.txt So it's reproducible. Great! Could someone look into the segfault? The repro steps are simple: 1) apply the patch above, 2) run 'make -C test eglot-tests' or the longer command above which executes just one test from that file. The backtrace that I managed to generate is attached.Core was generated by `../src/emacs --module-assertions --no-init-file --no-site-file --no-site-lisp -'. Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=) at ./nptl/pthread_kill.c:44 Download failed: Invalid argument. Continuing without source file ./nptl/./nptl/pthread_kill.c. 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x794b524428e6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #4 0x557cbe936774 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:480 #5 0x557cbe959e9f in emacs_abort () at sysdep.c:2391 #6 0x557cbe8793fb in try_window_id (w=0x557cc05f09e8) at xdisp.c:22092 #7 redisplay_window (window=0x557cc05f09ed, just_this_one_p=just_this_one_p@entry=false) at xdisp.c:20444 #8 0x557cbe87d13e in redisplay_window_0 (window=window@entry=0x557cc05f09ed) at xdisp.c:18020 #9 0x557cbe9bff71 in internal_condition_case_1 (bfun=bfun@entry=0x557cbe87d10b , arg=arg@entry=0x557cc05f09ed, handlers=, hfun=hfun@entry=0x557cbe835eac ) at eval.c:1637 #10 0x557cbe833d83 in redisplay_windows (window=0x557cc05f09ed) at xdisp.c:17989 #11 0x557cbe867eeb in redisplay_internal () at xdisp.c:17388 #12 0x557cbe86853d in redisplay () at xdisp.c:16563 #13 0x557cbe947be0 in read_char (commandflag=commandflag@entry=0, map=map@entry=0x0, prev_event=prev_event@entry=0x30, used_mouse_menu=used_mouse_menu@entry=0x0, end_time=0x7fff70418740) at keyboard.c:2678 #14 0x557cbe9ebec0 in read_filtered_event (no_switch_frame=no_switch_frame@entry=false, ascii_required=ascii_required@entry=false, error_nonascii=error_nonascii@entry=false, input_method=input_method@entry=false, seconds=seconds@entry=0x794b4e67024f) at lread.c:791 #15 0x557cbe9ec0fa in Fread_event (prompt=0x0, inherit_input_method=0x0, seconds=0x794b4e67024f) at lread.c:941 #16 0x557cbe9c47e8 in eval_sub (form=) at eval.c:2604 #17 0x557cbe9c4df0 in Fprogn (body=) at eval.c:439 #18 0x557cbe9c55a9 in Fcond (args=0x794b4da7fd93) at eval.c:419 #19 0x557cbe9c45b2 in eval_sub (form=) at eval.c:2549 #20 0x557cbe9c4df0 in Fprogn (body=) at eval.c:439 #21 0x557cbe9c45b2 in eval_sub (form=) at eval.c:2549 #22 0x557cbe9c5545 in Fif (args=0x794b4d932be3) at eval.c:394 #23 0x557cbe9c45b2 in eval_sub (form=) at eval.c:2549 #24 0x557cbe9c4df0 in Fprogn (body=, body@entry=0x794b4d932e53) at eval.c:439 #25 0x557cbe9c597f in prog_ignore (body=0x794b4d932e53) at eval.c:450 #26 Fwhile (args=) at eval.c:1130 #27 0x557cbe9c45b2 in eval_sub (form=) at eval.c:2549 #28 0x557cbe9c4df0 in Fprogn (body=) at eval.c:439 #29 0x557cbe9c6210 in FletX (args=) at /home/dgutov/vc/emacs/src/lisp.h:1539 #30 0x557cbe9c45b2 in eval_sub (form=) at eval.c:2549 #31 0x557cbe9c5d5b in Flet (args=) at eval.c:1080 #32 0x557cbe9c45b2 in eval_sub (form=) at eval.c:2549 #33 0x557cbe9c4df0 in Fprogn (body=) at eval.c:439 #34 0x557cbe9c517b in funcall_lambda (fun=, nargs=nargs@entry=0, a
bug#43086: [PATCH] Allow tags backend to not query for TAGS file
On 07/09/2024 09:18, Eli Zaretskii wrote: Maybe just like this? This makes Xref identifier completion not query for TAGS unless already loaded. In many cases that would be TRT, although `C-u M-.` seems to regress (seems like we *would* want to query eagerly there). I don't understand why the obvious way of asking the user whether they would like to generate the tags table is not the solution here. What did I miss? I don't know if it's obvious, given that the optimal scenario at the beginning of the report describes ... allow the backend to never query a TAGS file Adding a query to avoid querying might not be ideal. And if we did query, that would raise a question of where to store the answer (should it be global, or per-project, or temporary somehow?). As it is, we already have a hint of the user preference from the fact that they have visited a TAGS file already (or not), or enabled etags-regen-mode (or not). It's not ironclad, but we could rely on these indicators to decide.
bug#72597: 30.0.60; Eglot: MarkedString with embedded Carriage Return
On Fri, Sep 6, 2024 at 3:31 PM João Távora wrote: > > I would just ask this server's > devs if they wouldn't mind not sending these odd doc snippets. > I've logged an inquiry with the LS developers. Hopefully we'll at least gain some insight with a rationale. https://github.com/AdaCore/ada_language_server/issues/1204
bug#72952: 30.0.90; Want way to break out of Eshell for loop
On 9/2/2024 1:26 AM, Sean Whitton wrote:
X-debbugs-cc: jporterb...@gmail.com
I am trying to run a series of tests like this:
% for test in tests/tests/tagupl* { tests/using-intree $test }
I want the command to give up as soon as one of the tests fails. But I
don't think there is any way to break out of the loop? In POSIX sh, you
could use 'break'.
I actually have a patch sitting in my pile of branches that does this,
but it needs a fair bit more work to get right. The main thing it needs
is to keep 'break' from bubbling up too far (e.g. if you run an Eshell
script from inside a loop, 'break' at the top level of the script
shouldn't break out of the parent loop).
Another way to do something like this would be to embrace the Lispy-ness
of Eshell and add a command-form for 'throw' and 'catch'. Something like:
catch my-tag {
for i in *.el {
do-stuff
if something-or-other { throw my-tag }
}
}
Or even support both 'throw'/'catch' *and* 'break'...
bug#73133: 29.2; EWW fails to render some webpages
To Whom it may concern,
I have recently discovered the website gastonle.ru, however it does not
render with Emacs Web Wowser. It appears to be a relatively simple
website and I cannot see what would prohibit it from rendering.
I have also tried it on an Ubuntu 22.04.4 LTS distro running Emacs 28.1
but it also fails to render. This therefore appears to be a bug in EWW.
---
In GNU Emacs 29.2 (build 1, aarch64-apple-darwin21.6.0, NS
appkit-2113.60 Version 12.6.6 (Build 21G646)) of 2024-01-19 built on
armbob.lan
Windowing system distributor 'Apple', version 10.3.2487
System Description: macOS 14.2.1
Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules 'CFLAGS=-DFD_SETSIZE=1
-DDARWIN_UNLIMITED_SELECT' --with-x-toolkit=no'
Configured features:
ACL GLIB GMP GNUTLS JPEG JSON LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER
PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER ZLIB
Important settings:
value of $LANG: en_NZ.UTF-8
locale-coding-system: utf-8-unix
Major mode: Markdown
Minor modes in effect:
yas-global-mode: t
yas-minor-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
shell-dirtrack-mode: t
server-mode: t
TeX-PDF-mode: t
TeX-source-correlate-mode: t
global-display-line-numbers-mode: t
display-line-numbers-mode: t
whitespace-mode: t
global-page-break-lines-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/Users/ganimard/.emacs.d/elpa/transient-20230919.2146/transient hides
/Applications/Emacs.app/Contents/Resources/lisp/transient
Features:
(shadow sort mail-extr emacsbug files-x vc-hg vc-bzr vc-src vc-sccs
vc-svn vc-cvs vc-rcs log-view vc bug-reference help-fns radix-tree
magit-patch magit-subtree magit-gitignore magit-ediff ediff ediff-merg
ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util
magit-extras face-remap misearch multi-isearch vc-git vc-dispatcher
markdown-mode color dired-aux disp-table hl-todo flycheck forth-mode
forth-spec forth-smie smie forth-syntax llvm-mode splunk-mode ess
lisp-mnt ess-utils ess-custom go-mode find-file ffap etags fileloop xref
rust-utils rust-mode rust-rustfmt rust-playpen rust-compile rust-cargo
yasnippet magit-submodule magit-blame magit-stash magit-reflog
magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-status
magit magit-repos magit-apply magit-wip magit-log which-func imenu
magit-diff smerge-mode diff diff-mode git-commit log-edit pcvs-util
add-log magit-core magit-autorevert autorevert magit-margin
magit-transient magit-process with-editor shell server magit-mode
transient magit-git magit-base magit-section cursor-sensor dash
auctex-latexmk latex latex-flymake flymake-proc flymake project compile
warnings tex-ispell tex-style tex texmathp latex-preview-pane doc-view
filenotify jka-compr image-mode exif auctex ebib ebib-reading-list
ebib-notes org-element org-persist xdg org-id org-refile org ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint
org-pcomplete pcomplete comint ansi-osc ansi-color org-list org-footnote
org-faces org-entities noutline outline icons ob-emacs-lisp ob-core
ob-eval org-cycle org-table org-keys oc org-loaddefs find-func cal-menu
calendar cal-loaddefs ol org-fold org-fold-core org-compat ring avl-tree
generator org-version org-macs ebib-filters ebib-keywords ebib-utils
ebib-db message sendmail yank-media puny dired dired-loaddefs rfc822 mml
mml-sec epa derived epg rfc6068 epg-config gnus-util
text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils
gmm-utils mailheader format-spec parsebib rx hl-line pp crm bibtex
iso8601 time-date writeroom-mode visual-fill-column olivetti
multiple-cursors mc-separate-operations rectangular-region-mode
mc-mark-pop mc-edit-lines mc-hide-unmatched-lines-mode mc-mark-more
thingatpt mc-cycle-cursors multiple-cursors-core advice rect move-text
no-littering compat paredit edmacro kmacro display-line-numbers
whitespace page-break-lines smart-mode-line-atom-one-dark-theme cl-extra
help-mode atom-one-dark-theme use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core finder-inf atom-one-dark-theme-autoloads
auctex-latexmk-autoloads auctex-autoloads tex-site company-autoloads
dracula-theme-autoloads
bug#73131: 28.2; Yielded threads get killed on C-g
When using the Emacs cooperative threading system in a new project, I noticed that calling C-g results in quitting the background thread I create, even when those threads are yielded. Sending this as a bug report per Eli Zaretskii's mention that it may not be expected behavior (https://www.reddit.com/r/emacs/comments/1fbkkii/comment/lm3boja/). Repro recipe: - emacs -Q - `C-x 3` and run `list-threads` in the new window, then return to the older window - `M-:` `(make-thread (lambda () (cl-loop while t do (progn (thread-yield) (sleep-for 30)` and wait for the new thread to yield to the main thread. - `C-g`. The new thread disappears from the `list-threads` window. Note: While I am admittedly on Windows, given this behavior is within the cooperative threads of the Emacs runtime (rather than actual Windows threads) I *really* doubt that has anything to do with it. In GNU Emacs 28.2 (build 2, x86_64-w64-mingw32) of 2022-09-13 built on AVALON Windowing system distributor 'Microsoft Corp.', version 10.0.22631 System Description: Microsoft Windows 10 Home (v10.0.2009.22631.4037) Configured using: 'configure --with-modules --without-dbus --with-native-compilation --without-compress-install CFLAGS=-O2' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM ZLIB Important settings: value of $LC_CTYPE: en_US.UTF-8 value of $LANG: ENU locale-coding-system: cp1252 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs password-cache json map text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils mule-util thread backtrace find-func novice comp comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra help-mode seq byte-opt gv cl-loaddefs cl-lib bytecomp byte-compile cconv iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 84196 8508) (symbols 48 8108 1) (strings 32 24204 4130) (string-bytes 1 796675) (vectors 16 17957) (vector-slots 8 324199 20918) (floats 8 36 215) (intervals 56 256 36) (buffers 992 15))
bug#72870: [PATCH] Flow fill texts after the last hard newline
Pengji Zhang writes: Eli Zaretskii writes: AFAICT, this function exists for the special case of decoding email messages. Can email messages have flowed-encoded text without a hard newline at the end? I think you meant "encoding"? Anyway, if I understand it correctly, an email message should always end with a newline, but it is not necessarily a hard newline. For example, 'message.el' inserts a normal newline: https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/message.el#n4944 I just realized this insertion of newline happens after encoding, so this is irrelevant here. Sorry. It seems that during encoding, no such a newline is added at all. To reproduce: - Run 'emacs -Q' - C-x m C-c C-b - M-x use-hard-newlines RET n - C-x f 10 RET - Eval: (dotimes (i 10) (insert "word ")) - RET RET - Eval: (dotimes (i 10) (insert "word ")) - M-q - C-u M-x mml-preview RET In the preview buffer, the first paragraph is filled but the second is not.
bug#73131: 28.2; Yielded threads get killed on C-g
Swapneil Singh writes: > When using the Emacs cooperative threading system in a new project, I > noticed that calling C-g results in quitting the background thread I > create, even when those threads are yielded. > > Sending this as a bug report per Eli Zaretskii's mention that it may not > be expected behavior > (https://www.reddit.com/r/emacs/comments/1fbkkii/comment/lm3boja/). > > Repro recipe: > - emacs -Q > - `C-x 3` and run `list-threads` in the new window, then return to the > older window > - `M-:` `(make-thread (lambda () (cl-loop while t do (progn > (thread-yield) (sleep-for 30)` and wait for the new thread to yield to > the main thread. > - `C-g`. The new thread disappears from the `list-threads` window. > > > Note: While I am admittedly on Windows, given this behavior is within the > cooperative threads of the Emacs runtime (rather than actual Windows > threads) I *really* doubt that has anything to do with it. Data point: I might be doing something different but I can't reproduce this here on emacs-29.4 nor on emacs30 on GNU/Linux. Andrea
