From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: emacsclient: support `/' directory separator on w32 Date: Tue, 28 Nov 2006 15:49:57 +0100 Message-ID: <85irgzmxre.fsf@lola.goethe.zz> References: <20061124054526.72239.qmail@web62511.mail.re1.yahoo.com> <85fyc3oiio.fsf@lola.goethe.zz> <854psjoh67.fsf@lola.goethe.zz> <456C43D4.7060809@student.lu.se> <456C45C3.2050107@student.lu.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1164725742 16393 80.91.229.2 (28 Nov 2006 14:55:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Nov 2006 14:55:42 +0000 (UTC) Cc: Lennart Borgman , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 28 15:55:39 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Gp4Mb-00074t-QF for ged-emacs-devel@m.gmane.org; Tue, 28 Nov 2006 15:55:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gp4Mb-0004xn-8x for ged-emacs-devel@m.gmane.org; Tue, 28 Nov 2006 09:55:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gp4Hg-0001GZ-6r for emacs-devel@gnu.org; Tue, 28 Nov 2006 09:50:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gp4Hb-0001DR-2A for emacs-devel@gnu.org; Tue, 28 Nov 2006 09:50:06 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gp4Ha-0001DL-V5 for emacs-devel@gnu.org; Tue, 28 Nov 2006 09:50:02 -0500 Original-Received: from [212.7.152.118] (helo=mxout04.versatel.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Gp4Ha-00061P-6n for emacs-devel@gnu.org; Tue, 28 Nov 2006 09:50:02 -0500 Original-Received: from mx05.versatel.de (mx01.versatel.de [212.7.146.1]) by mxout04.versatel.de (8.13.1/8.13.1) with ESMTP id kASEnxnv011576; Tue, 28 Nov 2006 15:49:59 +0100 Original-Received: from lola.goethe.zz (i53879488.versanet.de [83.135.148.136]) by mx05.versatel.de (8.12.11.20060308/8.12.11) with ESMTP id kASEnx9K005921; Tue, 28 Nov 2006 15:49:59 +0100 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id B40571C29846; Tue, 28 Nov 2006 15:49:57 +0100 (CET) Original-To: "Juanma Barranquero" In-Reply-To: (Juanma Barranquero's message of "Tue\, 28 Nov 2006 15\:31\:24 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:62951 Archived-At: "Juanma Barranquero" writes: > On 11/28/06, Lennart Borgman wrote: > >> Well, it actually have to either require full path names or translate >> relative file names to full file names before sending the file names to >> emacs, or? > > I don't understand the question. It currently accepts absolute > pathnames, or pathnames relative to the current directory. Seems > sensible to me. And portable. I would not call that portable. "portable" means "work everywhere", not "work everywhere under the assumption that everywhere is supposed to be like Unix". > Most operating systems have the concept of a default current > directory. I don't think most of them have the concept of a default > current directory for each drive/device/filesystem/younameit (but I > could be wrong). Most operating systems have the concept of relative file names that can resolve to different files in different environments. So Emacsclient has to deal with this. At the moment it appears to do this by passing both the relative filename as well as what it considers relevant for absolutizing it, the current work directory. It appears that the current work directory alone is not sufficient. I see two approaches here: either Emacsclient will pass more info to Emacs, or it creates the absolute file names itself. The latter sounds more sane to me, however it requires that Emacsclient itself knows which parts on the command lines are filenames to be opened, and which are just arguments to be interpreted by commands or stuff. Maybe we really don't want to go there, but in the mean time, it sounds flaky. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum