From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id E51323858D38 for ; Fri, 12 Apr 2024 17:24:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E51323858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E51323858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712942677; cv=none; b=t/P2+vKB142+I/yIqswFL3ZT467AlzxU2AO5ywLGEav1UCEjW/1acNxgtRyOn2vA3TOyrNYk8vCQx0D6zsS75v12jEsaE5HoNLhfihljbHZKlFgIYRo9mkzlWQc4X4PdXOnjOefqweFBCQmEzsOeSiSohZSpLt8YcVYXqn7DMKk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712942677; c=relaxed/simple; bh=/AGXck25Hgle9POVAGLqvtytg0tARLwIYBP3D69xqEU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=MMsGm/6hLLQS09PfmFr9557RYZfJdpnBcrbqvbRKxAwvCbBhzRa3xo2U7e7wrH1j2CCKeV12AfEBCEYl6Txb7Rlje5RgaPJNUujKi1DshkXIiazywggEWj3OQxDDVROBHUckUxzoPJ22/kdjTS3TE3Rzoi9JTJlF3t0799p2CFM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712942675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pc64n6mvflTbc3r8LyAzM6/ABicm6eJ3/W8ays6kJ28=; b=Y4ZoNJyqqwwfVt2OleB8PSmSLHnd6GsUh9/7sbvo/W27K9r/PbhbEyc28VC6FwPkInqpIQ Gk5bo3Ksz1tjMeERU+oZBUXVKC+zyxfl+usKNBCtyXZFobHifwI/vxW+Hs61rltZE6XSK9 OLMlyuGvHLI+BsHw+EFRyiQ9DAcTMwE= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-16-jHdf8EECOr2YpOk6TdjA_Q-1; Fri, 12 Apr 2024 13:24:34 -0400 X-MC-Unique: jHdf8EECOr2YpOk6TdjA_Q-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-41663c713b7so10818445e9.0 for ; Fri, 12 Apr 2024 10:24:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712942673; x=1713547473; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nf6VLH3pMus6GT3tjiChWF3NMhI8bgo4WZv4SVREzuA=; b=K46i7ngZW0dKZbs+LIrspjauogdCjlqWkAg5DpD55IQFsZ+vwh03OG/1TGHuH8263u 8FuuYKoGg4+08cF+aESi+HOexMjrzJATGOGwl0fjeZt9Ic9la6z7pI98WFz+sD/LWdAJ er3fm5XAnf5CLrlQ6mUpvItzX11n/S03+gk80pIMfAGcS3SIf0/19bf+7NoQHcmlBjL/ 81puZUFK9sAjHe64KBsnbsMmbwrO1jrYbucRvDCcw8uyypkn9hzmqAUV1lyL22ICilhe P9VW1VJLubQCDbH0pdQYb1gxzxStULLl8+5o3iTaVSrezqbvlTfhXwprUXjPksRl8YSx CfRw== X-Gm-Message-State: AOJu0YzwPtUAKrHONu7aAaWvMUgiXGFQvawLAGoW+E1LHcYKxGqBNJMG N3xSgJHMWpjMTq7W30QVw1E2yNmHOsPWr9DMa9VR+EwhCPxi3j6SKvf+WsdBKqS1oFE6FgpWOnc DHzqFDtzBTsyt/UsYPgROuqi0aPC2luDkGdloJtVi4QkftkJpCA1xtXevLLrpOA9HYQM= X-Received: by 2002:a05:600c:4708:b0:418:c7a:1242 with SMTP id v8-20020a05600c470800b004180c7a1242mr1575552wmo.6.1712942672923; Fri, 12 Apr 2024 10:24:32 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEa1EwZXfWpgbfYu+UuEhXKOkRwK1CEBjQLMGFdWzibhZqte5b0HkLAQRXPKzEWr79Q1YGTJQ== X-Received: by 2002:a05:600c:4708:b0:418:c7a:1242 with SMTP id v8-20020a05600c470800b004180c7a1242mr1575529wmo.6.1712942672259; Fri, 12 Apr 2024 10:24:32 -0700 (PDT) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id u14-20020a05600c19ce00b004162bac1393sm6223067wmq.43.2024.04.12.10.24.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Apr 2024 10:24:32 -0700 (PDT) From: Andrew Burgess To: Eli Zaretskii , Lancelot SIX Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/6] gdb: move display of completion results into completion_result class In-Reply-To: <86v853ar3c.fsf@gnu.org> References: <86v855dyls.fsf@gnu.org> <20240330233038.sol5j3cp7vsym4uz@octopus> <86v853ar3c.fsf@gnu.org> Date: Fri, 12 Apr 2024 18:24:31 +0100 Message-ID: <87v84m4hps.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Eli Zaretskii writes: >> Date: Sat, 30 Mar 2024 23:30:38 +0000 >> From: Lancelot SIX >> Cc: Andrew Burgess , gdb-patches@sourceware.org >>=20 >> On Fri, Mar 29, 2024 at 03:14:07PM +0300, Eli Zaretskii wrote: >> > > From: Andrew Burgess >> > > Cc: Andrew Burgess >> > > Date: Fri, 29 Mar 2024 11:42:28 +0000 >> > >=20 >> > > When using the 'complete' command to complete file names we have som= e >> > > problems. The suggested completion should include any required >> > > escaping, so if there is a filename '/tmp/aa"bb' (without the single >> > > quotes), then this should be displayed in the completion output like= : >> > >=20 >> > > (gdb) complete file /tmp/aa >> > > file /tmp/aa\"bb >> >=20 >> > Why should it be displayed with the backslash? And would the >> > completed name, if passed to a command, also have the backslash added? >> > If so, it could cause some commands to fail; basically, you are adding >> > shell file-name semantics into commands that don't work via the shell. >>=20 >> Hi, >>=20 >> The "file" command currently expects "shell file-name semantics": > > For starters, this fact, if it is true, is not really documented. Agreed. This can be improved. > >> $ gdb -q >> (gdb) file test/aa bb/a.out >> test/aa: No such file or directory. >> (gdb) file "test/aa bb/a.out" >> Reading symbols from test/aa bb/a.out... >> (gdb) file test/aa\ bb/a.out >> Load new symbol table from "test/aa bb/a.out"? (y or n) y >> Reading symbols from test/aa bb/a.out... >> (gdb) > > Next, if 'file' indeed expects shell file-name semantics, then the > question is: which shell? Should the above behave differently on, for > example, MS-Windows, since file-name quoting there works differently? > For example, escaping whitespace with a backslash will not work on > Windows. I think calling this "shell file-name semantics" makes this change seem worse than it is. If we want to call it anything, then it should be called gdb-shell semantics. That is, this is how GDB quotes filenames. This syntax isn't getting forwarded to any system shell, it remains entirely within GDB, so I don't think we'd need to change the behaviour for MS-Windows vs GNU/Linux. > Also, Andrew used the 'file' command in his examples, but completion > in GDB is used in many other commands, including those who don't > necessarily expect/need shell file-name semantics. These changes only impact filename completion, anything that doesn't specifically invoke the filename completion function will not change its behaviour. If you see any examples of this then that is 100% a bug in this work. > And last, but not least: the manual says about the 'complete' command: > > This is intended for use by GNU Emacs. > > So one other thing we should consider is how Emacs handles these cases > and what it expects from GDB in response. Happy to test such a thing. Can you point me at any instruction/guides for how to trigger completion via emacs? My hope is that this change will fix things rather than break them. Previously the 'complete' command would output a partial completion that was invalid, that is, if the user passes emacs a short string and then triggers completion, GDB would provide a longer string which was invalid. If emacs then feeds that longs string back to GDB the command isn't going to work. After this change that should no longer be the case. > >> The problem Andrew is trying to solve is that the current completer for >> this command completes to something that is not a valid input. > > My point is that we need to have a clear idea what is a "valid input" > before we decide whether the current behavior is invalid, and if so, > how to fix it. I do disagree with the "decide whether the current behaviour is invalid" part of this text. Completion of files containing whitespace doesn't work right now, so I'd suggest the current behaviour is self-evidently invalid. But ... > IOW, we should step back and discuss the valid > behavior first. I'm totally happy to take suggestions on what the working behaviour should look like. > Andrew's patch series started from postulating a > certain desired result without any such discussion, and I think we > should discuss these aspects before we decide what is the desired > result. Sure. My experience of proposing changes without patches is that folk say, "Sure, sounds good, but how _exactly_ will it work. What _exactly_ will it look like." And honestly, I'm just not smart enough to answer those questions without writing the code first. I'm ALWAYS willing to rework changes based on feedback. Please don't think, just because I posted a patch that I'm saying it _has_ to be this way. That said, you email raises the idea concerns, but I'm still not clear exactly _what_ your concerns are (other than emacs compatibility which has been covered above). I think there's something else which has been missed from this discussion, which is super important when we talk about what the "correct" behaviour should be: I'm changing _completion_, I'm not changing how GDB actually reads files names. Right now if we want to pass a file containing whitespace to the 'file' command then a user can either quote the filename, or escape the whitespace. That is _current_ behaviour, and is not something I'm touching in this series. This series makes the completion engine offer completions using those schemes: if the user didn't include an opening quote then the whitespace will be escaped. If the filename did have an opening quote then no escaping is necessary. As such, it would seem that unless we want to change how GDB currently parses filenames[*] then what completion should do is pretty much prescribed by GDB's parsing rules... I'll see if I can figure out the emacs thing, but if you do have some hints that would be great. Thanks, Andrew > >> That being said, this is just my 2 cent, I am looking forward to >> hearing other people=E2=80=99s thoughts on the subject. > > Same here. > > Thanks.