I'm cc'ing stumpwm-devel because it looks like you
(presumably inadvertantly) didn't do this. Hopefully I'm not
taking a liberty.
On Thu, Dec 05, 2024 at 11:56:54PM +0000, LF wrote:
> In Stump there are multiple top maps, so you could bind keys to only be
> active in specific instances. Theres the *top-map*, *group-top-map*,
> *float-group-top-map*, *tile-group-top-map*, and
> *dynamic-group-top-map*. In addition, every minor mode has its own top
> map.
I'm confused: does this have any particular implications for
how I should make my binds?
The result I want is: a key like L-RET always makes a new
terminal, and L-2 always switches to group 2, unless I'm in
some kind of special-purpose submode^1 in which case that
doesn't necessarily have to happen. Or, you know, as close
to that as possible.
So for example I bind:
(define-key *top-map* (lead "w") '*notion-window-map*)
(define-key *notion-window-map* (kbd "s") "hsplit")
(define-key *notion-window-map* (kbd "v") "vsplit")
for doing splits with L-w s or L-w v (that way they're the
same as doom emacs). But it's not like I need L-w L-RET to
spawn a term or something.
In any case, my understanding based on looking at the code
and some example configs was that binding in *top-map* was
the correct way to have top level bindings, which is why I
have
(define-key *top-map* (lead "RET") "exec-term")
But you make it sound a bit like I'm supposesd to make that
bind in multiple different top-maps to get the result I
want.
If what you mean is that *top-map* is the _default_ top map,
but there are other top-maps which are merged into the
default top map in certain cases, and thus can override its
binds in some circumstances, then that's (probably) fine,
but it's not immediately obvious that this is what you mean.
Like, that's what would make sense to me, but I've been
burned by that assumption before.
> If i remember correctly there was an example minor mode posted on the
> devel mailing list when minor modes were added which implemented a mode
> line per frame, but left portions as exercises for the reader. It may be
> worth reading through that for ideas on how to implement an indicator
> that a frame has multiple tabs.
Neat! Maybe I'll look for it at some point.
> Finally, while i have little to add to your examples
Does that mean you have no idea about making the modeline
float? If so, who would know about that? I saw some
references to an ongoing project to combine float & tiled
windows in a single group somewhere. Is that happening? Are
people still doing that?
I suspect something like that would be more general than
whatever I would need for my specific use-case, but it'd be
worth knowing about.
Sorry, I hate to bug you about this when you were just
pretty clear, but I'm not really sure where to go to find
core stump folks if not the mailing list. If there are
better fora I should know about, please advise.
> I saw you mention CL-ADVICE and got excited - Im the
> author and maintainer, and it makes me very happy to see
> it being used in the wild.
Glad I could help.
I solved some issue in emacs with advice, so I saw this and
I thought: surely it must be possible to advise methods in
CL too, because CL is basically just elisp but better ("You
vs the lisp she tells you not to worry about"). Anyway, it
was a pretty straight shot from there to CL-ADVICE.
--dmr
[^1]: like notion's frame-resize mode or something like
that, where you'd have to ESC out to restore L-RET.
