fresh — редактор для терміналу в стилі VSCode

[Володимир Лісівка]

fresh — це редактор в стилі традиційних редакторів. Він схожий на VS Code, має меню, підтримує мишку, має вбудований файловий навігатор, термінал, калькулятор, підтримує сполучення клавіш в стилі VSCode та Emacs. Редактор швидкий, але їсть багато памʼяті, хоча підтримує відкриття навіть гігабайтних файлів.

Сайт: https://sinelaw.github.io/fresh/
Проєкт: https://github.com/sinelaw/fresh

[yvs115]

Трохи покритикую

Редактор швидкий, їсть мало памʼяті, та підтримує відкриття навіть гігабайтних файлів.

Перше що зразу кидається в очі - "гігабайтних файлів" - а чи комусь хоч коли-небудь знадобиться (чи взагалі бачив) гігабайтні файли з кодом такого розміру, та навіть просто текстові. І взагалі не дуже уявляю як будуть спрацьовувати парсери (lsp linters formaters etc.) навіть на значно менших об'ємах (хай в тисячі разів менші файли - мегабайти коду, що також під питанням чи зустрінуться десь в рамках одного файлу).

Потім релятивизм "швидкий, їсть мало" - у порівнянні з чим - редагування з *vi*, стрімінг з sed, чи ще з чимось малоресурсним? - принаймні без демонстрації того - є сумніви що то так, а не навпаки.

Якщо відкинути ці трохи незрозумілі характеристики "гіга-швидко-etc", візьмемо що може зацікавити: - з опису є що підтримується lsp (це якраз напевно одна з найважливіших фіч при роботі з кодом в редакторах). Але немає в опису для яких мов etc. існує відповідна підтримка. У порівнянні нп - відкрив зараз nvim - дивлюсь через Mason - available ~600 lsp/dap/linters/formatters, тобто практично все що хоч трохи відомо (треба shell чи systemd - є таке, треба щось не дуже розповсюджене з мов програмування нп odin-lang - також є, і т.д.).

[Володимир Лісівка]

Трохи покритикую

Редактор швидкий, їсть мало памʼяті, та підтримує відкриття навіть гігабайтних файлів.

Перше що зразу кидається в очі - "гігабайтних файлів" - а чи комусь хоч коли-небудь знадобиться (чи взагалі бачив) гігабайтні файли з кодом такого розміру, та навіть просто текстові. І взагалі не дуже уявляю як будуть спрацьовувати парсери (lsp linters formaters etc.) навіть на значно менших об'ємах (хай в тисячі разів менші файли - мегабайти коду, що також під питанням чи зустрінуться десь в рамках одного файлу).

Так, бувають гігабайтні текстові файли, наприклад логи.

Потім релятивизм "швидкий, їсть мало" - у порівнянні з чим - *vi*, sed? - принаймні без демонстрації того - є сумніви що то так, а не навпаки.

Поміряв споживання відкривши /var/log/messages на 41 тисячу рядків і прогортавши його в кінець під mate-terminal:

Програма	Памʼять	Процесор
fresh 0.1.67	320Мб	39% ЦП
vim-enhanced-9.1.1952	18 Мб	6% ЦП
codium-1.107.18627	98 Мб	104% ЦП

vim виграє по всіх параметрах (якщо не враховувати сам термінал, який його показує).

Якщо відкинути ці трохи незрозумілі характеристики "гіга-швидко-etc", візьмемо що може зацікавити: - з опису є що підтримується lsp (це якраз напевно одна з найважливіших фіч при роботі з кодом в редакторах). Але немає в опису для яких мов etc. існує відповідна підтримка.

rust, python, javascript, typescript, html, css, c, cpp, go, json, java, c-sharp, php, ruby, bash, lua, pascal

[yvs115]

Редактор швидкий, їсть мало памʼяті, та підтримує відкриття навіть гігабайтних файлів.

Перше що зразу кидається в очі - "гігабайтних файлів" - а чи комусь хоч коли-небудь знадобиться (чи взагалі бачив) гігабайтні файли з кодом такого розміру, та навіть просто текстові. І взагалі не дуже уявляю як будуть спрацьовувати парсери (lsp linters formaters etc.) навіть на значно менших об'ємах (хай в тисячі разів менші файли - мегабайти коду, що також під питанням чи зустрінуться десь в рамках одного файлу).

Так, бувають гігабайтні текстові файли, наприклад логи.

Якщо не код а просто текст - так, тут згоден - деяка ймовірність є. І якщо докритикувати пункт гігарозмір в логах: - тобто в системах з відсутнім бінарним зберіганням логфайлів (нп з systemd-journald) їх зазвичай розбивали ротацією по часу та/чи розміру на менші частини (ніж гігарозмір) але на більшу кількість (якщо ті файли потрібні були для аналізу). І в принципі не дуже зрозуміло навіщо такі логи в редакторах відкривати - бо по ідеї якщо пошук (бо достатньо великі значить щось знайти спершу) то грепати, якщо і поміняти щось просте і швидко у дуже великих текстових файлах - то sed.

Поміряв споживання відкривши /var/log/messages на 41 тисячу рядків і прогортавши його в кінець під mate-terminal:

По цифрам щось приблизно так і очікувалось, хоча думав що vsc буде важчим по всім параметрам. І це доречі приклад з більш-менш очікуваним по розміру текстовим лог.файлом ~10m (41k * ~200), і навіть з таким не гіга розміром - то зазвичай робота для grep/sed.

Якщо відкинути ці трохи незрозумілі характеристики "гіга-швидко-etc", візьмемо що може зацікавити: - з опису є що підтримується lsp (це якраз напевно одна з найважливіших фіч при роботі з кодом в редакторах). Але немає в опису для яких мов etc. існує відповідна підтримка.

rust, python, javascript, typescript, html, css, c, cpp, go, json, java, c-sharp, php, ruby, bash, lua, pascal

Дякую, корисна інфо з чим можна використовувати.

btw: за що буває анноїть rust часто (як у цьому випадку) - відсутність стандартизації і велика кількість модулів у залежностях, тобто щось на зразок bleeding edge з софтом, нп на свіжому релізі убунту не зібралося з компілятором з системних пакаджів

Код: [Вибрати]

% cargo build --release
error: rustc 1.85.1 is not supported by the following packages:
  home@0.5.12 requires rustc 1.88
  home@0.5.12 requires rustc 1.88
  libloading@0.9.0 requires rustc 1.88.0
...

% dpkg-query -W rustc
rustc 1.85.1ubuntu1

% lsb_release -d
Description: Ubuntu 25.10


[Tamer4]

О, дякую, це краще, замінив свій micro editor. Ще по ходу діла відкрив для себе joshuto file manager.

[Володимир Лісівка]

Fresh ще дуже глюкавий, наприклад LSP не працює чомусь у мене і в логах нічого не пише, українська майже не підтримується, але це перший термінальний редактор який мені подобається більше ніж mc + mcedit для кодування.

До речі, як на мене, в ghostty він працює краще ніж в mate-terminal, наприклад комбінація Ctrl-. працює.

[BeSiDa]

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

Не те що я дуже у захваті від такого, але ви можете експортувати ОпенСтрітМеп (значний шматок поверхні) у ХМЛ файл значно більшого розміру
До того ж то не буде "термінальний текстовий файл" (тобто з розбиттям по 80 символів у рядку для грепів та седів). І шукати серед нього краще у прозі що розуміє саме ХМЛ структуру та підсвітить відповідно.

Та всілякі хтмл, свг та інші... Хоча там мабуть значно менші розміри. Хоч вони також не завжди сумісні з "термінальним текстовим" форматом (можуть взагалі бути без \н і не перестають бути від того коректним ХМЛ).