LINUX.ORG.RU

А нормальные текстовые редакторы вообще бывают?

 


0

1

1) Чтобы в нем можно было редактировать файл, содержащий строки в несколько мегабайт длиной.

2) Бинарный

3) Длиной в несколько гигабайт.

4) Без тормозов.

К сожалению, всякие vi и emacs даже крашатся от таких испытаний или . Многие сразу не умеют п.1. Самый адекватный - это kate. Умеет 1-3, но совершенно невозможно минутами тормозит, даже если есть всего пара-тройка мегабайтных строчек.

Типичный сценарий, когда это нужно (за искл. п.2 пожалуй) - редактирование xml-файлов, генерируемых разными доморощеными и не совсем системами.

Нашел, что пункт 1 и 4 пока что решается xedit. Хотя глючноватый, нажатие клавиши End приводит к крашу с сообщением

X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  74 (X_PolyText8)
  Serial number of failed request:  2800
  Current serial number in output stream:  2800

Перемещено leave из talks

★★★★★

Последнее исправление: praseodim (всего исправлений: 2)

Таки vi (не vim) — размер редактируемого файла зависит только от кол-ва места в /tmp (или /var/tmp).

Для пунтка 2 — bvi.

Оба быстрые.

beastie ★★★★★
()

Прорубите на строки по символу '>', после редактирования соберите обратно.

bormant ★★★★★
()
Ответ на: комментарий от beastie

Что-то нормального редактирования таких файлов c vi толком не получается.

praseodim ★★★★★
() автор топика

Vim прекрасно с этим справляется, даже на мобильнике

upcFrost ★★★★★
()

1) Чтобы в нем можно было редактировать файл, содержащий строки в несколько мегабайт длиной.

Галоперидол неплохо решает эти проблемы. Но ты скинь файлы для теста.

Inshallah
()

Чтобы в нем можно было редактировать файл, содержащий строки в несколько мегабайт длиной.

Acme/Sam

Бинарный

Acme/Sam

Длиной в несколько гигабайт.

Acme/Sam

Без тормозов.

Acme/Sam

awesomebuntu
()

Чтобы в нем можно было редактировать файл, содержащий строки в несколько мегабайт длиной.
Длиной в несколько гигабайт.
Без тормозов.

зачем такое делать? понятное дело, что нормальные (99.(9)%) таким не занимаются, соответственно инструмент им тоже для этого в виде «текстового редактора» не нужен

umren ★★★★★
()
Ответ на: комментарий от Inshallah

Галоперидол неплохо решает эти проблемы.

А еще разрушает канал связи с космосом, убивает Бога, выводит пришельцев, блокирует чакры и закрывает третий глаз)

Meyer ★★★★★
()

Тоже страдал от этого. Kate кстати тоже очень большие файлы не осиливал, хотя если выключить подсветку то было лучше. А вот notepad++ даже в вайне справлялся гораздо лучше.

Ya_gnu_linux
()
Ответ на: комментарий от Valman_new

gedit - глюкалово на больших файлах, неправильно отображает строки. Да и вообще не лучше.

praseodim ★★★★★
() автор топика
Ответ на: комментарий от Ya_gnu_linux

Во-во, мне как раз такие xml надо редактировать.

Нашел, что пункт 1 и 4 пока что решается xedit. Хотя глючноватый, нажатие клавиши End приводит к крашу с сообщением

X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  74 (X_PolyText8)
  Serial number of failed request:  2800
  Current serial number in output stream:  2800
praseodim ★★★★★
() автор топика
Ответ на: комментарий от Inshallah

Галоперидол неплохо решает эти проблемы. Но ты скинь файлы для теста.

Не уверен, что могу свободно раздавать эти xml.

praseodim ★★★★★
() автор топика
Ответ на: комментарий от praseodim

xml
мегабайты

Я правильно понимаю что ты пытаешься текстовым редактором открыть импровизированную БД?

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

Inshallah
()
Ответ на: комментарий от Inshallah

Я правильно понимаю что ты пытаешься текстовым редактором открыть импровизированную БД?

А чем еще открывать невалидный xml-файл для приведения его в порядок? В редакторе и итерации с xmllint. Отредактировал, запустил, нашел где сбой, снова отредактировал и т.д. пока валидацию не пройдет. Я ничего не могу сделать с тем, что выгружает такой xml. Автоматически править тоже не очень получается.

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от praseodim

чё не подходит? разбивать-то можно не по строкам, а по буковкам, если уж строки длинные
Ну ещё попробуй в емаксе vlf.el(хотя вряд ли это поможет)

Bad_ptr ★★★★★
()
Ответ на: комментарий от Bad_ptr

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

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от alex4321

Что же в этом годного?

Возможность редактировать бинарные файлы без компуктера < всех побочек.

energetix_user ★★
()

[мимокрокодил]

А нормальные текстовые редакторы вообще бывают?

Зависит от твоего определения «нормальный»

1) Чтобы в нем можно было редактировать файл, содержащий строки в несколько мегабайт длиной.

Это довольно маргинальное требование, чтоб применить эпитет «нормальный» без специализации «нормльный для редактирования очень длинных строк»

3) Длиной в несколько гигабайт.

То же. Среднестатистические редакторы по просту не рассчитаны на такое.
[/мимокрокодил]

А если по теме: vi или nano.

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 2)
Ответ на: комментарий от Ya_gnu_linux

1) Чтобы в нем можно было редактировать файл, содержащий строки в несколько мегабайт длиной.

2) Бинарный

3) Длиной в несколько гигабайт.

гигабайтный json или xml почитать или отредактировать может приспичить, сталкивался.

Тебе ненормальный редактор нужен - не вводи в заблуждение местных своим заголовком.

А можно ради любопытства поинтересоваться - в какой области ты работаешь где сталкиваешься вот с этим:

гигабайтный json или xml почитать или отредактировать может приспичить, сталкивался.

?

ados ★★★★★
()

А нормальные текстовые редакторы вообще бывают?
1) Чтобы в нем можно было редактировать файл, содержащий строки в несколько мегабайт длиной.
2) Бинарный
3) Длиной в несколько гигабайт.

Зачем тебе редактор длиной в несколько гигабайт?

sudopacman ★★★★★
()

2) Бинарный

Нео, ты?

urxvt ★★★★★
()
Ответ на: комментарий от Ya_gnu_linux

Ну блин мало ли, гигабайтный json или xml почитать или отредактировать

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

SR_team ★★★★★
()

Попробуй

vim {путь файла} -u NONE -b -c "noswapfile"

Если не поможет - попробуй vis

StillSteal
()
Последнее исправление: StillSteal (всего исправлений: 2)
Ответ на: комментарий от ados

Тебе ненормальный редактор нужен - не вводи в заблуждение местных своим заголовком.

Про гигабайт я сильно преувеличил, большинство редакторов тупят и на 20МБ с подсветкой синтаксиса. Без неё чуть легче, да. Очевидно там просто неоптимизированный говнокод, в венде так тупит «блокнот» например. Но почему-то в вайне Notepad++ гоараздо лучше работает чем нативные редакторы.

А можно ради любопытства поинтересоваться - в какой области ты работаешь где сталкиваешься вот с этим:

А что, никогда не может понадобиться открыть большой дамп sql? Алсо такие дампы бывают в формате xml и json, например джанговский орм умеет экспортировать в эти форматы, так можно переносить данные например с sqlite в mysql.

Ya_gnu_linux
()
Ответ на: комментарий от Ya_gnu_linux

Зачем открывать большой дамп в редакторе? Характер битости кодировки например достаточно выяснить с помощью more.

Если файл «битый» сам по себе, то вряд ли это две-три опечатки от набора текста вручную. На таких объемах ошибки программные, и исправляться должны программно.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Вообще это тема из разряда «всё вокруг гвоздь, если у меня в руке молоток». Так и тут, если привык начинать любую работу с файлом с открытия его в редакторе, то конечно сложно.

Но на самом деле полно утилит которые работают с файлами напрямую. И например чтобы посмотреть опции дампа достаточно head, чтобы заменить подстроку - sed, чтобы поправить символы конца строки - dos2unix, чтобы исправить кодировку - iconv.

И хороший редактор это конечно всё _тоже_ может, но это не его задача.

alpha ★★★★★
()
Ответ на: комментарий от alpha

чтобы заменить подстроку - sed

Только перед этим ещё надо выяснить что конкретно менять и на что. Без чтения файла всё равно не обойтись.

Если файл «битый» сам по себе, то вряд ли это две-три опечатки от набора текста вручную. На таких объемах ошибки программные, и исправляться должны программно.

Да блин задачи могут возникнуть разные, не предусмотренные всякими узкоспециализированными утилитами типа sed. Может понадобиться тупо почитать старый бекап в поисках какой нибудь старой информации. Или например произвести непростую правку запроса в большом sql файле прежде чем он будет отправлен в БД. Даже прежде чем править его всякими sed, файл надо изучить. Да даже если и правка не требуется, бывает нужно просто изучить файл, интерактивно производя поиск по нему (ctrl+f или / в less). Ну в этом случае приходится less использовать, хотя в полноценном редакторе было бы удобнее.

Ya_gnu_linux
()
Ответ на: комментарий от Ya_gnu_linux

А что, никогда не может понадобиться открыть большой дамп sql?

Зачем редактировать данные через экспорт в pure текстовый дамп? Почему нельзя для этого взять более оптимизированную под это копию db?

Алсо такие дампы бывают в формате xml и json, например джанговский орм умеет экспортировать в эти форматы, так можно переносить данные например с sqlite в mysql.

Так переноси - зачем тебе текстовый редактор?

ados ★★★★★
()
Ответ на: комментарий от Ya_gnu_linux

Про гигабайт я сильно преувеличил, большинство редакторов тупят и на 20МБ с подсветкой синтаксиса.

Понимаешь нормальные текстовые редакторы созданы для создания и редактирования текста который может читать человек. 20M - это не для человека.

ados ★★★★★
()
Ответ на: комментарий от ados

Зачем редактировать данные через экспорт в pure текстовый дамп?

А кто сказал что экспорт делался именно ради этого?

Почему нельзя для этого взять более оптимизированную под это копию db?

Делать лишнюю работу только потому что качество реализации большинства текстовых редакторов очень низкое?

Так переноси - зачем тебе текстовый редактор?

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

Ya_gnu_linux
()
Ответ на: комментарий от ados

Понимаешь нормальные текстовые редакторы созданы для создания и редактирования текста который может читать человек. 20M - это не для человека.

Смешно. Исходный код не для людей, его не надо читать, он для компиляторов. Вселенная не для людей, её не надо изучать, выкиньте свои телескопы.

Ya_gnu_linux
()
Ответ на: комментарий от Ya_gnu_linux

Исходный код не для людей, его не надо читать, он для компиляторов.

Не знаешь что такое поддержка кода? И ты смеешь при этом судить о качестве кода?

ados ★★★★★
()
Ответ на: комментарий от Ya_gnu_linux

Ты знаешь - я понял твой диагноз. Поизучай как-нибудь написание скриптов на каком-нибудь python или ruby. Полезно будет на твоей работе. А заодно возможно придёт понимание куда лучше направить усилия свободного программиста.

ados ★★★★★
()
Ответ на: комментарий от Ya_gnu_linux

Делать лишнюю работу только потому что качество реализации большинства текстовых редакторов очень низкое?

Ага, а мало кому нужное оптимизирование кода - не лишняя работа? Давай тогда дерзай!

ados ★★★★★
()
Ответ на: комментарий от ados

Ага, а мало кому нужное оптимизирование кода - не лишняя работа?

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

Ya_gnu_linux
()
Ответ на: комментарий от ados

Кстати, как ни странно, LibreOffice с большими текстовыми файлами тоже работает ничего. Ну по крайней мере не тормозит скроллинг, курсор двигается шустро, буквы набираются тоже шустро. Правда он под plain text не предназначен и не очень удобно в нём с ними работать, лучше уж Notepad++ в вайне.

Ya_gnu_linux
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.