Consider renaming the project to make it easier to differentiate between it and nREPL

[bbatsov]

I believe that the current project name is problematic for a number of reasons and we might consider renaming it. Here's the problems:

• Confusion between nREPL and nrepl.el online.

Nobody actually calls nrepl.el nrepl.el - you'll find lots of articles about nrepl and Emacs, but not much about nrepl.el and Emacs if you do a web search. This makes it very hard to find something about nREPL itself, since most search results are actually about nrepl.el.

• Confusion between nREPL and nrepl.el in the code and the documentation.

The code of nrepl.el is pretty confusing for newcomers at some places because everything is nrepl- something and we have some pretty absurd naming situations from time to time (we had nrepl-nrepl-buffer at some point). The documentation is also confusing since often it refers to nREPL or nrepl.el just by nrepl.

• nrepl.el is more than just an nREPL client.

Sure, nREPL provides the basis from most of the functionality in nrepl.el, but ultimately nrepl.el is a Clojure programming environment similar to an IDE. The current name of the project hardly makes this apparent.

I think the community would be better served if we draw a clearer line between client and server in the naming department (like swank and SLIME, foreplay.vim and nREPL, etc).

I have no concrete ideas about a new name, but I've thought about the complexity of renaming the project. Since a lot of resources refer to it I plan to leave an empty repo named nrepl.el behind pointing to the new project. We'll also keep around the nrepl.el package on Marmalade at least for a while. ritz is the only major project depending on nrepl.el, so I guess the fallout from the renaming would be minimal.

/cc @hugoduncan @kingtim @purcell @technomancy @samaaron

I'd love to hear your thoughts on the subject.

[purcell]

I'd be strongly against renaming nrepl.el. I just don't see that the benefits are worthwhile. If there's clojure-related stuff in nrepl that is more general, then we should split that out into a separate package, and have that depend on nrepl.el.

The documentation can, of course, be made clearer if necessary.

[bbatsov]

Technically speaking the only thing that's really depending on nREPL is the evaluation and connection code. In theory it shouldn't be hard to use an nREPL alternative (but this is unlikely at this point) with nrepl.el. So if we end up with two packages, there'll be almost nothing in the nrepl.el package which would not be much different from directly renaming the project.

Personally I'm not exactly thrilled to do such a change, but yesterday I noticed that searching for nREPL returns just one non-Emacs related result in the first few pages of results which reminding me of my other annoyances with the name. And the nrepl-nrepl moments in the code have been bugging me for a quite a while now. Anyways, I can live with it as is. It's up to the Emacs Clojure community to decide :-)

[pmbauer]

Is this generally confusing or only confusing for a few people? Having done the same google search for nrepl, I'm not seeing the confusion; in fact the first hit is for the nrepl project proper.
I've never found this to be an issue and renaming is significant overhead for unknown gain.

[technomancy]

My vote is to ensure we are consistent and precise in the docs and possibly include a "Terminology" section in the readme.

[bbatsov]

@pmbauer Obviously it's not confusing for the people that are known what they are looking for and what nrepl.el and nREPL are :-) The one non-Emacs result I mentioned is indeed the nREPL project's home. Anyways, you should consider the fact that many of the people who come upon nrepl.el don't know even how to start it, let alone differentiate between two projects with almost the same names.

And the search results in Google are not something I care that much about. Personally as one of nrepl.el's maintainers I'm mostly interested in having no ambiguity in the code and the docs and as I already mentioned a different name will help a lot in this department. If someone can come with a way do resolve all the ambiguities in an alternative way - I'm obviously open to suggestions. Just to illustrate the problem with an example - the ops like nrepl-doc, nrepl-source, etc are invoked in an nREPL session called nrepl-tooling-session in our code. I know what this session exactly is, but I'm pretty sure casual readers of the code will be confused if they do no consult its docstring - is this some nREPL session on an nrepl.el client-side session?

[samaaron]

How about enrepl?

[pjstadig]

no

[samaaron]

no is a great name for the project!

[klang]

Swank Clojure was deprecated just over a year ago an nrepl.el was hailed as the replacement. nrepl.el is a fine name and does indicate connection with emacs right there in the .el part.
Please don't confuse people further by chaging the name. It's hard enough for new emacs users as it is.

[alexander-yakushev]

I don't think it's a good idea to rename the project at this point of time. People who distinguish between nRepl and nrepl.el use both these names correctly; for people who don't it is actually better not to care that those are two separate entities. "Clojure has a REPL, I do nrepl-jack-in from Emacs to run it, I'm happy".

[pjstadig]

@samaaron haha

[bbatsov]

@samaaron Yep, even such a small difference would make a big improvement IMO.

@klang Renaming the project has nothing to do with it's status :-) .el signifies a bond with Emacs indeed, but dots in project names are generally not cool and should be avoided. Even the official packages are currently named nrepl (not nrepl.el), which blurs the line between the two nrepl projects. Also nrepl.el could be a project, but could also be just an Elisp source file.

@alexander-yakushev As I already said several times - it's not only about distinguishing them externally, it's about distinguishing them internally. Consider this bit of code:

(defun nrepl (host port)
  "Connect nrepl to HOST and PORT."
   ...
)

(defun nrepl-default-port ()
  "Attempt to read port from target/repl-port.
Falls back to `nrepl-port' if not found."
...
)

In the first example a more correct docstring would be "Connect nrepl.el to an nREPL identified by HOST and PORT.", but that sounds a bit odd to me. nrepl.el, could very well be just a file name. Assuming that once project is nrepl and the other is nREPL the description would sound somewhat absurdly to newcomers.

In the second example - what is the nrepl-default-port - is the default port the client would try to connect to or the default port the server would be listening to? There is a difference between having something that's good enough and something that's really good :-) I'd very much like to hear ideas about disambiguation in scenarios like this, that don't involve naming changes. Maybe we could use client and server here and there in function names?

[alexander-yakushev]

Maybe we could use client and server here and there in function names?

Sounds pretty simple and solid.

[jsyeo]

What? They are different? Now I'm confused.

[darth10]

I feel nREPL and nrepl.el are distinguishing enough, since the later is just a client for nREPL written for Emacs.
Let's just stick to nrepl.el.