`port edit`, local/console vs. remote use

[Clemens Lang]

Hi,

----- On 7 Dec, 2016, at 10:26, René J.V. Bertin rjvbertin at gmail.com wrote:

> I often use `port edit --editor XX foo` when I don't want to use the default
> editor. Maybe the cleanest solution would be to add a short option equivalent
> of `port edit --editor vi`. I'd say `port edit -v` as a mnemonic, but that
> could cause confusion with the verbose option.

MacPorts should not be in the business of having a short option for everybody's
favorite editor. We'd have -e for emacs, -t for textmate, -w for textwrangler,
-d for ed(1), -s for sublime.


> Either way this could serve users like Ryan and me:
> 
> - A new MP_GUI_EDITOR variable contains the name of the preferred/GUI editor
>   that cannot be used over ssh

Again, this isn't a MacPorts problem. Whereever you set $EDITOR to a GUI tool,
add a check for an SSH connection and set $EDITOR to a command-line compatible
one.


> - `port edit` uses that value if available unless an option is given to override
>   this choice

port(1) already supports this, using the $EDITOR variable. Change its contents
if you want to use a different editor.


> A possible suitable choice for the short option: -f, as in "force editing even
> if your usual editor isn't available".

We do not use short options after actions. Only global flags have short options.


> In that case the option could override all env. variables with the possible
> exception of VISUAL_EDITOR if that's a traditional variable also used outside
> of MacPorts.

What does that achieve that setting $EDITOR doesn't?

-- 
Clemens Lang