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.
