bug#72739: [PATCH] * lisp/gnus/gnus-sum.el: Handle leafs with children in summary line
Ping! > Cc: 72...@debbugs.gnu.org > Date: Sat, 24 Aug 2024 12:14:07 +0300 > From: Eli Zaretskii > > > From: Blyte Scholar > > Date: Tue, 20 Aug 2024 17:44:48 -0400 > > > > Tags: patch > > > > > > This patch adds customization options which handle the cases where a > > thread leaf has both siblings and children. This allows using box > > drawing characters to seamlessly connect all messages in a > > thread. Previously, there would be messages could either be connected to > > a sibling or a child, but not both. > > Eric, any comments? > > > >
bug#72696: Track-changes errors out when file is overwritten using Node.js's fs.writeFile (at least on macOS)
> Cc: 72...@debbugs.gnu.org > From: Dario Gjorgjevski > Date: Thu, 22 Aug 2024 13:27:06 +0200 > > BTW, I am using Python for illustrative purposes only. This issue is > particularly annoying when writing JavaScript/TypeScript with a LSP > server and ESLint. Running eslint --fix for in-place linting makes > ESLint rewrite the files in exactly this way (see > https://github.com/eslint/eslint/blob/5dbdd63dc83428447e25f1fc1d05d8a69e3b006a/lib/eslint/eslint.js#L752), > which then makes the LSP server exhibit weird diagnostics and > necessitates a restart of Eglot. Stefan, any comments?
bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode
> Cc: 72...@debbugs.gnu.org > Date: Thu, 22 Aug 2024 17:33:16 +0300 > From: Eli Zaretskii > > > Cc: 72...@debbugs.gnu.org > > Date: Tue, 20 Aug 2024 15:24:12 +0300 > > From: Eli Zaretskii > > > > > From: "Martin Edström" > > > Date: Tue, 20 Aug 2024 10:28:44 +0200 (CEST) > > > > > > Can we undo the "notabug" tag on this one? The bug is with > > > visual-line-mode. > > > > I didn't yet have time to take another look at this, sorry. When I > > do, I will consider this aspect. > > I've now made this test case behave the same both with and without > visual-line-mode on the master branch of the Emacs Git repository. > The patch is below (you will need to rebuild Emacs for it to be > effective, since simple.el is preloaded). > > diff --git a/lisp/simple.el b/lisp/simple.el > index a9f8b58..1d3be2b 100644 > --- a/lisp/simple.el > +++ b/lisp/simple.el > @@ -8200,7 +8200,7 @@ line-move-finish > > ;; Move to the desired column. > (if (and line-move-visual > - (not (or truncate-lines truncate-partial-width-windows))) > + (not (or truncate-lines > (truncated-partial-width-window-p > ;; Under line-move-visual, goal-column should be > ;; interpreted in units of the frame's canonical character > ;; width, which is exactly what vertical-motion does. > No further comments, so I assume the bug is indeed fixed, and I'm closing this bug.
bug#73092: 31.0.50; Completion lists unbound variables with suffix - (e.g., rcirc-)
It just occurred to me that variable completion with C-h v lists non-existent variables with suffix -, e.g., rcirc-, Man-, Info-, info-, etc. When selecting one of those, the *Help* buffer just says --8<---cut here---start->8--- rcirc- is void as a variable. Not documented as a variable. --8<---cut here---end--->8--- Yeah, that's correct, but why was it shown in the *Completions* then? That happens with "emacs -Q" with emacs from git master. In GNU Emacs 31.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.2) of 2024-09-06 built on thinkpad-t440p Repository revision: df57e44a08fd5c7dc159254a40f5d2e4d008e8df Repository branch: master System Description: Arch Linux Configured using: 'configure --with-tree-sitter --with-pgtk --with-modules' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF 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_MONETARY: de_DE.utf8 value of $LC_NUMERIC: de_DE.utf8 value of $LC_TIME: de_DE.utf8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: mu4e:main Minor modes in effect: rcirc-color-mode: t breadcrumb-mode: t editorconfig-mode: t global-aggressive-indent-mode: t pdf-occur-global-minor-mode: t diredfl-global-mode: t mu4e-search-minor-mode: t mu4e-update-minor-mode: t mu4e-context-minor-mode: t mu4e-modeline-mode: t which-key-mode: t highlight-parentheses-mode: t global-git-commit-mode: t magit-auto-revert-mode: t server-mode: t corfu-popupinfo-mode: t corfu-history-mode: t global-corfu-mode: t corfu-mode: t vertico-mode: t marginalia-mode: t minibuffer-depth-indicate-mode: t switchy-window-minor-mode: t electric-pair-mode: t recentf-mode: t override-global-mode: t repeat-mode: t global-so-long-mode: t save-place-mode: t savehist-mode: t puni-global-mode: t puni-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 buffer-read-only: t column-number-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t overwrite-mode: overwrite-mode-binary Load-path shadows: ~/Repos/el/mu/mu4e/mu4e hides ~/Repos/el/mu/build/mu4e/mu4e ~/Repos/el/mu/mu4e/mu4e-modeline hides ~/Repos/el/mu/build/mu4e/mu4e-modeline ~/Repos/el/mu/mu4e/mu4e-context hides ~/Repos/el/mu/build/mu4e/mu4e-context ~/Repos/el/mu/mu4e/mu4e-main hides ~/Repos/el/mu/build/mu4e/mu4e-main ~/Repos/el/mu/mu4e/mu4e-vars hides ~/Repos/el/mu/build/mu4e/mu4e-vars ~/Repos/el/mu/mu4e/mu4e-window hides ~/Repos/el/mu/build/mu4e/mu4e-window ~/Repos/el/mu/mu4e/mu4e-speedbar hides ~/Repos/el/mu/build/mu4e/mu4e-speedbar ~/Repos/el/mu/mu4e/mu4e-view hides ~/Repos/el/mu/build/mu4e/mu4e-view ~/Repos/el/mu/mu4e/mu4e-thread hides ~/Repos/el/mu/build/mu4e/mu4e-thread ~/Repos/el/mu/mu4e/mu4e-bookmarks hides ~/Repos/el/mu/build/mu4e/mu4e-bookmarks ~/Repos/el/mu/mu4e/mu4e-org hides ~/Repos/el/mu/build/mu4e/mu4e-org ~/Repos/el/mu/mu4e/mu4e-lists hides ~/Repos/el/mu/build/mu4e/mu4e-lists ~/Repos/el/mu/mu4e/mu4e-actions hides ~/Repos/el/mu/build/mu4e/mu4e-actions ~/Repos/el/mu/mu4e/mu4e-helpers hides ~/Repos/el/mu/build/mu4e/mu4e-helpers ~/Repos/el/mu/mu4e/mu4e-search hides ~/Repos/el/mu/build/mu4e/mu4e-search ~/Repos/el/mu/mu4e/mu4e-server hides ~/Repos/el/mu/build/mu4e/mu4e-server ~/Repos/el/mu/mu4e/mu4e-obsolete hides ~/Repos/el/mu/build/mu4e/mu4e-obsolete ~/Repos/el/mu/mu4e/mu4e-update hides ~/Repos/el/mu/build/mu4e/mu4e-update ~/Repos/el/mu/mu4e/mu4e-draft hides ~/Repos/el/mu/build/mu4e/mu4e-draft ~/Repos/el/mu/mu4e/mu4e-message hides ~/Repos/el/mu/build/mu4e/mu4e-message ~/Repos/el/mu/mu4e/mu4e-compose hides ~/Repos/el/mu/build/mu4e/mu4e-compose ~/Repos/el/mu/mu4e/mu4e-headers hides ~/Repos/el/mu/build/mu4e/mu4e-headers ~/Repos/el/mu/mu4e/mu4e-query-items hides ~/Repos/el/mu/build/mu4e/mu4e-query-items ~/Repos/el/mu/mu4e/mu4e-notification hides ~/Repos/el/mu/build/mu4e/mu4e-notification ~/Repos/el/mu/mu4e/mu4e-contacts hides ~/Repos/el/mu/build/mu4e/mu4e-contacts ~/Repos/el/mu/mu4e/mu4e-icalendar hides ~/Repos/el/mu/build/mu4e/mu4e-icalendar ~/Repos/el/mu/mu4e/mu4e-mark hides ~/Repos/el/mu/build/mu4e/mu4e-mark ~/Repos/el/mu/mu4e/mu4e-contrib hides ~/Repos/el/mu/build/mu4e/mu4e-contrib ~/Repos/el/mu/mu4e/mu4e-folders hides ~/Repos/el/mu/build/mu4e/mu4e-folders ~/Repos/el/mu/mu4e/mu4e-mime-parts hides ~/Repos/el/mu/build/mu4e/mu4e-mime-parts /home/horn/.emacs.d/elpa/ef-themes-1.8.0/theme-loaddefs hides /home/horn/Repos/el/emacs/lisp/theme-loaddefs /home/horn/.emacs.d/elpa/transient-20240902.1048
bug#72328: [PATCH] Nested backquote in pcase
Ping! Stefan, should I install this in your name? > Cc: michael_heerde...@web.de, thuna.c...@gmail.com, 72...@debbugs.gnu.org > Date: Fri, 23 Aug 2024 22:29:10 +0300 > From: Eli Zaretskii > > > From: Stefan Monnier > > Cc: michael_heerde...@web.de, thuna.c...@gmail.com, 72...@debbugs.gnu.org > > Date: Fri, 23 Aug 2024 15:11:04 -0400 > > > > >> > Would be good to hear from Stefan > > >> The first step is to declare nested backquotes unsupported and add > > >> a warning when we encounter them. > > > Where and how would you suggest to do that? > > > > Somethink like... > > > > > > Stefan > > > > > > diff --git a/lisp/emacs-lisp/pcase.el b/lisp/emacs-lisp/pcase.el > > index fd6b0c8db5c..fe62820f0cb 100644 > > --- a/lisp/emacs-lisp/pcase.el > > +++ b/lisp/emacs-lisp/pcase.el > > @@ -1172,7 +1172,10 @@ pcase--expand-\` > >(upatd (pcase--expand-\` (cdr qpat > >(if (and (eq (car-safe upata) 'quote) (eq (car-safe upatd) 'quote)) > >`'(,(cadr upata) . ,(cadr upatd)) > > -`(and (pred consp) > > +`(and ,@(when (eq (car qpat) '\`) > > + `((guard ,(macroexp-warn-and-return > > + "Nested ` are not supported" t nil nil > > qpat > > + (pred consp) > >(app car-safe ,upata) > >(app cdr-safe ,upatd) > > ((or (stringp qpat) (numberp qpat) (symbolp qpat)) `',qpat) > > Feel free to install on master, and thanks. > > > >
bug#72701: eglot crash when project-files-relative-names t
Ping! Is this issue resolved and can be closed, or do we need to do anything else here? > Cc: 72...@debbugs.gnu.org > Date: Sat, 24 Aug 2024 02:51:16 +0300 > From: Dmitry Gutov > > On 23/08/2024 18:08, João Távora wrote: > > > Eglot could be one of those features if there's a performance advantage. > > But I doubt it, because server-supplied glob expressions may target the > > full file name (indeed likely the truename). > > If the glob can match the full name, and it's hard to separate it into > two matchers, I suppose there's not much that could be done. > > The binding is probably and an improvement for some off-in-the-future > scenario where somebody has Emacs 30 installed, but upgrades project.el > to some yet-unreleased version where the variable's default is flipped. > > > Maybe it's worth it nevertheless, > > dunno. Anyway while let-binding p-f-r-names to nil in Eglot could work, I > > don't think it's the right solution, especially since it probably triggers a > > compilation warning in older Emacsen which don't have this. > > A (defvar ...) at the top of the function's body would help. > > > >
bug#70994: [PATCH] Make cache regeneration work in group names with /
Ping! Eric, any further comments, or should we install the patch? > From: James Thomas > Cc: e...@ericabrahamsen.net, 70...@debbugs.gnu.org, > stefankan...@gmail.com, dan...@dsemy.com > Date: Sat, 24 Aug 2024 14:54:28 +0530 > > Eli Zaretskii wrote: > > > Ping! Can we make some progress here? > > I'd like to confess again that this doesn't seem to be a big deal: > 'gnus-cache-generate-nov-databases' and 'gnus-cache-generate-active' > should work regardless. It's only for someone who might accidentally do > this. > > Regards, > James > > > >> Cc: 70...@debbugs.gnu.org, Stefan Kangas , > >> Daniel Semyonov > >> Date: Thu, 08 Aug 2024 06:46:48 +0530 > >> From: James Thomas via "Bug reports for GNU Emacs, > >> the Swiss army knife of text editors" > >> > >> Eric Abrahamsen wrote: > >> > >> > James Thomas via "Bug reports for GNU Emacs, the Swiss army knife > >> > of > >> > text editors" writes: > >> > > >> >> Eric Abrahamsen wrote: > >> >> > >> >>> Stefan Kangas writes: > >> >>> > >> James Thomas via "Bug reports for GNU Emacs, the Swiss army > >> knife of > >> text editors" writes: > >> > >> > Reproduction steps for bug: > >> > > >> > - emacs -Q > >> > - (setq gnus-secondary-select-methods > >> > '((nnatom "github.com/vedang/pdf-tools/commits.atom"))) > >> > (setq gnus-select-method '(nnnil "")) > >> > - M-x gnus > >> > - Open a message in the new group and press * > >> > - Add the cache virtual server (info "(gnus) Creating a Virtual > >> > Server") > >> > - ^ (server buffer) and: g on the cache > >> > - RET to open (fails) > >> > > >> > This is a possible fix that I've tested only on my (limited) setup, > >> > for > >> > now: > >> > >> Eric, what do you think of the below patch? > >> >>> > >> >>> Thanks for the bump... > >> >>> > >> >>> James, wasn't this what bug#69517 was supposed to be fixing? > >> >> > >> >> You're right, but that was specifically the 'cache'. In > >> >> regenerate, all > >> >> it sees is that the backend is nnml and there's nothing else > >> >> special > >> >> about the server. > >> > > >> > Okay, thanks. > >> > > >> >>> I'm still feeling like we're patching pinhole leaks in a > >> >>> fundamentally > >> >>> broken system. > >> >> > >> >> Sorry if my patch made you think so, but I don't feel that way > >> >> 🙂. This > >> >> feature is just tangential and things like slashes in group names > >> >> are > >> >> bound to complicate things. > >> > > >> > I wasn't complaining about your code :) Just generally grumbling > >> > that > >> > this is so complex. > >> > > >> >> But let me see if I can whip up an alternative patch that does > >> >> things in > >> >> a simpler way (I did say: 'possible' patch). One thing to decide > >> >> is > >> >> whether '%'s are uncommon enough in group names to warrant > >> >> special > >> >> treatment in a backend as fundamental as nnml. > >> > >> I've gone ahead and assumed the above; so now the patch is way > >> simpler. > >> (Btw I meant to say 'nnmail' above, not 'nnml'). It shouldn't be a > >> problem: think I remember only Gmail using a % at some point - and a > >> simple renaming fixes that - perhaps there should be a NEWS entry. > >> > >> > >> Note that for this to work with nnatom in the current upstream > >> you'll > >> also need (ahem!) my patch in bug#65467: bug#71888 must be > >> responsible. > >> > >> > Without diving into this right now, it seems like this is > >> > something that > >> > should be governed by the nnmail abstract backend, from which nnml > >> > and > >> > friends inherit. I would dearly, dearly love it if all backends > >> > that > >> > might potentially create an on-disk directory from a group name > >> > would > >> > use the same code (applying the same user options) to do it, > >> > essentially > >> > transparently. It makes me nervous when various functions in > >> > various > >> > places repeat similar-but-not-quite-identical routines in encoding > >> > and > >> > decoding group names. I suppose that URL encoding/decoding > >> > functions > >> > might end up being an okay tool, but I wonder if Elisp doesn't > >> > already > >> > have some prior art here. I'll do a bit of reading. > >> > >> That's worthwhile of course, but here, for the time being, I've > >> decided > >> I'm only grappling with the new allowance of '/'s in group names. > >> :-) > >> > >> (A further improvement involves replacing the '/'s in the code with > >> '-directory-separator-character', but that's for another report) > >> > >> Regards, > >> James >
bug#72549: 29.4; menus do not work properly on wayland (pgtk)
Ping! How can we make some further progress here? > Date: Sat, 24 Aug 2024 16:17:12 +0200 > Cc: 72...@debbugs.gnu.org > From: Sergio Callegari > > Sorry for the delay. > > Unfortunately cannot try with other compositors, only kwin. > > Other gtk3 applications are mostly fine. Note that on the specific > machine many things are slow. For instance typing with thunderbird shows > some lag and minor hangs. However, one thing is being slow, bothering > but acceptable, and some other thing is becoming incorrect as in opening > the wrong menu. > > Thanks for looking into the issue > > Sergio > > On 10/08/2024 10:27, Po Lu wrote: > > Eli Zaretskii writes: > > > >>> Date: Fri, 9 Aug 2024 13:42:54 +0200 > >>> From: Sergio Callegari > >>> > >>> Using emacs in KDE wayland, with the pgtk build. On a low spec machine, > >>> emacs is hardly usable in this configuration. The menu system (file, > >>> edit, options, etc.) misbehaves. For instance, you position the mouse on > >>> "buffers", but the buffers menu does not open. To get it, you need to go > >>> on File and then slowly move right through edit and options. > >>> > >>> On a high spec machine emacs is usable with exactly the same config (Amd > >>> ryzen 9 with amd graphics). > >>> > >>> in X11 mode, emacs is fine on both. > >> Po Lu, any ideas or suggestions? > > Is this specific to KWin and Emacs, or reproducible on other compositors > > and with other GTK 3 programs also? >
bug#70007: [PATCH] native JSON encoder
> From: Stefan Kangas > Date: Sat, 31 Aug 2024 15:15:25 -0700 > Cc: mattias.engdeg...@gmail.com, acora...@gnu.org, caso...@gmail.com, > 70...@debbugs.gnu.org > > Stefan Monnier writes: > > >> And against the additional variable to make this more > >> backward-compatible? > > > > Yup. The var would be my second-best choice (and I assume it's > > immediately declared obsolete). > > I tend to agree with Stefan M here. Thanks. Andrea, would you please voice your opinion on this?
bug#72808: 30.0.90; editorconfig doesn't set tab_width to a default value
> Cc: 72...@debbugs.gnu.org, jaygka...@gmail.com, 8.slas...@gmail.com > From: Damien Cassou > Date: Sun, 25 Aug 2024 22:23:14 +0200 > > Hi Stefan, > > Stefan Monnier writes: > >> when a .editorconfig file assigns a value for "indent_size" and no > >> value for "tab_width", I expect "tab_width" to default to the value of > >> "indent_size" as described in the documentation [1]. Unfortunately, > > > > Yes, I consciously disagreed with the standard here. IMO, this better > > reflects Emacs's habitual behavior, so it makes more sense for Emacs users. > > > > Indeed, you can already get the "missing" behavior by setting > > `indent_size` to `tab` and then setting `tab_width` to the desired > > indentation size. > > 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?
bug#70968: 29.2.50; choose-completion on an emacs22-style completion deletes text after point
> Date: Mon, 26 Aug 2024 03:08:56 +0300 > Cc: sba...@janestreet.com, 70...@debbugs.gnu.org, j...@linkov.net, > monn...@iro.umontreal.ca > From: Dmitry Gutov > > On 16/05/2024 21:25, Eli Zaretskii wrote: > >> I don't think that would be required exactly. > >> > >> The problem here (IIUC) is that completion behaves differently with the > >> emacs22 style depending on whether the execution path went through > >> choose-completion (which is not a method of completion style but a > >> common subroutine) or not (when completion--do-completion performed > >> expansion). > > I understand that much. But what did these two (or their > > then-equivalents) do in Emacs 22 and Emacs 23? > > I'm guessing they behaved incorrectly (or however we want to call the > inconsistent behavior), but I don't have a compiled Emacs 22/23 around, > and they might be difficult to build. > > Note that we fixed bug#48356 not too long ago, which is from the same > general area, and it probably originated from before Emacs 22/23 too. > > It's worth looking for edge cases where we'd strongly prefer the current > behavior, and they might exist, but so far I only know of situations > where the change would be for the better, or the user might be okay with > either (example at the end of https://debbugs.gnu.org/72705#35). Ping! How should we proceed with this bug report?
bug#72819: [PATCH] Correctly include fixed strings before a prefix wildcard in PCM
Ping! Stefan, any comments? > 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#72768: [PATCH] Keep local keymap out of vc-git-stash-get-at-point
> Date: Tue, 27 Aug 2024 03:37:54 +0530 > From: James Thomas via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > James Thomas wrote: > > > emacs -Q > > (define-key key-translation-map [?\C-j] (kbd "RET")) > > M-x vc-dir (select a git repo) > > (with point on a 'stash' entry) C-x v ! = C-j (fails) > > Of course, if a 'stash' doesn't exist, it may be created, so that the > steps are: > > emacs -Q > C-x C-f (open a git-tracked file, make changes), C-x C-s (and save it) > C-x p v (select the above repo) > z c (create stash) > M-: (define-key key-translation-map [?\C-j] (kbd "RET")) > (with point on the new 'stash' entry) C-x v ! = C-j (fails) Dmitry, any comments or suggestions?
bug#72525: 31.0.50; Forward sexp inconsistency issue c++-ts-mode
> From: Yuan Fu
> Date: Mon, 26 Aug 2024 19:53:51 -0700
> Cc: Ergus ,
> 72...@debbugs.gnu.org
>
>
>
> > On Aug 24, 2024, at 1:28 AM, Eli Zaretskii wrote:
> >
> > Ping! Any progress with this?
> >
> >> From: Yuan Fu
> >> Date: Sat, 10 Aug 2024 22:10:01 -0700
> >> Cc: Ergus ,
> >> 72...@debbugs.gnu.org
> >>
> >>
> >>
> >>> On Aug 10, 2024, at 12:56 AM, Eli Zaretskii wrote:
> >>>
> Date: Thu, 08 Aug 2024 16:45:42 +0200
> From: Ergus via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors"
>
>
> Hi:
>
> Using this code:
>
> ```
> int main()
> {
> abort(); /* 1 */
> abort(); /* 1 */
> }
> ```
>
> There is an inconsistency in the c++-ts-mode behavior of `forward-sexp`.
>
> When there is a comment at the end of the line, if I do `mark-sexp`
> (C-M-SPC) consecutively I get this selected regions:
>
> -
> 1.
> abort();
>
> 2.
> abort(); /* 1 */
>
> 3.
> abort(); /* 1 */
> abort
>
> 4.
> abort(); /* 1 */
> abort()
>
> 5.
> abort(); /* 1 */
> abort();
>
> 6.
> abort(); /* 1 */
> abort(); /* 1 */
>
> ---
>
>
>
> But when there is NOT trailing comment
>
> ```
> int main()
> {
> abort();
> abort();
> }
> ```
>
> ---
> 1.
> abort();
>
> 2.
> abort();
> abort();
> ---
>
>
> It looks like in the fist example after 3 the sexp definition is more
> fine
> grained (similar to the previous c++-mode behavior) and it selects
> separately:
> the function name,
> the arguments
> the semicolon
> the comment
>
> But if there is no comment at the end, it always considers the complete
> line as a sexp (including the ;).
>
> For my use case I would prefer the old behavior because it is consistent
> with the current sexp definition in all emacs (with maybe the exception
> of python-mode). Because it is easier to copy function names or
> function calls with a few movements.
>
> However, if it is too difficult to reproduce the old behavior; then the
> new one may be implemented consistently.
> >>>
> >>> Yuan, any comments or suggestions?
> >>>
> >>> FWIW, I'm not sure this is a bug: what constitutes a "sexp" in C++
> >>> source code is not well-defined.
> >>
> >> Yeah I’ll look into this. And yeah there were some discussion around how
> >> should we define sexp in c++-ts-mode but there wasn’t a concrete
> >> conclusion (I don’t think it’s possible to come up with a concrete one
> >> anyway.) Still, if it can be made more convenient for common use-cases I’m
> >> more than happy to improve it. Just be aware that I’ll be super busy next
> >> week (and I still haven’t done the parse string feature) so it might take
> >> me a while to get back.
> >>
> >> Yuan
>
> I know the reason for the inconsistency now. Treesit-forward-sexp first
> checks whether point is in a “text” node, ie, comment or string; if so, it
> uses the default/normal forward-sexp function; if not, it uses the parse tree
> to go over sexp.
>
> In the first example, because there’s a comment right before point,
> treesit-forward-sexp thinks it’s in a text node, and used the normal
> forward-sexp function, which moved point after the next symbol.
>
> In the second example, because there’s no comment anymore,
> treesit-forward-sexp uses the parse tree to move the point; and since the
> next node after point is the statement line, it moves point over the whole
> line. When using the parse tree to move point, treesit-forward-sexp always
> moves in the same “level” in which that point is. Eg, when point is between
> two lines, treesit-forward-sexp moves over lines; if point is inside an
> argument list between two arguments, treesit-forward-sexp moves over each
> argument.
>
> If you want to just select the identifier or other more fine-grained
> movement, IMHO it’s probably better to use forward-word.
>
> I fixed the inconsistency so now treesit-forward-sexp in both example moves
> over the whole line. The fix is pushed to emacs-30.
Thanks.
No further comments, so I assume the bug is fixed, and I'm therefore
closing it.
bug#72788: 30.0.50; multisession--ensure-db: Symbol’s function definition is void: sqlite-open [2 times]
> From: Stefan Monnier > Cc: Jean Louis , 72...@debbugs.gnu.org > Date: Sat, 31 Aug 2024 10:09:05 -0400 > > > Stefan, do we have a way of causing the cl-defmethod dispatch reject a > > method due to a failed predicate? The relevant method of > > multisession.el says: > > > > (cl-defmethod multisession-backend-value ((_type (eql 'sqlite)) object) > > > > How can I modify this (or its callers?) to make this implementation be > > called only if sqlite-available-p returns non-nil? > > AFAIK, the standard way to do that is: > > (cl-defmethod multisession-backend-value ((_type (eql 'sqlite)) object) > (if (not (sqlite-available-p)) > (cl-call-next-method) > ...do the usual thing...)) Thanks, now done on master, and closing the bug.
bug#72870: [PATCH] Flow fill texts after the last hard newline
> From: Pengji Zhang > Date: Thu, 29 Aug 2024 18:44:36 +0800 > > I found that function `fill-flowed-encode' would not fill texts > after the last hard newline in a buffer. To reproduce, run 'emacs > -Q' and then evaluate the following snippet: > > --8<---cut here---start->8--- > (with-current-buffer (get-buffer-create "*tmp-f=f*") > (use-hard-newlines) > (insert "1\n2") > (fill-flowed-encode) > (display-buffer (current-buffer))) > --8<---cut here---end--->8--- > > The expected output should be '1 2', but the actual is '1\n2'. > > The first patch changes this. > > Besides, I found that the test case > 'fill-flow-tests-fill-flowed-encode' in 'fill-flow-tests' does not > actually test the function 'fill-flowed-encode', which requires > 'use-hard-newlines'[1], and the test input does not cover some > behaviors of the function. The second patch improves it a bit. > > The second patch depends on the first one, without which the new > test will fail. So I decided to submit both together. Please let > me know if it is better to file another report. Thanks. 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? > 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.
bug#72692: Emacs 31.05 (40eecd594ac) get SIGSEGV on Linux (Linux 6.6.45 Kde Wayland)
> Cc: pip...@protonmail.com, exe...@gmail.com, 72...@debbugs.gnu.org, > j...@linkov.net > Date: Thu, 29 Aug 2024 15:26:07 +0300 > From: Eli Zaretskii > > > From: Po Lu > > Cc: Juri Linkov , pip...@protonmail.com, > > exe...@gmail.com, 72...@debbugs.gnu.org > > Date: Thu, 29 Aug 2024 20:06:17 +0800 > > > > Eli Zaretskii writes: > > > > > Po Lu, is there any reason why frame-parameter handlers for GUI frames > > > should ignore the fact that the new value of a parameter is exactly > > > equal to the old value? Is there some subtle issue here, and if so, > > > does it affect all the parameters or only some? > > > > No reason occurs to me why redundant changes shouldn't be discarded in > > the case of alpha-background, but modifications to other parameters > > (e.g. Qfullscreen) always trigger recomputation of various window > > manager properties and states, which is not redundant when these > > properties change without Emacs's knowledge. > > OK, I was aware of the issues with Qfullscreen. > > But what about the rest? Would you mind reviewing the other handlers > in frame.c, and telling which ones should do their thing regardless of > whether the old and the new value of the parameter are identical? Ping!
bug#71646: 29.3; pixel-scroll-precision-mode overrides paging behaviour even when pixel-scroll-precision-interpolate-page is off
> From: Po Lu > Cc: Stefan Kangas , m...@bulsara.com, > 71...@debbugs.gnu.org > Date: Sun, 01 Sep 2024 19:52:19 +0800 > > Eli Zaretskii writes: > > >> From: Stefan Kangas > >> Date: Sun, 1 Sep 2024 02:48:57 -0700 > >> Cc: m...@bulsara.com, 71...@debbugs.gnu.org > >> > >> Eli Zaretskii writes: > >> > >> > Ping! Should I close this? > >> > >> Shouldn't we rather fix the bug described by Mike? I.e. this: > >> > >> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to > >> > turn off the paging animation (which it does) however even when it’s > >> > off, and invoke `cua-scroll-up’ & `cua-scroll-down’ > >> > rather than allowing another keymap to handle it. > > > > I don't mind to fixing this, if possible, but (a) I don't think I > > understand what is being suggested by the text you quote above, and > > (b) given Po Lu's response, it doesn't seem like the proposed changes > > will be accepted, or did I miss something? > > My problem is that two years ago I stated quite clearly why it was > inappropriate to engineer paging interpolation into p-s-p-m (in a > Telegram group), to the deaf ears of the mob requesting it, but since it > is only now that we have received a lone complaint, it's safe to > conclude that most users are satisfied with its established behavior, > which should at least give us pause before any decision to tamper with > it some more, and which behavior, mind you, had already been revised > once in response to user feedback before 29.1. The optimal solution is > simply not to bind p-s-p-i-p in pixel-scroll-precision-mode, but users > disagreed then, and now it's far too late to tamper with these bindings. So what to do with this bug? close as wontfix? leave open and hope someone will find a solution? something else?
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Eli Zaretskii writes: > Thanks you. So the problem seems to be symlinks, and specifically > symlinks to directories. After sending the penultimate email, and before sending the last (which contained the workaround for modifying `dired-font-lock-keywords' buffer-locally) I ran some more tests, and symbolic links to files are also problematic. Specifically, it's the three checks marked by the following comments in `dired-font-lock-keywords' that are problematic: - ";; Broken Symbolic link." - ";; Symbolic link to a directory." - ";; Symbolic link to a non-directory." Only when the three entries corresponding to the above are removed from `dired-font-lock-keywords', does the issue get resolved. Removing some (but not all) of the entries improves matters, but doesn't resolve them completely. Quoting Michael: #+begin_quote It seems to be related to font-locking, indeed. See variable `dired-font-lock-keywords'. It specifies face recognition running basic file oprtations. For example, ";; Broken Symbolic link" calls `file-truename' and `file-exists-p', while "Symbolic link to a directory" and ";; Symbolic link to a non-directory" invoke `file-truename' and `file-directory-p'. I believe it would be helpful to suppress these checks via a user option. And no, the checks shouldn't be suppressed for remote directories in general, on a fast connection they are valuable. #+end_quote > Michael, what does Tramp do specially in these cases that could > explain the slowdown? > >> The above observations seem consistent with Michael's comments above >> regd. font-lock checks for "Broken Symbolink link" and "Symbolic link to >> a directory". > > Michael, what do these checks entail, and why are they so > CPU-expensive and take a lot of time with slow connections? -- Suhail
bug#73032: 31.0.50; vtable header is not aligned
> From: Aleksandr Vityazev
> Cc: 73...@debbugs.gnu.org
> Date: Thu, 05 Sep 2024 19:39:37 +0300
>
> On 2024-09-05 10:36, Eli Zaretskii wrote:
>
> >> Date: Thu, 05 Sep 2024 01:45:14 +0300
> >> From: Aleksandr Vityazev via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors"
> >>
> >> There is a problem in vtable.el when an emoji is specified as a delimiter;
> >> the
> >> header and row delimiters are not aligned.
> >>
> >> Minimal reproducer for emacs -Q:
> >>
> >> (require 'vtable)
> >> (with-current-buffer (get-buffer-create "*test*")
> >> (make-vtable
> >>:columns '((:name "Name" :width 20) "Size" "File")
> >>:objects (buffer-list)
> >>:actions '("k" kill-buffer
> >> "RET" display-buffer)
> >>:divider " 🍉 "
> >>:getter (lambda (object column vtable)
> >> (pcase (vtable-column vtable column)
> >>("Name" (buffer-name object))
> >>("Size" (buffer-size object))
> >>("File" (or (buffer-file-name object) "")
> >> (switch-to-buffer "*test*"))
> >>
> >> Screenshot is attached.
> >
> > I cannot get them aligned even if I replace the Emoji character with
> > an ASCII character, like 'x'. Can you?
> No, I can't.
>
> > AFAICT, there's inconsistency in whitespace calculation between the
> > header line and the body of the table, due to the desire to display
> > the sorting indicator not quite right-aligned. The patch below
> > attempts to fix that; does it give good results?
>
> The patch helped, but there are still some issues. I was able to achieve
> alignment with the following settings:
> (set-face-attribute 'default nil :family "monospace" :height 210)
>
> With: (set-face-attribute 'default nil :family "monospace" :height 220)
> the header separators are also misaligned. My patch is based on the one
> that was sent; I just commented out the insertion of an extra space
> after the column name.
Thanks, I've now installed the changes with your modification, and I'm
therefore closing this bug.
bug#72986: Disabling menu-bar-mode changes size of new frames
> I then applied the trivial patch you gave to git master HEAD, ran 'emacs
> -Q' and did C-x 5 2, and got a small window as usual, but with no error
> message in the terminal.
Let's try to continue from here. Instead of the "trivial" patch please
now use
diff --git a/src/xfns.c b/src/xfns.c
index 3f0d8f3fcd0..e47f5219a6f 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -5340,7 +5340,7 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,
gui_default_parameter (f, parms, Qno_accept_focus, Qnil,
NULL, NULL, RES_TYPE_BOOLEAN);
-#if defined (USE_X_TOOLKIT) || defined (USE_GTK)
+#if defined (USE_X_TOOLKIT) && !defined (USE_GTK)
/* Create the menu bar. */
if (!minibuffer_only && FRAME_EXTERNAL_MENU_BAR (f))
{
Do you see any error message in the terminal? Now set
(setq default-frame-alist '((menu-bar-lines . 0)))
and do C-x 5 2. How does that behave?
martin
bug#73092: 31.0.50; Completion lists unbound variables with suffix - (e.g., rcirc-)
Tassilo Horn writes: > It just occurred to me that variable completion with C-h v lists > non-existent variables with suffix -, e.g., rcirc-, Man-, Info-, info-, > etc. When selecting one of those, the *Help* buffer just says > > rcirc- is void as a variable. > > Not documented as a variable. > > Yeah, that's correct, but why was it shown in the *Completions* then? I trapped into this as well, have a look at bug#72787. Best, Arash
bug#72549: 29.4; menus do not work properly on wayland (pgtk)
Eli Zaretskii writes: > Ping! How can we make some further progress here? > >> Date: Sat, 24 Aug 2024 16:17:12 +0200 >> Cc: 72...@debbugs.gnu.org >> From: Sergio Callegari >> >> Sorry for the delay. >> >> Unfortunately cannot try with other compositors, only kwin. >> >> Other gtk3 applications are mostly fine. Note that on the specific >> machine many things are slow. For instance typing with thunderbird shows >> some lag and minor hangs. However, one thing is being slow, bothering >> but acceptable, and some other thing is becoming incorrect as in opening >> the wrong menu. Sorry for the belated response. Thunderbird is unfortunately not a "real" GTK 3 application, as it implements a custom GUI; rather I'm interested in the behavior of the GTK menu bar widget under your compositor, which is best tested with the `gtk3-demo-application' program.
bug#72919: 29.1; chart-space-usage in chart.el does not work correctly on windows
> Cc: 72...@debbugs.gnu.org > Date: Sun, 01 Sep 2024 21:35:03 +0300 > From: Eli Zaretskii > > > I've tried your changes with and without du. This uncovered something in the > > original implementation, namely that the original implementation did not > > count > > hidden files and directories. du * skips dotfiles for me. > > > > With du present chart-space-usage shows the lisp directory as the largest > > in the > > emacs repository root. Without du it shows .git as the largest. > > This just means minor adjustments in the code I posted: we need to use > a different regexp in the call to directory-files-recursively, and > also ignore files that start with a dot in the command itself. I will > make those changes, thanks for pointing them out Actually, there's more here than meets the eye. 'du' does NOT skip dotfiles (unless instructed to do so via the --exclude= command-line option). What happens here is that a typical Unix shell does not include dotfiles in the expansion of the "*" wildcard, so "du *" does not count dotfiles, but only in the directory in which 'du' was invoked; dotfiles in subdirectories _are_ counted. I made the Lisp implementation skip dotfiles in the directory for which the command is invoked, but not in the subdirectories. Windows users who do have 'du' installed will now depend on how "*" is expanded, which is probably different in different ports of 'du'. I considered using --exclude=, but that would exclude dotfiles in subdirectories as well, which is not what happens in the Unix case. > I will post a version that ignores dotfiles. I installed a modified version on the emacs-30 branch. The patch is below in case you want to try it. With that, I'm closing this bug. diff --git a/lisp/emacs-lisp/chart.el b/lisp/emacs-lisp/chart.el index da61e45..2ca9b64 100644 --- a/lisp/emacs-lisp/chart.el +++ b/lisp/emacs-lisp/chart.el @@ -641,27 +641,68 @@ chart-file-count (lambda (a b) (> (cdr a) (cdr b )) +;; This assumes 4KB blocks +(defun chart--file-size (size) + (* (/ (+ size 4095) 4096) 4096)) + +(defun chart--directory-size (dir) + "Compute total size of files in directory DIR and its subdirectories. +DIR is assumed to be a directory, verified by the caller." + (let ((size 0)) +(dolist (file (directory-files-recursively dir "." t)) + (let ((fsize (nth 7 (file-attributes file +(if (> fsize 0) +(setq size + (+ size (chart--file-size fsize)) +size)) + (defun chart-space-usage (d) "Display a top usage chart for directory D." (interactive "DDirectory: ") (message "Collecting statistics...") (let ((nmlst nil) (cntlst nil) - (b (get-buffer-create " *du-tmp*"))) -(set-buffer b) -(erase-buffer) -(insert "cd " d ";du -sk * \n") -(message "Running `cd %s;du -sk *'..." d) -(call-process-region (point-min) (point-max) shell-file-name t -(current-buffer) nil) -(goto-char (point-min)) -(message "Scanning output ...") -(while (re-search-forward "^\\([0-9]+\\)[ \t]+\\([^ \n]+\\)$" nil t) - (let* ((nam (buffer-substring (match-beginning 2) (match-end 2))) -(num (buffer-substring (match-beginning 1) (match-end 1 - (setq nmlst (cons nam nmlst) - ;; * 1000 to put it into bytes - cntlst (cons (* (string-to-number num) 1000) cntlst +b) +(if (executable-find "du") +(progn + (setq b (get-buffer-create " *du-tmp*")) + (set-buffer b) + (erase-buffer) + (if (and (memq system-type '(windows-nt ms-dos)) + (fboundp 'w32-shell-dos-semantics) + (w32-shell-dos-semantics)) + (progn +;; With Windows shells, 'cd' does not change the drive, +;; and ';' is not reliable for running multiple +;; commands, so use alternatives. We quote the +;; directory because otherwise pushd will barf on a +;; directory with forward slashes. Note that * will not +;; skip dotfiles with Windows shells, unlike on Unix. +(insert "pushd \"" d "\" && du -sk * \n") +(message "Running `pushd \"%s\" && du -sk *'..." d)) +(insert "cd " d ";du -sk * \n") +(message "Running `cd %s;du -sk *'..." d)) + (call-process-region (point-min) (point-max) shell-file-name t + (current-buffer) nil) + (goto-char (point-min)) + (message "Scanning output ...") + (while (re-search-forward "^\\([0-9]+\\)[ \t]+\\([^ \n]+\\)$" nil t) +(let* ((nam (buffer-substring (match-beginning 2) (match-end 2))) + (num (buffer-substring (match-beginning 1) (match-end 1 + (setq nmlst (cons nam nmlst) + ;; * 1000 to put it into bytes + cntlst (cons (*
bug#72945: 29.4; Org: ox-html: attr_html not supported in source code and fixed-width blocks during HTML export
> Cc: 72...@debbugs.gnu.org
> Date: Mon, 02 Sep 2024 15:32:02 +0300
> From: Eli Zaretskii
>
> > From: Suhail Singh
> > Cc: "Suhail Singh" , 72...@debbugs.gnu.org
> > Date: Mon, 02 Sep 2024 08:26:07 -0400
> >
> > Eli Zaretskii writes:
> >
> > > Thanks, but why are you posting this here? ox-html.el is part of Org,
> >
> > My reasoning was that Org is a part of Emacs, so debbugs would be
> > appropriate. Or at least, that it would _not be inappropriate_.
> > Perhaps I was mistaken.
>
> Org has its own bug tracker and mailing list to discuss problems
> specific to Org. So I suggest to report this there.
>
> > I understand that Org uses some custom mailing list software ("Woof!")
> > to help with tracking issues. However, it's not clear whether that is
> > exclusively the case (i.e., debbugs is not to be used for Org issues).
> > On a related note, "Woof!" doesn't list the issue under "Bugs" and I
> > don't quite understand why:
> > .
>
> The general advice is to post Org problems to the Org forums first,
> and only come here if the Org developers decide that the underlying
> problem is a general Emacs problem, not a problem in Org.
No further comments, so I'm now closing this bug. If the Org
developers decide it's a core Emacs issue, we can reopen.
bug#72983: 29.4; Inconsistent parameter types sent to GUI selection converters
> Date: Mon, 02 Sep 2024 11:15:40 -0700
> From: Derek Upham via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors"
>
>
> Existing code
> -
>
> We'll have to go into some obscure areas of the GUI selection
> code.
> Let's start with xselect-convert-to-targets (select.el).
>
> (defun xselect-convert-to-targets (selection _type value)
> ;; Return a vector of atoms, but remove duplicates first.
> (if (eq selection 'XdndSelection)
> ;; This isn't required by the XDND protocol, and sure
> enough no
> ;; clients seem to dependent on it, but Emacs implements
> the
> ;; receiver side of the Motif drop protocol by looking at
> the
> ;; initiator selection's TARGETS target (which Motif
> provides)
> ;; instead of the target table on the drag window, so it
> seems
> ;; plausible for other clients to rely on that as well.
> (apply #'vector (mapcar #'intern x-dnd-targets-list))
> (apply #'vector
> (delete-dups
> `( TIMESTAMP MULTIPLENIL
> . ,(delq '_EMACS_INTERNAL
> (mapcar (lambda (conv)
> (if (or (not (consp (cdr
> conv)))
> (funcall (cadr conv)
> selection
> (car conv)
> value))
> (car conv)
> '_EMACS_INTERNAL))
> selection-converter-alist)))
>
> This function evaluates each converter in
> selection-converter-alist
> against the selection value, and returns the labels of any
> converters
> that return non-NIL. The goal here is to filter out targets that
> Emacs
> can't vend for the current value. The converters are responsible
> for
> noticing and rejecting inputs that they can't support.
>
> Be aware that the "value" parameter may be a string with text
> properties. The "gui-set-selection" Info documentation mentions
> this:
>
> If DATA is a string, then its text properties can specify
> values
> used for individual data types. For example, if DATA has a
> property named ‘text/uri-list’, then a call to
> ‘gui-get-selection’
> with the data type ‘text/uri-list’ will result in the value
> of that
> property being used instead of DATA itself.
>
> Now compare the xselect-convert-to-targets function with the code
> in
> x_get_local_selection (xselect.c, excerpted).
>
> CHECK_SYMBOL (target_type);
> handler_fn = CDR (Fassq (target_type,
> Vselection_converter_alist));
>
> if (CONSP (handler_fn))
> handler_fn = XCDR (handler_fn);
>
> if (!need_alternate)
> tem = XCAR (XCDR (local_value));
> else
> tem = XCAR (XCDR (XCDR (XCDR (XCDR (local_value);
>
> if (STRINGP (tem))
> {
> local_value = Fget_text_property (make_fixnum (0),
> target_type, tem);
>
> if (!NILP (local_value))
> tem = local_value;
> }
>
> if (!NILP (handler_fn))
> value = call3 (handler_fn, selection_symbol,
> ((local_request
>&& NILP
>(Vx_treat_local_requests_remotely))
> ? Qnil
> : target_type),
> tem);
> else
> value = Qnil;
>
> The caller (possibly another X client) provides the target, which
> defines the converter to use. If tem is a string, then we check
> for a
> property that matches the target type. If such a property exists,
> we
> clobber the existing string with the associated property's object.
> Then
> we call the converter.
>
>
> Problem
> ---
>
> This discrepancy trips up potential HTML support.
>
> A typical application like Firefox or LibreOffice vends both
> text/html
> and text/plain content. Clients will ask for the targets, then
> ask
> for the text/html value if available, falling back to text/plain.
> For
> example, we might want to support an italiced "foo", while falling
> back to the underlying word.
>
> #("foo" 0 3 (text/html "foo"))
>
> We want to advertise a text/html target only when our value has a
> text/html property. We can do that with new
> "xselect-convert-to-html"
> function in selection-converter-alist.
>
> (text/html . xselect-convert-to-html)
>
> The function returns true if the input is a string with a
> text/html
> property. But if the client then *asks* for the text/html, the C
> code
> will send the same function a plain string “foo” without
> the
> property. The function bails out with NIL. Most clients will
> then fall
bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
> Date: Wed, 4 Sep 2024 12:23:28 +0100 (BST) > From: Peter Oliver > > If my understanding of this bug is correct, newer versions of WebKitGTK > reliably crash Emacs, and no-one has been in touch with the WebKitGTK > developers, so there are no plans to fix that. > > If that’s the case, how about this attached patch to disable this feature > with problematic versions of the library? > > From 262ea1bb8c47f703819f2df4d920a1f15f2c35b9 Mon Sep 17 00:00:00 2001 > From: Peter Oliver > Date: Wed, 4 Sep 2024 12:12:50 +0100 > Subject: [PATCH] Disable xwidgets with recent webkitgtk versions (Bug#66068) > > * configure.ac: Accept only webkit2gtk-4.* versions less than 2.41.92. > --- > configure.ac | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 28361be4211..1d0ea314f6a 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -4511,10 +4511,11 @@ AC_DEFUN > if test "$with_xwidgets" != "no"; then >if test "$USE_GTK_TOOLKIT" = "GTK3" && test "$window_system" != "none"; > then > WEBKIT_REQUIRED=2.12 > -WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED" > +WEBKIT_BROKEN=2.41.92 > +WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED webkit2gtk-4.1 < > $WEBKIT_BROKEN" > EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES]) > if test "$HAVE_WEBKIT" = "no"; then > - WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED" > + WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED webkit2gtk-4.0 < > $WEBKIT_BROKEN" >EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES]) > fi > HAVE_XWIDGETS=$HAVE_WEBKIT > -- > 2.46.0 > Po Lu, any objections to this patch?
bug#71646: 29.3; pixel-scroll-precision-mode overrides paging behaviour even when pixel-scroll-precision-interpolate-page is off
Eli Zaretskii writes: >> From: Po Lu >> Cc: Stefan Kangas , m...@bulsara.com, >> 71...@debbugs.gnu.org >> Date: Sun, 01 Sep 2024 19:52:19 +0800 >> >> Eli Zaretskii writes: >> >> >> From: Stefan Kangas >> >> Date: Sun, 1 Sep 2024 02:48:57 -0700 >> >> Cc: m...@bulsara.com, 71...@debbugs.gnu.org >> >> >> >> Eli Zaretskii writes: >> >> >> >> > Ping! Should I close this? >> >> >> >> Shouldn't we rather fix the bug described by Mike? I.e. this: >> >> >> >> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to >> >> > turn off the paging animation (which it does) however even when it’s >> >> > off, and invoke `cua-scroll-up’ & `cua-scroll-down’ >> >> > rather than allowing another keymap to handle it. >> > >> > I don't mind to fixing this, if possible, but (a) I don't think I >> > understand what is being suggested by the text you quote above, and >> > (b) given Po Lu's response, it doesn't seem like the proposed changes >> > will be accepted, or did I miss something? >> >> My problem is that two years ago I stated quite clearly why it was >> inappropriate to engineer paging interpolation into p-s-p-m (in a >> Telegram group), to the deaf ears of the mob requesting it, but since it >> is only now that we have received a lone complaint, it's safe to >> conclude that most users are satisfied with its established behavior, >> which should at least give us pause before any decision to tamper with >> it some more, and which behavior, mind you, had already been revised >> once in response to user feedback before 29.1. The optimal solution is >> simply not to bind p-s-p-i-p in pixel-scroll-precision-mode, but users >> disagreed then, and now it's far too late to tamper with these bindings. > > So what to do with this bug? close as wontfix? leave open and hope > someone will find a solution? something else? I'd prefer to decide this question after Emacs 30 is released when I will enjoy more time to devote to Emacs.
bug#73042: 29.1; Regression: negation missing in ediff-nonempty-string-p
> Date: Thu, 5 Sep 2024 13:47:28 + > From: Jurgen De Backer via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > In emacs 29.1-29.4 the negation is missing in function > ediff-nonempty-string-p, see ediff-init.el: > > (defsubst ediff-nonempty-string-p (string) > (and (stringp string) (string-empty-p string))) > > should be > > (defsubst ediff-nonempty-string-p (string) > (and (stringp string) (not (string-empty-p string Thanks, fixed on the emacs-30 branch, and closing the bug.
bug#73050: 30.0.90; Empty tool tip when hovering over tab-bar separator
> Date: Thu, 05 Sep 2024 18:35:14 +0200 > From: Daniel Mendler via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > 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?
bug#69097: [PATCH] Add 'kill-region-or-word' command
> From: Sean Whitton > Cc: phil...@posteo.net, stefankan...@gmail.com, acora...@gnu.org, > j...@linkov.net, r...@gnu.org, 69...@debbugs.gnu.org > Date: Fri, 06 Sep 2024 14:54:58 +0100 > > +(defun forward-unix-word (arg &optional delim) > + "Move forward ARG unix-words. > +A unix-word is whitespace-delimited. > +Interactively, ARG is the numeric prefix argument, defaulting to 1. > +A negative ARG means go backwards to the beginning of unix-words. I again ask whether we need this command. It is okay to have a function (perhaps even an internal one) to move by Unix-words, but what are the use cases for such a command? > +(defun unix-filename-rubout (arg) > + "Kill ARG unix-words backwards, also treating `/' as whitespace. > +A unix-word is whitespace-delimited. > +Interactively, ARG is the numeric prefix argument, defaulting to 1. > +A negative ARG means to kill forwards. > + > +This is like `unix-word-rubout' (which see), but `/' is also considered > +whitespace. I'd say '/' is treated as word delimiter. "Considered whitespace" sounds strange to me. Should we also treat a backslash as delimiter, for MS-Windows?
bug#73092: 31.0.50; Completion lists unbound variables with suffix - (e.g., rcirc-)
merge 73092 72787 thanks > Cc: 73...@debbugs.gnu.org > From: Arash Esbati > Date: Sat, 07 Sep 2024 11:07:58 +0200 > > Tassilo Horn writes: > > > It just occurred to me that variable completion with C-h v lists > > non-existent variables with suffix -, e.g., rcirc-, Man-, Info-, info-, > > etc. When selecting one of those, the *Help* buffer just says > > > > rcirc- is void as a variable. > > > > Not documented as a variable. > > > > Yeah, that's correct, but why was it shown in the *Completions* then? > > I trapped into this as well, have a look at bug#72787. Indeed, this is a known issue.
bug#73092: 31.0.50; Completion lists unbound variables with suffix - (e.g., rcirc-)
Alright, thanks. My debbugs searching foo needs improvement. ;-) Am Sa, 7. Sep 2024, um 12:00, schrieb Eli Zaretskii: > merge 73092 72787 > thanks > >> Cc: 73...@debbugs.gnu.org >> From: Arash Esbati >> Date: Sat, 07 Sep 2024 11:07:58 +0200 >> >> Tassilo Horn writes: >> >> > It just occurred to me that variable completion with C-h v lists >> > non-existent variables with suffix -, e.g., rcirc-, Man-, Info-, info-, >> > etc. When selecting one of those, the *Help* buffer just says >> > >> > rcirc- is void as a variable. >> > >> > Not documented as a variable. >> > >> > Yeah, that's correct, but why was it shown in the *Completions* then? >> >> I trapped into this as well, have a look at bug#72787. > > Indeed, this is a known issue.
bug#69097: [PATCH] Add 'kill-region-or-word' command
Eli Zaretskii writes: >> From: Sean Whitton >> Cc: phil...@posteo.net, stefankan...@gmail.com, acora...@gnu.org, >> j...@linkov.net, r...@gnu.org, 69...@debbugs.gnu.org >> Date: Fri, 06 Sep 2024 14:54:58 +0100 >> >> +(defun forward-unix-word (arg &optional delim) >> + "Move forward ARG unix-words. >> +A unix-word is whitespace-delimited. >> +Interactively, ARG is the numeric prefix argument, defaulting to 1. >> +A negative ARG means go backwards to the beginning of unix-words. > > I again ask whether we need this command. It is okay to have a > function (perhaps even an internal one) to move by Unix-words, but > what are the use cases for such a command? I think it is conceivable that some users might prefer to have deterministic word movement that doesn't change depending on the major mode. But as mention earlier, this is functionality that might be worth relegating into a subword-mode-like mode, instead of defining new commands. >> +(defun unix-filename-rubout (arg) >> + "Kill ARG unix-words backwards, also treating `/' as whitespace. >> +A unix-word is whitespace-delimited. >> +Interactively, ARG is the numeric prefix argument, defaulting to 1. >> +A negative ARG means to kill forwards. >> + >> +This is like `unix-word-rubout' (which see), but `/' is also considered >> +whitespace. > > I'd say '/' is treated as word delimiter. "Considered whitespace" > sounds strange to me. > > Should we also treat a backslash as delimiter, for MS-Windows? -- Philip Kaludercic on siskin
bug#72986: Disabling menu-bar-mode changes size of new frames
On Sat, 7 Sept 2024 at 09:37, 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 > 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. -- https://rrt.sc3d.org
bug#72328: [PATCH] Nested backquote in pcase
Eli Zaretskii writes: > Ping! Stefan, should I install this in your name? In the meantime I installed the patch locally and got two warnings when rebuilding Emacs completely: | In testcover-analyze-coverage: | emacs-lisp/testcover.el:472:8: Warning: Nested ` are not supported | ELC emacs-lisp/timer-list.elc | | In testcover-analyze-coverage-wrapped-form: | emacs-lisp/testcover.el:551:8: Warning: Nested ` are not supported But they should be trivial to fix (they are only warnings anyway). Michael.
bug#73084: [PATCH] Include the variable name in the `setopt` warning
Okamsn writes: > Hello, > > The attached patch adds the variable name to the `setopt` warning. > > I write my Emacs config in an Org file, from which I make the Emacs Lisp > file. Currently, if `setopt` detects that the value I wish to make a > variable hold does not conform to the variable's Custom.el type, then it > reports the type and the problematic value, but not the variable itself, > when I open Emacs. This adds extra steps to editing the code in the Org > file to fix the warning, especially when the value is created > programmatically. It would be faster to search for the variable name > directly in the Org file and to then re-tangle the Org file. I think this is a good idea! What might also be useful would be to generate line warnings, as the backtrace should have the necessary information. > Thank you. > > From 7cc7134b1b751428b7c14a0b54f55193a59363b1 Mon Sep 17 00:00:00 2001 > From: Earl Hyatt > Date: Fri, 6 Sep 2024 20:04:24 -0400 > Subject: [PATCH] Include the variable name in the warning in `setopt--set'. > > Including the variable name makes it easier to find the location of the > error. > > * lisp/cus-edit.el (setopt--set): Include the variable name in the > warning. > --- > lisp/cus-edit.el | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el > index 9f5ac47490c..035499deb71 100644 > --- a/lisp/cus-edit.el > +++ b/lisp/cus-edit.el > @@ -1072,7 +1072,7 @@ setopt--set >;; Check that the type is correct. >(when-let ((type (get variable 'custom-type))) > (unless (widget-apply (widget-convert type) :match value) > - (warn "Value `%S' does not match type %s" value type))) > + (warn "`%s': Value `%S' does not match type %s" variable value type))) >(put variable 'custom-check-value (list value)) >(funcall (or (get variable 'custom-set) #'set-default) variable value)) -- Philip Kaludercic on siskin
bug#73082: 30; Inconsistent Stipple Support
> On Sep 7, 2024, at 2:51 AM, Po Lu wrote: > > Eli Zaretskii writes: > >>> From: JD Smith >>> Date: Fri, 6 Sep 2024 17:58:02 -0400 >>> >>> (let* ((w (window-font-width)) >>> (stipple `(,w 1 ,(apply #'unibyte-string (make-list (/ (+ w 7) 8) >>> 186) >>> (insert "\n" (propertize (concat (make-string 15 ?\s) >>> "THIS IS A TEST" >>> (make-string 15 ?\s)) >>> 'face `(:background "red" :foreground "blue" >>> :stipple ,stipple >>> >>> Only some Emacs 30 builds correctly render this simple stipple. There has >>> been some progress on :stipple support recently, but it remains incomplete. >>> To my knowledge, the current situation for :stipple support in Emacs 30 is >>> as follows... >> The MS-Windows build of the emacs-30 branch here shows the display you >> expected. > > You should add Haiku and Android to your list, as Emacs supports > stipples on both of these window systems. (And on the latter they were > in fact implemented for your package.) > > I am also interested to know precisely which Cairo builds fail to > display them, the stipple implementations being virtually identical > across the PGTK and the X + Cairo builds. Thanks, this is all positive news. Glad to learn of Android+Haiku support. Is support on these builds arriving for Emacs 30 only? The Cairo issue has been harder to track down. Several users have reported Cairo builds which fail to display stipples. I gather Cairo is the default so this must be a sporadic failure. Recently a user with identical builds on two different machines, with the precise same version of GTK3 and Cairo, found that one system shows stipples correctly, the other omits them entirely. On the non-working system, compiling --without-cairo resolves this. The build version in questions is:  He's willing to test these systems. Thanks for your work on this.
bug#73098: setopt float warning unexpected
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 -Stephane P.S. I reported a bug to Prot as some much more complex modus defcustom type definitions seem either themselves broken or setopt needs some work to accommodate them.
bug#73082: 30; Inconsistent Stipple Support
> The Cairo issue has been harder to track down. Several users have reported > Cairo builds which fail to display stipples. I gather Cairo is the default > so this must be a sporadic failure. Recently a user with identical builds on > two different machines, with the precise same version of GTK3 and Cairo, > found that one system shows stipples correctly, the other omits them > entirely. On the non-working system, compiling --without-cairo resolves this. > > The build version in questions is: > > > > He's willing to test these systems. > Copying in the affected user.
bug#72983: 29.4; Inconsistent parameter types sent to GUI selection converters
Eli Zaretskii writes: > Po Lu, any comments? The facilities that currently exist for customizing selection-converter-alist and the data types returned for a conversion from a string to any particular target are only designed for drag and drop operations, unfortunately. If you remind me of this report after the 30.1 release (or maybe in a number of weeks) I will probably find enough time to address it. At the moment, I'm only willing to attend to issues that affect new functionality introduced in Emacs 30, or absolutely critical issues. Sorry to disappoint.
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Suhail Singh writes: Hi, > The above observations seem consistent with Michael's comments above > regd. font-lock checks for "Broken Symbolink link" and "Symbolic link to > a directory". As such, if Michael's proposal below is implemented I > believe it would be an adequate fix to the issue: > I believe it would be helpful to suppress these checks via a user option. And no, the checks shouldn't be suppressed for remote directories in general, on a fast connection they are valuable. I gave it a try, see appended patch. 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. You can switch this option on and off globally. However, it would be better to do this host-wise. For this, we have connection-local variables. The following code snippet in your ".emacs" switches the option off for the remote host "remotehost". --8<---cut here---start->8--- (connection-local-set-profile-variables 'my-dired-profile '((dired-highlight-symlinks . nil))) (connection-local-set-profiles '(:application tramp :machine "remotehost") 'my-dired-profile) --8<---cut here---end--->8--- Comments? Best regards, Michael. diff --git a/lisp/dired.el b/lisp/dired.el index 0d526dfc376..53d6d213951 100644 --- a/lisp/dired.el +++ b/lisp/dired.el @@ -738,6 +738,13 @@ dired-ignored-face ;;; Font-lock +(defcustom dired-highlight-symlinks t + "Whether symlinks shall use an own face. +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-highlight-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-highlight-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,13 @@ 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) + (when (connection-local-value dired-highlight-symlinks) + (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
Eli Zaretskii writes:
Hi Eli,
> Thanks you. So the problem seems to be symlinks, and specifically
> symlinks to directories. Michael, what does Tramp do specially in
> these cases that could explain the slowdown?
>
>> The above observations seem consistent with Michael's comments above
>> regd. font-lock checks for "Broken Symbolink link" and "Symbolic link to
>> a directory".
>
> Michael, what do these checks entail, and why are they so
> CPU-expensive and take a lot of time with slow connections?
I made a test. In a remote directory I have created a cyclic symlink
"zzz", in order to see what Tramp does when running dired on the
directory. The additional actions are
--8<---cut here---start->8---
16:26:26.596764 tramp-send-command (6) # test -d /home/albinus/tmp/zzz
2>/dev/null; echo tramp_exit_status $?
16:26:26.598277 tramp-wait-for-regexp (6) #
tramp_exit_status 1
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:26.601447 tramp-send-command (6) # (if test -h "/home/albinus/tmp/zzz";
then echo t; else echo nil; fi) && \readlink --canonicalize-missing
/home/albinus/tmp/zzz 2>/dev/null; echo tramp_exit_status $?
16:26:26.620202 tramp-wait-for-regexp (6) #
t
/home/albinus/tmp/zzz
tramp_exit_status 0
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:26.621815 tramp-send-command (6) #
tramp_stat_file_attributes_with_selinux /home/albinus/tmp/zzz 2>/dev/null; echo
tramp_exit_status $?
16:26:26.701825 tramp-wait-for-regexp (6) #
(("‘/home/albinus/tmp/zzz’ -> ‘/home/albinus/tmp/zzz’") 1 ("albinus" . 1000)
("albinus" . 1000) 1725715198 1725627151 1725627151 21 "lrwxrwxrwx" t 11020655
-1 "unconfined_u:object_r:user_tmp_t:s0")
tramp_exit_status 0
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:26.727631 tramp-send-command (6) # (if test -h "/home/albinus/tmp/zzz";
then echo t; else echo nil; fi) && \readlink --canonicalize-missing
/home/albinus/tmp/zzz 2>/dev/null; echo tramp_exit_status $?
16:26:26.744351 tramp-wait-for-regexp (6) #
t
/home/albinus/tmp/zzz
tramp_exit_status 0
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:26.763045 tramp-send-command (6) # (if test -h "/home/albinus/tmp/zzz";
then echo t; else echo nil; fi) && \readlink --canonicalize-missing
/home/albinus/tmp/zzz 2>/dev/null; echo tramp_exit_status $?
16:26:26.844666 tramp-wait-for-regexp (6) #
t
/home/albinus/tmp/zzz
tramp_exit_status 0
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:26.870794 tramp-send-command (6) # (if test -h "/home/albinus/tmp/zzz";
then echo t; else echo nil; fi) && \readlink --canonicalize-missing
/home/albinus/tmp/zzz 2>/dev/null; echo tramp_exit_status $?
16:26:26.887610 tramp-wait-for-regexp (6) #
t
/home/albinus/tmp/zzz
tramp_exit_status 0
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:26.906448 tramp-send-command (6) # (if test -h "/home/albinus/tmp/zzz";
then echo t; else echo nil; fi) && \readlink --canonicalize-missing
/home/albinus/tmp/zzz 2>/dev/null; echo tramp_exit_status $?
16:26:26.983946 tramp-wait-for-regexp (6) #
t
/home/albinus/tmp/zzz
tramp_exit_status 0
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:27.006076 tramp-send-command (6) # (if test -h "/home/albinus/tmp/zzz";
then echo t; else echo nil; fi) && \readlink --canonicalize-missing
/home/albinus/tmp/zzz 2>/dev/null; echo tramp_exit_status $?
16:26:27.010734 tramp-wait-for-regexp (6) #
t
/home/albinus/tmp/zzz
tramp_exit_status 0
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:27.030175 tramp-send-command (6) # (if test -h "/home/albinus/tmp/zzz";
then echo t; else echo nil; fi) && \readlink --canonicalize-missing
/home/albinus/tmp/zzz 2>/dev/null; echo tramp_exit_status $?
16:26:27.117633 tramp-wait-for-regexp (6) #
t
/home/albinus/tmp/zzz
tramp_exit_status 0
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:27.139885 tramp-send-command (6) # (if test -h "/home/albinus/tmp/zzz";
then echo t; else echo nil; fi) && \readlink --canonicalize-missing
/home/albinus/tmp/zzz 2>/dev/null; echo tramp_exit_status $?
16:26:27.151833 tramp-wait-for-regexp (6) #
t
/home/albinus/tmp/zzz
tramp_exit_status 0
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:27.171011 tramp-send-command (6) # (if test -h "/home/albinus/tmp/zzz";
then echo t; else echo nil; fi) && \readlink --canonicalize-missing
/home/albinus/tmp/zzz 2>/dev/null; echo tramp_exit_status $?
16:26:27.252462 tramp-wait-for-regexp (6) #
t
/home/albinus/tmp/zzz
tramp_exit_status 0
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:27.275070 tramp-send-command (6) # (if test -h "/home/albinus/tmp/zzz";
then echo t; else echo nil; fi) && \readlink --canonicalize-missing
/home/albinus/tmp/zzz 2>/dev/null; echo tramp_exit_status $?
16:26:27.292574 tramp-wait-for-regexp (6) #
t
/home/albinus/tmp/zzz
tramp_exit_status 0
///dd77c20acbfe3e98bd0661ddf70b1f4a#$
16:26:27.311554 tramp-send-command (6) # (if test -h "/home/albinus/tmp/zzz";
then echo t; else echo nil; fi) && \readlink --canonicalize-missing
/home/albinus/tmp/zzz 2>/dev/null; echo tramp_exit_status $?
16:26:27.396961 tram
bug#73102: 29.4; `package-recompile-all' should skip packages installed by distro package manager
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. In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.16.0) of 2024-07-22, modified by Debian built on x86-ubc-01 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/29.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.4/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/29.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.4/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-29.4+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 SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LC_ALL: C value of $LC_MONETARY: zh_CN.UTF-8 value of $LANG: zh_CN.UTF-8 value of $XMODIFIERS: @im=fcitx locale-coding-system: nil Major mode: Help Minor modes in effect: consult-denote-mode: t denote-menu-bar-mode: t TeX-PDF-mode: t magit-wip-initial-backup-mode: t magit-wip-before-change-mode: t magit-wip-after-apply-mode: t magit-wip-after-save-mode: t magit-wip-mode: t global-git-commit-mode: t magit-auto-revert-mode: t sly-symbol-completion-mode: t eat-eshell-visual-command-mode: t eat-eshell-mode: t shell-dirtrack-mode: t xterm-mouse-mode: t term-keys-mode: t server-mode: t lin-global-mode: t savehist-mode: t repeat-mode: t global-diff-hl-mode: t global-auto-revert-mode: t save-place-mode: t recentf-mode: t activities-tabs-mode: t activities-mode: t windmove-mode: t corfu-terminal-mode: t corfu-popupinfo-mode: t corfu-history-mode: t global-corfu-mode: t corfu-mode: t nerd-icons-completion-mode: t marginalia-mode: t vertico-multiform-mode: t vertico-mode: t pixel-scroll-mode: t spacious-padding-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tab-bar-mode: t file-name-shadow-mode: t isearch-fold-quotes-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /home/zhengyi/.emacs.d/elpa/magit-4.1.0/magit-autorevert hides /home/zhengyi/.emacs.d/elpa/magit-section-4.1.0/magit-autorevert /home/zhengyi/.emacs.d/site-lisp/gtags hides /usr/share/emacs/site-lisp/global/gtags /usr/share/emacs/site-lisp/elpa/mu4e-1.10.8/mu4e hides /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e /usr/share/emacs/site-lisp/elpa/mu4e-1.10.8/mu4e-window hides /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-window /usr/share/emacs/site-lisp/elpa/mu4e-1.10.8/mu4e-view hides /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-view /usr/share/emacs/site-lisp
bug#73100: Regarding a bug in suspend-emacs
Hello I am running Linux with kernel 6.6.47 and am running emacs in xterm, using the -nw command line argument. I am new to emacs and was experimenting with the suspend-emacs command. Following the example on https://www.gnu.org/software/emacs/manual/html_node/elisp/Suspending-Emacs.html . When following the example, I added the suspend-resume-hook to my .emacs.d/init.el file. When I run M-: (suspend-emacs "pwd") it does not show the current working directory. But when I do fg from the terminal that I got into, I see the "Resumed!" message. I asked in the libera chat about that, and also in the gnu-help-emacs list. I have been talking to wasamasa on libera chat (#emacs-beginners) and we pinpointed the problem to the stuff_char function (in https://git.savannah.gnu.org/cgit/emacs.git/tree/src/sysdep.c#n403). We came to this point from stuff_buffered_input ( https://git.savannah.gnu.org/cgit/emacs.git/tree/src/keyboard.c#n11963), and from suspend-emacs function definition (in https://git.savannah.gnu.org/cgit/emacs.git/tree/src/keyboard.c#n11908). The stuff_char function is using ioctl with TIOCSTI. TIOCSTI requires CAP_SYS_ADMIN capability. You can set this capability using sysctl setting dev.tty.legacy_tiocsti to 1. Unless I had set "dev.tty.legacy_tiocsti" to 1 I could not run the suspend-emacs command with an argument string. Either emacs can check the return value of ioctl in stuff_char and if there return value is EPERM, then handle this accordingly, with a message regarding the problem. Or the information relating to the kernel version and CAP_SYS_ADMIN can be added to the infor page os suspend_emacs, along with the information on how to set this capability using sysctl. Kind Regards Riza Dindir
bug#73101: Regarding a bug in suspend-emacs
Hello Note: Sending this a second time, I forgot to confirm my request to register to the bug-gnu-emacs list. I am running Linux with kernel 6.6.47 and am running emacs in xterm, using the -nw command line argument. I am new to emacs and was experimenting with the suspend-emacs command. Following the example on https://www.gnu.org/software/emacs/manual/html_node/elisp/Suspending-Emacs.html . When following the example, I added the suspend-resume-hook to my .emacs.d/init.el file. When I run M-: (suspend-emacs "pwd") it does not show the current working directory. But when I do fg from the terminal that I got into, I see the "Resumed!" message. I asked in the libera chat about that, and also in the gnu-help-emacs list. I have been talking to wasamasa on libera chat (#emacs-beginners) and we pinpointed the problem to the stuff_char function (in https://git.savannah.gnu.org/cgit/emacs.git/tree/src/sysdep.c#n403). We came to this point from stuff_buffered_input ( https://git.savannah.gnu.org/cgit/emacs.git/tree/src/keyboard.c#n11963), and from suspend-emacs function definition (in https://git.savannah.gnu.org/cgit/emacs.git/tree/src/keyboard.c#n11908). The stuff_char function is using ioctl with TIOCSTI. TIOCSTI requires CAP_SYS_ADMIN capability. You can set this capability using sysctl setting dev.tty.legacy_tiocsti to 1. Unless I had set "dev.tty.legacy_tiocsti" to 1 I could not run the suspend-emacs command with an argument string. Either emacs can check the return value of ioctl in stuff_char and if there return value is EPERM, then handle this accordingly, with a message regarding the problem. Or the information relating to the kernel version and CAP_SYS_ADMIN can be added to the infor page os suspend_emacs, along with the information on how to set this capability using sysctl. Kind Regards Riza Dindir
bug#72831: [PATCH] gnus-icalendar: Allow comments in event replies
Any further feedback on the patch or could someone please apply the patch?
Thanks!
Patch once again below, this time as attachment instead of inline…
>From 5f75ab29fd0f0fbed523863c6ce13ce1f8de Mon Sep 17 00:00:00 2001
From: fpi
Date: Wed, 28 Aug 2024 18:33:20 +0200
Subject: [PATCH] Allow comments to organizer in event replies (bug#72831)
* lisp/gnus/gnus-icalendar.el
(gnus-icalendar-event--build-reply-event-body): Add optional COMMENT
argument to be inserted into the reply.
(gnus-icalendar-event-reply-from-buffer): Add COMMENT argument to be
passed through to gnus-icalendar-event--build-reply-event-body
(gnus-icalendar-reply-accept, gnus-icalendar-reply-tentative,
gnus-icalendar-reply-decline): If interactively called with a prefix
argument ask user for a COMMENT to add to the reply.
* test/lisp/gnus/gnus-icalendar-tests.el
(gnus-icalendar-accept-with-comment,
gnus-icalendar-decline-withouth-changing-comment): New tests.
---
lisp/gnus/gnus-icalendar.el| 61 +++---
test/lisp/gnus/gnus-icalendar-tests.el | 72 ++
2 files changed, 115 insertions(+), 18 deletions(-)
diff --git a/lisp/gnus/gnus-icalendar.el b/lisp/gnus/gnus-icalendar.el
index af7284b88e8..85f1aa09a56 100644
--- a/lisp/gnus/gnus-icalendar.el
+++ b/lisp/gnus/gnus-icalendar.el
@@ -309,7 +309,7 @@ gnus-icalendar-event-from-buffer
;;; gnus-icalendar-event-reply
;;;
-(defun gnus-icalendar-event--build-reply-event-body (ical-request status identities)
+(defun gnus-icalendar-event--build-reply-event-body (ical-request status identities &optional comment)
(let ((summary-status (capitalize (symbol-name status)))
(attendee-status (upcase (symbol-name status)))
reply-event-lines)
@@ -319,6 +319,10 @@ gnus-icalendar-event--build-reply-event-body
(if (string-match "^[^:]+:" line)
(replace-match (format "\\&%s: " summary-status) t nil line)
line))
+ (update-comment
+ (line)
+ (if comment (format "COMMENT:%s" comment)
+ line))
(update-dtstamp ()
(format-time-string "DTSTAMP:%Y%m%dT%H%M%SZ" nil t))
(attendee-matches-identity
@@ -341,6 +345,7 @@ gnus-icalendar-event--build-reply-event-body
(cond
((string= key "ATTENDEE") (update-attendee-status line))
((string= key "SUMMARY") (update-summary line))
+ ((string= key "COMMENT") (update-comment line))
((string= key "DTSTAMP") (update-dtstamp))
((member key '("ORGANIZER" "DTSTART" "DTEND"
"LOCATION" "DURATION" "SEQUENCE"
@@ -363,16 +368,24 @@ gnus-icalendar-event--build-reply-event-body
attendee-status user-full-name user-mail-address)
reply-event-lines))
+ ;; add comment line if not existing
+ (when (and comment (not (gnus-icalendar-find-if (lambda (x) (string-match "^COMMENT" x))
+ reply-event-lines)))
+(push (format "COMMENT:%s" comment) reply-event-lines))
+
(mapconcat #'identity `("BEGIN:VEVENT"
,@(nreverse reply-event-lines)
"END:VEVENT")
"\n"
-(defun gnus-icalendar-event-reply-from-buffer (buf status identities)
+(defun gnus-icalendar-event-reply-from-buffer (buf status identities &optional comment)
"Build a calendar event reply for request contained in BUF.
The reply will have STATUS (`accepted', `tentative' or `declined').
The reply will be composed for attendees matching any entry
-on the IDENTITIES list."
+on the IDENTITIES list.
+Optional argument COMMENT will be placed in the comment field of the
+reply.
+"
(cl-labels
((extract-block
(blockname)
@@ -396,7 +409,7 @@ gnus-icalendar-event-reply-from-buffer
"PRODID:Gnus"
"VERSION:2.0"
zone
- (gnus-icalendar-event--build-reply-event-body event status identities)
+ (gnus-icalendar-event--build-reply-event-body event status identities comment)
"END:VCALENDAR")))
(mapconcat #'identity (delq nil contents) "\n"))
@@ -878,13 +891,13 @@ gnus-icalendar-send-buffer-by-mail
(insert "Subject: " subject)
(message-send-and-exit
-(defun gnus-icalendar-reply (data)
+(defun gnus-icalendar-reply (data &optional comment)
(let* ((handle (car data))
(status (cadr data))
(event (caddr data))
(reply (gnus-icalendar-with-decoded-handle handle
(gnus-icalendar-event-reply-from-buffer
- (current-buffer) status (gnus-icalendar-identities
+ (current-buffer) status (gnus-icalendar-identities) comment)))
(organizer (gnus-icalendar-event:organizer event)))
(when reply
@@ -1009,25 +1022,37 @@ gnus-icalendar-save-event
(when data
(g
bug#72831: [PATCH] gnus-icalendar: Allow comments in event replies
> From: Ferdinand Pieper > Cc: Robert Pluim , Eli Zaretskii , Andrew > G Cohen , Alexandre Duret-Lutz > Date: Sat, 07 Sep 2024 14:22:41 +0200 > > Any further feedback on the patch or could someone please apply the patch? > Thanks! > > Patch once again below, this time as attachment instead of inline… Thanks, I'd like to wait for a few days, to let people comment if they want.
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
> From: Michael Albinus > Cc: Suhail Singh , 73...@debbugs.gnu.org > Date: Sat, 07 Sep 2024 16:36:42 +0200 > > Eli Zaretskii writes: > > > Michael, what do these checks entail, and why are they so > > CPU-expensive and take a lot of time with slow connections? > > I made a test. In a remote directory I have created a cyclic symlink > "zzz", in order to see what Tramp does when running dired on the > directory. The additional actions are > [...] > 15 times the "test -h" command - I guess, Tramp shall do cyclic link > detection better. 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? I'm sorry to insist on understanding these fine details, but my experience is that without a good understanding of a problem we might devise a solution that is only a partial one. Thanks.
bug#73100: Regarding a bug in suspend-emacs
> From: Riza Dindir > Date: Sat, 7 Sep 2024 15:37:17 +0300 > > I am running Linux with kernel 6.6.47 and am running emacs in xterm, using > the -nw command line argument. > > I am new to emacs and was experimenting with the suspend-emacs command. > Following the example on > https://www.gnu.org/software/emacs/manual/html_node/elisp/Suspending-Emacs.html. > > When following the example, I added the suspend-resume-hook to my > .emacs.d/init.el file. When I run M-: > (suspend-emacs "pwd") it does not show the current working directory. But > when I do fg from the terminal that I > got into, I see the "Resumed!" message. > > I asked in the libera chat about that, and also in the gnu-help-emacs list. I > have been talking to wasamasa on > libera chat (#emacs-beginners) and we pinpointed the problem to the > stuff_char function (in > https://git.savannah.gnu.org/cgit/emacs.git/tree/src/sysdep.c#n403). We came > to this point from > stuff_buffered_input > (https://git.savannah.gnu.org/cgit/emacs.git/tree/src/keyboard.c#n11963), and > from > suspend-emacs function definition (in > https://git.savannah.gnu.org/cgit/emacs.git/tree/src/keyboard.c#n11908). > > The stuff_char function is using ioctl with TIOCSTI. TIOCSTI requires > CAP_SYS_ADMIN capability. You can set > this capability using sysctl setting dev.tty.legacy_tiocsti to 1. > > Unless I had set "dev.tty.legacy_tiocsti" to 1 I could not run the > suspend-emacs command with an argument > string. > > Either emacs can check the return value of ioctl in stuff_char and if there > return value is EPERM, then handle > this accordingly, with a message regarding the problem. You mean, you want suspend-emacs signal an error if it is called with STUFFSTRING argument, but fails to stuff the string into the terminal's input buffer?
bug#73101: Regarding a bug in suspend-emacs
merge 73101 73100 thanks > From: Riza Dindir > Date: Sat, 7 Sep 2024 16:34:45 +0300 > > Note: Sending this a second time, I forgot to confirm my request to register > to the bug-gnu-emacs list. That was a mistake, because by doing that you have created an identical copy of the first bug report. I'm now merging them.
bug#70007: [PATCH] native JSON encoder
Eli Zaretskii writes: >> From: Stefan Kangas >> Date: Sat, 31 Aug 2024 15:15:25 -0700 >> Cc: mattias.engdeg...@gmail.com, acora...@gnu.org, caso...@gmail.com, >> 70...@debbugs.gnu.org >> >> Stefan Monnier writes: >> >> >> And against the additional variable to make this more >> >> backward-compatible? >> > >> > Yup. The var would be my second-best choice (and I assume it's >> > immediately declared obsolete). >> >> I tend to agree with Stefan M here. > > Thanks. > > Andrea, would you please voice your opinion on this? I'm for returning unibyte indeed. And for the variable or the second function I'm kind of neutral, I'd do it only if it's not too much effort so I'll trust Mattias preference here. Andrea
bug#70007: [PATCH] native JSON encoder
> From: Andrea Corallo > Cc: Stefan Kangas , monn...@iro.umontreal.ca, > mattias.engdeg...@gmail.com, caso...@gmail.com, 70...@debbugs.gnu.org > Date: Sat, 07 Sep 2024 11:48:36 -0400 > > Eli Zaretskii writes: > > >> From: Stefan Kangas > >> Date: Sat, 31 Aug 2024 15:15:25 -0700 > >> Cc: mattias.engdeg...@gmail.com, acora...@gnu.org, caso...@gmail.com, > >>70...@debbugs.gnu.org > >> > >> Stefan Monnier writes: > >> > >> >> And against the additional variable to make this more > >> >> backward-compatible? > >> > > >> > Yup. The var would be my second-best choice (and I assume it's > >> > immediately declared obsolete). > >> > >> I tend to agree with Stefan M here. > > > > Thanks. > > > > Andrea, would you please voice your opinion on this? > > I'm for returning unibyte indeed. And for the variable or the second > function I'm kind of neutral, I'd do it only if it's not too much effort > so I'll trust Mattias preference here. OK, so let's go with unconditionally unibyte, as it seems to be the consensus here.
bug#73100: Regarding a bug in suspend-emacs
> From: Riza Dindir > Date: Sat, 7 Sep 2024 19:11:02 +0300 > Cc: 73...@debbugs.gnu.org > > I am new to the code base, and it was just a suggestion to check for the > ioctl call for any failures and take > precautions, maybe inform the user of the issue that the suspend-emacs > command did not run correctly. Since > the command was not printing out anything when called with 'M-: > (suspend-emacs "pwd")' I was not sure what > was happening. I was asking for your user's expectations, not how to do that in the code. > For users that use the linux kernel 6.2+ the ioctl command does not work > correctly. When the STUFFSTRING is > passed to the suspend-emacs command, it does nothing. The problem with kernel > 6.2+ is that it requires > CAP_SYS_ADMIN capability > (https://www.man7.org/linux/man-pages/man2/TIOCSTI.2const.html). > > In the code at some point suspend-emacs command calls stuff_char, which uses > ioctl (code snippet below, from > https://git.savannah.gnu.org/cgit/emacs.git/tree/src/sysdep.c#n403). The > ioctl call fails. But in the code there is > no check for that, that might confuse people that use linux kernel 6.2+. I > wanted to use suspend-emacs with > "pwd" as the string (as shown in the example in the documentation in > https://www.gnu.org/software/emacs/manual/html_node/elisp/Suspending-Emacs.html). > But the "pwd" command > was not displaying anything. Because it was not being sent/stuffed to the > superior process. Does ioctl return -1 in that case? (I don't have access to a system where it fails, it works for me on GNU/Linux.) > Adding an error check would be one of the solutions. Assuming we can check that (see above), the question is what to do if we do detect a failure. > The other solution might be to add a piece of information to the > documentation for suspend-emacs, (and > maybe to the documentation string for suspend-emacs) regarding this problem. > So that people that use linux > kernel 6.2+ would be aware of this issue. That is already done, except that the documentation cannot be too specific regarding when and under what conditions it could happen.
bug#73108: 29.2; easy-menu-define
The docstring and the Elisp manual both state that easy-menu-define "defines SYMBOL as a function for popping up the menu" but it doesn't. It defines SYMBOL as a variable whose value is the menu, which could be used for popping up the menu. This behaviour is useful and I use it, so I suggest that the documentation should be corrected. Thanks, Francis In GNU Emacs 29.2 (build 2, x86_64-w64-mingw32) of 2024-01-18 built on AVALON Windowing system distributor 'Microsoft Corp.', version 10.0.22631 System Description: Microsoft Windows 10 Home (v10.0.2009.22631.4037)
bug#73108: 29.2; easy-menu-define
> From: Francis Wright > Date: Sat, 7 Sep 2024 16:47:17 + > > The docstring and the Elisp manual both state that easy-menu-define "defines > SYMBOL as a function for > popping up the menu" but it doesn't. Are you sure? emacs -Q M-x load-library RET bookmark RET M-: (symbol-function 'bookmark-menu) RET => #[257 "\301^A\3009\203^W\0\302\300\303N\304\"... Adding Stefan in case he has comments.
bug#73110: 29.4; emacs.service failed with result 'timeout'
I want to run Emacs as a service and connect to it with a client. I followed the instructions here: https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html and ran the command systemctl --user enable emacs This apparently creates a file at ~/.config/systemd/user/default.target.wants/emacs.service whose contents are: [Unit] Description=Emacs text editor Documentation=info:emacs man:emacs(1) https://gnu.org/software/emacs/ [Service] Type=notify ExecStart=/usr/local/bin/emacs --fg-daemon # Emacs will exit with status 15 after having received SIGTERM, which # is the default "KillSignal" value systemd uses to stop services. SuccessExitStatus=15 # The location of the SSH auth socket varies by distribution, and some # set it from PAM, so don't override by default. # Environment=SSH_AUTH_SOCK=%t/keyring/ssh Restart=on-failure [Install] WantedBy=default.target The directions also say: (If your Emacs was installed into a non-standard location, you may need to copy the emacs.service file to a standard directory such as ~/.config/systemd/user/.) I built this emacs distribution from source and installed it using "sudo make install"; the executable is at /usr/local/bin/emacs, so I don't think it is installed in a non-standard location, and so I did not follow these instructions. I modified the [Service] command above to include the -Q flag for the purposes of this bug report. After activating the service, restarting, etc., my journalctl output is as follows: Sep 07 12:52:45 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: emacs.service: start operation timed out. Terminating. Sep 07 12:52:45 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: emacs.service: Failed with result 'timeout'. Sep 07 12:52:45 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: Failed to start emacs.service - Emacs text editor. Sep 07 12:52:46 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: emacs.service: Scheduled restart job, restart counter is at 1. Sep 07 12:52:46 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: Starting emacs.service - Emacs text editor... Sep 07 12:52:46 patrick-ThinkPad-X1-Carbon-Gen-10 emacs[183514]: Starting Emacs daemon. Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: emacs.service: start operation timed out. Terminating. Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: emacs.service: Failed with result 'timeout'. Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: Failed to start emacs.service - Emacs text editor. Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: emacs.service: Scheduled restart job, restart counter is at 2. Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: Starting emacs.service - Emacs text editor... Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 emacs[183623]: Starting Emacs daemon. Sep 07 12:55:46 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: emacs.service: start operation timed out. Terminating. Sep 07 12:55:46 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: emacs.service: Failed with result 'timeout'. Sep 07 12:55:46 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: Failed to start emacs.service - Emacs text editor. Sep 07 12:55:47 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: emacs.service: Scheduled restart job, restart counter is at 3. Sep 07 12:55:47 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: Starting emacs.service - Emacs text editor... Sep 07 12:55:47 patrick-ThinkPad-X1-Carbon-Gen-10 emacs[183684]: Starting Emacs daemon. etc., etc., every ninety seconds. For some reason emacs is not successfully communicating to systemd that it has launched successfully, and so systemd terminates emacs. In GNU Emacs 29.4 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-08-30 built on patrick-ThinkPad-X1-Carbon-Gen-10 System Description: Ubuntu 24.04.1 LTS Configured using: 'configure --with-native-compilation=aot --with-tree-sitter --with-gif --with-png --with-jpeg --with-rsvg --with-tiff --with-pgtk --with-imagemagick --with-x-toolkit=gtk3 --with-xwidgets' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ IMAGEMAGICK JPEG JSON LCMS2 LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM XWIDGETS GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=ibus 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 line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Feat
bug#73108: 29.2; easy-menu-define
Looking again, SYMBOL appears to be both a variable and a function, so I was wrong. Sorry! But it might be helpful to add to the documentation that SYMBOL also defines a variable. Francis From: Eli Zaretskii Sent: 07 September 2024 6:19 PM To: Francis Wright Cc: 73...@debbugs.gnu.org <73...@debbugs.gnu.org> Subject: Re: bug#73108: 29.2; easy-menu-define > From: Francis Wright > Date: Sat, 7 Sep 2024 16:47:17 + > > The docstring and the Elisp manual both state that easy-menu-define "defines > SYMBOL as a function for > popping up the menu" but it doesn't. Are you sure? emacs -Q M-x load-library RET bookmark RET M-: (symbol-function 'bookmark-menu) RET => #[257 "\301^A\3009\203^W\0\302\300\303N\304\"... Adding Stefan in case he has comments.
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Eli Zaretskii writes: >> 15 times the "test -h" command - I guess, Tramp shall do cyclic link >> detection better. > > 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. -- Suhail
bug#73110: 29.4; emacs.service failed with result 'timeout'
> From: Patrick Nicodemus > Date: Sat, 7 Sep 2024 13:22:30 -0400 > > I want to run Emacs as a service and connect to it with a client. I > followed the instructions here: > > https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html > > and ran the command > systemctl --user enable emacs > > This apparently creates a file at > ~/.config/systemd/user/default.target.wants/emacs.service > > whose contents are: > > [Unit] > Description=Emacs text editor > Documentation=info:emacs man:emacs(1) https://gnu.org/software/emacs/ > > [Service] > Type=notify > ExecStart=/usr/local/bin/emacs --fg-daemon > > # Emacs will exit with status 15 after having received SIGTERM, which > # is the default "KillSignal" value systemd uses to stop services. > SuccessExitStatus=15 > > # The location of the SSH auth socket varies by distribution, and some > # set it from PAM, so don't override by default. > # Environment=SSH_AUTH_SOCK=%t/keyring/ssh > Restart=on-failure > > [Install] > WantedBy=default.target > > The directions also say: > (If your Emacs was installed into a non-standard location, you may need > to copy the emacs.service file to a standard directory such as > ~/.config/systemd/user/.) > > I built this emacs distribution from source and installed it using "sudo > make install"; the executable is at /usr/local/bin/emacs, so I don't > think it is installed in a non-standard location, and so I did not > follow these instructions. > > I modified the [Service] command above to include the -Q flag for the > purposes of this bug report. > > After activating the service, restarting, etc., my journalctl output is > as follows: > > Sep 07 12:52:45 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > emacs.service: start operation timed out. Terminating. > Sep 07 12:52:45 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > emacs.service: Failed with result 'timeout'. > Sep 07 12:52:45 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > Failed to start emacs.service - Emacs text editor. > Sep 07 12:52:46 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > emacs.service: Scheduled restart job, restart counter is at 1. > Sep 07 12:52:46 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > Starting emacs.service - Emacs text editor... > Sep 07 12:52:46 patrick-ThinkPad-X1-Carbon-Gen-10 emacs[183514]: > Starting Emacs daemon. > Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > emacs.service: start operation timed out. Terminating. > Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > emacs.service: Failed with result 'timeout'. > Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > Failed to start emacs.service - Emacs text editor. > Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > emacs.service: Scheduled restart job, restart counter is at 2. > Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > Starting emacs.service - Emacs text editor... > Sep 07 12:54:16 patrick-ThinkPad-X1-Carbon-Gen-10 emacs[183623]: > Starting Emacs daemon. > Sep 07 12:55:46 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > emacs.service: start operation timed out. Terminating. > Sep 07 12:55:46 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > emacs.service: Failed with result 'timeout'. > Sep 07 12:55:46 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > Failed to start emacs.service - Emacs text editor. > Sep 07 12:55:47 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > emacs.service: Scheduled restart job, restart counter is at 3. > Sep 07 12:55:47 patrick-ThinkPad-X1-Carbon-Gen-10 systemd[2704]: > Starting emacs.service - Emacs text editor... > Sep 07 12:55:47 patrick-ThinkPad-X1-Carbon-Gen-10 emacs[183684]: > Starting Emacs daemon. > > etc., etc., every ninety seconds. > > For some reason emacs is not successfully communicating to systemd that > it has launched successfully, and so systemd terminates emacs. According to this: > Configured features: > ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ > IMAGEMAGICK JPEG JSON LCMS2 LIBSELINUX LIBXML2 MODULES NATIVE_COMP > NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF > TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM XWIDGETS GTK3 ZLIB your Emacs is built without libsystemd support, which I think is required for this to work? Or maybe I'm missing something.
bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Michael Albinus writes: > I believe it would be helpful to suppress these checks via a user > option. And no, the checks shouldn't be suppressed for remote > directories in general, on a fast connection they are valuable. > > I gave it a try, see appended patch. Thank you for sharing the patch. I haven't tested the patch yet, so my comments below are based on reviewing the code and my experience with the workaround I currently have. > 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. > You can switch this option on and off globally. However, it would be > better to do this host-wise. For this, we have connection-local > variables. The following code snippet in your ".emacs" switches the > option off for the remote host "remotehost". > > (connection-local-set-profile-variables > 'my-dired-profile > '((dired-highlight-symlinks . nil))) > > (connection-local-set-profiles > '(:application tramp :machine "remotehost") > 'my-dired-profile) > > Comments? 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? -- Suhail
bug#73101: Regarding a bug in suspend-emacs
I apologize for the duplicate. On Sat, Sep 7, 2024, 18:22 Eli Zaretskii wrote: > merge 73101 73100 > thanks > > > From: Riza Dindir > > Date: Sat, 7 Sep 2024 16:34:45 +0300 > > > > Note: Sending this a second time, I forgot to confirm my request to > register to the bug-gnu-emacs list. > > That was a mistake, because by doing that you have created an > identical copy of the first bug report. > > I'm now merging them. >
bug#72831: [PATCH] gnus-icalendar: Allow comments in event replies
Eli Zaretskii writes: > Thanks, I'd like to wait for a few days, to let people comment if they > want. Sounds good, thanks for handling it.
bug#73100: Regarding a bug in suspend-emacs
Hello Eli,
I am new to the code base, and it was just a suggestion to check for the
ioctl call for any failures and take precautions, maybe inform the user of
the issue that the suspend-emacs command did not run correctly. Since the
command was not printing out anything when called with 'M-: (suspend-emacs
"pwd")' I was not sure what was happening.
For users that use the linux kernel 6.2+ the ioctl command does not work
correctly. When the STUFFSTRING is passed to the suspend-emacs command, it
does nothing. The problem with kernel 6.2+ is that it requires CAP_SYS_ADMIN
capability (https://www.man7.org/linux/man-pages/man2/TIOCSTI.2const.html).
In the code at some point suspend-emacs command calls stuff_char, which
uses ioctl (code snippet below, from
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/sysdep.c#n403). The
ioctl call fails. But in the code there is no check for that, that might
confuse people that use linux kernel 6.2+. I wanted to use suspend-emacs
with "pwd" as the string (as shown in the example in the documentation in
https://www.gnu.org/software/emacs/manual/html_node/elisp/Suspending-Emacs.html).
But the "pwd" command was not displaying anything. Because it was not being
sent/stuffed to the superior process.
/* Should perhaps error if in batch mode */#ifdef TIOCSTI
ioctl (fileno (CURTTY()->input), TIOCSTI, &c);#else /* no TIOCSTI */
error ("Cannot stuff terminal input characters in this version of
Unix");#endif /* no TIOCSTI */
I have downloaded the code for emacs 29.4 and compiled it with a simple
error check and the ioctl call failed on my system silently (with kernel
6.6.47).
To add a check is of course for the people who develop emacs to decide. I
have seen the code today, and am not in a position to suggest anything at
this stage. Maybe there would be a better way of handling this error.
Adding an error check would be one of the solutions.
The other solution might be to add a piece of information to the
documentation for suspend-emacs, (and maybe to the documentation string for
suspend-emacs) regarding this problem. So that people that use linux kernel
6.2+ would be aware of this issue.
The issue is fixable by just setting the dev.tty.legacy_tiocsti sysctl
variable to 1. This variable was set to 0 on my system. Hence the ioctl
call for TIOCSTI was failing, and no indication of the error was given.
After I have read the man page for TIOCSTI, and set the sysctl
variable dev.tty.legacy_tiocsti to 1 was I able to call suspend-emacs with
a STUFFSTRING and it worked. It was displaying the output of the "pwd"
command.
Regards
Riza
On Sat, Sep 7, 2024, 18:20 Eli Zaretskii wrote:
> > From: Riza Dindir
> > Date: Sat, 7 Sep 2024 15:37:17 +0300
> >
> > I am running Linux with kernel 6.6.47 and am running emacs in xterm,
> using the -nw command line argument.
> >
> > I am new to emacs and was experimenting with the suspend-emacs command.
> Following the example on
> >
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Suspending-Emacs.html
> .
> >
> > When following the example, I added the suspend-resume-hook to my
> .emacs.d/init.el file. When I run M-:
> > (suspend-emacs "pwd") it does not show the current working directory.
> But when I do fg from the terminal that I
> > got into, I see the "Resumed!" message.
> >
> > I asked in the libera chat about that, and also in the gnu-help-emacs
> list. I have been talking to wasamasa on
> > libera chat (#emacs-beginners) and we pinpointed the problem to the
> stuff_char function (in
> > https://git.savannah.gnu.org/cgit/emacs.git/tree/src/sysdep.c#n403). We
> came to this point from
> > stuff_buffered_input (
> https://git.savannah.gnu.org/cgit/emacs.git/tree/src/keyboard.c#n11963),
> and from
> > suspend-emacs function definition (in
> https://git.savannah.gnu.org/cgit/emacs.git/tree/src/keyboard.c#n11908).
> >
> > The stuff_char function is using ioctl with TIOCSTI. TIOCSTI requires
> CAP_SYS_ADMIN capability. You can set
> > this capability using sysctl setting dev.tty.legacy_tiocsti to 1.
> >
> > Unless I had set "dev.tty.legacy_tiocsti" to 1 I could not run the
> suspend-emacs command with an argument
> > string.
> >
> > Either emacs can check the return value of ioctl in stuff_char and if
> there return value is EPERM, then handle
> > this accordingly, with a message regarding the problem.
>
> You mean, you want suspend-emacs signal an error if it is called with
> STUFFSTRING argument, but fails to stuff the string into the
> terminal's input buffer?
>
bug#69097: [PATCH] Add 'kill-region-or-word' command
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. On Sat 07 Sep 2024 at 12:52pm +03, Eli Zaretskii wrote: > I again ask whether we need this command. It is okay to have a > function (perhaps even an internal one) to move by Unix-words, but > what are the use cases for such a command? That's fine. I've turned it back into a function. > Should we also treat a backslash as delimiter, for MS-Windows? Good idea. That's more useful. -- Sean Whitton >From 9163f6ab16816702f8bc6acb6f22734eb57acfc7 Mon Sep 17 00:00:00 2001 From: Sean Whitton Date: Fri, 6 Sep 2024 11:35:46 +0100 Subject: [PATCH v3] New commands for moving and killing unix-words * lisp/simple.el (forward-unix-word): New function. (unix-word-rubout, unix-filename-rubout): New commands. * etc/NEWS: Announce the new commands. --- etc/NEWS | 6 ++ lisp/simple.el | 57 ++ 2 files changed, 63 insertions(+) diff --git a/etc/NEWS b/etc/NEWS index f3e719a34d3..104941425c2 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -123,6 +123,12 @@ When using 'visual-wrap-prefix-mode' in buffers with variable-pitch fonts, the wrapped text will now be lined up correctly so that it's exactly below the text after the prefix on the first line. +--- +** New commands 'unix-word-rubout' and 'unix-filename-rubout'. +Unix-words are words separated by whitespace regardless of the buffer's +syntax table. In a Unix terminal or shell, C-w kills by Unix-word. +The new commands 'unix-word-rubout' and 'unix-filename-rubout' allow +you to bind keys to operate more similarly to the terminal. * Changes in Specialized Modes and Packages in Emacs 31.1 diff --git a/lisp/simple.el b/lisp/simple.el index 2453a129d0a..1b910b0ed22 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -8892,6 +8892,63 @@ current-word ;; If we found something nonempty, return it as a string. (unless (= start end) (buffer-substring-no-properties start end) + +(defun forward-unix-word (n &optional delim) + "Move forward N Unix-words. +A Unix-word is whitespace-delimited. +A negative N means go backwards to the beginning of Unix-words. + +Unix-words differ from Emacs words in that they are always delimited by +whitespace, regardless of the buffer's syntax table. This function +emulates how C-w at the Unix terminal or shell identifies words. + +Optional argument DELIM specifies what characters are considered +whitespace. It is a string as might be passed to `skip-chars-forward'. +The default is \"\\s\\f\\n\\r\\t\\v\". Do not prefix a `^' character." + (when (and delim (string-prefix-p "^" delim)) +(error "DELIM argument must not begin with `^'")) + (unless (zerop n) +;; We do skip over newlines by default because `backward-word' does. +(let* ((delim (or delim "\s\f\n\r\t\v")) + (ndelim (format "^%s" delim)) + (start (point)) + (fun (if (> n 0) +#'skip-chars-forward + #'skip-chars-backward))) + (dotimes (_ (abs n)) +(funcall fun delim) +(funcall fun ndelim)) + (constrain-to-field nil start + +(defun unix-word-rubout (arg) + "Kill ARG Unix-words backwards. +A Unix-word is whitespace-delimited. +Interactively, ARG is the numeric prefix argument, defaulting to 1. +A negative ARG means to kill forwards. + +Unix-words differ from Emacs words in that they are always delimited by +whitespace, regardless of the buffer's syntax table. +Thus, this command emulates C-w at the Unix terminal or shell. +See also this command's nakesake in Info node +`(readline)Commands For Killing'." + (interactive "^p") + (let ((start (point))) +(forward-unix-word (- arg)) +(kill-region start (point + +(defun unix-filename-rubout (arg) + "Kill ARG Unix-words backwards, also treating `/' as delimiting words. +A Unix-word is whitespace-delimited. +Interactively, ARG is the numeric prefix argument, defaulting to 1. +A negative ARG means to kill forwards. + +This is like `unix-word-rubout' (which see), but `/' is also treated as +a word delimiter. See this command's namesake in Info node +`(readline)Commands For Killing'." + (interactive "^p") + (let ((start (point))) +(forward-unix-word (- arg) "\\/\s\f\n\r\t\v") +(kill-region start (point (defcustom fill-prefix nil "String for filling to insert at front of new line, or nil for none." -- 2.39.2
bug#69097: [PATCH] Add 'kill-region-or-word' command
Hello, On Sat 07 Sep 2024 at 10:08pm +01, Sean Whitton wrote: > Hello, > > Thank you both for the feedback. Attached is an updated version. I neglected to update the docstring for adding backslashes as delimiters in unix-filename-rubout. Fixed in the attached, along with a another few small fixes. -- Sean Whitton >From 059ca7388494f21d13c87f114965a2ec1fc1cc55 Mon Sep 17 00:00:00 2001 From: Sean Whitton Date: Fri, 6 Sep 2024 11:35:46 +0100 Subject: [PATCH v4] New commands unix-word-rubout, unix-filename-rubout * lisp/simple.el (forward-unix-word): New function. (unix-word-rubout, unix-filename-rubout): New commands. * etc/NEWS: Announce the new commands. --- etc/NEWS | 6 ++ lisp/simple.el | 57 ++ 2 files changed, 63 insertions(+) diff --git a/etc/NEWS b/etc/NEWS index f3e719a34d3..104941425c2 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -123,6 +123,12 @@ When using 'visual-wrap-prefix-mode' in buffers with variable-pitch fonts, the wrapped text will now be lined up correctly so that it's exactly below the text after the prefix on the first line. +--- +** New commands 'unix-word-rubout' and 'unix-filename-rubout'. +Unix-words are words separated by whitespace regardless of the buffer's +syntax table. In a Unix terminal or shell, C-w kills by Unix-word. +The new commands 'unix-word-rubout' and 'unix-filename-rubout' allow +you to bind keys to operate more similarly to the terminal. * Changes in Specialized Modes and Packages in Emacs 31.1 diff --git a/lisp/simple.el b/lisp/simple.el index 2453a129d0a..18cc15f6f5d 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -8892,6 +8892,63 @@ current-word ;; If we found something nonempty, return it as a string. (unless (= start end) (buffer-substring-no-properties start end) + +(defun forward-unix-word (n &optional delim) + "Move forward N Unix-words. +A Unix-word is whitespace-delimited. +A negative N means go backwards to the beginning of Unix-words. + +Unix-words differ from Emacs words in that they are always delimited by +whitespace, regardless of the buffer's syntax table. This function +emulates how C-w at the Unix terminal or shell identifies words. + +Optional argument DELIM specifies what characters are considered +whitespace. It is a string as might be passed to `skip-chars-forward'. +The default is \"\\s\\f\\n\\r\\t\\v\". Do not prefix a `^' character." + (when (string-prefix-p "^" delim) +(error "DELIM argument must not begin with `^'")) + (unless (zerop n) +;; We do skip over newlines by default because `backward-word' does. +(let* ((delim (or delim "\s\f\n\r\t\v")) + (ndelim (format "^%s" delim)) + (start (point)) + (fun (if (> n 0) +#'skip-chars-forward + #'skip-chars-backward))) + (dotimes (_ (abs n)) +(funcall fun delim) +(funcall fun ndelim)) + (constrain-to-field nil start + +(defun unix-word-rubout (arg) + "Kill ARG Unix-words backwards. +A Unix-word is whitespace-delimited. +Interactively, ARG is the numeric prefix argument, defaulting to 1. +A negative ARG means to kill forwards. + +Unix-words differ from Emacs words in that they are always delimited by +whitespace, regardless of the buffer's syntax table. +Thus, this command emulates C-w at the Unix terminal or shell. +See also this command's nakesake in Info node +`(readline)Commands For Killing'." + (interactive "^p") + (let ((start (point))) +(forward-unix-word (- arg)) +(kill-region start (point + +(defun unix-filename-rubout (arg) + "Kill ARG Unix-words backwards, also treating slashes as word delimiters. +A Unix-word is whitespace-delimited. +Interactively, ARG is the numeric prefix argument, defaulting to 1. +A negative ARG means to kill forwards. + +This is like `unix-word-rubout' (which see), but `/' and `\\' are also +treated as delimiting words. See this command's namesake in Info node +`(readline)Commands For Killing'." + (interactive "^p") + (let ((start (point))) +(forward-unix-word (- arg) "\\/\s\f\n\r\t\v") +(kill-region start (point (defcustom fill-prefix nil "String for filling to insert at front of new line, or nil for none." -- 2.39.2
bug#72692: Emacs 31.05 (40eecd594ac) get SIGSEGV on Linux (Linux 6.6.45 Kde Wayland)
Eli Zaretskii writes: >> Cc: pip...@protonmail.com, exe...@gmail.com, 72...@debbugs.gnu.org, >> j...@linkov.net >> Date: Thu, 29 Aug 2024 15:26:07 +0300 >> From: Eli Zaretskii >> >> > From: Po Lu >> > Cc: Juri Linkov , pip...@protonmail.com, >> > exe...@gmail.com, 72...@debbugs.gnu.org >> > Date: Thu, 29 Aug 2024 20:06:17 +0800 >> > >> > Eli Zaretskii writes: >> > >> > > Po Lu, is there any reason why frame-parameter handlers for GUI frames >> > > should ignore the fact that the new value of a parameter is exactly >> > > equal to the old value? Is there some subtle issue here, and if so, >> > > does it affect all the parameters or only some? >> > >> > No reason occurs to me why redundant changes shouldn't be discarded in >> > the case of alpha-background, but modifications to other parameters >> > (e.g. Qfullscreen) always trigger recomputation of various window >> > manager properties and states, which is not redundant when these >> > properties change without Emacs's knowledge. >> >> OK, I was aware of the issues with Qfullscreen. >> >> But what about the rest? Would you mind reviewing the other handlers >> in frame.c, and telling which ones should do their thing regardless of >> whether the old and the new value of the parameter are identical? > > Ping! I will, but after the release. I'm a little drained of energy for these matters at the moment.
bug#73117: 30.0.90; Imenu missing entries when flattening by group
This issue appears to be similar to the issue reported in 70846, but
this is specifically regarding when Imenu is configured to flatten
into "groups" (as opposed to "annotation" as was reported there).
When "imenu-flatten" is set to "group", I see an issue where nested
entries, with the same name but belonging to different parents, aren't
all displayed.
I've included an example below (based on the example menu
configuration described in 70846). This example cycles through
flattening based on "index", "group" and "annotation" with the example
menu configuration.
For "prefix" and "annotation" configurations, it appears to work
correctly, as pressing "M-" when the menu prompt is displayed, I
can see both entries identified in the "*Completions*" buffer.
However, when I do this with "imenu-flatten" set to "group" and press
"M-" to display the completions window, the window indicates "2
possible completions" but only one is actually displayed and
selectable (i.e., the one under "Bar"). The menu entry "Foo" under
"Baz" is not displayed at all and it appears there is no way to select
it.
```
;; 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
```
bug#70968: 29.2.50; choose-completion on an emacs22-style completion deletes text after point
On 07/09/2024 10:30, Eli Zaretskii wrote: Date: Mon, 26 Aug 2024 03:08:56 +0300 Cc:sba...@janestreet.com,70...@debbugs.gnu.org,j...@linkov.net, monn...@iro.umontreal.ca From: Dmitry Gutov On 16/05/2024 21:25, Eli Zaretskii wrote: I don't think that would be required exactly. The problem here (IIUC) is that completion behaves differently with the emacs22 style depending on whether the execution path went through choose-completion (which is not a method of completion style but a common subroutine) or not (when completion--do-completion performed expansion). I understand that much. But what did these two (or their then-equivalents) do in Emacs 22 and Emacs 23? I'm guessing they behaved incorrectly (or however we want to call the inconsistent behavior), but I don't have a compiled Emacs 22/23 around, and they might be difficult to build. Note that we fixed bug#48356 not too long ago, which is from the same general area, and it probably originated from before Emacs 22/23 too. It's worth looking for edge cases where we'd strongly prefer the current behavior, and they might exist, but so far I only know of situations where the change would be for the better, or the user might be okay with either (example at the end ofhttps://debbugs.gnu.org/72705#35). Ping! How should we proceed with this bug report? I suggest we come up with a fix (which Stefan might have some ideas for), then see which reasonable scenarios get broken, if any. The one edge case in Eglot could be fixed in the same Emacs release, I believe. If any larger scope problems, we could add a variable/option to switch to the previous behavior.
bug#72768: [PATCH] Keep local keymap out of vc-git-stash-get-at-point
Version: 31.1 On 07/09/2024 10:33, Eli Zaretskii wrote: Date: Tue, 27 Aug 2024 03:37:54 +0530 From: James Thomas via "Bug reports for GNU Emacs, the Swiss army knife of text editors" James Thomas wrote: emacs -Q (define-key key-translation-map [?\C-j] (kbd "RET")) M-x vc-dir (select a git repo) (with point on a 'stash' entry) C-x v ! = C-j (fails) Of course, if a 'stash' doesn't exist, it may be created, so that the steps are: emacs -Q C-x C-f (open a git-tracked file, make changes), C-x C-s (and save it) C-x p v (select the above repo) z c (create stash) M-: (define-key key-translation-map [?\C-j] (kbd "RET")) (with point on the new 'stash' entry) C-x v ! = C-j (fails) Dmitry, any comments or suggestions? Makes sense. Pushed to master, thanks!
bug#73044: [PATCH] Add project-find-file-in-root
On 07/09/2024 09:10, Eli Zaretskii wrote: If you consider this not important enough to be in the manual, please mark the NEWS entry with "---", to convey your opinion. Added, thanks. Also split the entry into two lines.
bug#72701: eglot crash when project-files-relative-names t
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: diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index acc197754db..e5b14ce9f80 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -3813,6 +3813,7 @@ eglot--code-action (cl-defmethod eglot-register-capability (server (method (eql workspace/didChangeWatchedFiles)) id &key watchers) "Handle dynamic registration of workspace/didChangeWatchedFiles." + (defvar project-files-relative-names) (eglot-unregister-capability server method id) (let* (success (globs (mapcar @@ -3823,6 +3824,7 @@ eglot-register-capability ;; (2), WatchKind.Delete (4) (or kind 7))) watchers)) + (project-files-relative-names nil) (dirs-to-watch (delete-dups (mapcar #'file-name-directory (project-files diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index c38d3f0048a..78f5c127900 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -331,7 +331,10 @@ project-files-relative-names The file names should be relative to the project root. And this can only happen when all returned files are in the same directory. In other words, the DIRS argument of `project-files' has to be nil or a -list of only one element.") +list of only one element. + +This variable is only meant to be set by Lisp code, not customized by +the user.") (cl-defgeneric project-files (project &optional dirs) "Return a list of files in directories DIRS in PROJECT.
bug#72765: Eglot + Clangd + Company + non-empty suffix = duplicate text
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?)
bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code
> On Sep 4, 2024, at 9:32 PM, Yuan Fu wrote:
>
>
>
>> On Sep 4, 2024, at 12:42 AM, m...@ssbb.me wrote:
>>
>> I can confirm that I never had such problems in heex-ts-mode but only with
>> inline heex in elixir-ts-mode.
>>
>>> On Sep 4, 2024, at 10:39 AM, Wilhelm Kirschbaum
>>> wrote:
>>>
>>>
>>>
>>> On Thu, Aug 29, 2024 at 8:14 AM Yuan Fu wrote:
>>>
>>>
On Aug 28, 2024, at 10:09 PM, Eli Zaretskii wrote:
> From: m...@ssbb.me
> Date: Thu, 29 Aug 2024 06:57:38 +0400
>
> Code in attached file cause Emacs to hang and memory leak infinitely
> while editing. Try to open this code in elixir-ts-mode and move cursor
> on line 6 (between <:loading> ) and type char by char:
>
> <.some_component a={
>
> (for some reason it does not happen with electric-pair-mode when {}
> inserted automatically).
>
> I am able to reproduce this with -Q on few different machines (Linux and
> MacOS) and Emacs 29, 30.0.5 and current HEAD.
>
> C-g does nothing (including with debug-on-quit and sending SIGUSR2)
>
> At the same time I can't reproduce this in other tree-sitter based
> editors.
>
> I got this sample code sample from elixir-ts-mode repo but now it's moved
> to the Emacs core so seems to be out of scope of Github repo issues.
>
> Attaching samle code and LLDB backtrace.
> Also attaching report from built-in MacOS crash reporting tool just in
> case.
Thanks.
Wilhelm and Yuan, could you please look into this soon?
>>>
>>> That’s bizarre, might have some bug around ranges. I’m looking into this.
>>> Hopefully I can figure it out in a few days :-(
>>>
>>> Yuan
>>>
>>> I can reproduce the issue by following the above instructions, but need to
>>> do some digging. It only seems to be the case with embedded heex and not
>>> with heex-ts-mode by itself.
>>>
>>> WIlhelm
>>>
>
> At the moment I’m still not able to pinpoint the culprit, but here’s what I
> found: I can reproduce the issue by simply creating a heex parser, set the
> ranges to [108,240], [300,572], [820,1346] (these are byte position, aka one
> less than character position), then make it parse the buffer (with the
> "<.some_component a={" part already typed in. I instrumented the buffer
> reader and the program hangs after reading the character at byte position 908
> (end of "phx-click={“). Also the hang appears in ts_parser_parse.
>
> I wrote a C program that does exactly that, but the program runs fine without
> hanging. I haven’t found what Emacs does differently that causes the hang to
> happen.
>
> Also I found some other range bug, but fixing those didn’t help this issue.
Still don’t have much progress. The buffer’s gap is at the beginning, and
there’s no narrowing, which means the parser is really just reading a continues
chunk of memory, there’s no reason why it should behave differently. At this
point I might have to read tree-sitter’s source :-(
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?
Yuan
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: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?
bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code
> 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? Yuan
bug#73098: setopt float warning unexpected
> 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#73084: [PATCH] Include the variable name in the `setopt` warning
> Date: Sat, 07 Sep 2024 00:23:00 + > From: Okamsn via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > The attached patch adds the variable name to the `setopt` warning. > > I write my Emacs config in an Org file, from which I make the Emacs Lisp > file. Currently, if `setopt` detects that the value I wish to make a > variable hold does not conform to the variable's Custom.el type, then it > reports the type and the problematic value, but not the variable itself, > when I open Emacs. This adds extra steps to editing the code in the Org > file to fix the warning, especially when the value is created > programmatically. It would be faster to search for the variable name > directly in the Org file and to then re-tangle the Org file. Thanks, I made the warning say Value `foo' for variable `bar' does not match its type "type" I installed this on the master branch, and I'm therefore closing this bug.
bug#72966: 30.0.90; [PATCH] php-ts-mode: custom php.ini config for the built-in php webserver
> 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).
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 */
bug#72862: 29.1; Strange interaction between append-next-kill and kill-whole-line
> Cc: 72...@debbugs.gnu.org > Date: Thu, 29 Aug 2024 07:53:52 +0300 > From: Eli Zaretskii > > > From: Sean McAfee > > Date: Wed, 28 Aug 2024 14:12:11 -0700 > > > > Starting from emacs -Q: > > > > - Enter the text "12345\n" in the scratch buffer. > > - Kill the text by any means, eg: C-SPC C-p C-w > > - Enter the text "ABCDE" and put point on the C. > > - Run append-next-kill with C-M-w and then kill-whole-line with > > C-S-. > > - Yank the most recent kill with C-y. > > > > The text I get back is "AB12345\nCDE". Apparently the killed whole line > > is being wrapped around the preceding kill, at the place where point > > was, rather than being appended to it. > > Yes, because kill-whole-line kills the line in two parts. The > commentary to the code there says: > > ;; - We need to kill in two steps, because the previous command > ;; could have been a kill command, in which case the text before > ;; point needs to be prepended to the current kill ring entry and > ;; the text after point appended. > > Perhaps what the code there does needs to be augmented for the case of > append-next-kill. After reading the documentation of append-next-kill, I think I'm changing my mind on this. The doc string of append-next-kill says: (append-next-kill &optional INTERACTIVE) Cause following command, if it kills, to add to previous kill. If the next command kills forward from point, the kill is appended to the previous killed text. If the command kills backward, the kill is prepended. Since kill-whole-line kills both backward and forward from point, it seems we should expect that the first part is prepended to previous kill, whereas the second part is appended. Which is what the command already does. WDYT?
bug#73117: 30.0.90; Imenu missing entries when flattening by group
> This issue appears to be similar to the issue reported in 70846, but
> this is specifically regarding when Imenu is configured to flatten
> into "groups" (as opposed to "annotation" as was reported there).
> When "imenu-flatten" is set to "group", I see an issue where nested
> entries, with the same name but belonging to different parents, aren't
> all displayed.
>
> I've included an example below (based on the example menu
> configuration described in 70846). This example cycles through
> flattening based on "index", "group" and "annotation" with the example
> menu configuration.
>
> For "prefix" and "annotation" configurations, it appears to work
> correctly, as pressing "M-" when the menu prompt is displayed, I
> can see both entries identified in the "*Completions*" buffer.
>
> However, when I do this with "imenu-flatten" set to "group" and press
> "M-" to display the completions window, the window indicates "2
> possible completions" but only one is actually displayed and
> selectable (i.e., the one under "Bar"). The menu entry "Foo" under
> "Baz" is not displayed at all and it appears there is no way to select
> it.
>
> ```
> ;; 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`.
