Здравствуйте, vsb, Вы писали:

А мне FAR'а хватает на все случаи жизни. Ну, еще иногда Notepad++ использую; вижуалку, идею, кейл — для сборки и небольших фиксиков

Здравствуйте, Marty, Вы писали:

M>Здравствуйте, Lazytech, Вы писали:


L>>Смутно подозреваю, что вряд ли какие-то методы оптимизации доступа позволят быстро найти нужный фрагмент кода в файле размером даже 10 ГБ, не говоря уже о 200 ГБ. Разве что файл будет предварительно индексирован, но индексировать файл размером 200 ГБ...

M>Исходник на 10 Гб, не говоря уж о 200? И всё небось в main запихано

Нет, это реализация преобразования чисел в строку методом огромного switch 200гб, потом автора увезли

Здравствуйте, Marty, Вы писали:

M>А как быть с прокруткой? Во всех известных программах она имеет размер, пропорциональный количеству строк.

Прокручивать пропорционально размеру файла и текущего отступа.

M>Т.е. по любому весь файл просканировать надо. Ну и таких функции, как "перейти к строке N" без этого не реализовать

Это понятно. Но вряд ли оно понадобится.

Здравствуйте, swame, Вы писали:

S>6 пункт вообще бредовый.
S>Как программа узнает, нужны ли сделанные изменения

Все изменения нужны, пока я не сказал обратного.

S>и как решит, когда можно удалить свои временные данные.

Когда я закрою таб с редактируемым файлом и скажу "не сохранять" (или "сохранить").

S>А при повторном открытии будет вопрос — открывать фал что лежит, или рабочую копию.

Рабочую копию, конечно.

Здравствуйте, vsb, Вы писали:

vsb>Не очень понимаю, откуда какие-то ограничения могут быть. Редактор или использует алгоритмы и структуры данных для того, чтобы считывать и показывать видимую часть файла, или грузит файл в память. В первом случае ограничения могут быть только от 2^63, что явно больше любых разумных размеров. Во втором случае всё понятно, максимальный размер в районе установленной оперативной памяти (а то и кратно меньше, если не использовать UTF-8 внутри).

Вот именно. У тебя есть 200 Гб ОП ?

Здравствуйте, CaptainFlint, Вы писали:

CF>Кстати, можно. Everything каким-то образом умеет мгновенно искать по своей базе даже с регулярками. Хотя как он это делает, представления не имею…

https://en.wikipedia.org/wiki/Everything_(software)

Everything is a desktop search utility for Windows that can rapidly find files and folders by name.

Если так искать, то файлы могут быть хоть 200-терабайтными. Даже так: будет лучше, если файлы будут огроменного размера, потому что так их будет меньше.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вот именно. У тебя есть 200 Гб ОП ?

Если я правильно понял, без индексации никак, причем файл индексов, возможно, тоже будет нехилого размера.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, swame, Вы писали:

S>>6 пункт вообще бредовый.
S>>Как программа узнает, нужны ли сделанные изменения

vsb>Все изменения нужны, пока я не сказал обратного.

S>>и как решит, когда можно удалить свои временные данные.

vsb>Когда я закрою таб с редактируемым файлом и скажу "не сохранять" (или "сохранить").

Так что тогда экономится?

S>>А при повторном открытии будет вопрос — открывать фал что лежит, или рабочую копию.

vsb>Рабочую копию, конечно.

Т.е. открываем один и тот же файл на диске одной программой (этой, знающей про копии) содержимое одно,
открываем другой — содержимое другое. Пользователи будут в восторге.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Впрочем, 200 Гб и впрямь слишком много. Для ultraedit

vsb>Не очень понимаю, откуда какие-то ограничения могут быть. Редактор или использует алгоритмы и структуры данных для того, чтобы считывать и показывать видимую часть файла, или грузит файл в память. В первом случае ограничения могут быть только от 2^63, что явно больше любых разумных размеров. Во втором случае всё понятно, максимальный размер в районе установленной оперативной памяти (а то и кратно меньше, если не использовать UTF-8 внутри).

Чуть выше по треду писали о сохранении изменений Простой текстовый редактор для огромных файлов

Здравствуйте, swame, Вы писали:

S>>>6 пункт вообще бредовый.
S>>>Как программа узнает, нужны ли сделанные изменения

vsb>>Все изменения нужны, пока я не сказал обратного.

S>>>и как решит, когда можно удалить свои временные данные.

vsb>>Когда я закрою таб с редактируемым файлом и скажу "не сохранять" (или "сохранить").

S>Так что тогда экономится?

Экономится моя ментальная энергия. Мне не нужно отвечать на вопросы "сохранять", "не сохранять", "где сохранять" в тот момент, когда я про это не хочу думать.

S>>>А при повторном открытии будет вопрос — открывать фал что лежит, или рабочую копию.

vsb>>Рабочую копию, конечно.

S>Т.е. открываем один и тот же файл на диске одной программой (этой, знающей про копии) содержимое одно,
S>открываем другой — содержимое другое. Пользователи будут в восторге.

Конечно пользователи будут в восторге. Они же не идиоты. Попробуй vim-ом воспользоваться когда-нибудь. Если он грохнулся, то в папке остаётся файл автосохранения. И при открытии в следующий раз он откроет файл с несохранёнными изменениями. То же самое с вордом. И, я думаю, с абсолютно любой адекватной программой. Я просто хочу сделать следующий шаг и применять этот режим не только при аварийном завершении программы, но вообще при любом завершении программы.

Здравствуйте, a7d3, Вы писали:

A>Чуть выше по треду писали о сохранении изменений Простой текстовый редактор для огромных файлов

Не понимаю проблему. Ну да, если я удалил один символ в начале файла, при сохранении надо его переписать полностью. Меня это устраивает. Современный SSD пишет достаточно быстро линейные файлы, чтобы это не было проблемой.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, a7d3, Вы писали:

A>>Чуть выше по треду писали о сохранении изменений Простой текстовый редактор для огромных файлов

vsb>Не понимаю проблему. Ну да, если я удалил один символ в начале файла, при сохранении надо его переписать полностью. Меня это устраивает. Современный SSD пишет достаточно быстро линейные файлы, чтобы это не было проблемой.

Достаточно, но когда это десятки-сотни гигабайт, то скорость работы редактора не будет сопоставима с файлом в 200 байт.
А изменяемый файл приходится сохранять по несколько раз за одну сессию работы с ним. Не вводить же абстракцию «проект» на уровне текстового редактора, как в IDE.
И не будет никто учить текстовый редактор понимать нюансы файловой системы, на которой лежит файл, чтобы максимально эффективно выполнять операции изменения в больших файлах.

Здравствуйте, a7d3, Вы писали:

A>Достаточно, но когда это десятки-сотни гигабайт, то скорость работы редактора не будет сопоставима с файлом в 200 байт.

Большие файлы я обычно смотрю. Возможность редактирования нужна больше гипотетически. Чтобы если нужно — то можно было сделать. Но нужно редко.

A>А изменяемый файл приходится сохранять по несколько раз за одну сессию работы с ним.

Зачем? Сделал все изменения, сохранил, пошёл домой.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, a7d3, Вы писали:

A>>Достаточно, но когда это десятки-сотни гигабайт, то скорость работы редактора не будет сопоставима с файлом в 200 байт.

vsb>Большие файлы я обычно смотрю. Возможность редактирования нужна больше гипотетически. Чтобы если нужно — то можно было сделать. Но нужно редко.

Потому люди и придумали Agile, что пользователи вечно неспособны выкатить детализированные и конкретные требования.


A>>А изменяемый файл приходится сохранять по несколько раз за одну сессию работы с ним.

vsb>Зачем? Сделал все изменения, сохранил, пошёл домой.

Потому что случаются отказы оборудования, электросетей и — журнал транзакций есть лишь в СУБД и является экзотикой в мире текстовых редакторов.
Взаимодействовать с журналом транзакций файловой системы текстовые редакторы тоже не умеют.

vsb>Современный SSD пишет достаточно быстро линейные файлы, чтобы это не было проблемой.

Если не секрет, а зачем вы редактируете логи (просто интересно)? Вообще, такой редактор будет в любом случае "задумчивым". Если положить среднюю скорость SSD за 1-2Гб/сек, то на сохранение 200Гб файла будет уходить более 3-х минут. На HDD сохранение будет занимать около 20 минут.

Здравствуйте, a7d3, Вы писали:

A>Достаточно, но когда это десятки-сотни гигабайт, то скорость работы редактора не будет сопоставима с файлом в 200 байт.
A>А изменяемый файл приходится сохранять по несколько раз за одну сессию работы с ним. Не вводить же абстракцию «проект» на уровне текстового редактора, как в IDE.
A>И не будет никто учить текстовый редактор понимать нюансы файловой системы, на которой лежит файл, чтобы максимально эффективно выполнять операции изменения в больших файлах.

А если не перезаписывать весь файл при сохранении в процессе работы?

Залочить файл.
При сохранении в процессе работы, сохранять только разницу с исходным.
При выходе из редактора, сохранять полностью, удалять файлы, в которых записаны изменения и разблокировать файл.

Здравствуйте, Максим, Вы писали:

vsb>>Современный SSD пишет достаточно быстро линейные файлы, чтобы это не было проблемой.

М>Если не секрет, а зачем вы редактируете логи (просто интересно)?

Ну мало ли, возможность такую иметь нужно, даже если она применяется редко. Не обязательно логи, любой файл. Например образ файловой системы и тд.

M>Вообще, такой редактор будет в любом случае "задумчивым". Если положить среднюю скорость SSD за 1-2Гб/сек, то на сохранение 200Гб файла будет уходить более 3-х минут. На HDD сохранение будет занимать около 20 минут.

Ну и ладно, это ерунда.

Здравствуйте, Lazytech, Вы писали:

L>

Everything is a desktop search utility for Windows that can rapidly find files and folders by name.

L>Если так искать, то файлы могут быть хоть 200-терабайтными. Даже так: будет лучше, если файлы будут огроменного размера, потому что так их будет меньше.

Я о том, что из базы с несколькими миллионами записей (имён) он практически мгновенно делает выборку по поисковому запросу, являющемуся регулярным выражением.

Здравствуйте, AleksandrN, Вы писали:

AN>А если не перезаписывать весь файл при сохранении в процессе работы?

AN>Залочить файл.
Нельзя, это может быть файл открытый другим процессом для дописывания в него данных. Например, логи сервисов/демонов.

Вносить изменения придётся во временную копию файла, зафиксировав текущее состояние оригинала.
Если за время работы с копией оригинал не изменился, то менять местами изменённую копию с оригиналом.
На файлах размером в 200Гб это всё очень небыстро.

Здравствуйте, Lazytech, Вы писали:

L>Если я правильно понял, без индексации никак, причем файл индексов, возможно, тоже будет нехилого размера.

Редактирование бинарного файла без вставок и удалений можно делать хоть на терабайтных файлах. Просто маппируем куски файла, которые сейчас редактируем. Поскольку юзер переключается между кускамисо скоростью, заметно меньшей скорости работы диска , проблем не будет.

А вот для текстовых файлов сложнее. Там вставки (и удаления) — это скорее правило, чем исключение. Поэтому редактор должен как-то хранить измененные куски (это еще не проблема), а потом слить их в исходный файл. А вот это как он делает — я не знаю, но это не просто.