Bug 34293

Summary: Сделать vim редактором по умолчанию вместо vi
Product: Sisyphus Reporter: Vitaly Lipatov <lav>
Component: vim-consoleAssignee: Gleb F-Malinovskiy <glebfm>
Status: CLOSED NOTABUG QA Contact: qa-sisyphus
Severity: normal    
Priority: P3 CC: admsasha, glebfm, ldv, mike, rider
Version: unstable   
Hardware: all   
OS: Linux   
Bug Depends on:    
Bug Blocks: 17656, 33360, 33697, 34231, 33359    

Description Vitaly Lipatov 2017-12-07 14:47:24 MSK
Предлагаю сделать так, чтобы во всех неаварийных случаях программы, вызывающие дефолтный редактор, не вызывали vi, который у нас в пакете vim-minimal, а вызвали vim, или другой редактор, назначенный на системном или пользовательском уровне в качестве дефолтного.

Кстати, необходимость отдельного урезанного vi держится на рассказах о мифических авариях, при которых не смонтирован /usr, но посмотрите уже на  Fedora, где /bin — это ссылка на /usr/bin.

По поводу неудобства vi в качестве дефолта уже насоздавали кучу багов, наболтали кучу текста, а толку — ноль.

Давайте уже либо призна́ем, что /bin/vi — это де-факто ссылка на дефолтный редактор, либо продолжим это отрицать и обозначим настройку (задание EDITOR) на системном и пользовательском уровне в виде дистрибутивного решения.

По мне так, если кто-то оказывается в аварийной ситуации, пусть использует ed. Когда-то я в строчном редакторе писал программы на тысячи строк — ничего, вполне себе. Даже не думал, что возможно по-другому.
Comment 1 Michael Shigorin 2017-12-13 05:20:04 MSK
(В ответ на комментарий №0)
> Кстати, необходимость отдельного урезанного vi держится на рассказах о
> мифических авариях, при которых не смонтирован /usr, но посмотрите уже на 
> Fedora, где /bin — это ссылка на /usr/bin.
Если у кого-то руки из жопы (а весь usrmove вызван, помимо прочего, желанием замести под коврик проблемы с линковкой через границу /usr вместо исправления реальных багов) -- вряд ли именно в этом на них стоит ориентироваться.

А применимость vi(1) после неисправимого улучшения vim-minimal (см. bug 33299) и впрямь под большим вопросом, давать такое пользователям как $EDITOR я бы не стал (в отличие от vim).
Comment 2 Anton Farygin 2017-12-13 06:54:50 MSK
Улучшение то поправимо, в том то и смех
Comment 3 Dmitry V. Levin 2018-09-05 11:55:36 MSK
Правильная программа, которой нужно запустить редактор для редактирования временных файлов, выбирает редактор в следующем порядке:
1. $VISUAL
2. $EDITOR
3. vitmp(1)

Ни vi, ни vim в этом списке нет.
vitmp(1) запускает /bin/vi
Comment 4 Vitaly Lipatov 2020-10-08 15:22:47 MSK
(Ответ для Dmitry V. Levin на комментарий #3)
> Правильная программа, которой нужно запустить редактор для редактирования
> временных файлов, выбирает редактор в следующем порядке:
> 1. $VISUAL
> 2. $EDITOR
> 3. vitmp(1)
...
Получается, бага висит не на той компоненте. Тогда нужно переместиться в сторону пакетов или дистрибутивов, задающих эти переменные.
Comment 5 Anton Farygin 2020-10-08 15:24:16 MSK
мне, например, больше нравится идея превратить vi в что-то более юзабельное чем есть сейчаc.
Comment 6 Michael Shigorin 2020-10-08 17:28:45 MSK
(Ответ для Vitaly Lipatov на комментарий #4)
> (Ответ для Dmitry V. Levin на комментарий #3)
> > Правильная программа, которой нужно запустить редактор для редактирования
> > временных файлов, выбирает редактор в следующем порядке:
> > 1. $VISUAL
> > 2. $EDITOR
> > 3. vitmp(1)
> Получается, бага висит не на той компоненте. Тогда нужно переместиться
> в сторону пакетов или дистрибутивов, задающих эти переменные.
Да, VISUAL можно было бы и выставлять (slave alternatives на profiles.d-файл или хотя бы просто "кто встал, того и тапки").

(Ответ для Anton Farygin на комментарий #5)
> мне, например, больше нравится идея превратить vi в что-то более юзабельное
> чем есть сейчаc.
Да, всё-таки "в борьбе за мир" нашим vi(1) в последние годы стало крайне неудобно пользоваться в тех случаях (новый хост/чрут, включая hasher chroot), когда ничего больше по умолчанию не завезли либо вызывается именно /bin/vi в итоге.

2 lav: может не только не быть /usr (это сейчас и впрямь редкость), а и быть повреждено его содержимое -- "бомбе" легче попасть в большой раздел, чем в маленький, и повреждение _каталога_ /usr/lib64 в таком разе лишит сразу и аварийного редактора.  Но при этом действительно стоит соразмерять возможность аварии и плату за подстраховку в повседневной деятельности, как мне кажется.
Comment 7 Vitaly Lipatov 2020-10-08 18:36:03 MSK
(Ответ для Michael Shigorin на комментарий #6)
> (Ответ для Vitaly Lipatov на комментарий #4)
> > (Ответ для Dmitry V. Levin на комментарий #3)
> > > Правильная программа, которой нужно запустить редактор для редактирования
> > > временных файлов, выбирает редактор в следующем порядке:
> > > 1. $VISUAL
> > > 2. $EDITOR
> > > 3. vitmp(1)
> > Получается, бага висит не на той компоненте. Тогда нужно переместиться
> > в сторону пакетов или дистрибутивов, задающих эти переменные.
> Да, VISUAL можно было бы и выставлять (slave alternatives на profiles.d-файл
> или хотя бы просто "кто встал, того и тапки").

Обнаружил пакет nano-editor с единственным файлом
$ cat /etc/profile.d/nano-editor.sh
#!/bin/sh

[ -n "$EDITOR" ]  || export EDITOR="nano"

То есть вот уже такой шаг был:
* Ср июл 26 2017 Sergey V Turchin <zerg@altlinux.org> 0.1-alt1
- initial build

 
> (Ответ для Anton Farygin на комментарий #5)
...
> 2 lav: может не только не быть /usr (это сейчас и впрямь редкость), а и быть
> повреждено его содержимое -- "бомбе" легче попасть в большой раздел, чем в
> маленький, и повреждение _каталога_ /usr/lib64 в таком разе лишит сразу и
> аварийного редактора.  Но при этом действительно стоит соразмерять
> возможность аварии и плату за подстраховку в повседневной деятельности, как
> мне кажется.
С аварийным vi всё понятно, пусть будет всегда.

Речь о том, что VISUAL должна указывать на вменяемый редактор.
Мне кажется, было бы правильным управлять этим через control, а не установкой пакетов/альтернативами.
При этом варианты для выбора control бы нам показывал исходя из доступных команд.

Поскольку у меня уже есть control-umask, могу сделать control-editor.
Comment 8 Vitaly Lipatov 2023-05-14 15:35:00 MSK
(Ответ для Vitaly Lipatov на комментарий #7)
...
> Обнаружил пакет nano-editor с единственным файлом
> $ cat /etc/profile.d/nano-editor.sh
> #!/bin/sh
> 
> [ -n "$EDITOR" ]  || export EDITOR="nano"
> 
> То есть вот уже такой шаг был:
> * Ср июл 26 2017 Sergey V Turchin <zerg@altlinux.org> 0.1-alt1
> - initial build
> 
Случайно открыл для себя

 $ rpm -q --changelog mcedit-editor
* Чт янв 21 2021 Sergey V Turchin <zerg@altlinux.org> 0.2-alt1
- fix editor program

* Ср дек 16 2020 Sergey V Turchin <zerg@altlinux.org> 0.1-alt1
- initial build


 $ rpm -ql mcedit-editor
/etc/profile.d/mcedit-editor.csh
/etc/profile.d/mcedit-editor.sh

$ cat /etc/profile.d/mcedit-editor.sh

export EDITOR="mcedit"
Comment 9 Vitaly Lipatov 2023-05-14 15:36:51 MSK
(Ответ для Michael Shigorin на комментарий #6)
...
> 2 lav: может не только не быть /usr (это сейчас и впрямь редкость), а и быть
> повреждено его содержимое -- "бомбе" легче попасть в большой раздел, чем в
> маленький, и повреждение _каталога_ /usr/lib64 в таком разе лишит сразу и
> аварийного редактора.  Но при этом действительно стоит соразмерять
> возможность аварии и плату за подстраховку в повседневной деятельности, как
> мне кажется.
Да, вот прямо открытым текстом и написано, что есть аварийные случаи, для которых некий vi должен _присутствовать_ в системе и есть повседневная работа, в которой никакой аварийный редактор не сдался.
И всё, что мы обсуждаем, это ручки для управления и дистрибутивные умолчания.