From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#56865: M-x find-dired fails with "Wrong type: processp, nil" Date: Fri, 12 Aug 2022 17:12:07 +0200 Message-ID: References: <87pmhjylv1.fsf@gnus.org> <875yjax4te.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004d796f05e60cb541" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23885"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56865@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 12 17:24:04 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oMWW2-000609-PC for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Aug 2022 17:24:02 +0200 Original-Received: from localhost ([::1]:46130 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMWW1-0005oA-Q4 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Aug 2022 11:24:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49780) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMWLO-0006p3-NN for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2022 11:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40614) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oMWLO-0004ge-Dz for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2022 11:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oMWLO-0005qy-99 for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2022 11:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Aug 2022 15:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56865 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 56865-submit@debbugs.gnu.org id=B56865.166031714922454 (code B ref 56865); Fri, 12 Aug 2022 15:13:02 +0000 Original-Received: (at 56865) by debbugs.gnu.org; 12 Aug 2022 15:12:29 +0000 Original-Received: from localhost ([127.0.0.1]:58595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMWKq-0005q5-MC for submit@debbugs.gnu.org; Fri, 12 Aug 2022 11:12:29 -0400 Original-Received: from mail-ej1-f49.google.com ([209.85.218.49]:41934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMWKn-0005pr-BC for 56865@debbugs.gnu.org; Fri, 12 Aug 2022 11:12:27 -0400 Original-Received: by mail-ej1-f49.google.com with SMTP id gk3so2526736ejb.8 for <56865@debbugs.gnu.org>; Fri, 12 Aug 2022 08:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=IxEUmCQEgOQNG1Pl3pN7HBkKjQ9quXRcQIwJjTq774I=; b=kcFLQTrTzfk00XPactPTO7JVszH83d5o0Jl623gEUEqBzbjXVZdPnBEUPmvNPALlHg iwKcm/tKb/SfSCw32U7E7Rl3HCskPvbeY0DnoZa7YhtCFB4V0TTd9DMNlUHzAY3IKGqL U/nkkNVtoUuWFej7mQmU5vmRzsZVsDKSCahSSM1VLAaqJGn6tEXlRIOnD+kXmxCKg4je MPnOM/Zf+06Ob8pxspHzraPh9VJzXl1GdJ3HG/cP4ts++XRoUwNSRkIlIwMCQNaGvsiE WTxoYX6AwcAsrliQ204s9syHUi9YUflXFwhkaxfAzEdlYEhWDvYiVyG7UCb3Mmh17C1X vciQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=IxEUmCQEgOQNG1Pl3pN7HBkKjQ9quXRcQIwJjTq774I=; b=miJzM++mGUFW7PR4GKgNILGEwfBSebFXzKF4YRvlucrQnJ7alJQX32nTdlIjyUbb9V F0dd0Pfz96GypHZrEJVZw+Uvl0gasXJIc5Phe5XY2z453sfzJNGh20j7NaPsn1Mmnij9 mNxZx/EFVso/eMDjhymOVK1AtFMGlzDT1khwUyxJnlU831IMsbuT21EIPg5L12gFTwiZ 5EZG1Q5JrDkQj3kIVvdE0kmnXTgIcwLzGK2rorkJMiQ01mK3ThuBJbUl26eVUrFOwbFA S/FKDteQOD2W08VeYRu7aD8mAX3B8YHREtITiSMGkwKNYzC89WU8L44tzPUW8n9TL5sL +CHA== X-Gm-Message-State: ACgBeo30+DgvfkRYLaUMVNTNruSVLS9ifAV+9PXLDuo8TEFDQDZX2aSB vtXx9fx03SZSJlygSu66rEYVA/whBbsCMDsuGQ== X-Google-Smtp-Source: AA6agR6p0xHWnQLtCpkATuYuC+i3M7n6+l6T0aGJDw/IljGoMS91t01eGSnWmnAnkoo4LK/RWKIA/+NzfvG9piEa+rk= X-Received: by 2002:a17:907:7b95:b0:731:113a:d7a2 with SMTP id ne21-20020a1709077b9500b00731113ad7a2mr2855963ejc.377.1660317139301; Fri, 12 Aug 2022 08:12:19 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:239424 Archived-At: --0000000000004d796f05e60cb541 Content-Type: text/plain; charset="UTF-8" For what it's worth, I use `grep-find' a lot over Tramp and have never had problems with it. (Other than when it finds a match in something like a 500 KB minified JS, but this is not Tramp-specific; Emacs in general sucks with very long lines in text files.) It works over compilation infrastructure apparently. Compilation itself also works fine for me. Paul On Wed, 10 Aug 2022 at 15:26, Paul Pogonyshev wrote: > Actually no, it doesn't help in all cases. It got better, but sometimes > still dies with the same error: > > Debugger entered--Lisp error: (wrong-type-argument processp nil) > process-mark(nil) > (move-marker (process-mark proc) (point) (current-buffer)) > (let ((proc (get-buffer-process (current-buffer)))) (message "@ %S %S" > (current-buffer) proc) (move-marker (process-mark proc) (point) > (current-buffer)) (set-process-filter proc #'find-dired-filter) > (set-process-sentinel proc #'find-dired-sentinel)) > ... > > For debugging I also added this line: > > (shell-command (concat command "&") (current-buffer)) > (let ((proc (get-buffer-process (current-buffer)))) > + (message "@ %S %S" (current-buffer) proc) > ;; Initialize the process marker; it is used by the filter. > (move-marker (process-mark proc) (point) (current-buffer)) ;; <-- > dies here > > Here is the resut in buffer *Messages*: > > @ # nil > > So, the process can be nil immediately after `shell-command' returns too. > > Paul > > > On Tue, 2 Aug 2022 at 13:28, Lars Ingebrigtsen wrote: > >> Paul Pogonyshev writes: >> >> > Seems so. I guess with the way Elisp works it is even correct, because >> > (as I understand) Elisp has no way to notice that process has died if >> > there are no IO calls between `shell-process' and `set-process-*'. >> >> Yes, but I'm not quite sure that's actually the case in all >> circumstances (especially when Tramp is involved)... >> >> > But it does feel dirty. (Also that `(sit-for 1)' a few lines above >> > feels dirty.) >> >> Yeah, much of the code in find-dired.el looks pretty fragile. >> >> But I guess this works now, so I'm closing this bug report. >> >> --0000000000004d796f05e60cb541 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For what it's worth, I use `grep-find' a lot over = Tramp and have never had problems with it. (Other than when it finds a matc= h in something like a 500 KB minified JS, but this is not Tramp-specific; E= macs in general sucks with very long lines in text files.) It works over co= mpilation infrastructure apparently. Compilation itself also works fine for= me.

Paul

On Wed, 10 Aug 2022 at 15:26, Paul Pogony= shev <pogonyshev@gmail.com&g= t; wrote:
Actually no, it doesn't help in all cases. It got better, bu= t sometimes still dies with the same error:

Debugger ent= ered--Lisp error: (wrong-type-argument processp nil)
=C2=A0 process-mark= (nil)
=C2=A0 (move-marker (process-mark proc) (point) (current-buffer))<= br>=C2=A0 (let ((proc (get-buffer-process (current-buffer)))) (message &quo= t;@ %S %S" (current-buffer) proc) (move-marker (process-mark proc) (po= int) (current-buffer)) (set-process-filter proc #'find-dired-filter) (s= et-process-sentinel proc #'find-dired-sentinel))
=C2=A0 .= ..

For debugging I also added this line:

=C2=A0 =C2=A0 =C2=A0(shell-command (concat command "&a= mp;") (current-buffer))
=C2=A0 =C2=A0 =C2=A0(let ((proc (get-buffer= -process (current-buffer))))
=C2=A0+=C2=A0 =C2=A0 =C2=A0(message "@= %S %S" (current-buffer) proc)
=C2=A0 =C2=A0 =C2=A0 =C2= =A0;; Initialize the process marker; it is used by the filter.
=C2=A0 =C2=A0 =C2=A0 =C2=A0(move-marker (process-mark proc) (point) (curr= ent-buffer))=C2=A0 ;; <-- dies here

Here is= the resut in buffer *Messages*:

@ #<buffer *Fi= nd*> nil

So, the process can be nil immedia= tely after `shell-command' returns too.

Paul


On Tue, 2 Aug 2022 at 13:28, Lars Ingebrigtsen <larsi@gnus.org> wrote= :
Paul Pogonyshe= v <pogonyshev@= gmail.com> writes:

> Seems so. I guess with the way Elisp works it is even correct, because=
> (as I understand) Elisp has no way to notice that process has died if<= br> > there are no IO calls between `shell-process' and `set-process-*&#= 39;.

Yes, but I'm not quite sure that's actually the case in all
circumstances (especially when Tramp is involved)...

> But it does feel dirty. (Also that `(sit-for 1)' a few lines above=
> feels dirty.)

Yeah, much of the code in find-dired.el looks pretty fragile.

But I guess this works now, so I'm closing this bug report.

--0000000000004d796f05e60cb541--