From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22733 invoked by alias); 21 Sep 2003 12:32:32 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22726 invoked from network); 21 Sep 2003 12:32:32 -0000 Received: from unknown (HELO balder.inter.net.il) (192.114.186.15) by sources.redhat.com with SMTP; 21 Sep 2003 12:32:32 -0000 Received: from zaretski (pns03-196-39.inter.net.il [80.230.196.39]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id CTM53972; Sun, 21 Sep 2003 15:32:07 +0300 (IDT) Date: Sun, 21 Sep 2003 12:32:00 -0000 From: "Eli Zaretskii" To: Joel Brobecker Message-Id: <1438-Sun21Sep2003152844+0300-eliz@elta.co.il> CC: gdb-patches@sources.redhat.com In-reply-to: <20030918191641.GY15984@gnat.com> (message from Joel Brobecker on Thu, 18 Sep 2003 12:16:41 -0700) Subject: Re: [RFC] Word break characters are language dependent Reply-to: Eli Zaretskii References: <20030918191641.GY15984@gnat.com> X-SW-Source: 2003-09/txt/msg00443.txt.bz2 > Date: Thu, 18 Sep 2003 12:16:41 -0700 > From: Joel Brobecker > > I was working on implementing proper completion for Ada in GDB, and > ended up reading this part of the code (completer.c:localtion_completer()): > > else if (strchr (gdb_completer_word_break_characters, *p)) > symbol_start = p + 1; > > Unfortunately, the word-break characters for Ada are not exactly the > same as the ones used by default. As a consequence, the current > completer does not always find the correct starting location of the > symbol name. So I think we should make them language-dependent by > adding a new field to the language vector. Did you actually try to replace the hard-coded string with a different one that is good for Ada, and see if that solves your problem? I'm asking because I have a vague memory of things being not-quite-that-simple in that part of the code, since readline's interface with customized completers is--how should I put it?--less than optimal. So I think before we discuss the design of a possible solution, we should be sure that it is in fact a solution ;-) Other than that, I think your general idea is correct and the proposed direction is reasonable.