From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Manheimer Newsgroups: gmane.emacs.bugs Subject: bug#22452: 24.4; Tramp remote shell fails on remote+sudo+homedir destination Date: Sun, 24 Jan 2016 14:11:38 -0500 Message-ID: References: <871t96c1il.fsf@gmx.de> <87wpqyak4k.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c29944ee7366052a1939ff X-Trace: ger.gmane.org 1453662800 8151 80.91.229.3 (24 Jan 2016 19:13:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 19:13:20 +0000 (UTC) Cc: 22452@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 24 20:13:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aNQ63-0001xV-77 for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Jan 2016 20:13:11 +0100 Original-Received: from localhost ([::1]:33122 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNQ62-0006KW-5X for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Jan 2016 14:13:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNQ5y-0006KR-2A for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2016 14:13:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNQ5t-0000QA-Vo for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2016 14:13:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNQ5t-0000Q6-Rf for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2016 14:13:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aNQ5t-00052P-Kn for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2016 14:13:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ken Manheimer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 Jan 2016 19:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22452 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22452-submit@debbugs.gnu.org id=B22452.145366272419301 (code B ref 22452); Sun, 24 Jan 2016 19:13:01 +0000 Original-Received: (at 22452) by debbugs.gnu.org; 24 Jan 2016 19:12:04 +0000 Original-Received: from localhost ([127.0.0.1]:35138 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNQ4y-00051F-HG for submit@debbugs.gnu.org; Sun, 24 Jan 2016 14:12:04 -0500 Original-Received: from mail-ob0-f175.google.com ([209.85.214.175]:36306) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNQ4x-00050l-Jx for 22452@debbugs.gnu.org; Sun, 24 Jan 2016 14:12:03 -0500 Original-Received: by mail-ob0-f175.google.com with SMTP id ba1so101888484obb.3 for <22452@debbugs.gnu.org>; Sun, 24 Jan 2016 11:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oJRDL7moJnRDWX53W2bU9RdVfit7n2Ef3LPQW+WsUBs=; b=DHRDPfHDFURawF9rgvHl656f/46cPIlRLUUVvyCjLHQ1uNQcsa2pzAQuYib+e8SAut pPQrs6Xavu+/hJ83qqravGMDCBD2Ik2sWwK8ugyiDbWEPSHcvVDqstt1UF9LbDduahGb 4Oqhc+X1BdsH5bn/NXgG52vyOn+uep81fCla4S1m98dCGfdXM8l30ePRw1pPAUGbP2do vs+In5GHlnLLmw33Phy3htb5UwRw22FGXnGV8G5mjxneLwSyi0HW+RimwMu2+uHQqAdL AryNQzDAiSh+ZJZ9KpGjYnpAWr8SAEFqfgKKIkuNGzB3WKh3bOfUsytrfvfKiNvkGM9V QizQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oJRDL7moJnRDWX53W2bU9RdVfit7n2Ef3LPQW+WsUBs=; b=EGyeHayFq90raNEowy6/dREuZ4I3mswSrpzI8v45AynahBsextiI71fViypg230xiD LiUcjJgskrHFdmqFxCpGETbep4pjZiO1ZPWOux46UDO8rgh8PzOaoApYiN0avT1e/pKH 2NlmKJ6uEjKKFVLsnzuOK5JKk/nBlKHl+Is6ykac9hZj9EQLipIaQT7nEEB45oJDnfWn jJ4vLxXqe0/jO/D8teb7Lx1R1dFNeDdb2sCky/btXEciNsZwiClpmTUbWLGWbYwftoku cfNwgGS7Nx1BmmjnRmmhwklnyUFtAu/UbVTHnBeMDkMcG1W0qqYUqyBJch/8g8xbAjaF jtEw== X-Gm-Message-State: AG10YOTnxre7mbXIyhUTQ0etaVIC9EaKvkqV34LBOmTAMWOqAULL3N7kxjeU3rML+NtHUHN5kkcQ2mDZHwxuyA== X-Received: by 10.182.24.37 with SMTP id r5mr10328060obf.77.1453662718028; Sun, 24 Jan 2016 11:11:58 -0800 (PST) Original-Received: by 10.202.196.143 with HTTP; Sun, 24 Jan 2016 11:11:38 -0800 (PST) In-Reply-To: <87wpqyak4k.fsf@gmx.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:111933 Archived-At: --001a11c29944ee7366052a1939ff Content-Type: text/plain; charset=UTF-8 On Sun, Jan 24, 2016 at 1:48 PM, Michael Albinus wrote: > Ken Manheimer writes: > > [...] But the "Selecting deleted buffer" error is hidden very well, likely by > an `ignore-errors' wrapper. And debugging changes the behaviour. > Ignore-errors wrappers are often not sufficiently thought through. An idea I've often had is that code which legitimately is not interrupted by errors is therefore, inherently, acting as a kind of "executive", responsible for running code for something else. (Some common examples are read-eval-print loops, more sophisticated ones are RPC services, interpreters, dev tools like debuggers and profilers, etc.) While the executive needs to continue, the part that's often insufficiently tended is a responsibility to convey the error to the parties for which it's running the code, so they can react accordingly. That's a pretty darn abstract assessment, though, very vague about what "convey the error" means. In this case, it may just mean indicating more about the code context where the error occurred, so that someone debugging the problem has more leads to track it down. A language that I like for this kind of thing, Python, provides library calls which expose the traceback context, so that info can be explicitly included. Not sure if emacs lisp has similar facilities. Ken > Interesting that changing tramp-verbose avoids the problem. Sounds > > like that, in itself, might be a lead on the problem? > > My guess is it is related to Tramp's debug buffer (it won't be touched > when tramp-verbose is less than 3). I'll continue to dig. > > > Ken > > Best regards, Michael. > --001a11c29944ee7366052a1939ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jan 24, 2016 at 1:48 PM, Michael Albinus <mi= chael.albinus@gmx.de> wrote:
Ken Manheimer &l= t;ken.manheimer@gmail.com>= ; writes:

[...]=C2=A0
But the "Selecting deleted buffer"= error is hidden very well, likely by
an `ignore-errors' wrapper. And debugging changes the behaviour.

Ignore-errors wrappers are often not sufficie= ntly thought through. An idea I've often had is that code which legitim= ately is not interrupted by errors is therefore, inherently, acting as a ki= nd of "executive", responsible for running code for something els= e. (Some common examples are read-eval-print loops, more sophisticated ones= are RPC services, interpreters, dev tools like debuggers and profilers, et= c.) While the executive needs to continue, the part that's often insuff= iciently tended is a responsibility to convey the error to the parties for = which it's running the code, so they can react accordingly.
<= br>
That's a pretty darn abstract assessment, though, very va= gue about what "convey the error" means.=C2=A0 In this case, it m= ay just mean indicating more about the code context where the error occurre= d, so that someone debugging the problem has more leads to track it down. A= language that I like for this kind of thing, Python, provides library call= s which expose the traceback context, so that info can be explicitly includ= ed. Not sure if emacs lisp has similar facilities.

Ken

> Interesting= that changing tramp-verbose avoids the problem. Sounds
> like that, in itself, might be a lead on the problem?

My guess is it is related to Tramp's debug buffer (it won't = be touched
when tramp-verbose is less than 3). I'll continue to dig.

> Ken

Best regards, Michael.

--001a11c29944ee7366052a1939ff--