Add flycheck and flycheck-clojure.

[mwfogleman]

This partially addresses #2. I am having difficulty loading the example-config, so I was unable to add the packages themselves. I will work on that.

[benedekfazekas]

anything I can assist with? what kind of difficulties?

[mwfogleman]

OK, I succeeded in doing a (package-install 'flycheck). Flycheck has a couple of dependencies, and I staged everything that changed.

@benedekfazekas, since you offered to help, can you check that last commit to see if anything is optional/unnecessary/undesirable?

I'll work on adding flycheck-clojure manually, as it doesn't seem to be in MELPA Stable yet.

[benedekfazekas]

I am getting an error (using emacs 24.3) at start up when using your branch as .emacs.d:

Warning (initialization): An error occurred while loading `/Users/benedekf/.emacs.d/init.el':

Symbol's function definition is void: function-put

[mwfogleman]

Hm, I probably installed flycheck incorrectly.

I've tried to install flycheck-clojure above. If and when we get this working, I will squash all my commits.

[benedekfazekas]

still the same error

[mwfogleman]

OK. I think I'll need your help installing these correctly, then.

I installed these by doing an "emacs -q", and then manually setting the package configuration.

I can't figure out how to load this configuration without loading my own personal configuration. Do you know how?

[ghost]

FWIW I put this example config as my .emacs.d directory and it opened just fine, loaded and compiled an existing project, no issues at all. I'm looking forward to exploring the many features in this setup.

Question for you: I do have several customizations from my old emacs config that I want to "merge" onto this config. The very easy solution I'm thinking is to just make a my-config.el file and then at the bottom of this exiting init.el do something like:

(load "my-config.el")

but can you clarify the elisp function for this, and the path? I see a symbol you are using dotfiles-dir but I'm not sure where that is defined, is that an emacs system var?

This way if I ever want to get the latest version of this repo (which would presumably include the latest versions of all the clojure-emacs libraries included), then all I have to do is put that single line back in there and dump my my-config.el back into .emacs.d. Unless I just did a pull, in which case I assume my my-config.el would stay in place but I might still need to add that load line back in at the bottom.

[benedekfazekas]

well, perhaps not the most elegant but you can temporary remove your .emacs.d and clone your branch into ~/.emacs.d/. I guess emacs -q -l some-custom-init.el won't work here as we load stuff from .emacs.d

[mwfogleman]

I did the equivalent of that (by exporting HOME to a more convenient directory) and did not see the error you are reporting.

I am using Emacs 25 head, though, so perhaps flycheck or flycheck-clojure do not support 24.3.

[benedekfazekas]

possible. will test.

[ghost]

the linting would be an example of one of those things i'm not entirely sure i'd want turned on by default. i assume flycheck is responsible for those squiggly red lines that appear under code sometimes? I had something like that in my old emacs config and it was always underlining stuff that was not actually an error, usually a namespace form at the top of a file for some reason.

[purcell]

perhaps flycheck or flycheck-clojure do not support 24.3.

flycheck certainly does.

[purcell]

the linting would be an example of one of those things i'm not entirely sure i'd want turned on by default.

If none of the various linter programs are installed, flycheck will have no effect.

[benedekfazekas]

if I get it right in case you use the clojure depedency of squiggly clojure that pulls in kibit and eastwood: https://github.com/clojure-emacs/squiggly-clojure#dependencies-in-clojure

[purcell]

if I get it right in case you use the clojure depedency of squiggly clojure that pulls in kibit and eastwood: https://github.com/clojure-emacs/squiggly-clojure#dependencies-in-clojure

Yep.

[benedekfazekas]

not 100% sure but it seems based on this if we want 24.3 support (yes please) then we need to install this pkgs with 24.3 emacs before pushing into the bundle

[mwfogleman]

OK. I don't plan to install 24.3 on my machine, so I welcome someone else to take over my fork and re-install the packages.

[pnf]

1. I verified that flycheck-clojure and its dependencies install and work without error under on my local build of 24.3 (though I do in fact develop on 24.4).
2. There is one (and only one) version tag on the master branch, so it should be on melpa stable soon... unless I misunderstand something about the process.
3. Correct, flycheck-clojure won't do anything unless you have the Clojure piece installed, and that in turn pulls in specific versions of kibit, eastwood and core.typed, unless you add :exclusions.
4. You can control which checkers run by setting flycheck-disabled-checkers in the usual way or, for somewhat more control, via project.clj or namespace metadata, as explained in the README.md.

[purcell]

There is one (and only one) version tag on the master branch, so it should be on melpa stable soon... unless I misunderstand something about the process.

I just looked into this, because it shouldn't take 3 days to build a package -- the tagged version has the .el file at a different location in the file tree, so the recipe doesn't find it. Can you re-tag the latest master with a fresh version?

[purcell]

not 100% sure but it seems based on this if we want 24.3 support (yes please) then we need to install this pkgs with 24.3 emacs before pushing into the bundle

Then don't check in the elpa packages: make the sample code install them on demand. Borrowing from the relevant part of my own config, you'd have something like:

(add-to-list 'package-archives '("melpa-stable" . "http://stable.melpa.org/packages/"))

(defun require-package (package &optional min-version no-refresh)
  "Install given PACKAGE, optionally requiring MIN-VERSION.
If NO-REFRESH is non-nil, the available package lists will not be
re-downloaded in order to locate PACKAGE."
  (if (package-installed-p package min-version)
      t
    (if (or (assoc package package-archive-contents) no-refresh)
        (package-install package)
      (progn
        (package-refresh-contents)
        (require-package package min-version t)))))

(setq package-enable-at-startup nil) ; Don't initialize later as well
(package-initialize)

Then you can just write

(require-package 'clojure-mode)

or

(require-package 'flycheck-clojure)

before the code which requires the corresponding packages, and they'll be installed on demand. You might also want to set package-user-dir to the elpa subdir here, and then git-ignore its contents.

[mwfogleman]

Yeah, that's a good suggestion, @purcell.

I'll make a separate pull in which I try to re-organize the packages in an intelligent way. And then I will revisit this pull when the MELPA Stable stuff is sorted out.

[pnf]

Tag 0.1.2 of flycheck-clojure is back in sync with the .el location.
And, 30 seconds later: http://stable.melpa.org/#/flycheck-clojure

[mwfogleman]

OK, great! I'll come back to this once we merge #4.

[purcell]

And, 30 seconds later:

Just lucky with the timing, I guess!

[benedekfazekas]

let me test...

[mwfogleman]

OK, #4 was merged, and flycheck-clojure is on MELPA stable, so this is trivial now. I pushed a revised commit, and it should be ready to be merged, although suggestions are welcome. Huzzah!

Thanks @purcell for the require-package suggestion, and also @pnf for squiggly-clojure, which is awesome! 👍

[benedekfazekas]

perhaps i am missing something. but even if i modify the ~/.lein/profiles.clj for squiggly-clj and my project.clj in the project I test with squggly never kicks in: never shows any errors. in fact flycheck mode is not enabled by default either on the clojure file but nothing happens either when I manually switch on flycheck mode. i am trying to test with eastwood (from my project.clj):

  :plugins [[lein-environ "1.0.0"]]
  :profiles {:dev {:env {:squiggly {:checkers [:eastwood]}}})

[pnf]

Did you flycheck-clojure-setup?
If you have, you should see three entries with clojure in their names in flycheck-checkers?
Depending on exactly when in the process you turned on flycheck-mode, it might be necessary to turn it on and off again.
If things are working on the emacs side, you should see signs of the traffic in the *nrepl-messages* buffer, even if the configuration on the Clojure side is disabling that checker.

[mwfogleman]

@pnf the set-up is here:
https://github.com/mwfogleman/example-config/blob/0d2259cb2d53ca36e889962d26f99cda513e4ae2/cfg-flycheck.el

I think flycheck-clojure-setup should run when flycheck runs. And flycheck should be running at init.

[pnf]

Can you confirm that there are clojure entries in flycheck-checkers and not in flycheck-disabled-checkers?

[benedekfazekas]

basically works: probably my inexperience with squiggly/flycheck, sry. problem was project clj code was not loaded in the repl. using tools.namespace.repl/refresh solved the problem. both kibit and eastwood checks kicked in. this (clj code needs to be loaded) is expected i suppose, or?

other thing: i had to manually enable flycheck mode on the clojure source file with M-x flycheck mode while on emacs-lisp code it worked automatically. suppose that is expected/intended too, right?

[benedekfazekas]

i am ready to merge as soon as you answer the above (perhaps silly) questions...

[mwfogleman]

@pnf I can confirm that there are entries in flycheck checkers. Looks like that's all flycheck-clojure-setup does. For some reason I expected it to add clojure-mode to the list of modes that flycheck would work with. So, no, @benedekfazekas, it is not intended that you need to manually enable flycheck mode.

Would something like this be inappropriate?

(add-hook 'clojure-mode-hook (lambda () (flycheck-mode))

Alternatively, should something to that effect be added to upstream (squiggly-clojure)?

[benedekfazekas]

above line does the trick: after a tools.namespace.repl/refresh checks kick in

[pnf]

@mwfogleman @benedekfazekas There are some confusing order dependencies that I'm not sure how to ease. Don't do (add-hook 'clojure-mode-hook (lambda () (flycheck-mode)); it shouldn't be necessary and won't help. What does work is the following order of work.

1. flycheck-clojure-setup has been run.
2. Open the project.clj; flycheck will not be active in the buffer, because Cider is not yet running, but it gets you in the right directory for the next step.
3. cider-jack-in. The REPL will now be running, with the appropriate class path for the project.
4. Open a source file in the project. Flycheck will be on, and you should see Clojure commands fly by in nrepl-messages, but the Clojure checkers will detect that the namespace has not been loaded, so no errors will be detected or reported.
5. cider-load-file or -buffer. At this point, we're all set, but, since the buffer hasn't changed, Flycheck won't initiate a check yet.
6. Tickle the file (e.g. by typing and deleting a character). This causes Flycheck to launch the checkers again. This time, since the namespace exists, they actually run and, if appropriate, return errors.

If, by contrast, you had opened the source file before starting Cider, flycheck would not be started in that buffer, because there would be no checkers with passing predicates. Once you started Cider, you'd have to start flycheck manually.

[pnf]

The more robust way around this fiddlyness would be to take the check for running Cider out of the predicate for the checker and put it into the checker itself, so it would run irrespective of whether Cider was connected but wouldn't actually do anything. This would arguably be wasteful.

[benedekfazekas]

@pnf I tested the above step by step (only diff i used t.ns.repl/refresh): flycheck mode is still not on for the opened clojure source file: have to enable it manually.

on your latest comment: wasteful in what sense? would it affect user experience in any way...

[pnf]

You have to open the Clojure source file in emacs after Cider has been connected in order for flycheck to be started automatically. You do not have to have the namespace loaded yet for flycheck to be started automatically; it just won't report anything interesting until you load.

The waste would be that every time you changed something in the source buffer without Cider running, checkers would run as no-ops. It shouldn't affect the user experience except by consuming slightly more CPU. I'm going to try this.

[benedekfazekas]

that is what i did as you described step by step:

1. jack-in on project.clj
2. open a source file

in fact i tried loading the source both before and after 2.: it did not matter as flycheck mode had not got enabled. tbh i could have kept an eye on nrepl msgs buffer (i did not) but i assume since mode was off there was nothing there worth noting.

[pnf]

Then I don't know understand what's going on. If the Clojure checkers are in flycheck-checkers, the only way for Flycheck not to start automatically is for the predicate of those checkers to fail. The predicate is:

(defun flycheck-clojure-may-use-cider-checker ()
  (let ((connection-buffer (nrepl-current-connection-buffer t)))
    (and (bound-and-true-p cider-mode)
         connection-buffer
         (buffer-live-p (get-buffer connection-buffer))
         (clojure-find-ns))))

so one of those clauses must be false.

[benedekfazekas]

just thinking out loud: is not it possible that flycheck is not triggered (therefore flycheck-clojure is not triggered as a result)?

[pnf]

Ok, I made the change in the master branch, so cider connection is checked every time the checker runs, rather than in the predicate that determines if the checker should be loaded. I tested this from a fresh emacs launch by

1. flycheck-clojure-setup as usual, with flycheck-global-mode on.
2. open sample_project/src/sample_project/core.clj; flycheck is on, but no errors are reported because it's not doing anything.
3. cider-jack-in from the source file: flycheck is on, but it's not doing anything because the file hasn't changed while it was on.
4. Tickle the file. Checkers run and report errors.

[benedekfazekas]

tested with squiggly's own sample project: same problem (no flycheck mode for clojure source file). just to rule out that the problem is with the setup of the project i use for testing.

[benedekfazekas]

tested your fix: works for both squiggly sample project and for the project i work with (flycheck mode is on and in fact i don't need to load the ns in the repl) :)

i guess you need to release your fix to melpa stable so we can access it...

[pnf]

👍
I'm waiting on feedback from @lunaryorn on whether this violates the flycheck honor code before versioning it to melpa stable.

[benedekfazekas]

okay. let me know when solved so i can retest. then finally merge. woot woot ;)

thx

[swsnr]

@pnf I replied to the corresponding issue in squiggly-clojure at clojure-emacs/squiggly-clojure#17. I think, it should be fixed in Flycheck itself, and I already pushed a corresponding branch, see flycheck/flycheck#568.

Just waiting for the green light from Travis CI…

[pnf]

@lunaryorn So, if I read flycheck.el correctly, this flycheck mode will now be on in all buffers, but flycheck-buffer will do nothing but cause "FlyC-" to be displayed in the status bar if there is no checker for the buffer with a passing predicate. If a checker materializes, or if an existing one's predicate begins returning t, then that checker will be invoked. It will then be safe for me to move the Cider check back into the :predicate.
If you release this change before I move the Cider check from the start function, then the user will see "FlyC:0/0", but otherwise have the same experience. Correct?

[swsnr]

@pnf Yes, absolutely.

[mwfogleman]

Looks like the Flycheck end of things is sorted out.

[pnf]

For most intents and purposes, it's sorted out on the flycheck-clojure side too. There will be an insignificant performance gain once I restore the original predicate, but it's not crucial... so I won't feel guilty about not getting around to it today!

---

Sent from my VAX-11/780

On Jan 15, 2015, at 16:57, Michael Fogleman notifications@github.com wrote:

Looks like the Flycheck end of things is sorted out.

—
Reply to this email directly or view it on GitHub.

[mwfogleman]

So functioning versions of flycheck and flycheck-clojure are on MELPA stable?

[benedekfazekas]

nope. still flycheck-0.22 and flycheck-clojure-0.1.2 in my .emacs.d/elpa dir with example config, fresh emacs start up

[benedekfazekas]

any progress on this? anything I can help with? cc @pnf @lunaryorn @mwfogleman (sry for nagging ;) )

[benedekfazekas]

@hellofunk @mwfogleman can you guys doublecheck that this works as expected. I cheated a bit so I can merge it: flycheck dependency added from unstable melpa becuase: clojure-emacs/squiggly-clojure#17 (comment)