Skip to content
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

Misc fixes #300

Merged
merged 3 commits into from
Jun 25, 2021
Merged

Misc fixes #300

merged 3 commits into from
Jun 25, 2021

Conversation

expez
Copy link
Member

@expez expez commented Jun 24, 2021

Could I trouble you to merge this and cut a snapshot release, @bbatsov?

Currently on a Windows machine and mranderson doesn't work here so I can't install locally or push to clojars. Haven't had time to investigate why, but would like to dogfood these changes prior to a new point release.

Copy link
Member

@vemv vemv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I like and regularly use the newly proposed newline style, a significant % of people don't, so I'd suggest keeping the traditional behavior and making the new one opt-in.

I know of teams that use refactor-nrepl as their official 'formatter' (that is, for ns forms).

WDYT?

@expez
Copy link
Member Author

expez commented Jun 24, 2021

a significant % of people don't

Do people write the other way around on purpose when they are manually managing the ns form?

I believe that this way of formatting dominates the other one completely, because you greatly reduce the risk of having the ns form take up too much horizontal space. Does the other way of formatting have any redeeming qualities beyond being familiar?

I'd suggest keeping the traditional behavior and making the new one opt-in

I really want the default behavior of the pretty printer to be in line with the style guide. I'd be way more open to adding a setting to explicitly preserve the old behavior.

While I have someone on the line that gives a shit about ns formatting, another thing that's been bugging me about the current pretty printer is this:

(:require
 [this.very.long.namespace.for.gets.printed.very.weirdly
  :as
  long-ns]

I believe this would be better as:

(:require
 [this.very.long.namespace.for.gets.printed.very.weirdly
  :as long-ns]

but didn't have the time to fix this today. This happens because we delegate the printing of the vector to clojure.pprint/pprint and it will print long vectors like that. If you had a long :refer it would do the same. This isn't something I noticed before it was too late, but it's making the ns form take up too much vertical space. Do you think this will also be contentious?

I have some other stuff I want to fix (e.g. hotload dependency) so maybe we can batch up the contentious stuff and do a 3.0.0 release where some breakage can be permitted.

@vemv
Copy link
Member

vemv commented Jun 24, 2021

Does the other way of formatting have any redeeming qualities beyond being familiar?

I'd be inclined to say that judging the merits of each approach is besides the point. Instead one can simply ohserve that the current approach has been there for many years, and also aligns with the way that many people have written Clojure historically.

I'd concur in that there's no big reason or advantage for the traditional style. It's just familiar, and saves one RET when typing it out. Aside that by now it's hardwired into the brains of a significant % of developers.

This is to say: not introducing breaking changes is valuable. RH's talks have increased the sensibility in that direction, so ideally we wouldn't disappoint people. Especially when refactor-nrepl has gradually some traction over the years; I'd say that for re-gaining it we should be careful with our users.

Finally, CIDER actually has some soft commitment to not further break behavior, see e.g. clojure-emacs/cider#2960

I really want the default behavior of the pretty printer to be in line with the style guide

Worth pointing out that the styleguide is actually worded quite leniently for this specific point, surely in acknowledgement that this was a contentious point.

@vemv
Copy link
Member

vemv commented Jun 24, 2021

I have some other stuff I want to fix (e.g. hotload dependency)

Just in case, I assume you're familiar with clojure-emacs/orchard#103 and related issues/PRs?

The whole goal appeared to be tricky - it could not work at all, or cause multiple bugs that were hard to track down, etc.

@expez
Copy link
Member Author

expez commented Jun 24, 2021

This is to say: not introducing breaking changes is valuable. RH's talks have increased the sensibility in that direction, so ideally we wouldn't disappoint people. Especially when refactor-nrepl has gradually some traction over the years; I'd say that for re-gaining it we should be careful with our users.

Definitely agree with the sentiment, but that conversation was in the context of libraries / APIs. I don't think we'll break any existing programs with this change, though we might surprise people a little.

The clean-ns functionality as a whole isn't perfect, but the point of it is to make something that's good enough that we never have to touch the ns form manually. Manually formatting and editing the ns form is a very low value activity that we want to minimize. My view is that in exchange for avoiding tedious our users have been willing to put up with certain bugs / idiosyncrasies, but would be even happier if we could resolve those issues. This newline is one, the splitting of vectors across too many lines is another and then there are various non-contentious bugs e.g. with deftypes.

Along this line of reasoning comes the argument that would shouldn't put the most sensible defaults behind opt-in settings, but instead allow ourselves some breakage.

I'm really glad you chimed in. I still want to do this, but I can definitely see the value in doing it in a 3.0.0 release and adding an explicit changelog entry. Do you think that's enough @vemv or should I also add a new setting so people can get the old behavior back?

@magnars
Copy link
Contributor

magnars commented Jun 24, 2021

It might not be the most pertinent point, but I manually "correct" these newlines every single time. I'm quite familiar with Emacs' M-j (join-line) after these years.

@expez
Copy link
Member Author

expez commented Jun 24, 2021

It might not be the most pertinent point, but I manually "correct" these newlines every single time. I'm quite familiar with Emacs' M-j (join-line) after these years.

The humanity! 😱

I've just left it as is, with a niggling feeling of it being 'incomplete'. Letting the anger and resentment against my own creation grow and grow 👿

expez added 3 commits June 24, 2021 20:32
The content of the artifact cache was stored in a sorted map and then
written to disk.  The default readeres for edn does not contain a reader
capable of handling sorted maps.  This caused the artifact cache to stop
working.

This commits drops the use of sorted maps, as we never rely on them
being sorted anyway.
This makes the pretty-printed namespace form more in line with the
clojure style guide.

Specifically we go from:

```
(ns foo.bar
  (:require [this.library :as lib]))
```

To:

```
(ns foo.bar
  (:require
    [this.library :as lib]))
```

This commit closes clojure-emacs/clj-refactor.el#459
@expez
Copy link
Member Author

expez commented Jun 24, 2021

Aight, bumped the next release to 3.0.0 and added a proper changelog entry for this 'fix' :)

@vemv
Copy link
Member

vemv commented Jun 24, 2021

I'm really glad you chimed in. I still want to do this, but I can definitely see the value in doing it in a 3.0.0 release and adding an explicit changelog entry. Do you think that's enough @vemv or should I also add a new setting so people can get the old behavior back?

Thanks! 3.0.0 is nice - often other projects follow semver more laxly.

Opt-out seems ok, would be the second best choice imo 😄 a Java system property tends to be nice for these cases - this way one can set it in a team's project.clj, removing the need to worry about individuals' emacs setups.

Would also be nice to keep the test coverage for the old formatting. It might be easy (without duplicating files such as test/resources/artifacts_pprinted ) by using string/replace within the relevant deftest.

@bbatsov
Copy link
Member

bbatsov commented Jun 24, 2021

I'll take a closer look at the proposed changes tomorrow/over the weekend.

@bbatsov
Copy link
Member

bbatsov commented Jun 25, 2021

While I welcome the suggested change to the ns formatting, I'm thinking it'd be nice if we added some configuration flag that controls on the client-side whether there's a newline or not. That's trivial to do (just a defcustom and an extra param to the nREPL op that tracks it) and I guess it will keep happy the people who want to stick to the old behavior after the next release is out.

@expez
Copy link
Member Author

expez commented Jun 25, 2021

While I welcome the suggested change to the ns formatting, I'm thinking it'd be nice if we added some configuration flag that controls on the client-side whether there's a newline or not. That's trivial to do (just a defcustom and an extra param to the nREPL op that tracks it) and I guess it will keep happy the people who want to stick to the old behavior after the next release is out.

Anyone willing to take that on? If not, I'm inclined to just drop the commit. There are many other bugs in this project that I'd rather spend that hour fixing.

@bbatsov
Copy link
Member

bbatsov commented Jun 25, 2021

I can do this down the road myself, but I've been crazy busy at work for the past few months. I guess we can just open a ticket about this and hope that someone will get to doing it.

@bbatsov
Copy link
Member

bbatsov commented Jun 25, 2021

I'm really glad you chimed in. I still want to do this, but I can definitely see the value in doing it in a 3.0.0 release and adding an explicit changelog entry. Do you think that's enough @vemv or should I also add a new setting so people can get the old behavior back?

I should have also read the discussion so far - seems you already discussed this. We can also "cheat" a bit and use a Java property to control this. Anyways, not a big deal for me.

@bbatsov bbatsov merged commit 09a690d into master Jun 25, 2021
@bbatsov bbatsov deleted the misc-fixes branch June 25, 2021 08:36
@vemv
Copy link
Member

vemv commented Jun 25, 2021

No issue 👍

I'll add the toggle in a PR. I happen to have the time and was planning to contribute to refactor-nrepl!

@bbatsov
Copy link
Member

bbatsov commented Jun 25, 2021

I've deployed a new snapshot.

@bbatsov
Copy link
Member

bbatsov commented Jun 25, 2021

I'll add the toggle in a PR. I happen to have the time and was planning to contribute to refactor-nrepl!

@vemv Great! I just noticed you can also add this as part of https://github.com/clojure-emacs/refactor-nrepl#configuration

I never used clj-refactor, I so I hadn't noticed it has one configuration map for everything. This makes the task even simpler than I thought it was.

vemv added a commit to reducecombine/refactor-nrepl that referenced this pull request Jun 27, 2021
vemv added a commit to reducecombine/refactor-nrepl that referenced this pull request Jun 27, 2021
vemv added a commit to reducecombine/refactor-nrepl that referenced this pull request Jun 27, 2021
@vemv vemv mentioned this pull request Jun 27, 2021
6 tasks
bbatsov pushed a commit that referenced this pull request Jun 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants