> > I'm a bit confused by the patch intent and the above statement: do I > > read a misplaced "not"? Did you perhaps mean that in your system > > $EDITOR > > *is* a visual editor? Probably my fault I'm not understanding :-) > > I was confused as well: Turns out in this context, a VISUAL editor is > one that can assume the user is running in a terminal, so it can e.g. > move to previous lines, unlike a non-visual (line) EDITOR which is > limited to the current line, because output e.g. goes to a teletype > (remote printer).
Here `EDITOR=ex`, which does not start a "graphical" curses interface. > I still don’t really get it though: Why would anyone (today) set > EDITOR to a line editor *and* then expect programs to use VISUAL over > EDITOR? ¯\_(ツ)_/¯ Not sure either. I think I had problems with `EDITOR=vi` years ago and then looked up those variables and set $VISUAL. But might be the case that I was just being a purist or blindly following standards and I don't know anymore :) One thing is certain though: I don't see `ex` being invoked very often, so most commands I use do honour the $VISUAL setting (bash and git for sure). > I mean, strictly speaking, if pass were to use both VISUAL and EDITOR, > it should check that it is running in a terminal, and only then, call > VISUAL, otherwise call EDITOR. But I think the de facto standard today > is for people to just set EDITOR to a “visual” editor, as teletypes > are a thing of the past. I think it depends on whether we want to support old terminals or just the variables. I've seen it implemented like that in a few places, but I've also seen others doing the terminal check. My patch is just about the variables, as I didn't want to change them just because of pass, or have a wrapper script in ~/bin/pass, like I do now, setting `EDITOR=$VISUAL`. -- Pudim
