Hi,
A little late, as the bug was closed.
I think this bug also applies to my set-up. My Gnus has these time-outs,
all the time, and, I agree with Eric it started with Emacs 29 (Debian).
I can perhaps contribute logs, if needed.
On Tue, 10 Sep 2024 09:37:11 +0200 Gijs Hillenius wrote:
> Hi,
>
> A little late, as the bug was closed.
>
> I think this bug also applies to my set-up. My Gnus has these time-outs,
> all the time, and, I agree with Eric it started with Emacs 29 (Debian).
Possibly bug#52735 (which I continue to e
Eli Zaretskii writes:
Hi Eli,
>> The umbrella function is tramp-send-command. It sends the command to
>> remote via tramp-send-string, and waits then for a proper shell prompt
>> via tramp-wait-for-output. The latter function calls
>> tramp-wait-for-regexp, which loops using tramp-accept-process
Stefan Monnier writes:
> I tend to agree. If the type doesn't accept the value, you can use
> something lower-level than `setopt` [...]
What would that be in case the option has a custom setter function?
Michael.
Thank you all for the fix.
Emacs is Awesome
Casey Banner writes:
> AC_INIT([libexec], [30.0.50], [bug-gnu-emacs@gnu.org], [],
> [https://www.gnu.org/software/emacs/])
This version number shouldn't appear in any binaries built for
MS-Windows (or otherwise than for Android in general), and its value is
not really significant even there.
>> What does (frame-text-height) return for the first and the
>> second frame?
>
> 1260 for both.
Relieving.
>>Also I hope you didn't get the GTK assertion failure.
>>
>
> Indeed, I do not.
So the sequence definitely is: For some inexplicable reason we receive a
ConfigureNotify event that t
> From: Stefan Monnier
> Cc: Michael Heerdegen , shipmi...@gmail.com,
> 73...@debbugs.gnu.org
> Date: Mon, 09 Sep 2024 18:41:46 -0400
>
> IMO, the whole point of `setopt` is to check the value against the type.
I agree, but some users expect setopt to be a variant of setq,
especially since we
> Date: Tue, 10 Sep 2024 02:32:46 +0300
> Cc: phil...@posteo.net, 43...@debbugs.gnu.org
> From: Dmitry Gutov
>
> >>> I don't understand why the obvious way of asking the user whether they
> >>> would like to generate the tags table is not the solution here. What
> >>> did I miss?
> >>
> >> I don
> Date: Tue, 10 Sep 2024 03:58:58 +0300
> Cc: joaotav...@gmail.com, 72...@debbugs.gnu.org
> From: Dmitry Gutov
>
> >> The backtrace that I managed to generate is attached.
> >
> > Thanks. Please try the patch below.
>
> Thanks! The patch takes care of the crash AFAICS (no core dump now), but
> From: Sean McAfee
> Date: Mon, 9 Sep 2024 22:13:06 -0500
> Cc: 72...@debbugs.gnu.org
>
> 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
>> I tend to agree. If the type doesn't accept the value, you can use
>> something lower-level than `setopt` [...]
> What would that be in case the option has a custom setter function?
AFAIK people used `setq` before `setopt`. For vars that come with
setter functions, this usually doesn't work q
> From: Casey Banner
> Date: Tue, 10 Sep 2024 00:15:24 -0400
>
> I recently pulled the latest emacs-30 branch
> (f47297782bdb5e5a07e02f119c8013d11f7d7fae),
> and I'm building emacs using MSYS2 mingw64 on Windows.
>
> With a build on this branch, certain symbols (from the nerd-icons
> package)
> From: Casey Banner
> Date: Tue, 10 Sep 2024 01:50:43 -0400
>
> I did a procmon dump to see what .pdmp files emacs.exe is trying to load, and
> it attempts these locations:
>
> - E:\dev\emacs-src\bin\emacs.pdmp
> -
> E:\dev\emacs-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs-ef314e5e05618
> Cc: 73...@debbugs.gnu.org
> Date: Tue, 10 Sep 2024 17:29:27 +0800
> From: Po Lu via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors"
>
> Casey Banner writes:
>
> > AC_INIT([libexec], [30.0.50], [bug-gnu-emacs@gnu.org], [],
> > [https://www.gnu.org/software/emacs/])
>
>
Eli Zaretskii writes:
> Unrelated to the problem of the MinGW build, the fact that
> exec/configure.ac is not modified by admin/admin.el:set-version is a
> bug, don't you agree? We should have 30.0.90 in that file, not
> 30.0.50, right?
Yes I do. I think I'll make this so tomorrow.
On 10/09/2024 14:47, Eli Zaretskii wrote:
Date: Tue, 10 Sep 2024 03:58:58 +0300
Cc:joaotav...@gmail.com,72...@debbugs.gnu.org
From: Dmitry Gutov
The backtrace that I managed to generate is attached.
Thanks. Please try the patch below.
Thanks! The patch takes care of the crash AFAICS (no core
> This is caused by commit 63588775fcb, so Cc-ing Stefan.
>
> But probably this commit just exposed the problem
> that existed before?
I think you're on to something.
> => (error "Match data clobbered by buffer modification hooks")
This comes from
if (search_regs.num_regs != num_regs)
> We should probably use something like
>
> ptrdiff_t
> search_regs_last_reg (void)
> {
> ptrdiff_t i = search_regs.num_regs - 1;
> while (i >= 0 && search_regs.start[i] < 0)
> i--;
> return i;
> }
>
> instead of `search_regs.num_regs`.
And maybe we should
On 10/09/2024 14:41, Eli Zaretskii wrote:
But what do you expect from a backend that depends on TAGS to do when
TAGS is not there? You yourself just noticed the regression. Why
would we want that?
I'm thinking of the xref-find-references case - where the scanner
doesn't depend on the tags ta
On 10/09/2024 15:45, Eli Zaretskii wrote:
Cc: phil...@posteo.net, 43...@debbugs.gnu.org
Date: Tue, 10 Sep 2024 14:41:43 +0300
From: Eli Zaretskii
How do you feel about etags-regen-mode being on by default in some next
Emacs release? It shouldn't conflict with the manual invocations of 'M-x
vis
> Cc: phil...@posteo.net, 43...@debbugs.gnu.org
> Date: Tue, 10 Sep 2024 14:41:43 +0300
> From: Eli Zaretskii
>
> > How do you feel about etags-regen-mode being on by default in some next
> > Emacs release? It shouldn't conflict with the manual invocations of 'M-x
> > visit-tags-file' - and of
> Date: Mon, 09 Sep 2024 22:38:13 +
> From: Serghei Iakovlev via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors"
>
> I’m reaching out because I’ve hit a wall after spending many hours
> debugging what seemed like a straightforward issue but turned out to
> be a rabbit ho
> Cc: 73...@debbugs.gnu.org
> From: Ihor Radchenko
> Date: Tue, 10 Sep 2024 06:19:41 +
>
> Serghei Iakovlev via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" writes:
>
> > --8<---cut here---start->8---
> > (require 'ps-print)
> > (ps
> Cc: 73...@debbugs.gnu.org
> Date: Tue, 10 Sep 2024 16:51:28 +0300
> From: Eli Zaretskii
>
> However: I last used this with Emacs 21, which is before Emacs was
> converted to Unicode-based treatment of non-ASCII characters. So it
> is possible that the above will not work with the current codeb
Zhengyi Fu writes:
> Philip Kaludercic writes:
>
>> Zhengyi Fu writes:
>>
>>> When I try recompiling all packages installed by package.el with `M-x
>>> package-recompile-all', I got the following error:
>>>
>>> Debugger entered--Lisp error: (permission-denied "Removing old name"
>>> "Permission
Philip Kaludercic writes:
> Zhengyi Fu writes:
>
>> When I try recompiling all packages installed by package.el with `M-x
>> package-recompile-all', I got the following error:
>>
>> Debugger entered--Lisp error: (permission-denied "Removing old name"
>> "Permission denied"
>> "/usr/share/emacs/s
Eli Zaretskii writes:
>> Cc: monn...@iro.umontreal.ca
>> From: Spencer Baugh
>> Date: Mon, 26 Aug 2024 10:17:05 -0400
>>
>> In 63a48252306a631dc07d62d19311433c7877bd27 I fixed a bug with
>
> Git tells me "bad object 63a48252306a631dc07d62d19311433c7877bd27", so
> I couldn't figure out which comm
Stefan Monnier writes:
>> Ping! How should we proceed with this bug report?
>
> I don't quite understand the question.
>
> After:
>
> Eli wrote:
>> Stefan wrote:
>> > I'm not sure it's terribly important to preserve this detail of the
>> > behavior of `Emacs-22`. The `emacs22` style does not aim
On Tue, 10 Sept 2024 at 10:32, martin rudalics wrote:
>
> Since you run with
>
> emacs -Q --eval "(setq default-frame-alist '((menu-bar-lines . 0)))"
>
> Emacs considers menu bars to be currently enabled "globally" and
> disabling them globally has no effect on that frame. Do you agree with
> t
Can I just check: do you want me to apply your latest gtkutil-reject.diff
on top of your previous size_hints.diff, or instead of it?
Instead of it.
martin
> Please try the attached diff (from my heavily edited copy of master, if
> it doesn't apply cleanly, complain immediately rather than messing up
> your Emacs). It should fix two silly bugs in window.el that make a
> frame's safe minimum size much too large and includes the fix I proposed
> earlie
> How come your LANG is set to en_US.UTF-8? Did you set this in the
> environment or something. Using UTF-8 as the default encoding on
> Windows is not a good idea.
It seems that the msys2 .profile has `export LANG=$(locale -uU)`, and that
returns en_US.UTF-8 for me.
> Please look at src/epaths
Tags: patch
(The following change is split across two patches; the first one, "move
easy-mmode", fixes an unrelated FIXME, which makes the diff in the
second patch simpler)
If point was after a file or hunk header, the diff-file-prev and
diff-hunk-prev commands would move to the start of that he
> From: Casey Banner
> Date: Tue, 10 Sep 2024 14:31:07 -0400
> Cc: 73...@debbugs.gnu.org
>
> > How come your LANG is set to en_US.UTF-8? Did you set this in the
> > environment or something. Using UTF-8 as the default encoding on
> > Windows is not a good idea.
>
> It seems that the msys2 .pro
> OK, so that's one mystery down. We are left with the HarfBuzz issue;
> please answer the questions I asked about that.
Ah, yes sorry - I acquired the DLLs from the
mingw64/mingw-w64-x86_64-harfbuzz package.
$ objdump -x /mingw64/bin/libharfbuzz-0.dll | grep "DLL Name":
DLL Name: libgc
Artur, do you have any thoughts on the below patch?
Spencer Baugh writes:
> From 28e52a343f72991cafd23fea910cc5f64ac5 Mon Sep 17 00:00:00 2001
> From: Spencer Baugh
> Date: Thu, 12 Oct 2023 18:01:46 -0400
> Subject: [PATCH] Support numeric indexing in let-alist
>
> let-alist is very useful.
Friendly ping for feedback.
--
Xiyue Deng
Michael Albinus writes:
> Tramp used a non-zero timeout in the past. This was removed some years
> ago, I don't remember the reason.
The timeout in tramp-accept-process-output was disabled in commit
54ef338ba3670415cf47fabc33a92d4904707c7e . The commit mentions
bug#61350 , however, it's not cle
Hi,
Xiyue Deng wrote:
> Hi,
>
> i'm having some issues that Gnus sometimes reports that there are new
> messages on an IMAP server but it doesn't show them. In my case it's
> using Gmail IMAP, and if I check using other mail clients
> (e.g. Thunderbird) or directly check on Gmail website I can s
> From: Casey Banner
> Date: Tue, 10 Sep 2024 14:56:28 -0400
>
> > OK, so that's one mystery down. We are left with the HarfBuzz issue;
> > please answer the questions I asked about that.
>
> Ah, yes sorry - I acquired the DLLs from the
> mingw64/mingw-w64-x86_64-harfbuzz package.
>
> $ obj
> On Sep 8, 2024, at 12:48 AM, Yuan Fu wrote:
>
>
>
>> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii wrote:
>>
>>> From: Yuan Fu
>>> Date: Sat, 7 Sep 2024 22:57:29 -0700
>>> Cc: m...@ssbb.me,
>>> wkirschb...@gmail.com,
>>> 72...@debbugs.gnu.org
>>>
>>>
>>>
On Sep 7, 2024, at 10:54 PM
> On Sep 9, 2024, at 2:50 AM, Vincenzo Pupillo wrote:
>
> In data martedì 27 agosto 2024 14:22:16 CEST, Eli Zaretskii ha scritto:
>>> From: Yuan Fu
>>> Date: Mon, 26 Aug 2024 20:13:52 -0700
>>> Cc: e...@gnu.org,
>>>
>>> vincenzo.pupi...@unimi.it
>>>
>>> Yuan Fu writes:
X-Debbugs-CC: e
Finally able to address this again.
> On Aug 28, 2024, at 11:01 PM, Eli Zaretskii wrote:
>
>> From: Yuan Fu
>> Date: Wed, 28 Aug 2024 21:54:26 -0700
>> Cc: Stefan Kangas ,
>> Alan Mackenzie ,
>> 64...@debbugs.gnu.org
>>
>> Ah, thanks for the review! TIL. Here’s the revised patch.
>
> A few mo
44 matches
Mail list logo
