From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Mon, 13 Nov 2023 03:37:35 +0200 Message-ID: <98f83b3f-268d-c463-0505-d14fe0d5e868@gutov.dev> References: <65a16247-1b1a-149c-b413-71612f88f184@yandex.ru> <9377bf2b-13ed-8d86-4294-0b88e6808d80@yandex.ru> <953056ea-9cfb-34ad-6515-9036633dfdbb@yandex.ru> <2d964697-2b4e-64c7-2f16-aae87e57def4@yandex.ru> <11b5a8be-b15c-f275-d84a-89c2a3a513f7@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15798"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Spencer Baugh , emacs-devel@gnu.org To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 13 02:38:39 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r2LuQ-0003t5-M0 for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Nov 2023 02:38:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2Ltb-0006rR-8K; Sun, 12 Nov 2023 20:37:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r2LtZ-0006qz-T0 for emacs-devel@gnu.org; Sun, 12 Nov 2023 20:37:45 -0500 Original-Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r2LtX-0007iR-1S for emacs-devel@gnu.org; Sun, 12 Nov 2023 20:37:45 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.west.internal (Postfix) with ESMTP id D63D932000D7; Sun, 12 Nov 2023 20:37:38 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 12 Nov 2023 20:37:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1699839458; x=1699925858; bh=FOrXuNp85HVtqiUDFqlDzUq3NM3AOwViSn5 1An1sGfQ=; b=cU0hXNwMFrLSAvFg2VhF7GHrejGKWdPYWk3+ZzLyqG4e6H5rT7i cN9+B4uNT/Tw7kSREd1bcpXJEo1QkkUhHTpT1cX2gx2MKf510oiGJYB3ZrOUK+Xa yN+MJ2n+MpgvEN4KSYAgvg2aSdJ0o/XVKUecVScZU3zdvaM7V9nhVDLTvf/mMVRo bfb4Q8ZnaufryRh4gjCcEf8p/gbLKDL7dyI2kGPGLez/bsOKM4a8eCIeC8V1H/SF eiieUIDd9A/0gEY0Ge57bK1Oln5VsbH56ufzm+vLdjCisK40mPzsg5TIOcyYYeCw VG6TkWhH6LRhd2pn8dBgXGUsoobwdaqwLRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699839458; x=1699925858; bh=FOrXuNp85HVtqiUDFqlDzUq3NM3AOwViSn5 1An1sGfQ=; b=qMNgHlTOsFvqKqqpsLCSjEqZbkltrachx+LxWmmQgbv70ZU7HC7 aKp3ARy62/Y3xNMKGt8ORiXMaPXAAp/4yRWbIby0kX7duaMDZIt/i2lpIq2YZUJr RnTuP9RhqlFdGaAEEhkMrCaSiNQVtcSKMGeh3va97WrvFNyu6NasW98WCLF1Xp/k 5WEKNRJjC8lO5YWdB+3nfY37auVqqW2gnvLlYZSHwVNBdiTwH0v61BUY5eCaGVdg uWhwJeTm8MZYmw2BW0yuiUyxFvUmko3r0VNp/s7UrVk1PCcw7NzT2xH5vG+aWseF JVpYTIPXiQ9FatFiUjoAbLP/xe2VZ72v7kg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvledgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnheptddvgfetieeltdetteejgeduledvhfehteevffekveeuhfekieetudffffeg leehnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpjhguthdrlhhsnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhht ohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 12 Nov 2023 20:37:37 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=64.147.123.25; envelope-from=dmitry@gutov.dev; helo=wout2-smtp.messagingengine.com X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-2.553, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312677 Archived-At: On 12/11/2023 20:59, João Távora wrote: >> Dropping an implementation into master is one way to test out a >> hypothesis, but it has inherent problems: the feedback comes late >> anyway, and quite often we'd end up having to maintain half-bakes >> features or unfortunate capabilities this way simply because they had >> been added and time had passed. > > Maybe. Well Eglot has a fair enough audience, though not sure for > this specific feature. And I don't see any better alternatives if > collecting feedback is what we want. IOW, we shouldn't fall prey > to "analysis-paralysis". Hopefully not analysis paralysis. What we can do first, though, is iterate through a bunch of prototypes. I was hoping to reach some sort of consensus before pushing the next one, but it's not really necessary for experimenting. So I'll just push the one I've been thinking of lately and see what everyone thinks. >> Why contort? From where I'm standing, >> declarations/implementations/typeDefinitions apply to almost any >> object-oriented language (C++/Java/Ruby/Python/JS), and even some >> functional ones. > > What are "declarations" in JS, Java or Ruby and Python? It's a pretty common term. In Java, I'd be surprised if some interpreted it as something other than method definitions inside of an interface. And indeed: https://github.com/eclipse-jdtls/eclipse.jdt.ls/pull/2702 In JS, Mozilla's codebase actually had interface definitions, so a specialized backend could point to those. Some frontend frameworks had a thing similar to that. No idea about Python's practices, but for Ruby there also are classes and mixins that have "abstract" methods. There are no syntactic annotations for that in the base language (you just throw a certain exception in the implementation), but the type-definition projects like Sorbet will likely change that. The other two (implementations and typeDefinitions) make sense for the all of the above languages. Although "implementations" are of course only meningful to have when "declarations" exist. > Perhaps > nothing perhaps entirely different things. Also, there are a lot of > sub-kinds of declaration in C++. Is a forward declaration of a > type in C++ also a "declaration" here? If the type is the entered identifier, why not? I would first ask, are those definitions? Are they in the list returned by xref-find-definitions for the same input? If not, they might be useful to have in xref-find-declarations. > What about a C++20 concept, > is it a type definition? No right? I have no idea, but if it maps to the concept, and the users will find the binding in the common map using "M-' C-h", why not? The only big downside is when xref-find-type-definitions already returns some different things, conceptually incompatible with the potential addition. Or to look at it from another side, if xref-find-type-definitions is on "M-' t" in java-mode, would c++-mode prefer to have some other command on that bindings? If yes, would we want it to be arbitrarily incompatible? > Or maybe, depends on who you ask > some say it's a type for types. Not to mention I think in Elisp we > have at least 3 completely different kinds of "declaration": forward > declarations, (declare ...) forms and defgeneric. It's odd to mix > them. They can be returned together in xref-find-declarations (I would actually use that), and Elisp could have separate commands for more fine-grained navigation. Though the latter doesn't seem too much in demand, given they haven't materialized thus far. > Anyway, this is LSP's taxonomy so it's LSP's problem (or rather, > the problem of the poor servers that have to invent ways to shove > things in these categories. But not our problem by and large if we > don't let it spread any further than Eglot. IMO Eglot is where > LSP ends and Emacs starts. The practice of shoving things into categories didn't appear from nowhere. Having common bindings and menu entries and easy transition between language modes is nice. >> What's the alternative? To have many similar commands >> >> ruby-find-implementation >> c++-find-implementations >> python-find-implementations >> js-find-implementations > > Depends. If you are using Eglot/LSP as a backend, you don't need to. > Eglot already gives you the LSP trio. ruby-mode doesn't choose an Xref backend. It just uses the configured one. Same for other modes in the above list. > If you are using a non Eglot backend, then yes. If you are using > specific backend based on Eglot but with more servers, then yes too, > but only for the extra types you support. And for the rest? Unoccupied bindings? "undefined is not a function"? There be dragons? Suppose a language doesn't support "declarations" in particular? Will it find a much better use for the corresponding binding in the prefix map? >> that all do the same thing inside: call the Xref backend's "find >> implementations" mechanism? It will be especially great to use if some >> major mode authors bind that command to one key, and others to another. > > I don't think it'll happen that often, and xref can define a good prefix > map to use. It's unlikely we or major modes would find keybinding space > outside such a map anyway. I'm saying it would be bad if java-mode binds java-find-interface-declarations to "M-' i" and c++-mode binds c++-find-forward-declarations to "M-' f", while they are more similar than different and could be both put on "M-' d". >>> And Spencer even wanted to put cl-defgeneric in that bag, which I >>> can fully understand, as cl-defgeneric can also be viewed as a >>> declaration. But its a completely different concept from those >>> two. >> >> If Elisp doesn't have any other kind of declarations, what is the worry? >> Let's put the ones it has. > > But it does, at least for some understandings of "declaration". And it > could get even more. A declaration is of course a reference to a thing > that characterizes a part, but not the main part or totality of the thing. > Besides the other two I mentioned already, any source code locus > setting a property on a symbol could be viewed as that. Are we prepared > to handle this? We could be. If we are, do we really want to put this all > in a one-size-fits-all "declarations" bag? We are able to offer both the common "declarations" bag and separate lookup commands for finer searches. I would likely use the former.