From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: emacsclient: support `/' directory separator on w32 Date: Wed, 29 Nov 2006 23:30:52 +0100 Message-ID: <456E0A1C.3080402@student.lu.se> 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> <456C4A8C.2080208@student.lu.se> <85zmablgvk.fsf@lola.goethe.zz> <456C5916.1020305@student.lu.se> <456CC240.2050401@student.lu.se> <456D45A1.4050907@student.lu.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1164839514 31433 80.91.229.2 (29 Nov 2006 22:31:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 29 Nov 2006 22:31:54 +0000 (UTC) Cc: lekktu@gmail.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 29 23:31:44 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 1GpXxk-00010B-1f for ged-emacs-devel@m.gmane.org; Wed, 29 Nov 2006 23:31:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GpXxj-0005sC-Hj for ged-emacs-devel@m.gmane.org; Wed, 29 Nov 2006 17:31:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GpXxH-0005VW-B6 for emacs-devel@gnu.org; Wed, 29 Nov 2006 17:31:04 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GpXxC-0005MM-AM for emacs-devel@gnu.org; Wed, 29 Nov 2006 17:31:00 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GpXxB-0005Lq-Po for emacs-devel@gnu.org; Wed, 29 Nov 2006 17:30:57 -0500 Original-Received: from [80.76.149.213] (helo=ch-smtp02.sth.basefarm.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GpXx9-00005R-SE; Wed, 29 Nov 2006 17:30:56 -0500 Original-Received: from c83-254-145-24.bredband.comhem.se ([83.254.145.24]:62597 helo=[192.168.123.121]) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GpXx7-0008Du-7i; Wed, 29 Nov 2006 23:30:53 +0100 User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Original-To: Eli Zaretskii In-Reply-To: X-Scan-Result: No virus found in message 1GpXx7-0008Du-7i. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1GpXx7-0008Du-7i 7d7786ec8d541d739cfa6515f0a9be15 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:63083 Archived-At: Eli Zaretskii wrote: > Distributing variants just adds to confusion and wastes precious > resources. Therefore I think it should be done only if you have a > very good reason, and it certainly shouldn't be a knee-jerk reaction > to any disagreement. Yes, it adds to the confusion. I am aware of that and tries to tell that as clearly as possible on my web pages. If you have time and interest you can suggest improvements to this. The things I have added in my patches are things that I think should go into emacs later. We might prefer slightly different coding but that is of very minor importance to many. I code for the functionality and try to make the code clear and structured. I use this patches myself and I even doubt I would be using Emacs without some of them. Of course we have different views of things sometimes, but that does not change my mind unless you can convince me. It is not a big problem for me if we disagree and I try not to act because of that. However I try to make my view clear and offer alternatives based on my view - with all efforts I think are reasonable to minimize the patches. > Solving this in both Emacs and emacsclient is a non-trivial job that > should not be undertaken now. I hope you agree that solving it _only_ > in emacsclient is a bad idea. I think we should solve it for emacsclient now because it is more integrated with the w32 UI, but let it be for Emacs until after the release. I see no problems with that. However I believe also that we should try to solve the problems with bad filenames in both Emacs and Emacsclient now. This should not be to problematic I guess. It is only about testing for certain characters in the names. The main difficulty is perhaps what to do when a file name contains bad characters.