From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Newsgroups: gmane.emacs.bugs Subject: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 Date: Thu, 21 Aug 2014 17:54:11 +0100 Message-ID: References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1408640127 22891 80.91.229.3 (21 Aug 2014 16:55:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Aug 2014 16:55:27 +0000 (UTC) Cc: 18310@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 21 18:55:20 2014 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 1XKVdu-0000O3-3m for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Aug 2014 18:55:18 +0200 Original-Received: from localhost ([::1]:33381 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKVdt-0002tI-N1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Aug 2014 12:55:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKVdl-0002pp-Cb for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 12:55:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKVdf-00023s-FX for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 12:55:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKVdf-00023P-CO for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 12:55:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XKVde-0000U1-W1 for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 12:55:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Aug 2014 16:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18310 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18310-submit@debbugs.gnu.org id=B18310.14086400641781 (code B ref 18310); Thu, 21 Aug 2014 16:55:02 +0000 Original-Received: (at 18310) by debbugs.gnu.org; 21 Aug 2014 16:54:24 +0000 Original-Received: from localhost ([127.0.0.1]:49104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKVd1-0000Sb-Nv for submit@debbugs.gnu.org; Thu, 21 Aug 2014 12:54:24 -0400 Original-Received: from mail-wi0-f175.google.com ([209.85.212.175]:59663) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKVcy-0000SK-OV for 18310@debbugs.gnu.org; Thu, 21 Aug 2014 12:54:21 -0400 Original-Received: by mail-wi0-f175.google.com with SMTP id ho1so9005588wib.8 for <18310@debbugs.gnu.org>; Thu, 21 Aug 2014 09:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=MuUf1PL9lUv6OEpu8pDiJMgTXQIx/KMQ9ZfccZ+3Nu0=; b=vWgKjgMuCZdF2o4UQ0dC7jLK49b+Gc3W0HS6BX0Y7xPQrloU+wxkxwv21L6hwGWfup DSyxB5mrS2ea7MTK5BFp697FpQ11nLh4VqQra4nRVxFVa6z6JaRyKPC+pFBflsHlAUKE NZ1he0/bguKuIqMTfATlY3YjAusX9cNjuAdmdRu3mgogZS9E6lXh9iETZEAvtoMSjdRI E3M/kGx6IreOuJiSO15G769lgKtW0KodRmA7tZ0XdtJcbJbZlDxm6LvVPT+PEeVIeO2o NDRTuetA0AGRcaAIaenjiAvEzNZTsGmR0UaSmldaF6f5+hTgDHhQvpBn5jsbyZD+5FkW Rupw== X-Received: by 10.180.188.205 with SMTP id gc13mr11627029wic.66.1408640054796; Thu, 21 Aug 2014 09:54:14 -0700 (PDT) Original-Received: from GONDOMAR.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by mx.google.com with ESMTPSA id h3sm68027486wjn.10.2014.08.21.09.54.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Aug 2014 09:54:13 -0700 (PDT) In-Reply-To: <83lhqhbyvg.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 21 Aug 2014 19:17:55 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (windows-nt) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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:92577 Archived-At: Eli Zaretskii writes: >> From: joaotavora@gmail.com (Jo=E3o T=E1vora) >> Cc: 18310@debbugs.gnu.org >> Date: Thu, 21 Aug 2014 16:43:48 +0100 >>=20 >> Something other than `default-directory' seems to be influencing it. I >> did some tests: > > Like I said: Emacs uses the current drive to complete the missing > drive letter. That is what you see. OK. How is the "current drive" calculated when `default-directory' is nil? >> Finally >>=20 >> (let ((default-directory "\\\\")) >> (expand-file-name "../" "/something/bla")) >>=20 >> Crashed the Emacs process on my machine. > > It's not a crash, it's a deliberate abort. "\\\\" (i.e., 2 > backslashes in a row without anything after that) is an invalid file > name on Windows. Would signalling an error be very wrong, does the process really need to be aborted? I mean unprotected code may easily lead to that invalid case. > How does that obscure hint help? It doesn't tell anything that mere > mortals could understand.=20 It mirrors the function's obscurity, so mere mortals can at least be warned of death by deliberate abort. Anyway it was meant for you to complete with enlightenment about the function's interaction with things other than `default-directory', something you didn't do.=20 And needn't do, at least for me, since at least now I know to stay away from `expand-file-name's quirks. > Once again, you are talking about semi-invalid use cases. IMO, > complicating the doc string (which is not at all simple as it is) on > behalf of those use cases is not TRT. BTW "Semi-invalid" uses, or even downright absurd use cases, are what development/testing/experimentation is all about. IMO aborting the process and not at least warning elisp users about invalid cases in the documentation is not good practice in my opinion. Jo=E3o