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: Project support and completions (Was: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions) Date: Sat, 24 Jan 2015 20:43:02 +0200 Message-ID: <54C3E7B6.2020006@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> 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 1422125010 13741 80.91.229.3 (24 Jan 2015 18:43:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Jan 2015 18:43:30 +0000 (UTC) Cc: emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 24 19:43:29 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 1YF5g9-0002T0-4m for ged-emacs-devel@m.gmane.org; Sat, 24 Jan 2015 19:43:29 +0100 Original-Received: from localhost ([::1]:35778 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YF5g8-0008EQ-4o for ged-emacs-devel@m.gmane.org; Sat, 24 Jan 2015 13:43:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YF5fv-0008EA-Hv for emacs-devel@gnu.org; Sat, 24 Jan 2015 13:43:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YF5fn-00008X-WB for emacs-devel@gnu.org; Sat, 24 Jan 2015 13:43:15 -0500 Original-Received: from mail-we0-x235.google.com ([2a00:1450:400c:c03::235]:54360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YF5fn-000082-KF; Sat, 24 Jan 2015 13:43:07 -0500 Original-Received: by mail-we0-f181.google.com with SMTP id k48so2797356wev.12; Sat, 24 Jan 2015 10:43:06 -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=IGQAZCH9Sqz8GR7FerukxSCyWmwtRWPwxY1I7hMKdxY=; b=prVIFsFHoy4R2WLSiYOHhA9aWBFZhODVi255tnTsfSVEquhfRA9qtxdHG5LHzB7wrf 7qNkv8cotfr13J3iiZSp5Y519DSmlDj+dn158k3Z6YYsK+fCWS/2FRVLFeCntQ26Nwyb PLxH7ODjnj4QlSr9I2DKEMp1xXU5CeOKfxkUCB6hc4Av/4u1FqMZlhqPaWG+ddBzk/j6 Wu9NbVcEeoc/rjGX/QCtDZavwvxvciK2QchywPp0mQGeFFLD/84HnIFKpiApKUQiC0oK PAE4cqjmUgIhcH0e/ZOwsrba+ExdUxzttzXI5ppmdbkvzhvCg4BaBhRFghAWTPzimwKT VauA== X-Received: by 10.180.72.177 with SMTP id e17mr15800327wiv.42.1422124986547; Sat, 24 Jan 2015 10:43:06 -0800 (PST) Original-Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id bb2sm7189160wjc.43.2015.01.24.10.43.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 10:43:06 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 In-Reply-To: <83h9vgsehi.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::235 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:181729 Archived-At: On 01/24/2015 11:40 AM, Eli Zaretskii wrote: >> The easiest example is code completion. In emacs-lisp-mode, it will >> parse the current buffer context and offer completions from obarray, >> somewhat filtered. If you have a README in the same directory as >> foo.el (so we might consider them to be in the same project), when >> you open it, you definitely won't get the same completions as in >> emacs-lisp-mode. In fact, if there's no current tags file visited, >> in the default Emacs configuration you won't get any completions at >> all. >> >> Similarly for python-mode (python-shell-completion-at-point only works >> in Python buffers, and only when an inferior shell is running). Likewise >> for Octave, and I just haven't looked at Guile, Awk and GDB support. > > I'm not sure what completions are alluded to here. Completions are > context-dependent, i.e. their DWIM-ish nature should depend on what is > being completed, and for what purposes. Code completion, like the first sentence says. Or completions for text, if we're talking about that README file. Since external completion tools are usually already wedded to specific notions of projects, let's consider "all words in buffers" (a la dabbrev). Arguably, such completion source should use the words from all buffers belonging to the same project, as well as some limited dictionary that's applicable everywhere. elisp-completion-at-point only considers the local buffer contents and currently loaded symbols (which if fine by me, but that exactly follows the pattern). tags-completion-at-point-function, which is the default, has a different problem: it will be used in any buffer, even those not within the current tag file(s)'s subtree(s). > For example, I hope you'd > agree that it would be bad in general for completion in "C-x C-f" to > show only files from the current project. That's neither here no there. `find-file' is a plainly different function. > By contrast, a specialized > command that is meant to find files only from the current project > should probably limit the candidates to the project. Yes, and that's one feature that would use the current project. When used with a completing-read-function that provides some kind of fuzzy matching, it can be very handy: type a few letters and have the file you were thinking of at your fingertips. Not so with the default completing-read, though. > Likewise with symbols -- when the user wants only symbols from the > current project, or from the programming language of the current > buffer, that's what Emacs should show. But there are also situations > where such limitations produce bad results. Personally, I consider that handwavy thinking a problem. We can't support each and every approach and expect the user not to be overwhelmed trying to remember and be able to use all of them. Even if situations where given limitations are bad can exist, as long as they are rare enough, we can sacrifice certain edge cases if what's left is a coherent, simple user interface. An extreme example, I'd say, is Icicles (sorry, Drew). Just looking at the documentation makes my head spin. And even if there can be situations in my life where I could use each option, I'd rather do the work manually rather than look for it, or generally live with an interface that does so many things at once. > The important point is we cannot limit the user to just one possible > context, even if it is the most frequent one. Such a feature would be > too limited. Ideally, we should provide extensible interfaces. The backend logic that xref uses is swappable, and an interested user can write their take on the indexing and navigation logic, then share their code, and other like-minded users will benefit. Some would be included in Emacs, and would be used by enabling a specific minor mode.