From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] checking eww download directory Date: Sat, 28 Jan 2017 09:53:50 +0200 Message-ID: <83r33nzkkx.fsf@gnu.org> References: <87wpdgmi84.fsf@udel.edu> <66463069-a49f-1dc1-2399-a8e5c60af5ca@gmail.com> <87mvecntq1.fsf@udel.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1485590058 32308 195.159.176.226 (28 Jan 2017 07:54:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 28 Jan 2017 07:54:18 +0000 (UTC) Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org To: Mark Oteiza Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 28 08:54:09 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cXNpl-0007QM-4w for ged-emacs-devel@m.gmane.org; Sat, 28 Jan 2017 08:54:05 +0100 Original-Received: from localhost ([::1]:50320 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cXNpq-0001KI-Hs for ged-emacs-devel@m.gmane.org; Sat, 28 Jan 2017 02:54:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cXNpk-0001KC-5K for emacs-devel@gnu.org; Sat, 28 Jan 2017 02:54:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cXNpg-0000jv-F6 for emacs-devel@gnu.org; Sat, 28 Jan 2017 02:54:04 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cXNpg-0000jq-Bt; Sat, 28 Jan 2017 02:54:00 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1446 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cXNpe-0003VQ-Nk; Sat, 28 Jan 2017 02:53:59 -0500 In-reply-to: <87mvecntq1.fsf@udel.edu> (message from Mark Oteiza on Fri, 27 Jan 2017 15:17:10 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211673 Archived-At: > From: Mark Oteiza > Date: Fri, 27 Jan 2017 15:17:10 -0500 > Cc: emacs-devel@gnu.org > > > How hard would it be to integrate with the xdg-user-dirs standard > > instead? On many GNU/Linux systems, running "xdg-user-dir DOWNLOAD" is > > enough (http://stackoverflow.com/questions/13161226/). This would > > make eww consistent with Firefox, too (they take the slightly more > > painful route of parsing ~/.config/user-dirs.dirs: > > https://dxr.mozilla.org/mozilla-release/source/xpcom/io/SpecialSystemDirectory.cpp#256) > > An xdg.el would be nice to have for elisp that interfaces > with XDG-following things. mpc.el and image-dired.el are two files that > come to mind: mpd follows [0], image-dired > supports [1]. Actually, it looks like those are the only two files with > XDG bits, and I put them there. How about that. > > Anyways, these aren't difficult to implement. If it would be a welcome > addition I'd have a go at writing it. > > [0] https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html > [1] https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html This has come up before. I think this would be welcome, but one issue that didn't get resolved is how much of that should be automatic (i.e. should Emacs automatically search certain directories for certain kinds of files), and if so, how to split the imaginary xdg.el into two parts, with the automatic part living in some preloaded file (probably files.el). There's also the issue of whether users and/or Lisp programs should be able to disable this search (e.g., by binding some variable). Also, IMO supporting this on Windows will need a new primitive written in C, but that's an aside, and can be omitted in the initial implementation. Thanks.