From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 75fba4a1 for ; Sat, 24 Aug 2019 21:18:04 +0000 (UTC) Received: (qmail 17158 invoked by alias); 24 Aug 2019 21:17:56 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24183 Received: (qmail 16167 invoked by uid 1010); 24 Aug 2019 21:17:56 -0000 X-Qmail-Scanner-Diagnostics: from wout4-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25545. spamassassin: 3.4.2. Clear:RC:0(64.147.123.20):SA:0(-2.6/5.0):. Processed in 4.194818 secs); 24 Aug 2019 21:17:56 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type :content-transfer-encoding; s=fm1; bh=0Sew0qGskISLI8ZlbHjwLXTaEM LSD+ETqjhf2ZthLq4=; b=bKTjxQeZ8YrVTUNa1tbTNw3RSOIVSHRDdNoqiibkKz r1SOsv4HbXGSFVsVMarp2RIBTxZdQOqXf3MBtkoI6/FhXeSTERYZVyC/mhkPwfd8 Iv6EvFm0uc6lTZdz56rDTmzIxGNffKwvqBu9QGtggqWXyj6j65Vo/a/gR1hLV3Hc s6AOh+rvC8lkb7Dth+Kz9jB9qwx+ZRygY6hZRjgxaD0GvFYhk7cBge2eKJZtQ7RC utQzfkkbLqmneAYsb9AWNEDXlH0ePxaDt59GXxUjmPaSXh2XZhCxsVsab0A/vFCO 9WcUn4TuTl+iFZHcL9XsfpYE8Q51pBNTegmyywvSNbjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=0Sew0qGskISLI8ZlbHjwLXTaEMLSD+ETqjhf2ZthL q4=; b=ituakbnhiPiWvCR24VWLTxPPu9QgLR47johgQWHJYFGZluaSUwzhBK6ID sPN90y8XbQ7H4kdtsulzXDZnq3ZUSMB7K4Ne1OIw9LNnl4puluBnaj4KnXk5IvCD XiO+HYXkg9ZG/hfNF8xJDvoJXiovAZf3z9k+VTTuXO53VoVzQKclSShsMRn7jjX1 1FdeUod/QCdCaDwJygDQzknHoG/nPf4mgRHpXFoDCbthovbosoydCd5EktPbB39D sgegp3fe7iEJreJXzkBYgPT8T5nJ4Q7wyvS5LUsbkVOoyBliu8RUkYO7UBUlot2g JxqiAZsJzjMUeYytJezaIFnUmckFg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudehtddgudeifecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdff rghnihgvlhcuufhhrghhrghffdcuoegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrg hmvgeqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghnihgvlhdrshhhrghh rghfrdhnrghmvgenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-916-g49fca03-fmstable-20190821v7 Mime-Version: 1.0 Message-Id: In-Reply-To: <7E7BD433-3D39-4D86-9EAA-6DE282B5CFAF@uniroma1.it> References: <5521481D-C84A-449A-BBF7-0C429868247B@uniroma1.it> <20190824172433.c4v252jc4czjsyay@tarpaulin.shahaf.local2> <7E7BD433-3D39-4D86-9EAA-6DE282B5CFAF@uniroma1.it> Date: Sat, 24 Aug 2019 21:16:48 +0000 From: "Daniel Shahaf" To: "Cristiano De Michele" Cc: zsh-users@zsh.org Subject: Re: subversion complete functions obsolete Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Cristiano De Michele wrote on Sat, 24 Aug 2019 20:26 +00:00: > Dear Daniel, > first of all thank you for the prompt reply. To reproduce the issue tr= y=20 > to do what follows. > Let's assume that there is a file called 'rescheduler.py' and a=20 > directory > called 'RESCHEDULE_EXAMPLE' in a svn repository (both under version=20= > control), then > > svn diff r=20 > does not complete it as expected, since it suggests only the directory= =20 > 'RESCHEDULE_EXAMPLE'. Interesting. I can reproduce this in a new repository that contains just these two entries, but if I go to one of my usual working copies an= d modify some files, those files do get offered by the completion. > The same odd behavior can be also experienced with 'log' argument=20 > (i.e. svn log). Okay, but note that 'diff' and 'log' would be expected to complete different things. 'diff' tries to complete only files with local mods; 'log' should complete only filenames that exist on the server. For exam= ple: Status diff? log? ------ ----- ---- A yes no M yes yes no yes > With my patch it should provide all possible completions (i.e. all=20 > files and disr in the folder), since I removed completely the smart=20= > logic, >=20 > which was present in the original functions (i.e. I removed everywhere= =20 > the -g option and the relative argument of function _file) As I said in my previous email, simply using _files wouldn't complete everything that should be completed: files with status '!' or 'D', or files with 'Depth: exclude', for example. > (( $+functions[_svn_controlled] )) || > _svn_controlled() { > sta=3D$(svn status $REPLY)=20 > stat=3D$sta[1] > [[ $stat !=3D "?" ]] > } This sounds right, though the machinery currently in there (_call_program, cache) should be added back. Calling 'svn st foo' for each file individually would be slow. Also, a '--' should be added. > (( $+functions[_svn_status] )) || > _svn_status() { >=20 > sta=3D$(svn status $REPLY)=20 > [[ "$sta" !=3D "" ]] > } Not sure. What about conflicted files? Unmodified files in a changelist? Unmodified files that were locked by another working copy? > but I am not sure they work as the original versions=E2=80=A6 > I agree with you that _svn_conflict could be kept. According > to what you wrote a possible implementation of _svn_deletedfiles could= be >=20 > sta=3D$(svn status $REPLY)=20 > stat=3D$sta[1] > [[ $stat =3D=3D =E2=80=9CD" ]] What about completing foo/bar after =C2=ABsvn rm foo=C2=BB? > what do you think? Thanks a lot for working on this. Let's try to break this into small, incremental improvements. > The patch file is attached, You sent the diff reversed: the file as in HEAD of master should be the first argument to diff. Also, for bonus points, send the diff with a .txt extension and not compressed. (Doing so gives it a text/* MIME type, which makes the diff easier to read on our end.) Cheers, Daniel