From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] user/group completion for dired Date: Wed, 21 Sep 2011 17:59:14 +0400 Message-ID: <4E79EDB2.2020300@yandex.ru> References: <4E7993C8.6010609@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1316613755 2102 80.91.229.12 (21 Sep 2011 14:02:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 21 Sep 2011 14:02:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 21 16:02:31 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R6NNe-0000f8-3I for ged-emacs-devel@m.gmane.org; Wed, 21 Sep 2011 16:02:30 +0200 Original-Received: from localhost ([::1]:39285 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6NNd-0005a1-9t for ged-emacs-devel@m.gmane.org; Wed, 21 Sep 2011 10:02:29 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:49004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6NNX-0005Zs-TG for emacs-devel@gnu.org; Wed, 21 Sep 2011 10:02:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6NNS-0002wt-7C for emacs-devel@gnu.org; Wed, 21 Sep 2011 10:02:23 -0400 Original-Received: from mail.dev.rtsoft.ru ([213.79.90.226]:42368) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1R6NNR-0002wh-OH for emacs-devel@gnu.org; Wed, 21 Sep 2011 10:02:18 -0400 Original-Received: (qmail 25371 invoked from network); 21 Sep 2011 14:02:19 -0000 Original-Received: from unknown (HELO ?192.168.5.146?) (192.168.1.70) by 0 with SMTP; 21 Sep 2011 14:02:19 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 213.79.90.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:144150 Archived-At: 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. > 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. > 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. On my system (Fedora 15) it was able to decode and represent t=C3=B5endid=C3=BCtles (no ideas what= language it is and what does it mean :-) as multibyte string. Dmitry