Midnight Commander 4.8.16

Для итерации по «utf8 char» нужна ещё одна небольшая функция, она же будет использоваться для копирования.

Вот и весь код из glib, что нужен для utf-8 strlen:

#include <stdio.h>

typedef long glong;
typedef signed long gssize;
typedef char gchar;
typedef unsigned char guchar;

#define G_STMT_START  do
#define G_STMT_END    while (0)
#define g_return_val_if_fail(expr,val) G_STMT_START{ (void)0; }G_STMT_END

#define _GLIB_EXTERN extern
#define GLIB_VAR _GLIB_EXTERN

static const gchar utf8_skip_data[256] = {
  1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
  1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
  1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
  1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
  1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
  1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
  2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
  3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,5,5,5,5,6,6,1,1
};

const gchar * const g_utf8_skip = utf8_skip_data;

/* Array of skip-bytes-per-initial character.
 */
GLIB_VAR const gchar * const g_utf8_skip;

/**
 * g_utf8_next_char:
 * @p: Pointer to the start of a valid UTF-8 character
 *
 * Skips to the next character in a UTF-8 string. The string must be
 * valid; this macro is as fast as possible, and has no error-checking.
 * You would use this macro to iterate over a string character by
 * character. The macro returns the start of the next UTF-8 character.
 * Before using this macro, use g_utf8_validate() to validate strings
 * that may contain invalid UTF-8.
 */
#define g_utf8_next_char(p) (char *)((p) + g_utf8_skip[*(const guchar *)(p)])

/**
 * g_utf8_strlen:
 * @p: pointer to the start of a UTF-8 encoded string
 * @max: the maximum number of bytes to examine. If @max
 *       is less than 0, then the string is assumed to be
 *       nul-terminated. If @max is 0, @p will not be examined and
 *       may be %NULL. If @max is greater than 0, up to @max
 *       bytes are examined
 *
 * Computes the length of the string in characters, not including
 * the terminating nul character. If the @max'th byte falls in the
 * middle of a character, the last (partial) character is not counted.
 *
 * Returns: the length of the string in characters
 */
glong
g_utf8_strlen (const gchar *p,
               gssize       max)
{
  glong len = 0;
  const gchar *start = p;
  g_return_val_if_fail (p != NULL || max == 0, 0);

  if (max < 0)
    {
      while (*p)
        {
          p = g_utf8_next_char (p);
          ++len;
        }
    }
  else
    {
      if (max == 0 || !*p)
        return 0;

      p = g_utf8_next_char (p);

      while (p - start < max && *p)
        {
          ++len;
          p = g_utf8_next_char (p);
        }

      /* only do the last len increment if we got a complete
       * char (don't count partial chars)
       */
      if (p - start <= max)
        ++len;
    }

  return len;
}

int main(int argc, char *argv[])
{
        if (argc != 2) {
                printf("Usage: %s <строка>\n", argv[0]);
                return 1;
        }
        printf("Символов: %li. Строка: %s\n", g_utf8_strlen(argv[1], -1), argv[1]);
        return 0;
}

Проблема с неопределенностью длинны символа приводит к тому, что терминалы разворачивают utf-8 в фиксированное представление (2/4/6 байт) или как это делает терминал ядра проводят еще одну конвертацию в восьмибитную кодировку.

А при полноценной поддержке CJK вообще все грустно: посмотрите сколько поддержка cmaps занимает в mupdf.

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

А можно и без. Вот mate-terminal с моноширинным шрифтом просто рисует следующий символ на заранее положенном для него месте. И пусть он накрывает своих чересчур широких соседей слева-справа.

Просто не верится, что

IMHO там, где действительно мало ресурсов, юникоду в любом случае не место

есть тем не менее ресурсы для немоноширинных шрифтов. Так что можно подробнее?

А можно и без.

Нельзя. Следим за руками:

Один байт UTF-8 не равен одному кодепойнту юникода. Конвертнули UTF-8 в UCS-4.

Один кодепойнт UCS-4 не равен одному глифу. Делаем нормализацию юникода.

Один глиф не равен одному знакоместу на экране. Глифы делятся на:
* занимающие одно знакоместо по ширине.
* занимающие два знакоместа по ширине (китайщина, например).
* обязанные занимать 1 знакоместо, но занимающие 2, потому в терминале баги.
* обязанные занимать 2 знакоместа, но занимающие 1, потому в терминале баги.
* занимающие 0 знакомест (не отображающиеся), потому в терминале особо кривые баги.

А у нас интерфейс основан на счёте знакомест в строчках. Если на любом этапе ошибиться, вся «псевдографика» расползётся.

Речь не про шрифт, а про количество байт в строке. Сколько нужно выделить памяти под экранный буфер в терминале 80x25 для восьмибитной кодировки и для utf-8?

Просто не верится, что

«IMHO там, где действительно мало ресурсов, юникоду в любом случае не место»

есть тем не менее ресурсы для немоноширинных шрифтов. Так что можно подробнее?

А это не я утверждал про ресурсы.

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

Я не сталкивался, можешь рассказать? Гугл бормочет что-то невнятное.

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

grep -rn 'вхождение' ./каталоги/файлы

в mc можно эти файлы в найденных строках и посмотреть и отредактировать, удобно

почемуто mc противопоставляют командной строке, что неверно
не нужно спрашивать «где mc незаменим», но с mc удобнее делать некоторые вещи, не _отменяя_, а дополняя командную строку

почемуто mc противопоставляют командной строке, что неверно

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

Крайне раздражающее кеширование файла перед отправкой файла через fish осталось?

Это про fish, а не FISH. С FISH всё как было, так и осталось :-(

и кстати про предъявы - крайне раздражают сообщения vfs, висящие в верхней строке панелей. неужели так сложно обновлять панели, или хотя бы, верхнюю строку, после успешного завершения операциий?

неужели так сложно

Мигель оставил много багов. Чтобы всё почистить, надо много времени, или много людей. Про это представители текущей команды писали и на LOR.

Ок, не мой кейс. А что-то еще кроме патчей?

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

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

Это совсем не так, я не пользуюсь mc совсем, но в консоле и vim-e провожу 80% своего рабочего времени. Тут наверное как с виндой, когда мышки нет, то и ладно, а когда привык, долго перестраиваться будешь.

не нужно спрашивать «где mc незаменим»

Я это спросил на утверждение, что иногда mc незаменим.

но в консоле

В консоли.

Думаю, имеется в виду не «Files transferred over shell protocol», а friendly interactive shell.

Блин, а я уж надеялся что древнюю неудобность устранили.

Сама собой она не устранится.

Хммм, ну пофикси, я что-то не замечал никогда.

... минималистичный mc...

http://mc.linuxinside.com/

Ну и говнокод. Точнее стиль кода.

Вот такой патч на моём тестовом наборе уменьшает время работы
str_utf8_normalize() с 11.9% до 1.4%, или в абсолютном
выражении с 21 миллиона инструкций до 2 миллионов.

http://www.midnight-commander.org/ticket/3616

А как на это можно практически посмотреть ? На вид должно быть хорошо, но попался под руку каталог под 700K файлов вида «nfcapd.201301012200». Вход в каталог не особенно отличается для mc с патчем и без. Собственно говоря, все тесты в пределах погрешности, mc без патча бывает и быстрее. Может быть, где-то внутри glib какая-то похожая оптимизация есть ? Или же эта сортировка - не самая заметная задержка...

С некоторых пор прекрасно обхожусь без него, coreutils ftw. А так чтобы требуемые файлы нельзя было выделить по какому-то простому шаблону случается очень редко и не у меня, так что действительно не нужно. Всё равно в мц нужные команды набираешь руками. Пусть будет, конечно. Удобно просматривать содержимое файлов, наверное. Если бы он ещё архивы в /tmp не копировал. Кстати, копировать файлы удалённого хоста на локальный удобно в нём, это да.