#vim #emacs #editor
Вопрос:
Имеет ли смысл мой вопрос? Используя Vim или Emacs, вы начинаете понимать, что интерфейс предоставляет представление кода о состоянии файла, который вы редактируете в буфере, файл-это хранилище на диске, из которого вы можете заполнить буфер или записать буфер. Все эти вещи программист должен знать, но когда он просто редактирует текст, почему он открыт? Любой новый редактор просто скажет вам: «Вот файл. Отредактируйте его».
Да, я понимаю технические значения, но это не мой вопрос. Это вопрос даже не в том, хорошая это идея или нет. Vim и Emacs-два наших старейших редактора, которые сегодня широко используются, и они разделяют это поведение. Я не знаю ни одного нового редактора, который делал бы то же самое. Когда редакторы перестали это делать и почему?
Комментарии:
1. Я не понимаю вопроса. Я использую vim каждый день, но не вижу такого бизнеса с буферами. Как и в любом редакторе, то, что вы редактируете, не записывается в файл до тех пор, пока вы не сохраните.
2. Я тоже не понимаю вопроса. «Когда редакторы перестали это делать и почему?» Недавно, и потому что это проще. Какое это имеет значение? Какая у вас проблема? Чего ты не можешь сделать?
3. Я прочитал информативный ответ Какого-то Парня, и я использую vim каждый день, и я все еще не понимаю вопроса. Как они «выявляют разницу»? Поставив немного [ ] при изменении буфера?
4. Ну, есть меню «Буферы» и «Список M-x-буферов». Я полагаю, что более точным вопросом было бы «почему они не сделали все возможное, чтобы скрыть это» (на что я бы все равно дал тот же ответ).
5. Я знаю, что придираюсь (в основном это касается формулировки вопроса), но все текстовые редакторы различают то, что у вас есть, и то, что находится на диске. т. Е. вы должны явно сохранить свои изменения, и вы можете закрыть файл без сохранения изменений. Единственное приложение, которое я видел, которое этого не делает, — это Одна заметка, но в ней даже нет понятия «файл» (все это скрыто от пользователя).
Ответ №1:
Во-первых, Emacs использует множество буферов, которые не связаны ни с одним файлом. Каждый раз, когда вы открываете каталог, читаете свою почту, открываете терминал, компилируете программу, запускаете интерактивный сеанс Python или подключаетесь к базе данных, вы получаете буфер. Следовательно, основной единицей работы Emacs является буфер, а не файл, и та же логика применима и к Vim.
Новые приложения, которые редактируют только файлы, не делают различий, потому что каждый экран, окно или вкладка непосредственно представляют файл. Более мощные приложения, такие как Emacs и Vim, намного более гибки в этом отношении.
Комментарии:
1. Чтобы добавить к этому-и Emacs, и vim могут обрабатывать вещи, которые не являются файлами, но с которыми вы можете взаимодействовать так же, как и с ними. В vim вы можете изменить буфер на версию на диске, но это различие не является самим файлом. Большинство «современных» редакторов не могут делать такие вещи или создавать произвольные ограничения.
2. 1 к точке зрения Затруса. Возможность редактировать интерактивный сеанс с помощью вашего интерпретатора, командной строки, каталога (или чего-либо еще, если на то пошло) в виде текста чрезвычайно эффективна.
3. Особенно когда он использует те же нажатия клавиш, которые вы уже изучили для редактирования текста. Как только вы преуспеете в этом, вы сможете применять одни и те же навыки везде.
4. Чтобы добавить к этому, по крайней мере, в Emacs, у вас могут быть два буфера, которые содержат содержимое одного и того же файла (косвенные буферы). Тогда у вас могут быть разные основные режимы для каждого из буферов и, как я часто делаю, разное сужение для них. Это было бы невозможно, если бы файлы и буферы имели жестко закодированную переписку один на один.
Ответ №2:
Хорошо, вот мой странный философский ответ :
потому что поздняя привязка между буфером в редакторе и фактической конкретной вещью, над которой вы работаете, придает среде редактирования большую гибкость и мощь.
Думаешь, это устарело? Одно место, где идея возвращается с удвоенной силой,-это браузер, где у вас нет 1-1 соответствия между вкладками и веб-страницами. Вместо этого внутри каждой вкладки вы можете перемещаться вперед и назад между несколькими страницами. Никто не стал бы пытаться создать интерфейс типа MDI для Интернета, где у каждой страницы было свое собственное внутреннее окно. Это было бы невозможно неудобно использовать. Это просто не будет масштабироваться.
Лично я думаю, что IDE в наши дни становятся слишком сложными, и статическая привязка между документами и буферами является одной из причин этого. Я ожидаю, что в какой-то момент произойдет прорыв, когда они перейдут к браузерной модели буфера с вкладками, где :
а) вы сможете создавать гиперссылки между несколькими файлами в одном буфере/вкладке (и там будет кнопка «Назад» и т. Д.).
б) универсальные буферы смогут содержать любой тип данных : исходный код, командную строку, динамически создаваемый графический вывод, схему проекта и т.д.
Другими словами, большая часть модели Vim / Emacs, за исключением настройки, более соответствует открытиям, которые делают браузеры.
Ответ №3:
Потому что несколько буферов могут показывать вам разные представления одного и того же файла. Я не знаю других редакторов, но это верно для Emacs. И что именно вы имеете в виду под Старым?
Ответ №4:
Когда приложения начали активно использоваться не-гиками, которые не хотели утруждать себя несущественными деталями.
Ответ №5:
Я думаю, что новые редакторы перестали это делать по причинам, которые вы указали, что это абстракция, которая просто мешает. Кроме того, большинство современных редакторов имеют неограниченное количество отмен, поэтому идея «буфера» является своего рода неявной.
Комментарии:
1. Я думаю, вы неправильно понимаете слово «буфер».
2. Я также думаю, что вы переоцениваете «неограниченную» отмену других редакторов и недооцениваете «ограниченную» отмену Vim или Emacs.
Ответ №6:
Я думаю, что я просто старый дурак (в стойком лагере vim), но другие пакеты редактирования, которые я использую, такие как MS Word или Open Office, сохраняют различие между копией файла, который я редактирую, и последней сохраненной версией. Это совершенно бесценно-я не хочу, чтобы редактор топтал мою последнюю хорошую версию, пока я не буду готов к этому. Действительно, есть приличный шанс (скажем, один из тысячи), что я создам новый файл с буфером, в котором я редактирую.
С другой стороны, также полезна возможность создания образа файла путем чтения нескольких файлов (либо нескольких копий одного и того же файла, либо копий нескольких разных файлов). В других документах есть немного похожие объекты.
Итак, я, возможно, упускаю суть — я не знаю, каких редакторов вы имеете в виду, устраняя различие. Но я думаю, что все редакторы сохраняют различие между копией файла, который вы редактируете, и последней версией, сохраненной на диске.
Комментарии:
1. Они не устраняют это различие в точности. Они не просто сразу сбрасывают каждое нажатие клавиши на диск. Однако они не используют разные термины. Они ничего не называют «буфером», есть только сохраненные файлы и Несохраненные файлы.
Ответ №7:
Потому что разработчики этих редакторов не позаботились о том, чтобы скрыть детали реализации от пользователей.