GitHub: Discord (official chat):

Is there some magic necessary to make dir-locals.el work? ( Following the directions there doesn't give me anything new when I invoke inf-clojure.


Note: This file has to be in the directory in which you're invoking inf-clojure or a parent directory. Might be a clue, given that I'm using a GUI emacs.

dpsutton 2020-09-10T19:39:31.004Z

should work out of the box. in the buffer you can evaluate the thing you want to be picked up. M-: inf-clojure-whatever and see its its shadowed. also m-x describe-variable

dpsutton 2020-09-10T19:39:52.004200Z

i'm not familiar with that error message


that is on the readme in the repo for inf-clojure

dpsutton 2020-09-10T19:40:38.005Z

ah yeah. where is your project and where are you putting the dir-locals file?


I put dir-locals.el in the root of my project

dpsutton 2020-09-10T19:41:03.005400Z

that should be correct

dpsutton 2020-09-10T19:41:10.005600Z

can you put the dir-locals file here?


I'm using something simple right now for testing

  (inf-clojure-custom-startup . "clojure -A:rebl-jdk8")
  (inf-clojure-custom-repl-type . clojure)))

dpsutton 2020-09-10T19:48:19.006500Z

doesn't seem wrong to me. can you do (hack-local-variables) and then m-x describe-variable [ret] inf-clojure-custom-repl-type?


value is nil

dpsutton 2020-09-10T19:49:32.006900Z

weird. then its not picking them up

dpsutton 2020-09-10T19:51:12.007100Z

what's the name of your dir-locals file?



dpsutton 2020-09-10T19:52:46.007500Z

it needs to be .dir-locals.el

dpsutton 2020-09-10T19:52:47.007700Z

leading dot


so I got a warning about potentially unsafe variable locals list... but accepting (Y) did not affect my available startup commands

dpsutton 2020-09-10T19:55:57.008800Z

and now m-x describe-variable reports its seeing the new value?


value still nil

dpsutton 2020-09-10T19:56:32.009300Z

try (hack-local-variables) again


inf-clojure-custom-repl-type is a variable defined in 'inf-clojure.el'.
Its value is 'clojure'
Original value was nil
Local in buffer *Scratch*; global value is nil

  This variable's value is directory-local.

dpsutton 2020-09-10T19:57:42.009800Z

ok now its picking it up. it should work now

dpsutton 2020-09-10T19:57:54.010200Z

i'm assuming now it is asking you to choose the repl startup form?


to make sure I'm understanding this correctly: If I invoke inf-clojure , I should see this new startup?


because I do not

dpsutton 2020-09-10T20:00:11.011800Z

i'm trying to figure out if you're on the most recent version when these were introduced. if your forms are honored you should not get this choice as you are setting them now. but if its not working it should be offering you a list like this:


yes, I get that list currently


let me check my version


this is a new computer which I re-setup my emacs setup from scratch on Aug 17... so it should be a fairly new inf-clojure

dpsutton 2020-09-10T20:01:38.013400Z

ok. its strange that its seeing the value and still offering you the list


version <tel:202008011128|20200801.1128>


yeah, no updates

dpsutton 2020-09-10T20:03:47.014600Z

i can't reproduce that. i put dir-locals and it just worked

dpsutton 2020-09-10T20:04:43.014900Z

/t/stuff ❯❯❯ tree -a .
├── .dir-locals.el
└── stuff.clj

0 directories, 2 files
/t/stuff ❯❯❯ cat .dir-locals.el
  (inf-clojure-custom-startup . "clojure -A:async")
  (inf-clojure-custom-repl-type . clojure)))
/t/stuff ❯❯❯
and then m-x inf-clojure and it dumps me into a repl

dpsutton 2020-09-10T20:05:06.015600Z

and you are doing this from a buffer that is underneath this directory?


correct, I'm in a src/thing.clj


and .dir-locals.el is in root (parent of src)


I'm using a bare skeleton of a project to test this. It's just deps.edn, .dir-locals.el and src/thing.clj

dpsutton 2020-09-10T20:08:20.017200Z

me too. not sure what's going on


alright, I'm going to pack up what I'm doing here and kill my emacs server and clients then see if restarting it makes any difference


after a complete restart of emacs on my system, it works.


thanks @dpsutton

dpsutton 2020-09-10T20:42:43.019300Z

awesome. no idea why that was acting so funky but glad its working

dpsutton 2020-09-10T20:42:47.019500Z

are you on osx by any chance?

dpsutton 2020-09-10T20:43:07.019900Z

mention this just because there's kind of a show stopper bug in the emacs C code that will break you

dpsutton 2020-09-10T20:43:56.020800Z

all comint based emacs packages on osx are broken. and it blows my mind that more people haven't complained

dpsutton 2020-09-10T20:44:25.021300Z

well, anything that sends largish strings through a subprocess. it doesn't buffer correctly


I've encountered that issue a few times, but only when the evaluation takes a certain amount of time (seems to be >100ms)


Likely also because those return longer results 🙂