[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] user/group completion for dired
From: |
Eli Zaretskii |
Subject: |
Re: [PATCH] user/group completion for dired |
Date: |
Wed, 21 Sep 2011 18:04:06 +0300 |
> Date: Wed, 21 Sep 2011 17:59:14 +0400
> From: Dmitry Antipov <address@hidden>
> CC: address@hidden
>
> On 09/21/2011 12:49 PM, Eli Zaretskii wrote:
>
> > IMO, the last two sentences are too categorical and too OS-specific.
> > E.g., in the MS-DOS build of Emacs, getpwent and getgrent are
> > available and usable, although MS-DOS is certainly not a Unix system.
> > It should also be possible to write an emulation of these functions
> > for MS-Windows. And even on Unix systems, I'm not sure the
> > information is always on /etc/passwd. And the same goes for groups
> > and /etc/groups.
> >
> > So please make the doc strings more vague; it should be enough to say
> > that if this functionality is not supported, the value is nil, or
> > something like that.
>
> OK. I realize that receiving the list of system users/groups may require
> NSS/LDAP/whatever queries. On GNU/Linux system, it should be possible
> to interface libuser; other systems might have the similar methods,
> but I'm not sure it's worth playing with them just for input completion
> task.
??? My comment was only about the doc string which referenced
/etc/passwd. AFAIK, no matter where the information resides, the
functions you used will still be able to get at it. If I'm right,
there's no need to change the code regarding that.
> > We should at least return the single user that is the current user,
> > instead of nil. Emacs always knows who is the current user, on all
> > supported systems, so there's no need to be so restrictive when
> > getpwent is unavailable.
>
> OK, I guess it should be Vuser_real_login_name.
Yes, I think so.
> > What happens if the user name includes non-ASCII characters? If that
> > can happen, we should decode the pw_name string, not just call
> > build_string on the unibyte string we get. Same issue with the group
> > name.
>
> Comment around build_string() says it should guess about string data
> and produce multibyte string if necessary.
Why let it guess? You can do it with 100% certainty in this case,
because the encoding of strings provided by the OS is known -- it's
held in Vlocale_coding_system. See system_process_attributes for an
example of how to do this.
> On my system (Fedora 15) it was able to decode and represent
> tõendidütles (no ideas what language it is and what does it mean :-)
> as multibyte string.
That's because GNU/Linux systems normally use an encoding that maps
1:1 to the internal Emacs representation of characters. I'm guessing
that if you look in a debugger on the string you get from getpwent,
you will see it's UTF-8 encoded. If so, it's sheer luck that it
worked for you.