From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12526 invoked by alias); 24 Apr 2011 18:39:02 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 29033 Received: (qmail 1489 invoked from network); 24 Apr 2011 18:39:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110424113837.ZM30279@torch.brasslantern.com> Date: Sun, 24 Apr 2011 11:38:37 -0700 In-reply-to: Comments: In reply to "Jun T." "Re: menu-select interactive mode" (Apr 24, 7:40pm) References: <110409131236.ZM16037@torch.brasslantern.com > <110410074855.ZM9428@ torch.brasslantern.com> <110410115034.ZM9746@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh workers Subject: Re: menu-select interactive mode MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Apr 24, 7:40pm, Jun T. wrote: } } > .... (snip) } >Now hit ESC-m to enter menu-selection. I'm not even going to attempt } >to copy-paste the result, it's a screenful of garbage memory contents. } } I did some analysis on this problem. } I think I found what is causing the problem, but do not know how to fix it. } (The zsh is the latest CVS with ./configure --enable-zsh-debug). } } ## domenuselect() uses origline, but it has been corrupted } ## (it should be "ls "), and the command line will be broken soon. } } During "menu completion", the execution of zsh returns to } zlecore() after each TAB, and freeheap() is called at zle_main.c:1102. The problem seems to be that the menuselect widget bypasses docomplete() and jumps directly into domenuselect(). This misses out on some of the setup performed by docomplete() -- normally domenuselect() is entered from the after_complete() hook called at zle_tricky.c:869. There's a code fragment at the top of domenuselect() that is partly responsible for dealing with this situation: /* * Lots of the logic here doesn't really make sense if the * line isn't metafied, but the evidence was that it only used * to be metafied locally in a couple of places. * It's horrifically difficult to work out where the line * is metafied, so I've resorted to the following. * Unfortunately we need to unmetatfy in zrefresh() when * we want to display something. Maybe this function can * be done better. */ if (zlemetaline != NULL) wasmeta = 1; else { wasmeta = 0; metafy_line(); } In that else block I added code to populate origline/origcs/origll, as happens in docomplete() right after metafy_line(), and that resolves the memory issues -- but I'm not sure that menuselection is entered in the correct state. I think what *should* happen (from the user's point of view) is that the line is restored back to just "ls " (the starting point of menu completion) before selection begins. That is stored in the global struct "minfo" but I don't know the conditions in which it's OK to access that and whether minfo.pos points into a metafied or unmetafied line.