Package: sensible-utils Version: 0.0.11 Severity: normal Background:
Policy 11.4 describes the mechanism for determining the user's preferred editor: - check the EDITOR environment variable and use it if set; - (optionally): check the VISUAL environment variable and use it if set; - otherwise, use /usr/bin/editor (which is managed as a dpkg alternative). sensible-editor was invented as a convenient way for packages to implement this behaviour in programs whose source code doesn't do so already. In #482774, sensible-editor's behaviour was changed, adding a new helper script named 'select-editor', and is now roughly as follows: - check EDITOR and VISUAL as per policy; - if neither is set, check a ~/.selected-editor configuration file; - if that doesn't provide an editor, offer the user a list of editors and record their choice in ~/.selected-editor The list that select-editor provides comes from the dpkg alternatives system. If one of the editors in the list is 'nano', it's annotated with "<---- easiest". Problems: The intent of this change was to make life easier for inexperienced users, who might not find it easy to edit .bashrc to change an environment variable. But this does not work well, for a number of reasons. 1) Many (I believe most) programs shipped in Debian which invoke an editor implement the environment variable check and fallback directly, rather than using sensible-editor. 2) If the system administrator has selected a system-wide alternative which their users will find more friendly than nano, select-editor ends up making their lives worse. 3) If the user selects an editor via select-editor which is later removed (eg a versioned emacs), things go badly (see #753670). Of these I think the first is the most serious. The effect is that users see inconsistent behaviour depending which program is launching an editor. They can think they've told the system their preferred editor once, then find it's not used later. Or they can find they normally get an editor they're comfortable with, then on one occasion be presented with a list of unfamiliar names and end up with nano. I asked about this on Debian policy (#890946), and received the response that sensible-editor wasn't intended as a point where enhancements could be made, and a recommendation that #482774 should be reverted so that programs which use sensible-editor conform to policy.
