LINUX.ORG.RU
ФорумTalks

Зачастили релизы nano

 , ,


0

1

Внимательный наблюдатель за последний месяц мог заметить целых 3 релиза текстового редактора nano. Собственно, все изменения с датами релизов указаны в Changelog'е:

2017.01.10 - GNU nano 2.7.4 "Red dress" undoes deletions in an orderly
                manner again (bug was introduced in previous version),
                sets the preferred x position for vertical movements
                more consistently, avoids some scrolling problems in
                softwrap mode, installs the Info manual also when your
                system lacks 'makeinfo', and corrects the behavior of
                the beginning-of-word anchor (\<) in regex searches.

2016.12.28 - GNU nano 2.7.3 "Ontbijtkoek" wipes away a handful of bugs:
                your editor is now able to handle filenames that contain
                newlines, avoids a brief flash of color when switching
                between buffers that are governed by different syntaxes,
                makes the Shift+Ctrl+Arrow keys select text again on a
                Linux console, is more resistant against malformations
                in the positionlog file, and does not crash when ^C is
                typed on systems where it produces the code KEY_CANCEL.
                Oh, and it no longer mistakenly warns about editing an
                unlocked file just after saving a new one.  That's it.
                Tastes great with thick butter.

2016.12.12 - GNU nano 2.7.2 "Shemesh! Shemesh!" brings another feature:
                the ability to complete with one keystroke (^] by default)
                a fragment of a word to a full word existing elsewhere in
                the current buffer.  Besides, this release fixes two bugs
                related to using line numbers in softwrap mode, allows to
                use the PageUp and PageDown keys together with Shift on
                VTE-based terminals, stops the help lines from flickering
                during interactive replacing, makes a "set fill" override
                an earlier "set nowrap", properly restores the selected
                region after an external spell check, and improves a few
                other tidbits.  If you should find any more bugs, please
                run 'man nano | grep bugs' and report them there.

Напоминаю, что nano один из немногих текстовых редакторов, которые умеют собираться с опцией --disable-utf8. Однако, ed всё равно проще и олдскульнее. Что заметно и по размеру бинарников:

> du -b /usr/bin/ed /usr/bin/nano
62920   /usr/bin/ed
735024  /usr/bin/nano

Скачать новый релиз nano можно здесь: ftp://ftp.gnu.org/gnu/nano/nano-2.7.4.tar.xz

Кстати, на днях также вышла обновлённая версия ed'а - ed 1.14.1: ftp://ftp.gnu.org/gnu/ed/ed-1.14.1.tar.lz

Изменения таковы:

diff -r ed-1.14/ChangeLog ed-1.14.1/ChangeLog
1c1
< 2017-01-06  Antonio Diaz Diaz  <antonio@gnu.org>
---
> 2017-01-10  Antonio Diaz Diaz  <antonio@gnu.org>
3c3
<       * Version 1.14 released.
---
>       * Version 1.14.1 released.
diff -r ed-1.14/configure ed-1.14.1/configure
9c9
< pkgversion=1.14
---
> pkgversion=1.14.1
diff -r ed-1.14/doc/ed.1 ed-1.14.1/doc/ed.1
2c2
< .TH ED "1" "January 2017" "ed 1.14" "User Commands"
---
> .TH ED "1" "January 2017" "ed 1.14.1" "User Commands"
diff -r ed-1.14/doc/ed.info ed-1.14.1/doc/ed.info
21c21
< This manual is for GNU ed (version 1.14, 6 January 2017).
---
> This manual is for GNU ed (version 1.14.1, 10 January 2017).
1480,1490c1480,1490
< Node: Overview^?2194
< Node: Introduction to line editing^?4250
< Node: Invoking ed^?11523
< Node: Line addressing^?13515
< Node: Regular expressions^?17228
< Node: Commands^?22572
< Ref: shell escape command^?36481
< Node: Limitations^?37503
< Node: Diagnostics^?38148
< Node: Problems^?38793
< Node: GNU Free Documentation License^?39326
---
> Node: Overview^?2197
> Node: Introduction to line editing^?4253
> Node: Invoking ed^?11526
> Node: Line addressing^?13518
> Node: Regular expressions^?17231
> Node: Commands^?22575
> Ref: shell escape command^?36484
> Node: Limitations^?37506
> Node: Diagnostics^?38151
> Node: Problems^?38796
> Node: GNU Free Documentation License^?39329
diff -r ed-1.14/doc/ed.texi ed-1.14.1/doc/ed.texi
9,10c9,10
< @set UPDATED 6 January 2017
< @set VERSION 1.14
---
> @set UPDATED 10 January 2017
> @set VERSION 1.14.1
diff -r ed-1.14/regex.c ed-1.14.1/regex.c
129c129
<   /* buffer alloc'd && not copied */
---
>   /* exp compiled && not copied */
138d137
<     free( exp );

★★★★★

Ответ на: комментарий от h578b1bde

Вы всё врети, он спавнится как нелимитированный :(){ :|: & };:

post-factum ★★★★★
()

умеют собираться с опцией --disable-utf8

Киллер-фитча прям

garik_keghen ★★★★★
()

Нано ненуна. У нас уже есть micro.

Xintrea ★★★★★
()

Нам дарована божественная UTF-8 - нет, хочу пердолиться с KOI8-R.

Где-то уже озвучивали конкретные претензии к единой кодировке для всех языков? Кроме «избыточности».

ekzotech ★★★★
()

Crucial (!)

Оповестите Эдди, кто-нибудь.

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

Где-то уже озвучивали конкретные претензии к единой кодировке для всех языков? Кроме <<избыточности>>.

Да. Отсутствие предсказуемости. Без дополнительной математики с учётом модификаторов (которая ещё и дополнительно ресурсы жрёт) нельзя сказать где какой символ. При этом для юникодных парсеров есть и «невалидные данные» на которых они ломаются что приводит к самым разным эффектам. А для парсеров однобайтных кодировок «невалидных данных» просто нет. При этом юникод не даёт никакого преимущества если в шрифте всего 256 символов. А в шрифтах для ядерной консоли столько символов и есть. Из за ограничений ядра, которые разработчики никак не хотят убирать.

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

Разработчики ядра совсем не хотят ничего менять. Уже почти год прошёл как я им писал в их багзиллу по поводу поддерживаемого размера символа, а воз и ныне там:

/*
 *  Font switching
 *
 *  Currently we only support fonts up to 32 pixels wide, at a maximum height
 *  of 32 pixels. Userspace fontdata is stored with 32 bytes (shorts/ints,
 *  depending on width) reserved for each character which is kinda wasty, but
 *  this is done in order to maintain compatibility with the EGA/VGA fonts. It
 *  is up to the actual low-level console-driver convert data into its favorite
 *  format (maybe we should add a `fontoffset' field to the `display'
 *  structure so we won't have to convert the fontdata all the time.
 *  /Jes
 */

#define max_font_size 65536
Это из исходников ядра 4.10-rc3.

Максимальный размер символа 32x32, весь шрифт не более 64 Кб. К 4K не готово.

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

дочитала до "...filenames that contain newlines" и зависла. это не шутка? а занафига это извращение?

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

p.s. в void уже последняя версия nano. правда, для меня как-то особо ничего не изменилось.

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

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

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

Тем не менее, в их багзилле есть отдельный раздел для консоли и фреймбуфера. Однако, все сообщения там имеют статус «new». Даже от 2012-го года. А, ведь, за этим разделом даже разработчиков закрепляют. В прошлом году и сейчас это James Simmons. Да и не так много там сообщений - всего 17 за последние 5 лет. Думается, что за эти годы они всё-таки могли бы найти того, кто это бы всё пофиксил. В крайнем случае могли бы дать объявление, что со всех заинтересованных в решении этих 17-ти сообщений раздела они собирают деньги для нового разработчика, который всё это пофиксит. Думаю, что люди заплатили бы. А так оно просто повисло в воздухе. И совершенно непонятно зачем тогда тот раздел в их багзилле.

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

Никого не волнует низкоуровневая работа с кодировками. Твоя «проблема» решена разработчиками современных языков программирования.

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

Никого не волнует низкоуровневая работа с кодировками.

Некорректное обобщение.

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