text editor selection: follow unix defacto standards #356

Currently, tea only supports the $EDITOR env var to open the user's preferred editor (used for reviewing pull requests).

Standard *nix practice is, however, to check for $VISUAL first and only then use $EDITOR as fallback.
This is also done by Git itself, see man git-var(1).
(Actually, the order there is $GIT_EDITOR > core.editor > $VISUAL > $EDITOR > vi)

Maybe we also should change the fallback from vim to vi? (The latter is installed by default on many systems, unlike vim.

Maybe we also should change the fallback from vim to vi? (The latter is installed by default on many systems, unlike vim.

Yes, that would probably be the safer choice.

Should I open a new PR or edit this one?

@plgruener Just add it here :) Thanks!

@plgruener can you "Update" the branch?

Sorry, I didn't know I had to do anything else other than waiting (for the CI checks and then some of you merging the PR).

@plgruener can you "Update" the branch?

You mean rebasing it on top of master? I sure can, but then you'd have to review it again, wouldn't you?
Or do you mean the pending review? I don't know how I can un-request that.

No problem just merge current master into this feature branch, there should be a button 👇 somewhere called "update branch" witch would do the same

I did, but your CI is still failing.

You mean rebasing it on top of master? I sure can, but then you'd have to review it again, wouldn't you?

To clarify, this was not a technical question, but one about workflow and principle. What I meant:
as soon as I modify the PR – either by introducing a new commit, back-merging (with potential merge-conflicts) or rebasing – I instantly invalidate the (already approved) reviews, because I could have introduced another, potentially breaking or malicious, change.
So I was just wondering how you handled that.

Lgtm would still count, since the person who wil merge will have a final look anyway

text editor selection: follow unix defacto standards #356

Reviewers