From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5062 invoked by alias); 21 Nov 2014 17:28:44 -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: 33742 Received: (qmail 8599 invoked from network); 21 Nov 2014 17:28:41 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Authority-Analysis: v=2.1 cv=AduIQRnG c=1 sm=1 tr=0 a=SBdK3agBVlyT/P6vVha89Q==:117 a=SBdK3agBVlyT/P6vVha89Q==:17 a=G8GL833Es-AA:10 a=N659UExz7-8A:10 a=Xma7W6vfTBhujGM9moEA:9 a=pILNOxqGKmIA:10 Message-id: <546F7646.7080108@eastlink.ca> Date: Fri, 21 Nov 2014 09:28:38 -0800 From: Ray Andrews User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-version: 1.0 To: zsh-workers@zsh.org Subject: trouble with debugging binary References: <930.1416260160@thecus.kiddle.eu> <42F4E5F2-97E7-4803-87CB-B1C67CD943B2@kba.biglobe.ne.jp> <15511.1416528068@thecus.kiddle.eu> <546E9224.7090709@eastlink.ca> <546EA58F.7010101@eastlink.ca> <141120222353.ZM10495@torch.brasslantern.com> In-reply-to: <141120222353.ZM10495@torch.brasslantern.com> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit On 11/20/2014 10:23 PM, Bart Schaefer wrote: > Please don't hijack threads by hitting "reply" and then starting a > whole new conversation. If you have a new topic, start a new message. > Thanks. Pardon, it morphed out of what seemed like an error report on that topic. > > } Anyway, I deleted all of them and: > > Where were they before you deleted them? All in /usr/share/zsh/functions /usr/share/zsh/functions/Completions I'll restore them. No doubt they do something important, but I'm not noticing their absence right now. Is there some sort of global map of everything that zsh adds to one's system? These *.zwc files, I had no idea they were there and I have no idea what they do. } 6: text.c:865: unknown word code in gettext2() } 1: text.c:865: unknown word code in gettext2() } 7: text.c:865: unknown word code in gettext2() } 8: text.c:865: unknown word code in gettext2() } This is a bit suspicious because gettext2() is only called when turning a wordcode program back into readable text; for example, when calling a DEBUG trap or preexec. ... I can't say. I have this (which you helped me with some time ago): typeset -g TLC TRAPDEBUG() { (( $#functrace == 1 )) && TLC=(${(z)ZSH_DEBUG_CMD}) } I just rebuild without " --enable-zsh-debug " and all is well. Removing the above function, all is well with the debugging binary. So none of this had anything to do with the 'vi' patches and everything to do with TRAPDEBUG not liking the debugging binary. Tho one might expect that a specifically debugging function would go well with a specifically debugging binary.