On Sat, Jul 12 2025, Pip Cet wrote:

> Thanks.  It'd be nice to have a more general approach to growable
> vectors, but in this case, I don't understand why we use array
> structures at all: two simple linked lists should work just as well.

It seems that arrays are used because in some places the active minor
maps need to be processed in the reversed order from the order they are
stored in minor-mode-map-alist.

[...]
> My idea still would be to grow a vector aggressively until it's large
> enough to fit all elements, then "truncate" it in place in such a way
> that the GC knows to shrink it when it gets copied to the next
> generation.

This could work with MPS but I'm not so sure about the classic GC.

Here is a bit a different approach that doesn't use the cmm_vector:

  1. adds some test cases for the following changes

  2. uses Fcurrent_active_maps in keyboard.c and replaces the duplicated
     code with a common function

  3. replaces the remaining uses of current_minor_maps with
     functions that create some temporary lists

  4. This is an optional improvement for 2, if we are hellbent on
     avoiding consing & reversing the list returned from
     Fcurrent_active_maps.  This patch avoids the list at the cost of
     some complexity and alloca.