From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#70105: 30.0.50; Emacs should support EditorConfig out of the box Date: Wed, 19 Jun 2024 11:18:24 -0400 Message-ID: References: <867chibhqi.fsf@gnu.org> <86frtnd2e6.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9381"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: jcs090218@gmail.com, bjorn.bidar@thaodan.de, Eli Zaretskii , 8slashes+git@gmail.com, 70105@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 19 17:19:17 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sJx5g-0002EO-QB for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Jun 2024 17:19:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJx5R-0002jw-DO; Wed, 19 Jun 2024 11:19:01 -0400 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 1sJx5P-0002jU-4V for bug-gnu-emacs@gnu.org; Wed, 19 Jun 2024 11:19:00 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sJx5O-0004Fp-Su for bug-gnu-emacs@gnu.org; Wed, 19 Jun 2024 11:18:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sJx5R-0004UQ-Qa for bug-gnu-emacs@gnu.org; Wed, 19 Jun 2024 11:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Jun 2024 15:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70105 X-GNU-PR-Package: emacs Original-Received: via spool by 70105-submit@debbugs.gnu.org id=B70105.171881031817197 (code B ref 70105); Wed, 19 Jun 2024 15:19:01 +0000 Original-Received: (at 70105) by debbugs.gnu.org; 19 Jun 2024 15:18:38 +0000 Original-Received: from localhost ([127.0.0.1]:48099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJx53-0004TI-QX for submit@debbugs.gnu.org; Wed, 19 Jun 2024 11:18:38 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39719) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJx51-0004Sv-9X for 70105@debbugs.gnu.org; Wed, 19 Jun 2024 11:18:36 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A55D1100061; Wed, 19 Jun 2024 11:18:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1718810305; bh=M3RflPFpOtlMT/goE0B4NwPzVNy/nGkeHEE4DYL/J2w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iJz8ri1myiDTjjDOvcaMaoOAXoLBatwNcd45cRPJv6EokfMaK3OBJw6EFwWeangTJ I9fc9xxVU93lf0nqT9s7Sv6uNxaANZr8ItGUUsqzY4Od/lE36Sa8Xu6YUPDf+LHKZC RPnYxirSqVvAwMq4Aq5w0JIkAcBjdAZe0ASWovTFVD6/b2RxjY+g0OFNXhKbgEiUIi OjqTCUeyHIJgoWTr7kPHFL+rPk1iTo1vBiKMyQ43SES73AjNIHWCTWacP3ci8rS0bk BM+oZneM9xS+gr5GwOQZOMHxzFYa2phWNX7RIoUzyh+5uitD+/+6h7I7gHNfu9VcOB 7RmYWwveoaeOA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2846110002E; Wed, 19 Jun 2024 11:18:25 -0400 (EDT) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 13E4512059E; Wed, 19 Jun 2024 11:18:25 -0400 (EDT) In-Reply-To: (Stefan Kangas's message of "Wed, 19 Jun 2024 06:01:16 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287488 Archived-At: >> +If you want Emacs to obey those settings, you need to enable >> +the @code{editorconfig-mode} minor mode. This is usually all that is >> +needed: when the mode is activated, Emacs will look for @code{.editorconfig} >> +files whenever a file is visited, just as it does for @code{.dir-locals.el}. > > Is it ever dangerous to load settings from these files or is it always > safe? Should that be documented somewhere, e.g.: > > In contrast to @code{.dir-locals.el}, it is always considered safe > to load settings from @code{.editorconfig} files. (See @xref{...}) They're passed through the same checks, i.e. editorconfig.el translates them to their ELisp equivalent and then we check the result as if it came from a `dir-locals.el` file. Usually, the editorconfig.el code makes sure those tests pass without prompting the user, tho. >> +When both @code{.editorconfig} and @code{.dir-locals.el} files are >> +encountered, the corresponding settings are combined, and in case there > ^^^^^^^^^^^ a simpler word might suffice: "found" >> +is overlap, the settings coming from the nearest file take precedence. > > I don't think I understand this: > - Does "overlap" mean "conflict"? Your question suggests "conflict" is more clear, so I'll use that, thanks. > - What does "nearest" mean; which one is preferred? The settings come from a `.editorconfig` or `.dir-locals.el` file and apply to some other file. "nearest" here is the distance between the file where the settings were found and where they apply. E.g. a setting from `/foo/bar/baz/.editorconfig` should take priority over a setting from `/foo/bar/.dir-locals.el` because it's closer to `/foo/bar/baz/mydir/myfile.agda`. Not sure you state it more clearly (short of writing out a long explanation like I've just done, which doesn't seem warranted). >> +The @code{indent_size} setting of the EditorConfig standard does not >> +correspond to a fixed variable in Emacs, but instead needs to set >> +different variables depending on the major mode. Ideally all major >> +modes should set the corresponding @code{editorconfig-indent-size-vars}, >> +but if you use a major mode in which @code{indent_size} does not take >> +effect because the major mode does not yet support it, you can customize >> +the @code{editorconfig-indentation-alist} variable to tell Emacs which >> +variables need to be set in that major mode. > Does this suggest that our in-tree major modes should set that variable, > IOW that we should spread the knowledge to those modes? Yup. > Should this be documented also in (info "(elisp) Major Mode Conventions")? I have a pending bug-report for a discussion about that. Basically, I think `editorconfig-indent-size-vars` is a crutch because the need is not specific to EditorConfig: we should harmonize the way the "basic indentation step size" is set in the various major modes. Users shouldn't need to guess which variable does that for each and every mode. Instead we should have one convention for where that customization is done which applies uniformly to all modes. But I'm not completely sure what the convention should be. E.g. maybe they should all obey the same `indent-basic-offset` var (which would thus be set buffer-locally when you want to affect a single mode), or maybe they should all use a var whose name can be easily computed from the major mode's name, ... So, until we decide what the convention should be, I'd refrain from adding anything about it to that Texinfo node. >> +Similarly, there are several different ways to ``trim whitespace'' at > ^^ ^^ >> +the end of lines. When the EditorConfig @code{trim_trailing_whitespace} >> +setting is used, by default @code{editorconfig-mode} simply calls >> +@code{delete-trailing-whitespace} every time you save your file. >> +If you prefer some other behavior, You can customize > ^^^ lowercase >> +@code{editorconfig-trim-whitespaces-mode} to the minor mode of >> +your preference, such as @code{ws-butler-mode}. > > Why square quotes around "trim whitespace"? I think they can be > removed. Fair enough. >> @node Connection Variables >> @subsection Per-Connection Local Variables >> @cindex local variables, for all remote connections >> diff --git a/etc/NEWS b/etc/NEWS >> index b2fdbc4a88f..06742d24afe 100644 >> --- a/etc/NEWS >> +++ b/etc/NEWS >> @@ -1964,6 +1964,14 @@ The following new XML schemas are now supported: >> >> * New Modes and Packages in Emacs 30.1 >> >> +** New package EditorConfig. >> +This package provides support for the EditorConfig standard that >> +is an editor-neutral way to provide directory local settings. > > Suggested: > > This package provides support for the EditorConfig standard, an > editor-neutral way to provide directory local (project) settings. Thanks. >> +It is enabled via a new global minor mode 'editorconfig-mode' >> +which makes Emacs obey the '.editorconfig' files. >> +And the package also comes with a new major mode 'editorconfig-conf-mode' > ^^^ >> +to edit those configuration files. > > Suggest replacing "And the package also comes with a new major mode" > with "There is also a new major mode". OK. >> new file mode 100644 >> index 00000000000..2b4ddd4410f >> --- /dev/null >> +++ b/lisp/editorconfig-conf-mode.el >> @@ -0,0 +1,95 @@ >> +;;; editorconfig-conf-mode.el --- Major mode for editing .editorconfig >> files -*- lexical-binding: t -*- >> + >> +;; Copyright (C) 2011-2024 EditorConfig Team >> + >> +;; Author: EditorConfig Team >> + >> +;; See >> +;; https://github.com/editorconfig/editorconfig-emacs/graphs/contributors >> +;; or the CONTRIBUTORS file for the list of contributors. > ^^^^^^^^^^^^^^^^^^^^^ > > Suggested: > > "the CONTRIBUTORS file in the linked git repository" Hmm... good catch. >> +(defsubst editorconfig-core-handle--string-trim (str) >> + "Remove leading and trailing whitespaces from STR." >> + (replace-regexp-in-string "[[:space:]]+\\'" >> + "" >> + (replace-regexp-in-string "\\`[[:space:]]+" >> + "" >> + str))) > > Could this be replaced by string-trim? I never know *exactly* what is trimmed, and when I do it's usually not *quite* the same so I usually assume that the answer is "probably, but it would take more time to figure out than it's worth". > Also, is this defsubst unused? Oh, indeed, I removed all references to it, so it can be deleted, yay! >> +(defun editorconfig-version (&optional show-version) >> + "Get EditorConfig version as string. >> + >> +If called interactively or if SHOW-VERSION is non-nil, show the >> +version in the echo area and the messages buffer." >> + (interactive (list t)) >> + (let ((version-full >> + (if (fboundp 'package-get-version) >> + (package-get-version) >> + (let* ((version >> + (with-temp-buffer >> + (require 'find-func) >> + (declare-function find-library-name "find-func" (library)) >> + (insert-file-contents (find-library-name "editorconfig")) >> + (require 'lisp-mnt) >> + (declare-function lm-version "lisp-mnt" nil) >> + (lm-version))) >> + (pkg (and (eval-and-compile (require 'package nil t)) >> + (cadr (assq 'editorconfig >> + package-alist)))) >> + (pkg-version (and pkg (package-version-join >> + (package-desc-version pkg))))) >> + (if (and pkg-version >> + (not (string= version pkg-version))) >> + (concat version "-" pkg-version) >> + version))))) >> + (when show-version >> + (message "EditorConfig Emacs v%s" version-full)) >> + version-full)) > > Can this function be removed and/or obsoleted? I would like us to > discourage such functions in favor of using standard functions > (e.g. `M-x list-packages' or `C-h p') to find out what version of a > package is installed. OK, I'll remove it (I fully agree with your goal). But the upstream maintainers may like it enough that when I later harmonize the code between Emacs and upstream that function ends up coming back :-( Stefan