From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Project support and completions Date: Sun, 25 Jan 2015 20:18:59 +0200 Message-ID: <54C53393.3030906@yandex.ru> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> <83h9vgsehi.fsf@gnu.org> <54C3E7B6.2020006@yandex.ru> <837fwbstls.fsf@gnu.org> <54C429D8.6010302@yandex.ru> <83vbjurggg.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1422209965 26826 80.91.229.3 (25 Jan 2015 18:19:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Jan 2015 18:19:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 25 19:19:20 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YFRmD-0004CH-C3 for ged-emacs-devel@m.gmane.org; Sun, 25 Jan 2015 19:19:13 +0100 Original-Received: from localhost ([::1]:38533 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFRmC-0003K5-ND for ged-emacs-devel@m.gmane.org; Sun, 25 Jan 2015 13:19:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFRm9-0003Jt-7m for emacs-devel@gnu.org; Sun, 25 Jan 2015 13:19:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFRm6-0007aG-1K for emacs-devel@gnu.org; Sun, 25 Jan 2015 13:19:09 -0500 Original-Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:63081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFRm5-0007aA-R6; Sun, 25 Jan 2015 13:19:05 -0500 Original-Received: by mail-wi0-f177.google.com with SMTP id r20so5896107wiv.4; Sun, 25 Jan 2015 10:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XjK3FF0PjQ5GUS8G9IcWwTiRIFI9oF/PqN973PK0o+I=; b=AB9Q9SqMf18PfG0jA0hhWcf1Cf4AAVi40vdeu5GOWAIkGXDSxu0VfY65aZgirUJVgb AYlCvnICPK08xZ4LM5+la0uc1ruQc2FlgQGS+S91hpLO3UtpwnYY3DjdMjESiHOFYRcu pyepeC1EctPWKNhnF8ZShf6skHqrbqbdtWzsperXm3g/grTW0FCEEOFdGxlx0EZBN0cm hvcXEF9uLd71LNnAkugRVZ6emtE978whytyES+4VKYuzDU6nK7/Zr5fD9IY0RuJE3ncN ioqgjrlUgWm/lb/T9dhCH2ysTXEJ76nXS7aodH+A7apCNuzTa3ka3qZZnFsG/g0KUy20 N6Cg== X-Received: by 10.180.93.103 with SMTP id ct7mr18348667wib.77.1422209945279; Sun, 25 Jan 2015 10:19:05 -0800 (PST) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id x10sm10688863wif.15.2015.01.25.10.19.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jan 2015 10:19:04 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 In-Reply-To: <83vbjurggg.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::231 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:181755 Archived-At: On 01/25/2015 06:08 PM, Eli Zaretskii wrote: > However, for the purposes of this discussion, all that is needed is > for xref to expose some interface that would allow a project API to > tell xref which databases to use. It already does. Please keep xref out of this discussion, I've split it out intentionally. > The important aspect of this is that at least in some situations the > set of databases to use for symbol completion should be dictated by > some code outside xref that uses an interface provided by xref, and > not necessarily inferred automatically. Like I mentioned, xref itself doesn't keep any databases. > Suppose there's some bug when Emacs calls a GnuTLS function. Does > working on both of them trying to solve the bug makes them "related"? Sure. Emacs uses GnuTLS, so they're related. > Do you agree that being able to browse and complete on symbols from > both of them might be very useful in this use case? Of course. Being able to complete on symbols from _all_ libraries that the current project uses is useful. > Such automatic inference is not easy. Library dependencies come in > several forms: linking in a Makefile, dynamic loading in the sources, > dependencies in pkg-config style *.pc files, etc. Also, some > libraries depend on other libraries. Discovering all those > dependencies sounds like a non-trivial project to me. Different packages can provide support for different kind of projects. There's no reasons for users of languages and build systems where this is easier to suffer the same hurdles as you. > More importantly, most of the time when I work on the application, I > don't care about symbols in the libraries used by an application. So > doing what you suggest would fill my "namespace" with many symbols I > don't care about and don't want to see as completion candidates. If you had access to context-sensitive completion, you might change your mind. Or maybe not. But it would improve the namespace pollution considerably. > As > an extreme example, consider libc, the Standard C library, which any C > program uses, or the Standard C++ library. Is it really a good idea > for xref to offer all those when the user types 'M-.'? Yeah, why not? Want to see the definition of printf? There you go! > Once again, I don't think this can be resolved automatically in a > satisfactory manner, at least not in all important use cases. So a > provision for manual instruction by the user is still required, IMO. It will be solved by different users using different code completion solutions.