Julia: Why is `default_editor` emacs?

[sunoru]

This is just a trivial question I found here:https://github.com/JuliaLang/julia/blob/master/base/interactiveutil.jl#L15-L18.

I think there are a lot of Linux users (including me) who don't install emacs on their computers and don't have a "/etc/alternatives/editor". Then when the edit function is called in REPL without setting an enviromental variable, it can easily fail. So I suggest we should change the default_editor for Linux users to something like "nano", which is probably preinstalled in most Linux distributions.

[nalimilan]

So I suggest we should change the default_editor for Linux users to something like "nano", which is probably preinstalled in most Linux distributions.

It's not preinstalled on Fedora (vi is).

Maybe xdg-open would be a better choice? It should open the default application registered for the file's MIME type, which should even match the user's code editor if one is configured. Much better than trying to guess what's preinstalled on the user's machine and what the user prefers.

[sunoru]

Oh thanks, actually I'm using Fedora and I just realised I installed nano manually before :(

I don't know if xdg-open also exists on the distributions which are not desktop version... And as it says here, "it can be difficult to debug when the wrong default application is being opened". We can't even ensure the default application for a file with the MIME type "text/plain" to be the editor..

Maybe vi is OK..

[bdeonovic]

vi will rule all.

[Keno]

Why is default_editor emacs?

It's what Jeff uses ;).

[Keno]

FWIW though, vi isn't installed in many minimal linux distribution (though then again, neither is emacs).

[Keno]

Maybe we need to ship femtoemacs.

[sunoru]

FWIW though, vi isn't installed in many minimal linux distribution (though then again, neither is emacs).

Could you give some examples? I'm really curious then how people edit files on those distributions without installing one.

[vtjnash]

FWIW though, vi isn't installed in many minimal linux distribution

are you sure? Busybox implements vi, and it's technically part of the posix specification.

[Keno]

The example I was thinking off was the docker ubuntu base image.

[bdeonovic]

How about Notepad, I hear that is good /s

[bdeonovic]

The example I was thinking off was the docker ubuntu base image.

Docker doesn't have anything for file editing, so probably not the best thing to compare to.

[Keno]

Docker doesn't have anything for file editing, so probably not the best thing to compare to.

That's true, but there's docker containers based on that base image that provide julia (and do not have vi).

[sunoru]

That's true, but there's docker containers based on that base image that provide julia (and do not have vi).

edit function is only for interactive uses in REPL. Do you think it's necessary to provide this feature when using docker?

[nalimilan]

I'm more concerned about the fact that vi can be terribly confusing when you're not used to it. Even exit is hard to find.

Why not check for /usr/bin/xdg-open, and if that fails fall back to nano and vi (in that order)?

[nalimilan]

We can't even ensure the default application for a file with the MIME type "text/plain" to be the editor..

Please find an example where that's not the case first. :-) Seriously, I don't think any distro is going to mark e.g. LibreOffice as the default for text/plain.

[sunoru]

I mean, because users can change the default application by theirselves, it can be anything besides an editor.

[GunnarFarneback]

edit function is only for interactive uses in REPL. Do you think it's necessary to provide this feature when using docker?

There's no conflict between running in docker and using the REPL interactively. I do that frequently.

Would it be out of the question to prompt the user for choice of editor if none is configured (by /etc/alternatives/editor or whatever means)? Personally I'd rather have an error if the one true editor isn't set up rather than being dumped into some evil false editor.

(For that matter I'd rather have an error if /etc/alternatives/editor points to an evil false editor as well, but that just might be asking for too much.)

[StefanKarpinski]

How about if we can't find an editor we just throw an error?

[nalimilan]

That's an option, but that's certainly the less useful one, so why not try other possibilities first?

[hawkish]

This is what git does: By default, Git uses whatever you’ve set as your default text editor ($VISUAL or $EDITOR) or else falls back to the vi editor to create and edit your commit and tag messages. To change that default to something else, you can use the core.editor setting.

But I agree with the above. Vi is evil if you don't know your colons.