all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Francisco Miguel Colaço" <francisco.colaco@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Inclusion of XDG Base Directory library
Date: Sat, 12 May 2018 10:01:40 +0100	[thread overview]
Message-ID: <55940901-3401-f5ee-b065-c5d88d7bcd3a@gmail.com> (raw)
In-Reply-To: <8336yxnz6k.fsf@gnu.org>

  Eli,

  Thanks for your reply.  I did my best to address your concerns and
have commited code at Github.

    Francisco


Às 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).  I will have to locate where the code was shown
(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.  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.  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?  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.
 
>>  
>> 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ências" and
"Área de Trabalho" and "Vídeos" and no problems have arisen to me so
far.  Maybe our users Arabic, Hebrew, Cyrillic. Indic and CJK scripts
can see if it works on their machine.  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?  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.  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.




  reply	other threads:[~2018-05-12  9:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-06 19:04 Inclusion of XDG Base Directory library Francisco Miguel Colaço
2018-05-07  8:26 ` Francisco Miguel Colaço
2018-05-07 16:43   ` Stefan Monnier
2018-05-11 12:26   ` Eli Zaretskii
2018-05-11 20:22     ` Francisco Miguel Colaço
2018-05-12  6:52       ` Eli Zaretskii
2018-05-12  9:01         ` Francisco Miguel Colaço [this message]
2018-05-12 15:32       ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55940901-3401-f5ee-b065-c5d88d7bcd3a@gmail.com \
    --to=francisco.colaco@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.