Re: PATCH: completion in braces

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> On Oct 19,  3:50pm, Sven Wischnowsky wrote:
> } Subject: PATCH: completion in braces
> }
> } Horrors.
> } 
> } This allows completion inside nested braces.
> } [...] the next thing on my list if the nested-quotation problem and 
> } that may become at least as hard as this one...
> 
> Is there any point at which one of these glorious hacks of yours is
> likely to make the code *simpler*? :-)

We already had two of those. Some time ago.

> I always get nervous when I see a uuencoded block, but this doesn't
> look too horrific at all.

Yeah, since I have the same feelings when I see such blocks, I was
hesitating to uuencode it, but then wanted to save some bandwidth.

> ...
> 
> } I stumbled of some code in `do_single()' (that's where a single, full
> } match is inserted -- either because there is only one match or during
> } menucompletion) which makes sure that the otherwise automatically
> } inserted comma when completing in braces is *not* inserted during a
> } menucompletion. Does anyone rememeber why we did that?
> 
> When one of the possible menucompletions is a directory, the directory
> name gets a slash auto-appended to it, which then is autoremoved when
> you type the comma.  If the brace-completion code also auto-appended a
> comma, the slash wouldn't get autoremoved when you typed another comma.
> I think.

Ah, yes. I think this was the reason.

> } The second question: `zle_tricky.c' has now more than 10000
> } lines. Ouch. Maybe we should cut it in two/three/four/etc. parts. But
> } 1) if we ever offer all the things `comp{ctl,gen}' can do via
> } `compadd' plus something, then there is a lot of code that can be
> } removed from the file (or maybe if we have these mechanisms, we can at 
> } least put that stuff, which will eventually be removed, into a
> } separate file)
> 
> If you were up for a major code-factoring project -- refer to my remark
> above about glorious hacks -- I think it would be a great idea to make
> old-completion and new-completion into separate modules that both call
> a set of common functions wherever possible.

The idea we had at the beginning, yes. Since the C-code in tricky.c
(or, at least, most of it, including the way the functions call each
other) should be stable enough now, we really could start to think
about this. There is only the problem with `compgen'. As long as we
still have it, there is a lot of code needed by both old and new
completion. And exactly that type of code I'd like to move out of the
way.

Maybe I'll find time at the weekend to see what we need to remove
`compgen', implement that and then split the completion code. (Now
*that* would be fun writing, I think).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx