bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code
> On Sep 11, 2024, at 12:22 PM, m...@ssbb.me wrote:
>
> Wow, thank you so much for diving into this issue! I'll keep track of it in
> tree-sitter repo from now on.
My pleasure ;-)
> It seems like other integrations somehow manage to avoid hanging or crashing
> the main process, so it doesn't affect them?
> I just checked in the Zed editor again to confirm. When I type a={, it fails
> to highlight the rest of the embedded HEEX (but only within the current
> function) though.
I know a couple editors uses async parsing, Zed probably also uses async
parsing.
Yuan
>> On Sep 11, 2024, at 7:45 AM, Yuan Fu wrote:
>>
>>
>>
>>> On Sep 8, 2024, at 12:48 AM, Yuan Fu wrote:
>>>
>>>
>>>
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
>>
>> Good news: not an Emacs bug. Bad news: a tree-sitter bug. Turns out I made
>> an error in my test program, which is the reason why Emacs hangs but the
>> test program doesn’t. Once I fixed the error, the test program hangs too. I
>> submitted a bug report to tree-sitter:
>> https://github.com/tree-sitter/tree-sitter/issues/3620
>>
>> I can finally sleep soundly at night now; and I guess tree-sitter dev will
>> start having sleepless nights :-)
>>
>> Yuan
>>
>
bug#72814: 31.0.50; Add a variable controlling doxygen support in C/C++/Java?
> On Sep 11, 2024, at 5:05 AM, Eli Zaretskii wrote: > >> From: Vincenzo Pupillo >> Cc: Bug Report Emacs , 72...@debbugs.gnu.org >> Date: Wed, 11 Sep 2024 11:40:17 +0200 >> >>> Thanks for taking this up! I won’t signal a warning if doxygen grammar >>> isn’t found. Imagine a user without doxygen grammar, and din’t change >>> c-ts-mode-enable-doxygen: they’ll get a warning whenever they open a C >>> file. >>> We should either set c-ts-mode-enable-doxygen to nil by default, or not >>> warn when doxygen grammar doesn’t exist. Otherwise, the patch looks good to >>> me. >> >> Okay, fine. But Eli said something different... > > Not necessarily. All I said was "issue a user-friendly diagnostic". > We could output the message into *Messages*, and do it only once per > Emacs session. Another idea: use tertiary value for c-ts-mode-enable-doxygen, t for enable (and issue warning if doxygen isn’t present), nil for enable if doxygen exists but don’t issue any warning, ‘disabled for disable. (I don’t think there’s a convention for the three values of tertiary toggle, is that right Eli?) Yuan
bug#64830: 30.0.50 C++ treesitter mode no coloration
> On Sep 11, 2024, at 5:09 AM, Eli Zaretskii wrote:
>
>> From: Yuan Fu
>> Date: Tue, 10 Sep 2024 22:09:04 -0700
>> Cc: stefankan...@gmail.com,
>> a...@muc.de,
>> 64...@debbugs.gnu.org
>>
>> Done. Please take a look at the latest patch, thanks!
>
> LGTM, but...
>
>> +struct treesit_loaded_lang
>> +{
>> + /* The language object. */
>> + TSLanguage *lang;
>> + /* The path to the shared library. */
>> + const char *filename;
>> +};
>> +
>
> ..."path" again.
>
>> +DEFUN ("treesit-grammar-location", Ftreesit_grammar_location,
>> + Streesit_grammar_location,
>> + 1, 1, 0,
>> + doc: /* Return the absolute file name of the grammar file for
>> LANGUAGE.
>> +
>> +If LANGUAGE isn't loaded yet, load it first. If the langauge can't be
>
> A typo.
Oops (^^;) That’s embarrassing. Ok, I fixed everything and pushed to master.
Also, since the original problem is fixed, closing this report.
Yuan
bug#72814: 31.0.50; Add a variable controlling doxygen support in C/C++/Java?
> From: Yuan Fu > Date: Thu, 12 Sep 2024 00:51:20 -0700 > Cc: Vincenzo Pupillo , > Bug Report Emacs , > 72...@debbugs.gnu.org > > > > > On Sep 11, 2024, at 5:05 AM, Eli Zaretskii wrote: > > > >> From: Vincenzo Pupillo > >> Cc: Bug Report Emacs , 72...@debbugs.gnu.org > >> Date: Wed, 11 Sep 2024 11:40:17 +0200 > >> > >>> Thanks for taking this up! I won’t signal a warning if doxygen grammar > >>> isn’t found. Imagine a user without doxygen grammar, and din’t change > >>> c-ts-mode-enable-doxygen: they’ll get a warning whenever they open a C > >>> file. > >>> We should either set c-ts-mode-enable-doxygen to nil by default, or not > >>> warn when doxygen grammar doesn’t exist. Otherwise, the patch looks good > >>> to me. > >> > >> Okay, fine. But Eli said something different... > > > > Not necessarily. All I said was "issue a user-friendly diagnostic". > > We could output the message into *Messages*, and do it only once per > > Emacs session. > > Another idea: use tertiary value for c-ts-mode-enable-doxygen, t for enable > (and issue warning if doxygen isn’t present), nil for enable if doxygen > exists but don’t issue any warning, ‘disabled for disable. (I don’t think > there’s a convention for the three values of tertiary toggle, is that right > Eli?) That could also be OK, but I prefer something that does TRT by default.
bug#73037: 31.0.50; fullscreen tooltips break after loading pdf-tools on MacOS
> From: Paul Nelson > Date: Thu, 5 Sep 2024 11:01:11 +0200 > > I've tested the following setups: > > (1) Emacs master, pdf-tools 1.1.0 > (2) Emacs 29.4, pdf-tools 1.1.0 > > The issue appears with (1) but not (2), so I figured I'd report it as > a bug with Emacs rather than pdf-tools, but would welcome other > suggestions. > > Steps to reproduce: > > 1. Install pdf-tools (e.g., via list-packages) > > 2. Emacs -Q > > 3. Evaluate the following: > > (package-initialize) > (use-package pdf-tools > :config > (pdf-tools-install :no-query)) > > 4. Visit any pdf file. > > These steps put Emacs in a state where tooltips behave badly: when the > current frame is fullscreen (via (toggle-frame-fullscreen)), tooltips > display in a separate fullscreen frame rather than as a child frame. > > All tooltips are affected, not just those produced by pdf-tools. For > example, (x-show-tip "This is a tooltip." (selected-frame) nil 5) > triggers the issue, as does mousing over any link in *Help*. Could you please report this to the developers of pdf-tools first, and ask them to look into the issue? If they identify some issue with core Emacs functionality, please then come back here with the details, or ask them to post those details. Thanks.
bug#73144: [PATCH] Simple typo in `clean-buffer-list'
> Date: Mon, 09 Sep 2024 15:45:39 +0200 > From: Manuel Giraud via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Here is a patch for a simple harmless typo in `clean-buffer-list'. Thanks, installed on the master branch, and closing the bug.
bug#73150: [PATCH] Human readable last display time of killed buffer
> Date: Mon, 09 Sep 2024 17:23:57 +0200 > From: Manuel Giraud via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > This patch display a human readable version of `buffer-display-time' > when said buffer is selected to be killed. Thanks, installed on the master branch, and closing the bug.
bug#73037: 31.0.50; fullscreen tooltips break after loading pdf-tools on MacOS
Thanks, will do.
bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
>> It _might_ be incorrect when we allow FRAME_TOTAL_LINES (f) to exceed >> FrameRows (FRAME_TTY (f)) because we refuse to shrink a frame below some >> height. That's why I used the term "probably". If I knew what that >> code does in all consequences, I could tell you more. But I don't know. > > If FRAME_TOTAL_LINES is different from FrameRows at that spot, it's a > bug, isn't it? It depends. On a GUI frame do the following: In *scratch* insert the two lines (insert (format "%s" (frame-native-height))) (insert (format "%s" (window-pixel-height (frame-root-window and then do C-x 2 three times so yet get four windows. Now with the mouse drag the lower border upwards as far as you can. The minibuffer window should have disappeared by now. Evaluate the two lines above by putting point at their end and typing C-x e. You will see that the second value exceeds the first one - the root window got larger than its frame. So the window dimensions as Emacs can reasonably draw them exceed the dimensions of the window as the WM gives them to us. The same thing happens on TTY frames. With split windows, the size of the root window may exceed the size of the terminal window. Whether we now synch FRAME_TOTAL_LINES and FrameRows is just a matter of taste. > I still don't understand what is supposed to happen when we shrink the > frame to less lines/columns than the minimum window dimensions we > allow. There are two minimum window dimensions we "allow": The first are the hard-coded 5/2 values in handle_window_change_signal and additionally imposed in frame_windows_min_size. IIUC neither of these takes care of menu or tab bars nor of any window splitting. The second is the 'frame-windows-min-size' code that takes care of the entire frame layout in an equal fashion for GUI frames and TTY frames. In either case we do not shrink the dimensions of our windows but keep them as in the GUI example above. > Also, I'd be happier if you could describe the sequence of > events that lead to frame and window resizing following a SIGWINCH. IIUC we call change_frame_size, possibly delay it, and eventually call adjust_frame_size just as we do for GUI frames. There's no special magic involved. The problematic thing I see is that the entire cursor wrapping code including the check in cmcheckmagic seem botched because when a window is virtually drawn below the border of the terminal window (as in the GUI example sketched above) we do not check whether the cursor ends up below that border too. In particular the form /* First the degenerate case */ if (row == curY (tty) && col == curX (tty)) /* already there */ return; in cmgoto seems to indicate that we leave the cursor at its current location. Maybe we do that even earlier, for example, in if (curY (tty) == vpos && curX (tty) == hpos) return; of tty_cursor_to. And maybe neither of these is relevant because redisplay simply does nothing if the size of the root window does not change (I wouldn't know where and how redisplay checks that). At the very end the check in cmcheckmagic aborts us in any such case. martin
bug#72952: 30.0.90; Want way to break out of Eshell for loop
Hello,
On Sun 08 Sep 2024 at 05:59pm -07, Jim Porter wrote:
> 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'...
Heh. throw/catch seems like overkill to me but supporting both would be
cool!
--
Sean Whitton
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Suhail Singh writes: Hi Suhail, >> FTR, some years ago (2018?) I tried to use Lisp threads with Tramp. This >> experiment failed. > > OOC, the failure was from hard-to-debug edge cases while trying to get > to feature-parity or something else? IIRC, the major problem were interactive dialogues. See bug#32426 and bug#25214. Best regards, Michael.
bug#20481: 24.5; , Newlines in message-box output don't work on Windows
On 12/09/2024 4:49, Po Lu wrote:
Thanks. Following are a number of minor stylistic comments.
Sorry I missed those. They are corrected in the attached patch.
Lastly, I observe that you have implemented a bespoke dialog parser for
Windows, the likes of which have been a source of difficulties in the
past. Is there any particular reason that you decided against
implementing the w32_dialog_show function called in the "#ifdef
HAVE_DIALOGS" version of w32_popup_dialog?
I left w32_dialog_show as it was in case an implementation for
older versions of windows became available. I can rewrite it
if you think is better that way.
diff --git a/src/menu.c b/src/menu.c
index de4d0964e9c..6b4aaef1715 100644
--- a/src/menu.c
+++ b/src/menu.c
@@ -1594,9 +1594,10 @@ DEFUN ("x-popup-dialog", Fx_popup_dialog,
Sx_popup_dialog, 2, 3, 0,
Lisp_Object selection
= FRAME_TERMINAL (f)->popup_dialog_hook (f, header, contents);
#ifdef HAVE_NTGUI
- /* NTGUI supports only simple dialogs with Yes/No choices. For
-other dialogs, it returns the symbol 'unsupported--w32-dialog',
-as a signal for the caller to fall back to the emulation code. */
+ /* NTGUI on Windows versions before Vista supports only simple
+dialogs with Yes/No choices. For other dialogs, it returns the
+symbol 'unsupported--w32-dialog', as a signal for the caller to
+fall back to the emulation code. */
if (!EQ (selection, Qunsupported__w32_dialog))
#endif
return selection;
diff --git a/src/w32menu.c b/src/w32menu.c
index cea4f4892a4..8ecf7e8e8a7 100644
--- a/src/w32menu.c
+++ b/src/w32menu.c
@@ -52,6 +52,9 @@
#include "w32common.h" /* for osinfo_cache */
+#include "commctrl.h"
+
+/* This only applies to OS versions prior to Vista. */
#undef HAVE_DIALOGS /* TODO: Implement native dialogs. */
#ifndef TRUE
@@ -76,6 +79,11 @@ #define FALSE 0
IN const WCHAR *text,
IN const WCHAR *caption,
IN UINT type);
+typedef HRESULT (WINAPI *TaskDialogIndirect_Proc) (
+IN const TASKDIALOGCONFIG *pTaskConfig,
+OUT int *pnButton,
+OUT int *pnRadioButton,
+OUT BOOL *pfVerificationFlagChecked);
#ifdef NTGUI_UNICODE
GetMenuItemInfoA_Proc get_menu_item_info = GetMenuItemInfoA;
@@ -89,6 +97,8 @@ #define FALSE 0
MessageBoxW_Proc unicode_message_box = NULL;
#endif /* NTGUI_UNICODE */
+TaskDialogIndirect_Proc task_dialog_indirect;
+
#ifdef HAVE_DIALOGS
static Lisp_Object w32_dialog_show (struct frame *, Lisp_Object, Lisp_Object,
char **);
#else
@@ -101,14 +111,157 @@ #define FALSE 0
void w32_free_menu_strings (HWND);
+#define TASK_DIALOG_MAX_BUTTONS 10
+
+static HRESULT
+task_dialog_callback (HWND hwnd, UINT msg, WPARAM wParam,
+ LPARAM lParam, LONG_PTR callback_data)
+{
+ switch (msg)
+{
+case TDN_CREATED:
+ /* Disable all buttons with ID >= 2000 */
+ for (int i = 0; i < TASK_DIALOG_MAX_BUTTONS; i++)
+SendMessage (hwnd, TDM_ENABLE_BUTTON, 2000 + i, FALSE);
+ break;
+}
+ return S_OK;
+}
+
Lisp_Object
w32_popup_dialog (struct frame *f, Lisp_Object header, Lisp_Object contents)
{
-
check_window_system (f);
-#ifndef HAVE_DIALOGS
+ if (task_dialog_indirect)
+{
+ int wide_len;
+
+ CHECK_CONS (contents);
+
+ /* Get the title as an UTF-16 string. */
+ char *title = SSDATA (ENCODE_UTF_8 (XCAR (contents)));
+ wide_len = (sizeof (WCHAR)
+ * pMultiByteToWideChar (CP_UTF8, 0, title, -1, NULL, 0));
+ WCHAR *title_w = alloca (wide_len);
+ pMultiByteToWideChar (CP_UTF8, 0, title, -1, title_w, wide_len);
+ /* Prepare the arrays with the dialog's buttons and return values. */
+ TASKDIALOG_BUTTON buttons[TASK_DIALOG_MAX_BUTTONS];
+ Lisp_Object button_values[TASK_DIALOG_MAX_BUTTONS];
+ int button_count = 0;
+ Lisp_Object b = XCDR (contents);
+
+ while (!NILP (b))
+ {
+ if (button_count >= TASK_DIALOG_MAX_BUTTONS)
+ {
+ /* We have too many buttons. We ignore the rest. */
+ break;
+ }
+
+ Lisp_Object item = XCAR (b);
+
+ if (CONSP (item))
+ {
+ /* A normal item (text . value) */
+ Lisp_Object item_name = XCAR (item);
+ Lisp_Object item_value = XCDR (item);
+
+ CHECK_STRING (item_name);
+
+ item_name = ENCODE_UTF_8 (item_name);
+ wide_len = (sizeof (WCHAR)
+ * pMultiByteToWideChar (CP_UTF8, 0, SSDATA
(item_name),
+ -1, NULL, 0));
+ buttons[button_count].pszButtonText = alloca (wide_len);
+ pMultiByteToWideChar (CP_UTF8, 0, SSDATA (item_name), -1,
+ (LPWSTR)
+ buttons[button_count].pszButtonText,
+ wide_len);
+
bug#73199: soap-client; soap-invoke-internal is not thread-safe
Forward to debbugs From: Michael Albinus Subject: soap-client; soap-invoke-internal is not thread-safe To: Alexandru Harsanyi Date: Thu, 12 Sep 2024 15:57:45 +0200 (19 minutes, 24 seconds ago) In package debbugs, I try to use Emacs Lisp threads when retrieving SOAP data from the debbugs server. However, ocaasionally I run into the error --8<---cut here---start->8--- (error "Attempt to accept output from process debbugs.gnu.org locked to thread #") --8<---cut here---end--->8--- My work around is to advice url-http-create-request --8<---cut here---start->8--- (advice-add 'url-http-create-request :around (lambda (orig-fun) "Set `url-http-attempt-keepalives' to nil." (setq url-http-attempt-keepalives nil) (funcall orig-fun)) '(name debbugs-advice)) --8<---cut here---end--->8--- However, it would be great if soap-invoke-internal could care. Emacs : GNU Emacs 31.0.50 (build 35, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) of 2024-09-12 Package: soap-client
bug#72986: Disabling menu-bar-mode changes size of new frames
On Tue, 10 Sept 2024 at 18:16, martin rudalics wrote: > > Can I just check: do you want me to apply your latest gtkutil-reject.diff > > on top of your previous size_hints.diff, or instead of it? > > Instead of it. > Here is the frame size history: 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=400x340, DS=1328x1260 xg_frame_resized, rejected, PS=1328x1260, XS=400x340, DS=1328x1260 tool-bar-lines (2), MS=160x175 xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260 ConfigureNotify, PS=1328x1260, XS=2560x1346, DS=1328x1260 xg_frame_resized, rejected, PS=1328x1260, XS=2560x1346, DS=1328x1260 ConfigureNotify, PS=1328x1260, XS=2560x1326, DS=1328x1260 xg_frame_resized, rejected, PS=1328x1260, XS=2560x1326, DS=1328x1260 set_window_configuration (4), MS=160x175 IH IV Note that something quite different happens when I open the second frame: it ends up full screen, but the Emacs window only occupies the same space as the initial window (roughly half the screen wide, and a little shorter than the screen). frame-char-width: 16 frame-char-height: 35 -- https://rrt.sc3d.org
bug#73205: 30.0.91; Failed test: uniquify-project-transform at lisp/uniquify-tests.el:130
I'm not certain if this test failure is a bug in Emacs or a problem
with my build.
After building Emacs 30.0.91 from the tarball with
$ ./configure
$ make -j
and then running
$ make test
I get the following test results:
SUMMARY OF TEST RESULTS
---
Files examined: 519
Ran 7898 tests, 7661 results as expected, 1 unexpected, 236 skipped
1 files contained unexpected results:
lisp/uniquify-tests.log
The details of the failed test are:
ELC+ELN lisp/uniquify-tests.elc
GEN lisp/uniquify-tests.log
Running 7 tests (2024-09-12 12:30:54-0400, selector `(not (or (tag
:expensive-test) (tag :unstable)))')
passed 1/7 uniquify-basic (0.049446 sec)
passed 2/7 uniquify-dirs (0.052217 sec)
Test uniquify-project-transform backtrace:
signal(ert-test-failed (((should (equal (mapcar #'buffer-name bufs)
ert-fail(((should (equal (mapcar #'buffer-name bufs) '("README)()
#f(compiled-function () #)()
handler-bind-1(#f(compiled-function () #" "README")))
:form
(equal ("README" "README")
("README" "README"))
:value nil :explanation
(list-elt 1
(arrays-of-different-length 21 11 "README"
"README"
first-mismatch-at 7
FAILED 3/7 uniquify-project-transform (0.042755 sec) at
lisp/uniquify-tests.el:130
passed 4/7 uniquify-rename-to-dir (0.000854 sec)
passed 5/7 uniquify-separator-ignored (0.007538 sec)
passed 6/7 uniquify-separator-style-reverse (0.007087 sec)
passed 7/7 uniquify-space-prefix (0.007681 sec)
Ran 7 tests, 6 results as expected, 1 unexpected (2024-09-12 12:30:55-0400,
0.310196 sec)
1 unexpected results:
FAILED uniquify-project-transform
---
In GNU Emacs 30.0.91 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.41, cairo version 1.18.0) of 2024-09-12 built on fedora
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 39 (Xfce)
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM GTK3
ZLIB
Important settings:
value of $LANG: en_CA.utf8
value of $XMODIFIERS: @im=none
locale-coding-system: utf-8-unix
Major mode: Text
Minor modes in effect:
flyspell-mode: t
recentf-mode: t
erc-track-mode: t
erc-ring-mode: t
erc-notifications-mode: t
erc-netsplit-mode: t
erc-menu-mode: t
erc-match-mode: t
erc-list-mode: t
erc-irccontrols-mode: t
erc-noncommands-mode: t
erc-move-to-prompt-mode: t
erc-readonly-mode: t
erc-button-mode: t
erc-fill-mode: t
erc-stamp-mode: t
erc-autojoin-mode: t
yas-global-mode: t
yas-minor-mode: t
savehist-mode: t
save-place-mode: t
erc-networks-mode: t
electric-pair-mode: t
display-time-mode: t
display-battery-mode: t
desktop-save-mode: t
delete-selection-mode: t
cua-mode: t
tooltip-mode: t
global-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
minibuffer-regexp-mode: t
size-indication-mode: t
column-number-mode: t
line-number-mode: t
global-visual-line-mode: t
visual-line-mode: t
transient-mark-mode: t
auto-encryption-mode: t
auto-compression-mode: t
temp-buffer-resize-mode: t
abbrev-mode: t
Load-path shadows:
None found.
Features:
(shadow sort bbdb-message display-fill-column-indicator mail-extr
compile emacsbug message 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 gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils comp-run comp-common flyspell ispell
vc-git diff-mode track-changes easy-mmode vc-dispatcher warnings
thingatpt find-func org-version org-compat org-macs bbdb-anniv
diary-lib diary-loaddefs cal-menu calendar cal-loaddefs bbdb-com crm
mailabbrev bbdb bbdb-site timezone recentf tree-widget cus-edit pp
ido erc-track erc-ring erc-desktop-notifications notifications
erc-netsplit erc-menu erc-match erc-list erc-goodies erc-pcomplete
time-date pcomplete comint ansi-osc ansi-color ring erc-button
erc-fill erc-stamp wid-edit erc-join modus-vivendi-theme
modus-themes yasnippet-classic-snippets cl-extra yasnippet help-mode
savehist saveplace company pcase erc format-spec erc-backend
erc-networks erc-common erc-compat compat erc-loaddefs elec-pair
time battery dbus xml desktop frameset delsel cua-base cus-load
ace-window-autoloads auctex-autoloads tex-site avy-autoloads
bbdb-autoloads company-autoloads csv-mode-autoloads
debbugs-autoloads ess-autoloads expand-r
bug#73206: 28.2; xml comment with blank lines to do not indent correctly, nxml-mode.el
1. Create foo.xml containing: Notice that we have a blank line in the xml comment. 2. Put the point on 'bar' and press TAB. Notice that the 'bar' line is not indented correctly. Solution The problem is that in nxml-compute-indent-in-delimited-token, there is a (forward-line -1) which assumes that the prior line is indented. In this case the prior line is a blank line and thus doesn't have indentation. After the (forward-line -1), we need to keep going back until we see a non-blank line: (forward-line -1) + (while (looking-at "^[:blank:]*$") +(forward-line -1)) Attached is a patch for nxml-mode.el that fixes the issue. Thanks John In GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.16.0) of 2024-06-25, modified by Debian built on x86-conova-01 Windowing system distributor 'The X.Org Foundation', version 11.0.12101006 System Description: Debian GNU/Linux 12 (bookworm) Configured using: 'configure --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/libexec --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/28.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/28.2/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --with-native-compilation --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/libexec --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/28.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/28.2/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --with-native-compilation --with-cairo --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/emacs-28.2+1=. -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix 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 cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map text-property-search time-date subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd 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 dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 68059 5432) (symbols 48 6639 0) (strings 32 19490 1559) (string-bytes 1 664189) (vectors 16 13926) (vector-slots 8 297636 11873) (floats 8 22 31) (intervals 56 258 0) (buffers 992 10)) --- ./orig/nxml-mode.el 2024-09-12 09:10:46.580451579 -0400 +++ nxml-mode.el 2024-09-12 09:04:48.473571128 -0400 @@ -1522,6 +1522,8 @@ ((progn (goto-char p
bug#73204: Tree-sitter in clojure-ts-mode causes memory leak during parsing
Hi, I am using the precompiled version from https://emacsformacosx.com/builds https://emacsformacosx.com/emacs-builds/Emacs-2024-09-11_00-09-10-69e1aca041c57ba425425d31471e1c8f86d3bf04-universal.dmg I have chosen the latest Emacs 30 version. The min configuration is as follows: (add-to-list 'treesit-extra-load-path (expand-file-name "tree-sitter/" user-emacs-directory)) (add-to-list 'load-path "~/.emacs.d/site-lisp/clojure-ts-mode”) (require 'clojure-ts-mode) ;; debug (setq debug-on-quit t) and I only use clojure-ts-mode package cd ~/.emacs.d/site-lisp git clone https://github.com/clojure-emacs/clojure-ts-mode.git Then, after opening Emacs, I opened the attached file b.clj, moved to line 57, and entered the following characters: (comment At this point, Emacs freezes and becomes unresponsive. I noticed that Emacs' memory usage keeps increasing: 2024-09-12 21:12:23: 806624 KB 2024-09-12 21:12:28: 810720 KB 2024-09-12 21:12:33: 829840 KB 2024-09-12 21:12:38: 1582256 KB 2024-09-12 21:12:43: 4678816 KB 2024-09-12 21:12:48: 7831776 KB 2024-09-12 21:12:53: 10982384 KB 2024-09-12 21:12:58: 14140048 KB 2024-09-12 21:13:03: 17296176 KB 2024-09-12 21:13:08: 20440960 KB 2024-09-12 21:13:13: 23583008 KB 2024-09-12 21:13:18: 26726272 KB 2024-09-12 21:13:24: 29857312 KB 2024-09-12 21:13:29: 33011456 KB 2024-09-12 21:13:34: 36156624 KB 2024-09-12 21:13:39: 38685440 KB 2024-09-12 21:13:44: 34858560 KB 2024-09-12 21:13:49: 30892768 KB Then, Emacs eventually gets killed by the system. The bt.log is the information I was able to retrieve Sincerely, b.clj Description: Binary data bt.log Description: Binary data
bug#73207: 31.0.50; On PGTK frame outer-position and frame-monitor-workarea wrong.
In a PGTK build of Emacs running on KDE Wayland (versions are below) the position of a frame and the size of the workarea are wrong. These work correctly in non-PGTK builds. For example, (frame-edges nil 'outer-edges) returns (0 0 752 840), even though the top-left of the frame is not over pixel 0,0. In a call to (frame-monitor-attributes) the geometry and workarea dimensions are the same. The workarea is correctly reported as smaller in non-PGTK builds. I'd prefer that these be fixed, but if not they ought to be documented in etc/PROBLEMS. In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) of 2024-09-08 built on dmk-laptop-23 Repository revision: 4073c624376148d469a27a7c487a9b2f49d5352a Repository branch: master System Description: Fedora Linux 41 (KDE Plasma Prerelease) Configured using: 'configure 'CFLAGS=-O2 -march=native' --without-pop --with-native-compilation --with-pgtk' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB Important settings: value of $LC_COLLATE: C value of $LC_MONETARY: en_US.UTF-8 value of $LC_NUMERIC: en_US.UTF-8 value of $LC_TIME: C value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=none locale-coding-system: utf-8-unix Major mode: Info Minor modes in effect: global-hi-lock-mode: t hi-lock-mode: t which-function-mode: t global-ligature-mode: t ligature-mode: t tooltip-mode: t global-eldoc-mode: t show-paren-mode: t mouse-wheel-mode: t file-name-shadow-mode: t isearch-fold-quotes-mode: t global-font-lock-mode: t font-lock-mode: t minibuffer-regexp-mode: t buffer-read-only: t column-number-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: The problem occurs with a -Q run, no need for my load path details. Features: (shadow sort gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range gnus-win gnus nnheader range wid-edit emacsbug tabify color tex-mode latexenc verilog-mode-4702 skeleton reporter verilog-mode log-view pcvs-util bug-reference pcase emacs-news-mode noutline outline debug backtrace find-func shortdoc gud conf-mode wdired smerge-mode diff vc vc-git diff-mode track-changes vc-dispatcher cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs parse-time iso8601 mule-util info apropos cl-print help-fns radix-tree pcmpl-unix misearch multi-isearch cperl-mode facemenu mail-extr project add-log compile comp-run comp-common view p-math.el sh-script smie treesit executable files-x p-viewer-laptop browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util p-iimage simtools p-tex-funcs shell pcomplete comint ansi-osc ring man ansi-color hi-lock rmail p-stop-time time-stamp dired-aux p-page dabbrev ps-print ps-print-loaddefs lpr holidays holiday-loaddefs appt p-diary-aux cal-x p-diary-audit diary-lib diary-loaddefs cal-menu calendar cal-loaddefs mic-paren message sendmail mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader ffap url-parse auth-source eieio eieio-core icons password-cache json map byte-opt bytecomp byte-compile url-vars ccl-mode ampl-mode texize chemora-mode cmake-mode thingatpt which-func imenu flyspell ispell gnuplot-mode yaml-mode p-pwf-mode p-autoreload cl-extra help-mode rx cl-seq ligature easy-mmode advice derived sd image-file image-converter dbus xml subr-x cl-macs gv cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd 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 nadvice seq simple cl-generic indonesian philippine 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 abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properti
bug#73172: [PATCH] Move to start of current header in diff-{file, hunk}-prev
Hi Spencer and Stefan, On 10/09/2024 21:40, Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: (The following change is split across two patches; the first one, "move easy-mmode", fixes an unrelated FIXME, which makes the diff in the second patch simpler) If point was after a file or hunk header, the diff-file-prev and diff-hunk-prev commands would move to the start of that header. But if point was *within* the header, they would not move, and would report "No previous file" or "No previous hunk". This differs from the behavior of most other movement commands, e.g. backward-sexp or backward-sentence. This commit fixes diff-file-prev and diff-hunk-prev, as well as other easy-mmode-define-navigation BASE-prev commands. Now these commands move to the start of the containing "thing" just like other movement commands. * lisp/emacs-lisp/easy-mmode.el (easy-mmode--prev): Move to start of current match first. Also discussed here: https://lists.gnu.org/archive/html/help-gnu-emacs/2024-08/msg00367.html Patch#1 seems unequivocally a good thing (easier code iteration) and patch#2 seems good on balance. It does introduce some backward incompatibility in rare cases where I have probably internalized the current behavior already -- for example in the vc-print-root-log output pressing 'p' while on the first line somewhere between the initial '*' and the end of the date dings with "No previous log message", and how will move to bol. But it might be more consistent anyway, given that the there is no ding already if you start out inside the summary text. There aren't many in-tree callers of easy-mmode-define-navigation (diff-mode, log-view, smerge and, uh, cvs-status), and few 3rd party callers, so this seems low-impact. diff-hl-mode is not affected either because it only uses diff-hunk-next, not diff-hunk-prev.
bug#72426: 29.2.50; comint-pager doesn't affect async-shell-command
On 03/08/2024 18:38, Eli Zaretskii wrote: comint-terminfo-terminal affects async-shell-command, why not this? Ugh! A mistake, IMNSHO. But that ship sailed a long time ago, so we cannot fix the mistake. We can avoid enlarging the mistake, though. If the fact that the variable is in comint is the problem, I can rename it and move it elsewhere. I don't think functions that are almost primitives should pay attention to application-level features such as this one. FWIW async-shell-command's behavior is affected by a bunch of other comint-* variables as well because it uses a major mode which inherits from comint-mode (previously it was shell-mode, now shell-command-mode, but that aspect didn't change).
bug#72652: 31.0.50; url-retrieve on non-existent domain gives no indication of error
On 17/08/2024 15:54, Greg Minshall wrote: Patches to report an error in the (mytry 2) case are welcome. that'd be great. thanks. For those who'd like to try their hand at writing the fix, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26835#18 might be relevant, or at least point to the problem area.
bug#73217: 30.0.91; etc/ORG-NEWS typo
> Previously, all the image previews where always left-aligned. "where" should be "were". mike
bug#73218: [PATCH] Fix Fortran indent below do_not_a_loop=42
Tags: patch Hello, Following up from https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00904.html I'm submitting a patch to fix Fortran indentation due to an overly aggressive match for do loops. In GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0) of 2024-08-20 built on t480 Repository revision: ae8f815613c2e072e92aa8fe7b4bcf2fdabc7408 Repository branch: HEAD Windowing system distributor 'The X.Org Foundation', version 11.0.12101004 System Description: Ubuntu 22.04.5 LTS Configured using: 'configure --prefix=/home/kdm/local/emacs' >From ee63122df9d4ad4904030568d56d0ab9f2d200ea Mon Sep 17 00:00:00 2001 From: "Kenneth D. Mankoff" Date: Thu, 12 Sep 2024 11:34:38 -0700 Subject: [PATCH] Fix Fortran indent below do_not_a_loop=42 --- lisp/progmodes/fortran.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/progmodes/fortran.el b/lisp/progmodes/fortran.el index 8a726dfe66e..0643df64f65 100644 --- a/lisp/progmodes/fortran.el +++ b/lisp/progmodes/fortran.el @@ -1631,7 +1631,7 @@ fortran-calculate-indent (setq icol (+ icol fortran-if-indent))) ((looking-at "where[ \t]*(.*)[ \t]*\n") (setq icol (+ icol fortran-if-indent))) - ((looking-at "do\\b") + ((looking-at "do[\\ |0-9]+.*=[\\ a-z0-9_]*,[\\ a-z0-9_]*") (setq icol (+ icol fortran-do-indent))) ((looking-at "\\(structure\\|union\\|map\\|interface\\)\ -- 2.34.1
bug#73204: Tree-sitter in clojure-ts-mode causes memory leak during parsing
> On Sep 12, 2024, at 9:21 AM, vinurs wrote: > > Hi, > > I am using the precompiled version from https://emacsformacosx.com/builds > https://emacsformacosx.com/emacs-builds/Emacs-2024-09-11_00-09-10-69e1aca041c57ba425425d31471e1c8f86d3bf04-universal.dmg > > I have chosen the latest Emacs 30 version. The min configuration is as > follows: > > (add-to-list 'treesit-extra-load-path (expand-file-name "tree-sitter/" > user-emacs-directory)) > (add-to-list 'load-path "~/.emacs.d/site-lisp/clojure-ts-mode”) > (require 'clojure-ts-mode) > ;; debug > (setq debug-on-quit t) > > and I only use clojure-ts-mode package > > cd ~/.emacs.d/site-lisp > git clone https://github.com/clojure-emacs/clojure-ts-mode.git > > Then, after opening Emacs, > I opened the attached file b.clj, moved to line 57, > and entered the following characters: > (comment > > At this point, Emacs freezes and becomes unresponsive. I noticed that Emacs' > memory usage keeps increasing: > 2024-09-12 21:12:23: 806624 KB > 2024-09-12 21:12:28: 810720 KB > 2024-09-12 21:12:33: 829840 KB > 2024-09-12 21:12:38: 1582256 KB > 2024-09-12 21:12:43: 4678816 KB > 2024-09-12 21:12:48: 7831776 KB > 2024-09-12 21:12:53: 10982384 KB > 2024-09-12 21:12:58: 14140048 KB > 2024-09-12 21:13:03: 17296176 KB > 2024-09-12 21:13:08: 20440960 KB > 2024-09-12 21:13:13: 23583008 KB > 2024-09-12 21:13:18: 26726272 KB > 2024-09-12 21:13:24: 29857312 KB > 2024-09-12 21:13:29: 33011456 KB > 2024-09-12 21:13:34: 36156624 KB > 2024-09-12 21:13:39: 38685440 KB > 2024-09-12 21:13:44: 34858560 KB > 2024-09-12 21:13:49: 30892768 KB > > Then, Emacs eventually gets killed by the system. > The bt.log is the information I was able to retrieve > > Sincerely, Hi vinurs, Thank you for your detailed report! This looks very similar to bug#72863, which we determined to be a tree-sitter bug. In both that bug and this, ts_parser_parse falls into an inf loop. Your test file also uncovered another Emacs bug. I need fix this ASAP (emacs 30 pre-release is already out 😬). Once that’s fixed I’ll check if the hang is due to the same tree-sitter bug. Yuan
bug#72426: 29.2.50; comint-pager doesn't affect async-shell-command
> Date: Fri, 13 Sep 2024 04:17:11 +0300 > Cc: 72...@debbugs.gnu.org > From: Dmitry Gutov > > On 03/08/2024 18:38, Eli Zaretskii wrote: > >> comint-terminfo-terminal affects async-shell-command, why not this? > > Ugh! A mistake, IMNSHO. But that ship sailed a long time ago, so we > > cannot fix the mistake. We can avoid enlarging the mistake, though. > > > >> If the fact that the variable is in comint is the problem, I can rename it > >> and move it elsewhere. > > I don't think functions that are almost primitives should pay > > attention to application-level features such as this one. > > FWIW async-shell-command's behavior is affected by a bunch of other > comint-* variables as well because it uses a major mode which inherits > from comint-mode (previously it was shell-mode, now shell-command-mode, > but that aspect didn't change). Yes, and that is baaad!
bug#73218: [PATCH] Fix Fortran indent below do_not_a_loop=42
> From: Ken Mankoff > Date: Thu, 12 Sep 2024 11:44:44 -0700 > > Following up from > https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00904.html I'm > submitting a patch to fix Fortran indentation due to an overly aggressive > match for do loops. Thanks. > --- a/lisp/progmodes/fortran.el > +++ b/lisp/progmodes/fortran.el > @@ -1631,7 +1631,7 @@ fortran-calculate-indent > (setq icol (+ icol fortran-if-indent))) >((looking-at "where[ \t]*(.*)[ \t]*\n") > (setq icol (+ icol fortran-if-indent))) > - ((looking-at "do\\b") > + ((looking-at "do[\\ |0-9]+.*=[\\ a-z0-9_]*,[\\ a-z0-9_]*") What do you intend with the likes of "[\\ |0-9]+" ? Is this a character alternative, or is that an alternative of matches? If the former, there's no need to escape a backslash, but then why is '|' there? IOW, can you please describe in plain English what did you intend this regexp to match? Thanks.
bug#73205: 30.0.91; Failed test: uniquify-project-transform at lisp/uniquify-tests.el:130
> From: "N. Jackson"
> Date: Thu, 12 Sep 2024 17:42:36 +
>
>
> I'm not certain if this test failure is a bug in Emacs or a problem
> with my build.
It's a bug in the test and/or its expectations.
> After building Emacs 30.0.91 from the tarball with
>
> $ ./configure
> $ make -j
>
> and then running
>
> $ make test
>
> I get the following test results:
>
> SUMMARY OF TEST RESULTS
> ---
> Files examined: 519
> Ran 7898 tests, 7661 results as expected, 1 unexpected, 236 skipped
> 1 files contained unexpected results:
> lisp/uniquify-tests.log
>
> The details of the failed test are:
>
> ELC+ELN lisp/uniquify-tests.elc
> GEN lisp/uniquify-tests.log
> Running 7 tests (2024-09-12 12:30:54-0400, selector `(not (or (tag
> :expensive-test) (tag :unstable)))')
> passed 1/7 uniquify-basic (0.049446 sec)
> passed 2/7 uniquify-dirs (0.052217 sec)
> Test uniquify-project-transform backtrace:
> signal(ert-test-failed (((should (equal (mapcar #'buffer-name bufs)
> ert-fail(((should (equal (mapcar #'buffer-name bufs) '("README #f(compiled-function () #)()
> #f(compiled-function () #)()
> handler-bind-1(#f(compiled-function () # ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
> ert-run-test(#s(ert-test :name uniquify-project-transform :documenta
> ert-run-or-rerun-test(#s(ert--stats :selector (not (or ... ...)) :te
> ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
> ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
> ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
> eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
> command-line-1(("-L" ":." "-l" "ert" "--eval" "(setq treesit-extra-l
> command-line()
> normal-top-level()
> Test uniquify-project-transform condition:
> (ert-test-failed
>((should (equal (mapcar ... bufs) '("README" "README")))
> :form
> (equal ("README" "README")
>("README" "README"))
> :value nil :explanation
> (list-elt 1
> (arrays-of-different-length 21 11 "README"
> "README"
> first-mismatch-at 7
> FAILED 3/7 uniquify-project-transform (0.042755 sec) at
> lisp/uniquify-tests.el:130
> passed 4/7 uniquify-rename-to-dir (0.000854 sec)
> passed 5/7 uniquify-separator-ignored (0.007538 sec)
> passed 6/7 uniquify-separator-style-reverse (0.007087 sec)
> passed 7/7 uniquify-space-prefix (0.007681 sec)
>
> Ran 7 tests, 6 results as expected, 1 unexpected (2024-09-12 12:30:55-0400,
> 0.310196 sec)
>
> 1 unexpected results:
> FAILED uniquify-project-transform
Yes, confirmed. This test succeeds in the Git tree, but fails in the
tree created by unpacking the pretest tarball.
Spencer and Mattias, could you please fix the test so that it works in
both cases? It seems to rely on some assumptions that are false in
the source tree of a release tarball.
Thanks.
