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

[René J.V. Bertin]

On Wednesday December 7 2016 11:36:20 Clemens Lang wrote:

>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.

No, indeed, but that wasn't the gist of my suggestion. Personal choice would still be handled via an env. variable, the short option only serving to override it.

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

Even better: `port -f edit` would work just as well, and would probably equivalent to `port edit -f` if the edit procedure used `global_options(ports_force)`.

>From the looks of it we're talking about a small enough change: check for [macports::global_option_isset ports_force] before doing the
{{{
	if {[info exists local_options($editor_var)]} {} else {}
}}}

dance.

BTW, what's the intended use of the `local_options(ports_${action}_editor)` (where ${action} is always "edit" in this context)? This internal variable already overrides the env. variable, apparently without a way to change ports_${action}_editor from the commandline. IMHO that just makes it a bit more reasonable to check the ports_force setting.

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

For one thing it would also provide a convenient way to use a simple, lightweight editor when you want or have to avoid the usual editor for a few quick changes. The standard vi fallback also has certain power-user features that aren't always available in otherwise more convenient GUI editors. 
Evidently you can do `env EDITOR=foo port edit bar` or `vi `port file bar`` but 1) `port -f edit bar` is much quicker to type and 2) you have to remember the priorities among the 3 supported env. variables.

R.