From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=) Newsgroups: gmane.emacs.devel Subject: Re: init_buffer PWD fix Date: Wed, 24 Apr 2002 15:52:06 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200204220618.g3M6Icg23696@sic.twinsun.com> <200204231745.g3NHjCW00689@shade.twinsun.com> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1019631283 11063 127.0.0.1 (24 Apr 2002 06:54:43 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Apr 2002 06:54:43 +0000 (UTC) Cc: emacs-devel@gnu.org, knagano@sodan.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 170Gfr-0002sK-00 for ; Wed, 24 Apr 2002 08:54:43 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 170GhP-0002d7-00 for ; Wed, 24 Apr 2002 08:56:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 170GfP-0003ev-00; Wed, 24 Apr 2002 02:54:15 -0400 Original-Received: from meadow.scphys.kyoto-u.ac.jp ([130.54.54.165]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 170GdP-0003XP-00 for ; Wed, 24 Apr 2002 02:52:11 -0400 Original-Received: (qmail 25630 invoked from network); 24 Apr 2002 06:51:22 -0000 Original-Received: from meadow.scphys.kyoto-u.ac.jp (HELO MILCH.meadowy.org.meadowy.org) (root@130.54.54.165) by meadow.scphys.kyoto-u.ac.jp with SMTP; 24 Apr 2002 06:51:22 -0000 Original-To: Paul Eggert In-Reply-To: <200204231745.g3NHjCW00689@shade.twinsun.com> (Paul Eggert's message of "Tue, 23 Apr 2002 10:45:12 -0700 (PDT)") Original-Lines: 41 User-Agent: T-gnus/6.15.4 (based on Oort Gnus v0.04) (revision 11) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.1 (i386-msvc-nt5.1.2600) MULE/5.0 (SAKAKI) Meadow/1.99 Alpha1 (AWOFUCHI) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3160 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3160 Paul Eggert writes: > Efficiency is not the primary concern here. More important are: ...snip... > Your benchmark indicates that Emacs needs to spend one microsecond to > get the nicer name on your host; that's a win in my book. O.K. In short, this code is not mainly for optimization, but rather in order to receive more appropriate pathname from the shell (or any other invoking program). I agree on it. So we should change the comment not to misunderstand the intention. Thanks. BTW, on Windows, the current code dose not works correctly because of stat() problem. In the current implemenation, stat() always return the same value as inode. Please see the following, which is cut from stat()@w32.c. if (wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) { buf->st_mode = _S_IFDIR; buf->st_nlink = 2; /* doesn't really matter */ fake_inode = 0; /* this doesn't either I think */ } I think we have three choices to solve it. (1) Generate a proper inode value as well as for the directory (2) At the startup, set "PWD" env. to the value of getcwd(). (3) Use always getcwd() when WINDOWSNT(or DOS_NT?) is defined. As for (1), generate fake_inode from the value of FileIndex obtained by GetFileInformationByHandle(). But on WINDOWSNT, I'd like to apply (3) change too because on W32 we don't have to (or should not) take such rather profound intentions into considerations. With regards, from himi