Первый релиз текстового редактора Micro

Программа на Go не требует зависимостей - ахахах, т.е. мяу.

Скачал и запустил - работает на моем чистом Дебе (oldstable, кстати, который еще Wheezy). Что не так?

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

которые рантайм go, ну и что там ещё (lua) этому micro надо

Ты упорот чуть более чем полностью. Выше уже пояснили, почему.

потому как все зависимости вшиты внутри. Не нравится — пересобери обычным способом
которые рантайм go

Ну и как ты пересоберешь рантайм «обычным способом»? gcc-go не предлагать.

а что сразу как замена nano? пусть меняет его себе автор и те кто об этом редакторе узнали и захотели. остальной мир не трожь.

«легковесный»

http://dic.academic.ru/dic.nsf/ushakov/848738
http://www.vedu.ru/expdic/14072/

Зачем? Есть специальные средства для разбора больших файлов.

а на какой ляд нужен еще один редактор в консоли?

есть mcedit где всё работает и даже мышь и даже подсветка.

есть nano для тех, кто даже mc поставить не может, и вынужден править конфиги руками в том, что есть.

есть qtcreator для с++, eclipse и т.п. для жабы, и куча других редакторов для работы(то есть работы а не страдания в консоли).

Очередной неосиливший консоль? А, ведь, в своё время было много толковых статей по поводу: «CLI против GUI. Консоль против Графики.», «Зачем все это, или текстовая консоль - а чем же она хороша?», «Как перестать беспокоиться и полюбить командную строку»,... и т.д.

Суть комментария в том, что Go не умеет динамически линковать библиотеки.

Не нужно. Vim наше все.

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

уже есть ne

Спасибо, заценим.

Затем, что если ты случайно откроешь не тот файл, то говно, не умеющее открывать большие файлы зависнет намертво.

А НОРМАЛЬНЫЕ редакторы переваривают файлы любых размеров. Если они этого делать не умеют, то внутри - говнокод и точка. А авторы - говнокодеры и пусть идут учиться вместо того, чтобы лячкать свой говнокод.

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

http://www.unfire01.ru/uploads/tx_labshop/ognetushiteli_uglekislotnye_2.jpg

один исполняемый бинарный файл, не зависящий от других библиотек

«все свое тащу с собой»?

собери сам, в чем проблема?

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

Твоя аватарка весьма неплохо тебя характеризует.

Если софт говно, то его надо так и называть. vi, написанный 40 лет назад, открывает любые файлы, а «современный микро-мега жирный редактор» - нет. Вот это невиданный проэрэсс!

Да, оно не зависит ни от каких библиотек кроме тех что написаны на языке Go

Тебе уже наглядно показывали, что это не так:
Первый релиз текстового редактора Micro (комментарий)

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

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

Авторы языка постарались и написали на чистом go многое из того для чего мы обычно используем библиотеки

На, чтобы написать «обычно используемые» библиотеки, думаю, нужно около 50 человеко-лет. То есть, либо под «обычно используемыми» библиотеками понимается весьма ограниченный набор библиотек (что говорит об ограниченности языка go), либо ты что-то понял не так. Думаю - второе. Кроме того, переписывать существующие реализации - большая глупость.

А я на французский манер. Шах и мат.

Сразу баг: если сделать выделение Шифт+Стрелки, то перестают работать кнопки Home и End.

Автор только что пофиксил этот баг ;)

Второй баг: невозможно выделять строки от текущей позиции до конца (Шифт+Енд) или до начала (Шифт+Хоме).

У меня все работает, биндинги только пришлось поправить.

Непонятные обозначения в строке статуса: «+ (59,1) c». Цифры - позиция курсора. А остальное что?

Здесь как раз все вполне логично, не сложнее головоломок в мурзилке ;) : «+» признак наличия несохраненных изменений в редактируемом файле" «c» тип/язык файла и соотв. какой синтаксис подсветки будет исп-ся

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

Эта новость - шутка. Админ, срочно удали тему.

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

Каким бы компилятором ты его не собрал, всё равно будут зависимости.

Не «левым компилятором», а «с другими опциями». gcc-go умеет и статически линковать:

> go build -gccgoflags '-static' hw.go
> du -h ./hw
13M     ./hw
> ldd ./hw
        не является динамическим исполняемым файлом
> file ./hw
./hw: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, not stripped

> ldd ./micro
        не является динамическим исполняемым файлом
> du -h ./micro
23M     ./micro

Шта? Если собрать в статику - то зависимостей не будет.

Шта? Если собрать в статику - то зависимостей не будет.

Ок, библиотеки, которые статически линкуются.
А далее см. мой исходный пост.

Ну так никто и не говорит что это плохо или хорошо. Вопрос был про внешние зависимости и их нет.

Я хз как там go линкуется, и использует ли он вообще glibc.

С другой стороны rust линкуется только со своими либами статически, а внешние, всё тот же glibc, линкуются динамически. Как минимум на лине.

Итого, тот же xi-editor, собирается в 1МБ.

а ничего так, он еще и компиляет сам, и ошибки внятно подсвечивает

Почему не сделать обычную динамическую линковку, чтобы пересобирать вообще не нужно было?

кто мешает тебе ее сделать и выложить в дистр даже две сборки: статикой и динамикой?

привычные сочетания клавиш;

Даже для вимера?

нормальная поддержка мыши;

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

поддержка мыши

Зачем? Нет, серьезно, зачем МЫШЬ в терминальном редакторе?

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

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

Согласно закону Вирта, через пару лет micro разжиреет до macro milli.

Ок, библиотеки, которые статически линкуются.

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

Раст это самые настоящие растаманы же. Обкурятся и говорят, что безопасно.

Вот и получается, что при локали UTF-8 в ядерной консоли чуть больше чем 256 символов показываются нормально, а всё остальное отображается «квадратами».

А вот koi8-r дает огромнейший набор символов. Да?

с локалью KOI8-R более 10-ти лет и доволен.

Только в каждой теме, где засветилось сообщение о utf-8, видно ваше «доволен».

Ctrl-X вырезать
Ctrl-C копировать
Ctrl-V вставить

Ctrl-Q выход
Ctrl-S сохранить
Ctrl-O открыть

Короче все не так как в nano

mv /usr/bin/nano /dev/null

Зато без квадратов. Там шла речь именно об этом. А так мне и KOI8-R выше крыши, да и каждый символ ровно по одному байту, а это много стоит.

да и каждый символ ровно по одному байту, а это много стоит.

Да, в 2016 это особенно актуально :)

Ну так должен же кто-то и KOI8-R пропагандировать, тем более когда то там то здесь выпиливают всё кроме UTF-8 в её пользу. Я могу вообще никуда не писать и быть довольным. Но, иногда могу и написать.

Троян, понятно.

Не боись, тебя защитит антивирус гендиректора с зависимостью от .NET Framework.

31.08.2016
KOI8-R

Ненужно.

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

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

символ по одному байту — это удобно.

Чем символ по одному байту удобнее, чем символ по N-ному количеству байт, кроме банального «ручного» чтения и занимаемого пространства, что, конечно, актуально в 2016 году.