Onwards to 1.0 & most-wanted features

[mickeynp]

I'm going to cut a 1.0 release -- the first stable release -- of Combobulate in early 2026 or so. That sort of timeline. There's a few more issues to fix, but it's been quite stable for a long while now, so I think it's time.

So I wanted to ask: what are your most-wanted features? What do you want Combobulate to support/do next in terms of features?

[shsms]

I've only ever used it for Python, and it has change the way I write code. I like it even more than what emacs provides for lisp. Thank you for making it!

The one thing that I miss is the ability to navigate into elif/else blocks with just C-M-n from the if block. Right now, we have to switch back to basic navigation to reach them.

I also miss rust support, I might look into adding it the next time I'm on vacation.

[mickeynp]

Thanks for your kind words!

elif/else: it's not that it is impossible (you can amend the procedure rules to treat elif clauses as first-class citizens like if) but that it also affects everything: swapping nodes mean you can now swap if/elif and that of course breaks the tree. I had this feature enabled privately for a while and it worked fine, but it did have some awkward encounters in other areas. It's tricky thing to solve cleanly, though I do think there is scope to do so somehow!

I'm going to find time to add more language support. It does not take me long to do, but it's just meticulous work.

[robjgray]

Great package. I think highlighting could be improved.

Specifically, it doesn't allow me to highlight a majority of nodes and its error message isn't helpful. In my current code, I can edit the node text at point just fine in every place I try, but if I try to highlight those same nodes it tells me "Cannot derive a parent node from the current node"

I'm also unsure why console entries are always highlighted - what's the rationale for this?

[mickeynp]

Hi Rob. I am now even more confused.

Combobulate's carousel that you use when you type M-h for example locks the minibuffer because it is awaiting a key to be read. You should not see any text being obscured. The magit popup system is of course not going to do that either. So I am not sure what information it is you are losing.

[robjgray]

I am not sure what information it is you are losing.

I made a very short screen cap of it here. If you think it's an issue, perhaps you can point out a related area in the code and I could try to help with it?

[mickeynp]

I don't really see a problem here with Combobulate. The carousel is showing. When you're done, it goes away. You have some weird auto save stuff going on after edit. And it's noisy. That of course overrides what ever terminating message Combobulate has: it comes after, which obscures the message (if any) Combobulate has after making its changes.

[robjgray]

Okay. I'll work on getting other packages to avoid the minibuffer and re-evaluate my suggestion/request to avoid the minibuffer here. I'm generally not "done" editing or inputting by the time my other packages chime in but perhaps this is better solved by working with my other extensions than altering combobulate.

[mickeynp]

Combobulate emits messages on equal footing with your other packages. That means last one wins --- but that's how it is. You can pop open the message history with C-h e if you like, or find a way of silencing noisy packages.

[jgarvin]

I don't know if this is a documentation request or a feature request :) I think it would be useful to have some clarification around how to think about the navigation axes for control flow in Python and similar langs. Starting here:

-!-for (a,b) in zip([1, 2], [3, 4]):
    pass

combobulate (sanely) decides that navigating "down" from here must mean I want:

for (a,b) in zip([1, 2], [3, 4]):
    -!-pass

However, it's unclear to me what the best way to get this instead is:

for (-!-a,b) in zip([1, 2], [3, 4]):
    pass

Or:

for (a,b) in zip(-!-[1, 2], [3, 4]):
    pass

combobulate navigation is already 3D, since there is next/previous/forward/back/up/down, and forward/back seem to be the easiest way to navigate within the header, I've deduced I can go forward, then down, but this still behaves somewhat unintuitively. Seqeunce start:

-!-for (a,b) in zip([1, 2], [3, 4]):
    pass

Move forward 2x:

for (a,b)-!- in zip([1, 2], [3, 4]):
    pass

Move down:

for (a,b) in -!-zip([1, 2], [3, 4]):
    pass

Surprised that puts me on the zip rather than inside it, I'm guessing because in is forming an AST node? But from user POV it's weird that going down almost acts the same as going forward (almost because going forward a third time actually places you one character earlier).

[mickeynp]

Great points. The general answer for a lot of "why doesn't position X go to position Y" is usually down to a lack of explicit rules. There's a large amount of useful places for C-M-d to go to from a range of places, but haven't been specified by me or someone else for that matter due to a lack of urgency, time or interest: most of these are pretty specific and there are an infinite number of permutations we can generate, and also ambiguities where one really cool rule interferes with another really cool rule. So I've mostly made it so it just... moves around sensibly, focussing on code hierarchy as opposed to entering nested cul-de-sacs, with explicit rules and, failing that, it defaults to the natural tree of the grammar itself.

As for down/forward: yes that is the nature of mapping a tree with any arity of sibling and child nodes to a 2-dimensional display (X and Y) and you will lose a lot of information doing that unless you strictly move by tree nodes, but that is very very cumbersome and not useful at all for most languages aside from perhaps Lisp.