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 символів у рядку для грепів та седів). І шукати серед нього краще у прозі що розуміє саме ХМЛ структуру та підсвітить відповідно.

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

[yvs115]

"термінальний текстовий файл" (тобто з розбиттям по 80 символів у рядку

то визначення текстового файлу у 80символьній філософії?)

І шукати серед нього краще у прозі що розуміє саме ХМЛ

)) у xml прозі філософії

[BeSiDa]

Файли можуть одночасно відповідати декільком стандартам. Інколи трохи не відповідати ним (деяким). Інколи обирати підмножини, що відповідають кожному зі стандартів.

[yvs115]

"термінальний текстовий файл" (тобто з розбиттям по 80 символів у рядку

І шукати серед нього краще у прозі що розуміє саме ХМЛ

Файли можуть одночасно відповідати декільком стандартам.
Інколи трохи не відповідати ним (деяким). Інколи обирати підмножини, що відповідають кожному

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

[BeSiDa]

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

О! Вас обрали! у 3тьому рядку рівно 80 символів ))

[yvs115]

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

О! Вас обрали! у 3тьому рядку рівно 80 символів ))

добре хоч не квадратний xml корень з 80ти)