Подскажите текстовый редактор под онтопик, который умеет открывать текстовые файлы...

вопрос только в том, что он всё грузит в память. несколько гигов откроет, а вот чуть больше — уже нет.

И 100 гигов откроет. Смотря сколько у тебя памяти. Вот gedit, например, вообще не откроет.

P.S. А что у тебя за файлы по несколько гигов? Надо ли файлы редактировать или хватит только чтения? Если надо только читать, и это логи, то настрой правильно ротацию, и используй архивацию. Так из 10 гигового лога у тебя получится всего 300 мегабайт, а читать/обрабатывать его можно zcat, zless, zgrep

он называется LargeFile и не работает, если мы говорим о файлах более 4-5 гигов.

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

ясно, спасибо

Смотря сколько у тебя памяти

в самом лучшем случае 8, а если это чей-то ещё рабочий комп, то и вовсе 2-4. это быдлокод, в любом случае, поэтому я рассматриваю такой вариант как «не открывает».

Надо ли файлы редактировать или хватит только чтения?

редактировать тоже иногда надо, хотя не шибко активно

логично. и вот что-что, а отмена действий на 10-гиговых файлах уже и совсем не критична. могли бы и остальные также поступить.

64-битная система - это не только поддержка > 3 Гб оперативы, это ещё и дополнительные инструкции в процессоре, дополнительные оптимизации по работе с 64-разрядными числами и прочее. Глянь бенчмарки по gcc.

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

Он убирает подсветку, матчинг скобок, историю отмен и еще по мелочи. Становится возможным «комфортно» редактировать 2Gb, но дальше все равно упячка.

До меня все-таки не доходит, на кой черт кому-то может понадобиться в текстовом редакторе гигабайтные логи открывать и править!

Кстати, механизм вставки нового текста внутрь гигантского файла потребует как минимум весь хвост после места вставки заново перезаписать!

Так что, для таких извращенцев таки нужен патч модуля файловой системы!!! Или вообще новую ФС сделать, где будет не таблица инодов, а связный список. В итоге ты запросто сможешь воткнуть дополнительный блок куда угодно внутри файла и добавить туда текста. Правда, это приведет к появлению дофигища частично заполненных блоков → нужно будет периодически "дефрагментацию" проводить.

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

Кстати, механизм вставки нового текста внутрь гигантского файла потребует как минимум весь хвост после места вставки заново перезаписать!

это да, поэтому редактировать такое надо аккуратно)

less, nano, sed

Подправить в бинарнике информацию надо только в случае говномастдайки, чтобы "кряк" накатить!

А логи надо править sed'ом.

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

Почти любой hex редактор может работать с гигантскими файлами. hed, hexedit, …

более того, на самом деле, эта фича отсутствие такого бага вообще всем нужно. потому, что никому не интересно ждать, пока редактор будет открывать какой-нибудь простейший текстовый файл, весом, пускай в несколько мегабайт.

хорошо, если файл на ссд, а если он на флешке, да ещё на богомерзкой фат32, или, того хуже, нтфс? тогда, с таким тупым подходом, редактор будет пару секунд тупить уже не а логах, а на самом обыкновенном худлите, например. собственно, тот же емакс и тупит в такой ситуации. да он даже на ссд подтупливает на файлах чуть больше мегабайта.

но ими неудобно пользоваться, когда именно текст нужно подредактировать

Подправить в бинарнике информацию надо только в случае говномастдайки, чтобы «кряк» накатить!

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

но ими неудобно пользоваться,

В hed даже вставка есть) И уж точно удобнее чем ed/ex xD. К слову, последние тоже пытаются прочесть файл до конца.

sed, awk, perl

вот эти открывают. и плагинов не счесть.

И бОльшее потребление памяти, что для одногиговой машины куда важнее.

Это миф. Я не заметил значимого увеличения потребления памяти после перехода с 32-битной на 64-битную архитектуру!

Можно вместо np++ попробовать scite

У меня 16 Гб опреративной памяти ;)

Не хочешь грузить в память - грепай поток.

С уважением, всегда твой Капитан.

Эдди не котирует юникод

юникод это тоже миф, т.к. Эдик до смерти гордиться тем что выучил кои8 наизусть

Я не заметил

Крутейший и объективнейший бенчмарк, базара ноль.

Если бы потребление оперативы в 2 раза возросло, это было бы невооруженным глазом заметно!

Юникод нужен внутри pdf, но никак не в исходниках!

ed уже предлагали?

P.S. Ты что-то делаешь неправильно.

ed уже предлагали?

Да, ed уже обосрался. qulinxao

факт, обосрался.

scite /thread
Главное открывать в режиме текста без подсветки.

sam -d по определению не имеет захаркоженных ограничений в отличии от ed который делался 80% сейчас лучше чем 96% без сейчас.

http://en.wikipedia.org/wiki/Sam_(text_editor)#Endorsers

~полсектора из различных 0x08 0x7F ?

swap двух файлов без занятия дополнительного места

mv занимает дополнительное место?

Итак, дано: два файла офигенного размера (значительно больше свободного места на разделе); один на одном разделе, другой — на другом. Тебе надо поменять их местами. Твои действия?

// вот тот велосипед и был ответом на такой вопрос

http://swtch.com/usr/local/plan9/src/cmd/sam/README

плюсую ed.

А, на разных разделах! Всё, вопрос снимается.

Какой-то неправильный, видать, порт.

~$ sam -d lvwiki-20141213-pages-meta-history.xml
 -. lvwiki-20141213-pages-meta-history.xml
?temporary file too large
^C

Подскажите текстовый редактор под онтопик, который умеет открывать текстовые файлы... (комментарий)

хм.

экскалируем не заглядывая в сорцы:

acme

?

ed

кстати, недавно узнал, что означает grep (этимология): g/re/p (globally search a regular expression and print), впервые появившись в ed, перешло в ex, консольную команду, оттуда уже в vi, ну и в vim, в отличие от консольной команды в виме это явно:

:g/re/p

имхо ed должен справляться.
А вообще присоединяют к мнению большинства, я как-то слабо представляю для чего это может понадобиться… при условии что тот же sed не устраивает

иногда в бинарнике есть текстовая информация и её надо слегка подправить ручками.

Для это hexeditor'ы есть.

+1
Я о том что grep - это от команы ed g/re/p узнал изучая документацию по sed

в отличии от ed который делался 80% сейчас лучше чем 96% без сейчас.

Сейчас попробую напиться. Может тогда станет понятнее.