This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-10
Channels
- # aleph (1)
- # aws-lambda (1)
- # beginners (80)
- # boot (20)
- # cider (75)
- # cljs-dev (45)
- # cljsjs (1)
- # cljsrn (11)
- # clojure (428)
- # clojure-dusseldorf (13)
- # clojure-italy (4)
- # clojure-russia (153)
- # clojure-spec (47)
- # clojure-taiwan (1)
- # clojure-uk (62)
- # clojurescript (84)
- # cursive (19)
- # datascript (96)
- # datomic (75)
- # dirac (9)
- # docs (3)
- # emacs (19)
- # jobs (5)
- # jobs-discuss (20)
- # jobs-rus (17)
- # lein-figwheel (5)
- # leiningen (1)
- # liberator (4)
- # luminus (12)
- # off-topic (4)
- # om (31)
- # onyx (102)
- # pamela (1)
- # parinfer (3)
- # pedestal (3)
- # proton (1)
- # protorepl (14)
- # re-frame (54)
- # reagent (22)
- # rum (40)
- # spacemacs (2)
- # specter (8)
- # test-check (5)
- # unrepl (110)
- # untangled (80)
- # vim (3)
- # yada (46)
I was planning on fixing the rest of https://github.com/clojure-emacs/cider/issues/1352
@jfntn porting CIDER to some alternative backend would be way easier, trust me about this
when I had more time to work on the project I made a few steps towards isolating the nREPL-specific code, but didn’t get very far
basically to support some other backend you need a lot of passion and about one week of heavy work
* write some simple layer that abstracts away connection information from the interactive commands (things that call down to nREPL should be replaced with functions that dispatch on the connection type)
* extract the Clojure part of CIDER into some library that could be used with the new REPL and nREPL
all of those tasks are relatively simple, but they are still a lot of work that someone needs to do
dropping nREPL and replacing it with something else won’t be much easier, so I’d go in a direction to be able to support multiple REPL backends
@bozhidar I’ve gotten some headway into this, but struggeling with a last couple of issues:
cider $ emacs -Q --batch -l test/cider-checks.el
Warning (emacs):
cider.el:487: Probably "returns" should be imperative "return"
Warning (emacs):
cider-test.el:401: Probably "TESTS" should be imperative "Test"
Warning (emacs):
cider-test.el:516: Probably "tests" should be imperative "test"
Warning (emacs):
cider-test.el:530: Probably "tests" should be imperative "test"
Warning (emacs):
cider-test.el:573: Probably "tests" should be imperative "test"
Warning (emacs):
cider-test.el:629: Probably "tests" should be imperative "test"
Warning (emacs):
cider-test.el:639: Probably "tests" should be imperative "test"
Warning (emacs):
cider-test.el:644: Probably "tests" should be imperative "test"
Warning (emacs):
cider-test.el:649: Probably "tests" should be imperative "test"
Warning (emacs):
cider-macroexpansion.el:129: Lisp symbol `macroexpand-all' should appear in quotes
Warning (emacs):
cider-macroexpansion.el:134: Lisp symbol `macroexpand-all' should appear in quotes
Warning (emacs):
cider-interaction.el:283: Probably "highlights" should be imperative "highlight"
Warning (emacs):
cider-interaction.el:287: Probably "highlights" should be imperative "highlight"
Warning (emacs):
cider-interaction.el:1173: Some lines are over 80 columns wide
Warning (emacs):
cider-inspector.el:136: Keycode M-x embedded in doc string. Use \\<keymap> & \\[function] instead
Warning (emacs):
cider-apropos.el:79: Probably "matches" should be imperative “match”
checkdoc
has a ton of configuration that you can adjust via .dir-locals.el
to suppress some types of warnings
apart from the warnings about imperative that should probably be all disabled the others seem fixable to me
have you seen https://github.com/candid82/joker @bozhidar ?
highest hope is to use it as a drop in analyzer which does not even need a REPL running
so if I have a java6 project there's no reason the latest cider wouldn't work with it?
And if theres an error the stacktrace doesn't show up its just a blank cider-error buffer
Are defcustoms
global ? I have a case where in a buffer the value is picked from .dir-locals.el
and one where it is not. The latter is a freshly made buffer not associated with any file. Maybe this is why?
i understand dir locals affects that var from any buffer located in that folder or a folder located underneath that one
if you are saying the latter is a freshly made buffer not associated with a file then it couldn't possibly be in a folder underneath your dir locals
Sounds logic
So it follows that you can never use .dir-locals.el
for buffers not associated with a file
Like repls or comint-mode
buffers..
> Sometimes, you may wish to define the same set of local variables to all the files in a certain directory and its subdirectories, such as the directory tree of a large software project. This can be accomplished with directory-local variables. looks like it
Yes I control it and I might take that route