Fork me on GitHub
#cider
<
2016-04-21
>
dpsutton00:04:18

@udit: are you still having issues? If so can you tell me which version of clojure is specified in your boot/project file?

jstaffans12:04:59

should fuzzy completion on Java class names within the ns :import section work?

jstaffans12:04:25

I have to type the entire package name in order to get autocompletion, like java.util.UUID

jan.zy14:04:14

Hmm, I must have broken my configuration. When I start cider (0.12) I see this in REPL:

WARNING: CIDER's version (0.12.0) does not match cider-nrepl's version (nil). Things will break!
WARNING: The following nREPL ops are not supported:
artifact-list artifact-versions clean-ns extract-definition find-symbol find-used-locals hotload-dependency namespace-aliases rename-file-or-dir resolve-missing stubs-for-interface version warm-ast-cache
Please, install (or update) refactor-nrepl and restart the REPL.
You can mute this warning by changing cljr-suppress-middleware-warnings.
WARNING: clj-refactor and refactor-nrepl are out of sync.
Their versions are 2.0.0-SNAPSHOT (package: 20151210.200) and n/a, respectively.
You can mute this warning by changing cljr-suppress-middleware-warnings.
user> 

jan.zy14:04:53

In Messages buffer everything looks ok:

Starting nREPL server via lein update-in :dependencies conj \[org.clojure/tools.nrepl\ \"0.2.12\"\] -- update-in :plugins conj \[cider/cider-nrepl\ \"0.12.0\"\] -- repl :headless…

jan.zy14:04:01

Any ideas what might go wrong?

jan.zy14:04:12

this dependency was the reason: [org.clojure/clojure "1.6.0"]

dpsutton14:04:10

that has been fixed so that a better warning is issued

dpsutton14:04:20

The support was dropped since cljs requires 1.7.0 and above and they didn't want to manage the different versions

jan.zy14:04:05

ok, thanks for the explanation

malabarba15:04:11

@jstaffans: yes. Completion works for java classes. However, you probably need to type more than two characters to trigger your completion menu.

malabarba15:04:48

And you need to start from the start

jstaffans15:04:16

@malabarba: you mean start from the start of the class name?

malabarba15:04:21

j.u.U should complete to java.util.UUID

jstaffans15:04:43

hmm.. I type ConcurrentLi<TAB> and get No matches. I have to start typing from the start of the package name to see the completion menu: java.util.concurrent.ConcurrentLi<TAB>

jstaffans15:04:03

Also j.u.c.ConcurrentLi does’t work … what other packages does this completion depend on? I’m thinking the clojure layer in Spacemacs is broken somehow ..

malabarba15:04:00

Just company mode

malabarba15:04:16

But there are options to disable the fuzziness

malabarba15:04:25

Maybe it's disabled for you

jstaffans15:04:20

sounds likely ...

bozhidar17:04:57

@malabarba: company doesn’t support this

bozhidar17:04:05

there’s one long-running thread about it

bozhidar17:04:19

don’t think it will be resolved in the foreseeable future

bozhidar17:04:30

maybe there was some 3rd party extension doing this

bozhidar17:04:34

I don’t recall

bozhidar17:04:53

Alex Yakushev didn’t use company because of this

malabarba17:04:13

@bozhidar: are you referring to getting completion without typing the start of the symbol?

malabarba17:04:48

Or are you referring to getting completion on j.u.U?

bozhidar17:04:26

the package providing this

bozhidar17:04:34

maybe we should mention this in our manual

bozhidar17:04:14

as for the other problem - is ConcurrentList imported in your namespace?

bozhidar17:04:28

you won’t get completion candidate for it otherwise

malabarba17:04:24

My bad. Must have forgotten I installed that

harold19:04:10

wow (!) the mouse hover over symbol tooltip feature in 0.12 is epic nice.

dpsutton19:04:05

you put up a feature request on cider to remember which build version you used for cider

dpsutton19:04:12

haha sorry hit enter too quickly

harold19:04:26

mmm, you mean lein vs. boot?

dpsutton19:04:01

i was thinking remember across sessions might be difficult, but is it asking you which to use each time you redo it in the same session of emacs?

dpsutton19:04:28

do you rerun jack-in multiple times on the same project?

dpsutton19:04:36

and not just reloading, etc?

harold19:04:40

It does ask each time. I occasionally have to kill my repl to flush bugged datomic state.

harold19:04:57

This is why I thought a config var might be a good idea.

dpsutton19:04:08

seems like it might be pretty easy to keep a project-buildtype keyvalue to just remember the last one you entered

harold19:04:16

Though, I realize that only makes sense for my case of 100% of the time wanting to start all projects with lein.

dpsutton19:04:38

my thinking was to make you choose the first time and remember that for all successive jack-ins

dpsutton19:04:44

man what a terrible verb that is

harold19:04:52

I like it, as a verb.

dpsutton19:04:06

and i think malabarba mentioned you could c-u c-c m-j to force it to ignore the cache

dpsutton19:04:20

but this would not persist across restarting emacs

harold19:04:43

What about a config var that was, like, paths to projects mapped to lein/boot.

dpsutton19:04:04

i don't know enough to know where i could persist information about that

dpsutton19:04:19

but you could override things, manually in your .emacs

harold19:04:34

I do things like this in my .emacs:

(setq grep-find-ignored-directories '(".git" "out" ...

harold19:04:02

so if I could setq some state so cider would know I always wanted to start project X w/ lein.....

dpsutton19:04:34

hmm, maybe a preferred strategy in general?

dpsutton19:04:48

like (setq cider-build-precedence 'lein)

dpsutton19:04:58

and then whenever it comes across a choice, it uses your default

harold19:04:03

mmm, yeah, that could work for global.

harold19:04:12

a key/value map per-project might be nice as well.

dpsutton19:04:13

but you can always bring back the prompt with a prefix jack

harold19:04:34

I personally like managing state that way, because my .emacs is in source control, and I can avoid the AUTO-CONFIG var puke...

dpsutton19:04:50

i'll research if there is a way to persist things in packages that survive updates, don't encroach on the users files, etc, that we can remember an initial choice

dpsutton19:04:15

you've given me a lot to think about

dpsutton19:04:24

i'll put together a patch this weekend and see what it looks like

harold19:04:36

Sounds like fun, I'll keep an eye on the issue.

dpsutton19:04:05

wonder if there's something to the ordering: 1) allow explicit overrides 2) allow general resolution strategy of multiple builds 3) remember last choice during same session and offer to persist this choice

malabarba20:04:16

The variable you proposed already achieves that.

dpsutton20:04:21

persistence?

malabarba20:04:53

sorry, misread your last comment

malabarba20:04:22

In any case, I want to avoid asking an additional question during jack-in

dpsutton20:04:29

i'll look into the cider dict structure. Probably is a default value, which could be user set

dpsutton20:04:41

isn't this question already asked when multiple build chains are present?

dpsutton20:04:52

my thinking was just remember the answer to that question

dpsutton20:04:59

if none of the other things are set

dpsutton20:04:03

oh you mean about persisting?

dpsutton20:04:13

i liked your idea of checking for upprecase to persist it

dpsutton20:04:50

or just inform how to persist

dpsutton20:04:06

do you know of any strategies that allow retaining data between sessions?

malabarba20:04:12

Yes. There's customize-save-variable

malabarba20:04:18

But a lot of people don't like it

malabarba20:04:48

And there's the possibility to write to a file under .emacs.d

dpsutton20:04:59

yeah. i thought i remembered a package had done it somewhere else but i can't remember which one

dpsutton20:04:30

maybe just saving a dictionary with a customizable default is sufficient

malabarba20:04:10

I think we can start by adding a variable that lets people choose the default. We don't need to save anyuthing yet

malabarba20:04:16

But don't make it a dict

malabarba20:04:24

dicts are really just for nrepl interaction

malabarba20:04:38

use an alist which is more typical emacs-lisp

dpsutton20:04:44

ah of course

malabarba20:04:01

As in '(("/some/dir" . lein) ("/another/dir" . boot))

dpsutton20:04:24

oh is there no canonical name for the project? something cider would use as the name?

dpsutton20:04:37

i guess location is the only foolproof way to do it?

malabarba20:04:06

Yeah, we have to use location

malabarba20:04:30

while projects do have names, CIDER doesn't know how to figure that out, and I'd rather not teach it

malabarba20:04:00

besides, the name in project.clj clould be different from the name in build.boot

malabarba20:04:05

A directory is foolproof

dpsutton20:04:28

good thinking. thanks again.

malabarba20:04:34

By default the variable will be nil, and whenever the current directory is not in the variable we just ask like we currently do

dpsutton20:04:38

i was thinking allow for a custom set variable that would give a resolution strategy, so that when there are multiple bulid chains, like harold has, it would be able to just globablly prefer one or the other if the project doesn't have one explicitly set?

malabarba20:04:52

I changed my mind

malabarba20:04:02

let's just do a single global variable simple_smile

malabarba20:04:23

As in cider-preferred-command that can be set to boot or lein

malabarba20:04:35

If the user wants fine-grained control they can use emacs dir-local variables

dpsutton20:04:47

easy things easy, and the hard things possible?

dpsutton20:04:56

fair enough

malabarba20:04:22

There are already plenty of cider options that users may need to change on all per-project basis

malabarba20:04:26

and they're all global

malabarba20:04:36

no need to add the complication now

malabarba20:04:59

Emacs dir-local variables work perfectly well simple_smile

harold21:04:43

👏:skin-tone-2:

dpsutton22:04:59

cider-default-build-system sounds like it has more impact than it has

dpsutton22:04:26

what's a good variable name that says cider will use this when there are multiple possible build systems

malabarba22:04:27

default and preferred are both fine words for this purpose

malabarba22:04:43

default is probably the most used one

dpsutton22:04:47

does that almost give an impression of overriding rather than resolving conflicts?

dpsutton22:04:09

and if so its an easy change in the future, but its not an issue at the moment

malabarba22:04:36

but I'm not sure if we use the build system terminology anywhere in cider

malabarba22:04:53

I think we usually just call them commands

dpsutton22:04:12

ah. i can work that in

dpsutton22:04:17

one other question about conventions

dpsutton22:04:21

i'm asking for a default

dpsutton22:04:54

will most people use a string "lein", is it convention that i can set my type or should i be preparred for (setq cider-default-commands 'lein)

dpsutton22:04:08

do i need to handle symbols or is that a user learns the convention before using

malabarba22:04:00

That's up for discussion

malabarba22:04:24

Lately, I prefer to minimize the "variability" of a variable

malabarba22:04:28

as odd as that sounds simple_smile

malabarba22:04:08

I'd rather give an explicit error if the user made that mistake, than try to account for it and complicate the code

malabarba22:04:20

But it's just my opinion

malabarba22:04:25

Of course, regardless of anything else you should always list the possible values in the docstring of the variable.

dpsutton22:04:17

ah. and just realized the bug about when a command is not present you just get the stringp error

dpsutton22:04:44

there is no else case to (if (command-present-p project-type))

malabarba22:04:37

Good catch. simple_smile

malabarba22:04:52

We should just throw a user-error there

dpsutton22:04:28

cool cool. that one bit me recently. its what made me want to start fixing stuff

dpsutton22:04:40

but then the version thing popped up