-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dash.el (->, ->>): Indent with 1 distinguished arg. #375
Conversation
Copyright-paperwork-exempt: yes
2e6c1d0
to
911ef09
Compare
Thanks! |
FWIW this indentation change makes the indentation of -> and ->> different from the indentation they have in clojure which IMHO introduces redundant cognitive load. (cc @ericdallo) |
Yes, I thought this was an issue with my emacs config, but I just realized it's because of this change, I totally agree that the indentation should be like clojure |
I don't feel too strongly about this, but IMO it makes more sense to follow Elisp conventions and idioms when writing Elisp (this applies to any language/environment, not just Elisp). For example, Elisp indents @magnars @Fuco1 Do you favour reverting to Clojure indentation? Thanks. |
Since I code clojure all day, I personally prefer the Clojure indentation.
That doesn't mean it's necessarily right for this package, tho. However,
since there is now `thread-first` and `thread-last` macros in `subr-x.el`,
maybe our threading macros can have a Clojure flavor?
…On Mon, Apr 12, 2021 at 6:41 PM Basil L. Contovounesios < ***@***.***> wrote:
I don't feel too strongly about this, but IMO it makes more sense to
follow Elisp conventions and idioms when writing Elisp (this applies to any
language/environment, not just Elisp). For example, Elisp indents if
differently to some other Lisps.
@magnars <https://github.com/magnars> @Fuco1 <https://github.com/Fuco1>
Do you favour reverting to Clojure indentation?
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#375 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACA4OMZTFONAPRKMNP75ZLTIMPEDANCNFSM4YYOWA2Q>
.
|
Well, you know that I stand in the latter camp, not only because I don't like the idea of imposing another language's style on users of Dash who are writing Elisp; and there's no shortage of examples where Elisp is subtly different from other Lisps - that's par for the course. I'm sure that even within Dash we're not always consistent in which style we follow - that's also to be expected. But luckily what I think doesn't matter that much, and I defer to your preferred package-wide style. Whatever we decide, let's just be consistent ;).
Given the vast breadth of Dash's API, I'm not sure the presence of just |
The threading macros themselves are imposing another language style into elisp. And not only these macros - the whole package is breaking much more important elisp conventions(like package prefix and functions ending with |
Sorry, I don't follow this logic - macros don't constitute a programming/editing language/environment. We're talking about the syntax of Elisp, not the semantics of Elisp definitions.
See #213 and similar discussions re:
I don't see how Elisp-style indentation is less practical or convenient when Emacs does it for you. Besides, the Elisp-style indentation is less indented, so in my book that's actually more "practical and convenient". We can agree to disagree ;). |
It is less practical for multiple reasons.
|
I said "in my book" because what counts as practical, readable, cognitively cumbersome, etc. is clearly a personal and subjective issue. Whether undistinguished macro arguments are indented according to Clojure or Elisp conventions is less subjective, but still a stylistic choice. BTW, this being Emacs, the indentation can of course be customised per-user, per-project, etc. I've already given my context for why I personally follow each language's conventions when writing in that language. The decision for what to do in Dash isn't mine to make anyway.
According to my book, that indentation is wrong, so any argument following from that is moot ;). |
I personally follow common sense and the solutions that will be most useful for the actual users. I also try to avoid inflicting pain and redundant work for stuff that I don't feel strongly about. |
@magnars Your comments sounded like they were in favour of following Clojure indentation project-wide. Let me know if this is indeed the case and I'll make the necessary changes. |
I am not involved enough to impose my will in that way. I can certainly see the value of sticking to the Emacs lisp conventions as well. In the end dash is a collection of tools for use with Elisp, so let's go for that. |
I really respect that, but as the package's author and with feet in both the Elisp and Clojure pools, your will carries unique weight :). But I also understand that bikesheds aren't the best hill to die on ;).
Agreed. |
We already have Would it make sense to add something like a This would allow projects to specify e.g. ((emacs-lisp-mode (mode . dash-clojure-indent))) or ((emacs-lisp-mode (mode . dash-elisp-indent))) in their |
That sounds pretty good to me! With elisp being the default, then. |
IMHO "we" (not being a maintainer myself) should avoid unnecessary indentation changes; or, at least, space them out years apart. I just had a spate of dash-related indentation changes in one of my projects, and that pattern will repeat for most of my others the next time I work on them. Not only is it annoying to have to examine the diffs and commit these indentation changes manually, but they cause new linting warnings on CI until I update the package; and these warnings were not caused by any changes in my packages, they just start happening when dash is updated on MELPA. Dash is supposed to save Elisp developers work, not create more for them. ;) |
Sorry, I thought of the indentation changes as fixes/cleanups, but I can't in good conscience controversially force them on so many Elisp authors any more. Backward compatibility wins again! @magnars I'm guessing you don't have a problem with reconsidering this decision. If so, for the upcoming 2.19.0 release in #382 I'll try to revert any breaking indentation changes, and add Elisp-style indentation as an opt-in feature if I have time. Sorry again for the double hassle and thanks for bearing with my stubbornness. |
That's a good point. Let's keep it as-is, then. |
@basil-conto Thank you for being so considerate of downstream users! :) Not all Elisp packages are developed with such care, and pleas like mine often fall on deaf ears elsewhere. |
This reverts commit 9256290 "* dash.el (-->): Indent with 1 distinguished arg." of 2021-01-10. This reverts commit 911ef09 "* dash.el (->, ->>): Indent with 1 distinguished arg." of 2021-03-08. The Clojure-inspired threading macros -> and ->> are quite popular and were indented until recently with no distinguished arguments as per Clojure conventions. In Elisp practice this is not a problem since the macros have short names. For the converse argument against threading macros such as -some-> that have longer names, see the discussion in #319 and #321. This commit reverts relatively recent breaking and controversial indentation changes that tried to make ->, ->>, and --> more consistent with the rest of Dash, including -some->, -doto, etc. which are all indented with a distinguished argument despite being inspired by Clojure. For the relevant discussion, see #375. * dash.el (->, ->>, -->): Indent without a distinguished argument. (-as->, -some->, -some->>, -fixfn): Reindent. * NEWS.md (2.19.0): Announce indentation change to -->.
I've now done so in commit 3bd52a4. Please let me know if any outstanding issues remain. |
See, e.g. <magnars/dash.el#375>. Ultimately I'd prefer to indent with one distinguished argument, but the noise it causes downstream is likely not worth it. (And, unfortunately, the indentation of the built-in thread-first and thread-last forms has changed to be like this as well, which is even worse, causing 10-11 characters of extra indentation in those forms' bodies!)
Per discussion in 9256290