From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Add a separate mode for .dir-locals.el Date: Sun, 20 Oct 2019 23:21:11 +0300 Message-ID: <09a6f3b6-6743-fe31-4be8-9283e59753fd@yandex.ru> References: <2058328b-aee5-8cb1-2659-a793e1354517@mit.edu> <835zkndcz4.fsf@gnu.org> <83ftjrbjhm.fsf@gnu.org> <83ftjr9sx4.fsf@gnu.org> <83eezb9s5b.fsf@gnu.org> <83bluf9qgb.fsf@gnu.org> <835zkn9o01.fsf@gnu.org> <83lfti8ovn.fsf@gnu.org> <83d0eu8c80.fsf@gnu.org> <83lfth6p0y.fsf@gnu.org> <7f141905-6be3-2c21-e2af-b5926dd80223@gmail.com> <5c9ce9a7-aaa7-8299-e5be-498cb4f2b173@yandex.ru> <8336fo6koq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="2132"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 20 22:21:55 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iMHi6-0000Om-Ph for ged-emacs-devel@m.gmane.org; Sun, 20 Oct 2019 22:21:54 +0200 Original-Received: from localhost ([::1]:46624 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iMHi5-0002Y4-0e for ged-emacs-devel@m.gmane.org; Sun, 20 Oct 2019 16:21:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50514) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iMHhV-0002UN-FE for emacs-devel@gnu.org; Sun, 20 Oct 2019 16:21:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iMHhU-0001Kn-0n for emacs-devel@gnu.org; Sun, 20 Oct 2019 16:21:17 -0400 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:46707) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iMHhT-0001KZ-Qu; Sun, 20 Oct 2019 16:21:15 -0400 Original-Received: by mail-wr1-x435.google.com with SMTP id n15so698185wrw.13; Sun, 20 Oct 2019 13:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6K+srlphS56tB80A4ndUxPAXoB3WMdK86RgjpiJn5fg=; b=peTsPFHhFUhtoDY1u1l9eW7uqV6HL/HNajkQms0OG1B1Z8Qyy4t+imTGZT+Eq/lJV4 O1iaSkSZUsEUqkwjtyIusMovkeXcoPJg8K8heOXk9Ufrc50mm6W1IbPkQ93yPxJ2tl5e gLbsglKrgPnzcyCbVi9mGWMsXBfayZrw+OGnFWJ7mnuky0iIBk6Z9atsQbuLP/sA5jHG enFzglJ4Us1zXEAOF7MZhaRgUd+uuPcC8PT1g2qHMwGrq9IoBJh48aDJwZRe8tlTnUhf CXIo+yWX1n3w/fZ1L5PiNAK4P7upk/1z284pmrFrnScEDb65LMN4uEwuOIAbgTvpnF9e FWRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6K+srlphS56tB80A4ndUxPAXoB3WMdK86RgjpiJn5fg=; b=dS3b1hf/CyMAR/cDx/U5T5boEywyYQ7hmw0QpN8XWLLf5JTwSz60igFqWWUM5unl9c ACiAjhFaZi1LuFCGKq6D3+8lr27blrLN0a+z4TZYqiFg3Vb5gmZNULtmVy9ODflWF88J q6Du6gMlUmZYozxRNo8naBO2lDG8FFnnKEJsmV3buey7ozY7CAwXr+B0oPzWo0cxZawk LwrJatEaJ+hGuBXnn1JlJrvgRmTn2eIPpe2pICP3a5sTlrmCD5TUWHkDA7xvPfsh9mGX TRzCt+A/mBVSFOoA6lffiqC4I2yRfMgTBLcCzuuHDeoe4cTIUAnLIrU02zTzrVxkNc6z nKZQ== X-Gm-Message-State: APjAAAU09lHoHwWWX1HvO/rMhOc1QLA5snbprOv++RvlrmylPuLyg4XP UqgUnZA0Mj/ouyF/QOkqgA874GP4 X-Google-Smtp-Source: APXvYqzJw4M8A6VrAaunRBFK12I7X5a6MCmzGxnKxXen9qF6EP/fzW8k4+c1rg7Lk/esmCC44D98Iw== X-Received: by 2002:adf:fc44:: with SMTP id e4mr15296324wrs.26.1571602874224; Sun, 20 Oct 2019 13:21:14 -0700 (PDT) Original-Received: from [192.168.1.125] (62-65-176.netrun.cytanet.com.cy. [62.228.65.176]) by smtp.googlemail.com with ESMTPSA id r13sm20078879wra.74.2019.10.20.13.21.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Oct 2019 13:21:13 -0700 (PDT) In-Reply-To: <8336fo6koq.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::435 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:241267 Archived-At: On 20.10.2019 8:38, Eli Zaretskii wrote: >> xref-backend-functions and project-external-roots-functions come to mind >> as well. And they all will have to duplicate the check. > > What check did you have in mind? The "does this file contain an Elisp program" check. > AFAIK, the hooks you mention don't > need to byte-compile the file, so the issue at hand is not relevant > for them. And at least for Xref, I don't see why it should handle > ELisp data files differently from any other ELisp files. That depends on how we want to treat those files in general. If each such file is an "opaque" Lisp form, there's no reason to expect even normal Elisp variables here. So Xref could simply show/do nothing. But okay, we can assume that such files will contain symbols corresponding to variables/functions/etc in the current Emacs session. Seeing feature names there is highly unlikely, though, so Xref could filter out those in the search results. *If* the current file is in elisp-data-mode. project-external-roots-functions, again, would probably return nil in such files. And elisp-completion-at-point, as people mentioned already, would have to special-case them as well. So we might as well write a new completion function, for a new major mode. So we have several features that, somewhere in the implementation, will need to make that check and act differently because of that. A new major mode will do that nicely. Speaking of no-brainers, I don't see why you're fighting this one. Major modes are one of our methods of extensibility. Someone somewhere will create a new package/file-name/use-case for such files. They'll only have to add a new entry to auto-mode-alist, and voila, the new Elisp Data file buffer behaves as expected. They won't have to wait until Emacs hardcodes the new file name somewhere as well.