From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Francisco_Miguel_Cola=c3=a7o?= Newsgroups: gmane.emacs.devel Subject: Re: Inclusion of XDG Base Directory library Date: Sat, 12 May 2018 10:01:40 +0100 Message-ID: <55940901-3401-f5ee-b065-c5d88d7bcd3a@gmail.com> References: <779935bf-79ea-5783-4c9c-4b7e2857bc50@gmail.com> <83o9hmnzsi.fsf@gnu.org> <8336yxnz6k.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1526115592 18711 195.159.176.226 (12 May 2018 08:59:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 12 May 2018 08:59:52 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 12 10:59:47 2018 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 1fHQNX-0004ln-5w for ged-emacs-devel@m.gmane.org; Sat, 12 May 2018 10:59:47 +0200 Original-Received: from localhost ([::1]:58643 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fHQPe-0006mo-4U for ged-emacs-devel@m.gmane.org; Sat, 12 May 2018 05:01:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fHQPT-0006mO-1w for emacs-devel@gnu.org; Sat, 12 May 2018 05:01:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fHQPQ-00064e-0v for emacs-devel@gnu.org; Sat, 12 May 2018 05:01:47 -0400 Original-Received: from mail-wr0-x234.google.com ([2a00:1450:400c:c0c::234]:34682) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fHQPP-00064Y-P9; Sat, 12 May 2018 05:01:43 -0400 Original-Received: by mail-wr0-x234.google.com with SMTP id p18-v6so7463663wrm.1; Sat, 12 May 2018 02:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=yk90NyGsern37IOHdpCJc/sobwc3qQmQABuLI34NFq4=; b=avo+YpldKBzkCP14etjqxNYEmZ33OzSeSrQ2f/q/6Hp6XLzhXC3R+Y0v8YUY23R20x 9usVbFd56Wb4urbsJgGYHKtaC3eoY8SbO7WX0P2ADtAW/4uupS/jWrGnEx4rGjB00xjd A1hXf5SkuNQwwCyMX2ayZV9T34kPf9oIDgZXFA9Q3XTMB8+jzKeKXYi+hUbbkhHHvafP Ox7N9rrAICA+UX+qAp00ReyaHwhbGx10ZC+a/NYqrsLmJ3IyvFTwAUwnyRl6pM47V5BS ItoPhQ/OETzHNwsl8fQnrbOks9I3i4mVsvBfPWKQ3XJasjyKOYeZKY3P5Mfu/Aua2cUA J3SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=yk90NyGsern37IOHdpCJc/sobwc3qQmQABuLI34NFq4=; b=Zr+Omq+WJob9qjyOFf4MznaSXVeCeMg2nZUGVU8COfCqMwf3tXQZUrxoshNlpbCo7r RxVNY3RokO+CxU58BTUF8s0k3SBtkmVRQjRZ0jG94g9cnFTuPOw0zohR+cbml9Q2FCnM pQFhzu7PXl6Ih2N8ZBmJddxL+ngG9eGA2AYtowBD27NIUVXbL0GF1LNqWWTnDFUHm9J0 EGYmKCwCAeAfdt1OHo52/6HJl2rI0jbKVfJJGEf4Mbcj1gJf+Ai+qONGCzdRZyQhBJWX MnfBEFv+x+BYm/UNmb3qAzXwhqlVTknKMs/eo4/ajIx/h0ZUHopoQo2rrKlxZFkjpGda tVsQ== X-Gm-Message-State: ALKqPweoExGkGIamF4FRJZKAEbf3i9/ikyhzfYOAxNT7T1k9ciEXVq4E fpyG32rRc4Nqk7uwQwSNarTYhtw+ X-Google-Smtp-Source: AB8JxZrPSxeb+g4rn7W0NjnWQvqqMwjESYIgMgvIWfun3hbsvkYwLuhULihERZ5MYpTqa45W2p7Olw== X-Received: by 2002:adf:ae59:: with SMTP id u25-v6mr1521221wrd.157.1526115702004; Sat, 12 May 2018 02:01:42 -0700 (PDT) Original-Received: from localhost.localdomain (bl17-210-45.dsl.telepac.pt. [188.82.210.45]) by smtp.gmail.com with ESMTPSA id v18-v6sm5051799wrf.76.2018.05.12.02.01.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 May 2018 02:01:41 -0700 (PDT) In-Reply-To: <8336yxnz6k.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::234 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:225258 Archived-At: =C2=A0 Eli, =C2=A0 Thanks for your reply.=C2=A0 I did my best to address your concern= s and have commited code at Github. =C2=A0=C2=A0=C2=A0 Francisco =C3=80s 07:52 de 12-05-2018, Eli Zaretskii escreveu > I understand. Therefore, I raised an issue with the package, listing > there the problems I see in the code, and I hope the person(s) who > contributed this code will take notice and fix the problems I > mentioned there. Years ago, I have slightly adapted code I have seen on the Internet to write the two functions (windows-read-registry-value and windows-shell-folders).=C2=A0 I will have to locate where the code was sh= own (maybe on Stackoverflow, I sincerely do not remember where). Actually, I do not think those two should be in this library, since there is a broader utility and scope to be considered.=C2=A0 Maybe windows-read-registry-value should be a C primitive or a loadable module --- now that we can have them in Emacs. What do you think of factoring these two functions away from this library, creating an also dynamically configurable os.el library not unlike this one?That's exactly my point: Emacs on Windows still tries to support > versions of Windows that predate Vista. The code should not fail for > them, but should provide fallbacks for those directories that were > introduced in more recent versions. Done.=C2=A0 if not found, the value of LOCALAPPDATA will not be used, but= that of APPDATA, which, as far as I know, is even present in Windows XP. > In addition, I think it's gross to use 'reg' and 'echo' as external > commands to produce the Registry values; in particular, this will fail > if the values include non-ASCII characters not from the system locale. > We should have primitives for that. Volunteers are welcome to add > such capabilities to Emacs. Can any Windows user tackle the subject?=C2=A0 Anyone can contribute, and= the more, the merrier! :-) I really think, as I have said above, that these particular functions should be taken from this library and to a library of their own. =C2=A0 >> =C2=A0 >> IMO, the advantage of parsing files in Emacs is that we can be more >> sure we deal properly with non-ASCII file names. When you invoke a >> command to do the job for you, you rely on guesswork for decoding what= >> the program outputs, which could be tricky, especially when you do >> that remotely from another system, with a different locale. By >> contrast, I expect the file to be encoded in UTF-8 always, is that >> right? Actually, Portuguese does have diacritics, like "Transfer=C3=AAncias" and= "=C3=81rea de Trabalho" and "V=C3=ADdeos" and no problems have arisen to = me so far.=C2=A0 Maybe our users Arabic, Hebrew, Cyrillic. Indic and CJK script= s can see if it works on their machine.=C2=A0 XDG does mandate UTF-8, so I reckon that we will have no problems by using the file. On another record, if the blessed way is to use the command 'xdg-user-dir', how can one be sure they will not alter the file format to suit some future expansion desiderata?=C2=A0 The regexp way is quite simple, but we are on the very dangerous assumption that the line format is set in stone and will never change.=C2=A0 Nevertheless, if we get XDG people to recommend us the direct parsing of ~/.config/user-dirs.dirs, then we should definitely implement it that way.