GNU bug report logs - #78943
feature/igc [PATCH] Trace current minor maps exactly

Previous Next

Full log

View this message in rfc822 format

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, pipcet <at> protonmail.com, 78943 <at> debbugs.gnu.org
Subject: bug#78943: feature/igc [PATCH] Trace current minor maps exactly
Date: Sun, 13 Jul 2025 17:31:36 +0200

On Sat, Jul 12 2025, Stefan Monnier wrote:

>>> The patch uses the GC heap if there are more than 16 minor mode keymaps
>>> active.  I'm not sure if that is enough; viper mode already activates 8.
>
> Could we adjust this size dynamically, keeping a high-water-mark?
> This way GC allocation would happen only when the high-water mark is
> changed (if it goes beyond a preset threshold if we care about
> contrived situations with thousands of minor mode maps).

The only way I can think of is with alloca/SAVE_ALLOCA.  GC allocation
could be avoided entirely if we are willing to call current_minor_maps
twice with when the number of minior mode maps changes:

  size_t size;
  Lisp_Object *buffer;
  static size_t predicted_size = 0;
  do {
    size = predicted_size;
    buffer = SAFE_ALLOCA (size * word_size);
    predicted_size = current_minor_modes (size, buffer)
  } while (size != predicted_size)

But this is not exactly a nice API and it can't be packed up as a
function because of alloca.

>> Adding Stefan to the discussion.
>
> Fixing the API of `current_minor_modes` sounds good to me.

There is a lot of duplicated code in the functions menu_bar_items,
tool_bar_items, and tab_bar_items.  The duplicated code builds an array
of keymaps.  I wonder if we couldn't replace this with
Fcurrent_active_maps?  It seems to do something very similar.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.