Fish-shell: Сокращения

Другая идея - назвать эти «аббревиатуры», как в Vim, а затем решить, что делать с псевдонимами в другом выпуске [я склонен думать, что их следует удалить].

Придумал еще один аргумент против:

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

Мне нравится ваше предложение, звучит круто и подозрительно: +1:

Мне это тоже нравится.
Это очень чистое решение проблемы "доработки для псевдонимов" №393, которая очень раздражает.
В сочетании с распечаткой ll (Alias) при выполнении ll<tab> было бы идеально.

Поскольку alias - это просто оболочка сценария вокруг function сегодня, я бы хотел, чтобы это также изменилось, чтобы между функциями и псевдонимами была четкая разница, поскольку после этого они во многом различаются, например :

• Синтаксис
• Выразительность
• использование

@gustafj Я думаю, что, вероятно, лучше назвать эту идею «сокращениями» и заменить alias чем-то, что показывает полезное сообщение об ошибке, указывающее на function и abbreviate . Мысли?

Другое примечание:

Я хотел, чтобы это повлияло только на команду в командной строке, потому что было бы очень неприятно, если бы g продолжал расширяться до git в позиции аргумента. Однако нам может потребоваться некоторое расширение позиций аргументов, например, с помощью sudo (что будет означать, что вы можете использовать sudo с аббревиатурами - то, что вы не можете сделать с псевдонимами!) И в некоторых случаях однозначных завершений, таких как что касается собственных псевдонимов git или если вы вводите часть длинного параметра. Однако сделать это может быть непросто и будет мешать только в том случае, если доработки устарели, и если вы действительно хотите sudo g не sudo git , теперь вам нужно сделать что-то вроде sudo (echo git) . Возможно, мы могли бы сказать, что цитируемые аргументы никогда не расширяются, поэтому вы могли бы сказать sudo "g" . Не уверен, будет ли это слишком волшебным и удивительным или на самом деле именно то, что можно было бы ожидать и интуитивно. Мысли? :-)

Аббревиатуры мне нравятся (но я постоянный пользователь vim, поэтому могу быть предвзятым ...).
Когда я думаю об этом, с его помощью можно сделать довольно много "интересных" вещей, но (как вы уже заметили) на этом минном поле также спрятаны ловушки: /

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

Несколько собственных мыслей:
Должен ли он быть автоматическим при использовании space или должен запускаться опцией через tab или что-то еще?
Должно ли это быть только для простых строк ex g для git ?
Должно ли это быть применимо только к первому элементу в командной строке или где угодно?
Можно ли выполнить преобразование строки в значение ex d для текущей даты Tue May 14 20:23:03 CEST 2013 ?
Если возможно расширить подоболочки, ex vim (find . -iname '*cfg')<tab> дает

foo.cfg bar/poo.cfg foo/bar/more/beer.cfg
> vim

Мысли о ваших мыслях!

Должен ли он быть автоматическим с использованием пробела или должен запускаться опцией через вкладку или что-то еще?

Я не думаю, что это работает с чем-либо, кроме пробела (и ввода), потому что все дело в том, чтобы получить беспрепятственный опыт, который вы получаете с псевдонимами, когда вам не нужно думать о том, является ли что-то псевдонимом или нет, а вкладка не работают либо потому, что g<Tab> должен завершать команды, которые начинаются с g . Если мы добавим новую привязку, скажем, CTRL-X, у нас теперь будет три типа завершения: нормальные, самовнушения и сокращения. Я действительно считаю, что это нужно делать с пространством или вообще не делать.

Должно ли это быть только для простых строк ex g для git?

В командной позиции должна быть возможность включать аргументы в сокращение. Например, gc расширяется до git commit --all или что у вас есть. В основном я считаю аббревиатуры в точности похожими на псевдонимы, за исключением того, что они расширяются в командной строке.

Должно ли это быть применимо только к первому элементу в командной строке или где угодно?

Только командная позиция, вероятно, хорошее начало. Затем мы можем _maybe_ экспериментировать с вариантами использования позиции аргумента, которые я предлагал ранее.

Можно ли выполнить преобразование строки в значение ex d для текущей даты Вт, 14 мая, 20:23:03 CEST 2013?

Вы имеете в виду позицию аргумента? echo d расширяется, чтобы повторить дату? Я действительно думаю, что если мы вообще используем аббревиатуры позиций аргументов, их нужно использовать очень консервативно и _только_, когда аргумент является командой (как в случае sudo ) или когда у команды есть собственная система псевдонимов. (как в случае git ) и расширение будет иметь тот же эффект, что и не раскрытие (поэтому мы расширяемся только для удобства использования).

Можно ли развернуть подоболочки ex vim (find . -iname '*cfg')<tab>

Я думаю, что это вопрос о дополнениях, а не об аббревиатурах, поскольку я не думаю, что аббревиатуры включают табуляцию, и расширение подоболочек в пространстве, вероятно, плохая идея. Однако не уверен, что это может работать для дополнений, потому что вы уже можете заполнять имена переменных, не расширяя их.

Хотя это могло быть полезно. Как я представляю, выполняю rm *.png , расширяя подстановочный знак и удаляя некоторые файлы из списка.

Как насчет этого: у нас есть общая система «расширения» или «аббревиатуры», аналогичная системе дополнений; привязываем CTRL-X или что-то для расширения токенов; а в командной позиции мы также автоматически расширяем аббревиатуры. Это также может сделать варианты использования sudo и git менее навязчивыми, если сделать эти расширения явными.

Однако это предложение намного шире, чем моя первоначальная идея. :подмигивание:

Пространство в качестве триггера мне нравится, вероятно, дает лучший пользовательский опыт.
Расширение *.png звучит интересно;)
Я сам не люблю много разных привязок для разных вещей, возможно, вместо новой привязки можно использовать "двойную табуляцию".
Ex ....*.png<tab> дает press <tab> again to expand *.png (то же самое для подоболочек).

Но, возможно, было бы лучше ограничить это предложение: сокращениями для позиции команды, расширением с использованием пробела.
И есть ли отдельная поддержка «расширять подоболочки / подстановочные знаки» и sudo?

Не уверен, что двойная вкладка будет работать, поскольку в настоящее время она циклически переключается между завершениями. Кажется, что в Vim есть CTRL +] для расширения сокращений без ввода пробела ...

Я думаю, что если мы вообще делаем живые дополнения, то аббревиатуры нужно каким-то образом внедрять, чтобы идеи были связаны. Но если мы не делаем живые расширения, сокращения все равно следует рассматривать сами по себе. Так что не знаю, что здесь делать. :-)

Да, ты прав насчет <tab> , думал только о подоболочках (где в настоящее время ничего не делает).
Можно было бы изменить текущее поведение <anything><space><tab> который в настоящее время циклически перебирает все доступные файлы в текущем каталоге (сначала распечатывает их все).
Бывший

> ls <tab>
a.cfg  b.cfg  c.cfg  d.cfg
> ls <tab>
> ls a.cfg<tab>
> ls b.cfg<tab>

Но я бы предпочел "живые расширения" с новой комбинацией клавиш, чем жить без нее;)
Расширение *.cfg до a.cfg b.cfg c.cfg d.cfg кажется действительно полезным.
Но тогда все формы возможных расширений должны быть расширяемыми, а не только подстановочные знаки, исключая завершение скобок (которое я бы предпочел удалить ... но это другая проблема # 354)

Но тогда все формы возможных расширений должны быть расширяемыми, а не только подстановочные знаки, исключая завершение скобок (которое я бы предпочел удалить ... но это другая проблема # 354)

Согласен по обоим счетам. Интересно, нужно ли расширять и двойные кавычки ... echo "hello $USER" -> echo "hello dag" .

Я думаю, что то, о чем мы здесь говорим, на самом деле является скорее «оценкой», чем «расширением», в то время как, с другой стороны, сокращения не относятся к оценке, поэтому эти идеи, вероятно, разделены, и я сделаю новый выпуск для другого и отредактирую это немного.

Вот базовый рабочий прототип:

function __fish_expand_abbreviation
    if test (count (commandline -poc)) -eq 0
        switch (commandline -t)
            case g
                commandline -t git
            case gc
                commandline -t 'git commit'
        end
    end
end

bind \  '__fish_expand_abbreviation; commandline -i " "'
bind \n '__fish_expand_abbreviation; commandline -f execute'

Одна проблема, которую я заметил, заключается в том, что если вы нажмете Enter для выполнения сокращенной командной строки, развернутая форма будет выделена как ошибка (неизвестная команда), даже включая аргументы.

Мне это так понравилось, поэтому я реализовал способ управления этими сокращениями.

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

Это текущая реализация:

function __fish_expand_abbreviation
  if test (count (commandline -poc)) -eq 0
    set -l token (commandline -t)

    if abbreviations -q $token
      commandline -t (abbreviations $token)
    end
  end
end

function abbreviations --description 'List, show and query abbreviations'
  if test (count $argv) = 0
    printf '%s\n' $fish_abbreviations
    return
  end

  set -l abbreviation_index 0
  set -l expanded_abbreviation

  for i in $fish_abbreviations
    set abbreviation_index (math $abbreviation_index + 1)
    echo $i | read -l abbreviation command

    if test $abbreviation = $argv[-1]
      set expanded_abbreviation $command
      break
    end
  end

  if test -n "$expanded_abbreviation"
    switch $argv[1]
      case -q --query
        return 0
      case -e --erase
        set -e fish_abbreviations[$abbreviation_index]
      case '*'
        echo $expanded_abbreviation
      end
  else
    return 1
  end
end

function abbreviate --description 'Define a new abbreviation'
  if test (count $argv) -lt 2
    echo 'abbreviate: Takes two arguments. First abbreviation and then expanded command'
    return 1
  end

  echo $argv | read -l abbreviation command

  eval "function $abbreviation; $command \$argv; end"
  abbreviations -e $abbreviation

  set -U fish_abbreviations $fish_abbreviations "$argv"
  return 0
end

Затем вы делаете что-то вроде этого:

abbreviate !    'sudo'
abbreviate tf   'tail -f'
abbreviate l    'ls -la'
abbreviate l.   'ls -d .*'
abbreviate g    'git'
abbreviate gs   'git status'

Обновление 1: добавлена ​​возможность удалять сокращения и сохранять их в универсальной переменной.
Обновление 2. Создайте функции для сокращений.

Глядя на то, как работают функции, мы могли бы представить:

• abbred
• abbrsave

По сути, это было бы клонированием этих функций.

Отлично! Я не _ вполне_ уверен, что нам нужен каталог ~/.config/fish/abbreviations и сопровождающий его abbr{ed,save} . В отличие от функций и дополнений, они не очень медленно загружаются по отдельности, и для их определения требуется только одна строка. Я думаю, они больше похожи на bind , возможно, у нас могла бы быть функция fish_[user_]abbreviations такая как функция fish_user_key_bindings , которая загружается, когда рыба в первый раз пытается расширить аббревиатуру? ( [user_] для согласованности, но я не уверен, что мы должны отправлять какие-либо сокращения по умолчанию?)

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

Другая идея - сделать что-то вроде универсальных переменных, возможно, даже фактически используя универсалии (например, set -U fish_abbreviations ). Возможно, есть вариант использования сокращений для локальных хостов? Не уверен.

У вас есть хорошие моменты, и я склоняюсь к пути fish_user_abbreviations .

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

Сначала я планировал использовать set -U fish_abbreviations , но мне нравится, чтобы конфигурация поддерживалась git, поэтому предпочитаю устанавливать их где-нибудь, например, в config. Но хорошая вещь с универсальной переменной заключается в том, что вы можете добавлять завершения на лету без каких-либо проблем, например ( abbred , abbrsave ). Просто сделайте abbreviate .

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

У меня сейчас вот такое:
set -q fish_abbreviations ; or fish_user_abbreviations

Но это не сработает, если я продолжу поддерживать файл.

Обновлены мои предыдущие функции для использования универсальной переменной и добавлена ​​возможность их стирать, а также проверять перед добавлением новых, существуют ли они.

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

Что ж, с доработками можно увидеть то, что даже они загружаются для одной команды. Если текущий процесс командной строки - git то загружается completions/git.fish . Когда у вас есть отдельные имена команд, вы должны создавать отдельные файлы, см., Например, дополнения для [ef]grep которые на самом деле находятся в функции, вызываемой из каждого из этих трех файлов завершения.

С сокращениями я не вижу никакого способа узнать по сокращению, какой файл загружать, если только имя файла не является сокращением. И тогда вы не можете иметь несколько сокращений в одном файле. Я предполагаю, что мы могли бы загрузить все файлы сокращений при запуске или при первой попытке расширить аббревиатуры, но это отличается от того, как загружаются функции и дополнения, и потенциально может быть медленным, если у вас много файлов сокращений.

Новая идея: abbreviate -U чтобы сделать универсальное сокращение, и abbreviate -g или просто abbreviate чтобы сделать глобальное сокращение? Если мы сделаем это, возможно, нам стоит подумать о том, чтобы сделать это и для bind ...

Также я думаю, что abbreviate следует просто перезаписать любое существующее сокращение, такое же, как bind и function и set ...

Все точки действительны. Думаю, имеет смысл просто перезаписать, как это делают все остальные функции.

Мне также нравится предложение с универсальным и глобальным, которое дает гибкость в выборе способа обработки ваших сокращений / привязок. Я не совсем уверен, как это реализовать, и думаю, может быть, это должно быть встроено для повышения производительности?

Да, я только создавал прототип в скриптах для рыб, чтобы опробовать. Наверное, не хотите, чтобы медленные сценарии запускались каждый раз, когда вы вводите пробел. :подмигивание:

Да, все еще отлично работает. Пользуюсь им уже около 1 дня и больше не могу представить себя без него, ха-ха: grin:

:краснеть:

Еще одна проблема, которую я заметил, заключается в том, что если вы введете C-a в непустую командную строку и наберете аббревиатуру, она не расширится в пространстве, так как вы находитесь в середине слова. Скажем, вы делаете make install oops, вам нужен root C-a ! теперь у вас есть ![cursor]make install и ввод пробела не расширяет аббревиатуру ! . Я попытаюсь обойти это с помощью commandline -C .

Третья проблема, которая может быть особенностью, заключается в том, что она раскрывается только тогда, когда вы вводите пробел или вводите после сокращения. Так что не, например, если вы вводите пробел, а затем C-a ! C-e . Это может быть особенность, потому что она позволяет избежать расширения аббревиатуры, но я думаю, что это немного некрасиво, и вместо этого мы должны иметь что-то вроде команды для буквально запуска командной строки, немного похожей на команду command но также учет для функций оболочки и встроенных функций. Или какой-то специальный синтаксис, например \g в позиции команды интерпретируется как g и не раскрывается. Специальный синтаксис тоже не очень подозрительный, но у нас уже есть место перед командой, которая означает «не входить в историю», так что пожмите плечами.

В-четвертых, и этот непонятный: если вы сделаете то же самое, что и в предыдущем абзаце, у вас есть нерасширенная аббревиатура, за которой следует пробел, затем введите C-a и пробел, аббревиатура расширяется и добавляется дополнительный пробел после этого! Опять же, возможно, потребуется проверить позицию курсора с помощью commandline -C .

Да и первая проблема, о которой я упоминал в предыдущем комментарии, возникает только в том случае, если нерасширенная аббревиатура является неизвестной командой. Таким образом, аббревиатура gc заменяется на git commit и все это выделяется как ошибка при нажатии клавиши ввода (без пробела), а аббревиатура gs заменяется на git status и подсвечивается правильно, потому что, видимо, у меня установлен ghostscript:

> which gs
/usr/bin/gs

Мне также интересно, могут ли сокращения выделяться как известные «команды» даже до того, как вы нажмете пробел ... В настоящее время, если я набираю g он красный, пока не набираю пробел, но если я наберу git он выделяется как известное еще до пробела.

Со всеми этими проблемами, вероятно, можно было бы лучше справиться, если бы мы сделали это в частях C ++.

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

На самом деле, может быть, в любом случае это хорошая идея, хм ... Значит, сокращения будут работать в скриптах, в eval , с type ... Не уверен.

Ваш обходной путь - это то, что я использую в настоящее время, но я не уверен, что он должен делать это в конечном итоге или они должны использоваться внутри eval или type . Для меня они должны быть только вводом. Но я думаю, не повредит также позволить им запускаться, чтобы получить легкую поддержку, скажем, sudo.

Итак, я уже некоторое время использую текущую реализацию, и это проблемы, обнаруженные с помощью этого решения до сих пор (они не связаны с подходом: +1 :):

1. При вставке текста последний пробел вставляется в начало строки, например, echo this is a test _echo this is atest при вставке становится _ - это пробел.
2. При использовании встроенного read привязки к enter и space применяются там. Так, например, если я хочу ввести какую-то некую команду для чтения, она расширится. Я предполагаю, что в окончательной реализации это должно быть отключено по умолчанию и включено read -s
3. Это немного медленнее (~ 0,25-0,5 секунды)

Вы можете обойти 1. Вставив C-y .

Для меня C-y вставляет только внутри рыбы (из того, что вырезано внутри рыбы), а не из моего системного буфера обмена. Копирование между терминалами или другими приложениями.

Я думаю, что аббревиатуры - действительно крутая идея.

Я хочу дать людям возможность экспериментировать с сокращениями, чтобы уточнить, каким должно быть правильное поведение. Я проверил первоначальную поддержку сокращений в мастере как 92099c7af23d0cebf52f89de4f9d829825e53ac8 и f9c2a77c67754324f3036ec79501c6131d19562b.

Пример использования:

set -U fish_user_abbreviations 'gc=git checkout'
gc

gc будет расширен до "git checkout" на пробеле или при возврате.

Аббревиатуры представляют собой список, поэтому для добавления нового:

set fish_user_abbreviations $fish_user_abbreviations 'grh=git reset --hard'

Аббревиатуры раскрываются в «позициях команд» (например, в подоболочках или в качестве аргументов для if), но не в качестве аргументов. Аббревиатуры также не раскрываются в скриптах.

Вот несколько нерешенных вопросов для обсуждения:

1. «Аббревиатура» длинная и трудная для написания - можем ли мы найти лучшее название? "Псевдоним" был бы хорош, если бы он еще не использовался для других целей. Одна из возможностей - это перевернуть, например, «расширение». fish_user_expansions для меня звучит нормально.
2. Как следует указывать сокращения? Синтаксис gc=git checkout легковесен, но больше нигде в fish не используется.
3. Мы можем захотеть не расширяться при входе, а только пространство. Недостаток раскрытия при вводе состоит в том, что пользователь не видит, какую команду он выполнил, до тех пор, пока не подтвердит ее выполнение. Если мы расширяем только пространство, то пользователи могли бы вводить аббревиатуру, затем пробел, а затем вводить, что не кажется слишком обременительным. Вторая возможность состоит в том, чтобы заставить первое расширение триггера ввода, а второе вводить его на самом деле.

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

1. Расширенная форма аббревиатуры - это просто текстовая подстановка, и сама по себе она не должна быть действительной командой. Например, вы можете сделать сокращение, которое приведет к несоответствию кавычек или скобок. Я думаю, что это потенциально полезная функция, но это означает, что fish не может проверять синтаксис кода, содержащего сокращения, а это значит, что мы никогда не сможем использовать их в скриптах.
2. Должно ли само расширение аббревиатуры подвергнуться расширению подоболочки и переменной перед заменой? Думаю, да, потому что это сделало бы их чрезвычайно гибкими. Тогда аббревиатуры могут запускать произвольный код рыбы.
3. Если я нажму пробел, и аббревиатура расширится, и я передумаю, возможно, мне удастся нажать удалить и развернуть его.

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

Спасибо, я запускаю его сейчас, и, похоже, пока он работает очень хорошо.

1. Мы могли бы для краткости использовать аббревиатуру abbr . Что касается alias , если мы думаем, что это лучше, возможно, его можно было бы заменить таким поведением. Если люди хотят использовать псевдонимы в своих сценариях, они могут просто обернуть функцию. Аббревиатуры мне кажутся именно тем, для чего люди обычно используют псевдонимы.
2. Я думаю, было бы неплохо иметь некоторые вспомогательные функции для определения, а также удаления сокращений.
   Например: abbr gc 'git checkout' и abbr -e gc .
   На мой взгляд, это немного обременительно выполнять эту манипуляцию через переменную. Также хотелось бы заверить, что сокращения уникальны. Поэтому вам нужно только определить новый, чтобы обновить его.
3. Я предпочитаю поведение, которое есть сейчас, многие из моих сокращений, например gs для git status , не были бы столь полезны, если бы вам пришлось нажимать пробел. Тем не менее, я был бы в порядке с двойным вводом, чтобы на самом деле выполнить его, как вы упомянули.
4. Лично меня устраивает то, что я не использую их в скриптах.
5. Да, это было бы круто. Хотя не могу придумать аббревиатуры, чтобы использовать это в голове.
6. Это также хорошая идея, если, например, я слишком рано нажал пробел для сокращения. Это также хорошо сочетается с предложением номер 3 как двойной ввод (хотя все еще не уверен, хочу ли я этот дополнительный ввод).

alias любом случае является оболочкой совместимости с POSIX. У меня нет проблем с сокращениями. Если вы напишете abbr gc 'git checkout' или что-то в этом роде, вы все равно захотите завершить за git checkout .

Я использовал реализацию скрипта от terlar в течение последних нескольких недель и перешел на новую нативную версию сегодня, так что вот мои два цента на открытых точках

1. Я думаю, было бы отличной идеей просто позволить alias делать сокращения сейчас. В качестве бонуса он исправит неработающие доработки на текущих псевдонимах.
2. то, что сказал терлар, звучит хорошо
3. Если бы мне нужно было дважды нажимать клавишу ввода на аббревиатуре, чтобы выполнить их, меня бы действительно встревожило. Было бы неплохо, если бы они также работали нерасширенными, как псевдонимы, с одним нажатием клавиши ввода, но тогда у меня в моей истории есть нерасширенные аббревиатуры.
4. -
5. Разве расширение переменных не будет означать, что содержимое переменных будет помещено в команду и, следовательно, в вашу историю? Это сделало бы возможность повторного использования таких команд из истории намного ниже, поскольку они больше не содержат переменную, а только их более раннее содержимое. Или я неправильно понял этот момент?
6. Я не вижу себя использующим функцию нераскрытия, поскольку я не использую abbreviation длиннее 3 символов, что означает, что все они в основном находятся в мышечной памяти, и было бы быстрее просто очистить текущую строку. Теперь все может быть по-другому, поскольку нативная реализация может использоваться где угодно, а не только в начале строки. Но, вероятно, это хорошая идея, если это не означает, что я должен всегда нажимать пробел или дважды нажимать Enter, чтобы их развернуть.

«Аббревиатура» длинная и трудная для написания - можем ли мы найти лучшее название? "Псевдоним" был бы хорош, если бы он еще не использовался для других целей. Одна из возможностей - это перевернуть, например, «расширение». fish_user_expansions звучит нормально для меня.

Согласованы, но не проданы по «расширению».

Как следует указывать сокращения? Синтаксис gc = git checkout упрощен, но больше нигде в fish не используется.

Это должна быть просто новая встроенная функция, как complete и bind или, если на то пошло, function которую пользователь может вызывать, но чье базовое хранилище непрозрачно.

Мы можем захотеть не расширяться при входе, а только пространство. Недостаток раскрытия при вводе состоит в том, что пользователь не видит, какую команду он выполнил, до тех пор, пока не подтвердит ее выполнение. Если мы расширяем только пространство, то пользователи могли бы вводить аббревиатуру, затем пробел, а затем вводить, что не кажется слишком обременительным. Вторая возможность состоит в том, чтобы заставить первое расширение триггера ввода, а второе вводить его на самом деле.

Я действительно думаю, что мы хотим расширить Enter . Я полагаю, что получу много неприятных fish: Unknown command “gc” и не думаю, что буду одинок в этом. Однако раскрытие должно происходить в командной строке перед его выполнением, чтобы вы увидели раскрытие при прокрутке, и это развернутая форма оказалась в истории.

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

Думаю, не стоит. Обычно предпочтительнее, чтобы они раскрывались во время выполнения командной строки. Скажем, у меня есть сокращение для создания заметок с отметкой времени. Я набираю аббревиатуру и пробел, и она заменяется чем-то вроде vim 12:34:56.txt . Теперь я не запускаю эту команду в течение нескольких секунд, и метка времени будет неправильной. Было бы лучше, если бы аббревиатура расширилась до vim (time +%T).txt . Это правильно, а также означает, что у меня есть возможность редактировать командную строку перед ее выполнением, например, чтобы использовать другой формат времени. Это также делает его повторяемым; например, kill %firefox можно вызвать из истории и повторно запустить, даже если PID изменился. Наконец, я бы сказал, что это больше соответствует остальной части рыбы, где токены в командной строке оцениваются только во время выполнения.

С другой стороны, оценка во время расширения строго более эффективна, потому что мы можем отказаться от нее, например, с помощью экранирования, но без нее мы действительно не можем _opt in_. Я думаю, что это было бы лучше решить с помощью # 751, поскольку он дает пользователю возможность контролировать оценку. Тем не менее, это все еще не позволяет получить _точный_ момент расширения аббревиатуры; это будет момент, когда пользователь расширяет отдельный токен. Тем не менее, я думаю, что это было бы более полезным и более последовательным, поскольку он работал бы не только с сокращениями, но и с любым токеном в командной строке, который можно оценить, однако он был добавлен в командную строку.

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

Я думаю, что это не должно быть при удалении или возврате, потому что часть моей мотивации для сокращений - это возможность постредактировать _ части_ расширения перед выполнением. Возможно, лучше было бы добавить привязку для «удаления назад от курсора к текущему процессу», как определено в commandline -p . Это решило бы проблему с сокращениями (поскольку они расширяются только в командной позиции), но в то же время было бы действительно полезно без сокращений. Это будет работать в основном как Ctrl-U, но останавливаться в начале текущего «процесса». Вариант, соответствующий Ctrl-K, который останавливается на _end_ текущего процесса, может быть добавлен для согласованности и также может быть полезен.

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

Я не пробовал реализацию @terlar , но она основана на моей, где расширения действительно работают правильно в _любой_ позиции команды, а не только в начале строки, престиж commandline -p . На самом деле я в восторге от того, насколько хорошо работает мое грубое доказательство концептуального кода! : рыба:: сердце:

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

@ sch1zo Вставка должна работать, если вы используете Ctrl-Y .

это может быть так, но большую часть времени я копирую / вставляю с помощью выбора / среднего щелчка, и проблема присутствовала. Но в собственной реализации этой проблемы больше нет, и я уже обновил все свои машины, чтобы использовать ее.

Итак, после ~ 10 дней использования родных сокращений я обнаружил одну ошибку, которая меня беспокоит. Если вы уже набрали команду, а затем перешли к началу строки, чтобы добавить к ней аббревиатуру, она не расширяется и не будет работать в нерасширенном состоянии. Типичная для меня ситуация следующая:
Одно из моих сокращений - !=sudo поэтому теперь, когда я хочу отредактировать какой-либо файл конфигурации системы, как в vim /path/to/some/file/I/am/not/allowed/to/write я часто поздно понимаю, что мне нужен sudo, поэтому я обычно просто перехожу к началу и добавляю ! к сожалению, не расширит аббревиатуру и оставит мне сообщение command not found .
Мой текущий обходной путь для этого - просто добавить псевдоним для сокращения, но, разумеется, было бы лучше, если бы оно расширялось должным образом.

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

Коммит b6f495d1077b7627ea851da33936c77b2d594bb2 должен исправить проблему, которую идентифицировал

К этому следует добавить еще одно: мы, вероятно, должны сделать ll , la и подобные псевдонимы по умолчанию вместо функций.

Я перенастраиваю это на next-minor как эта функция, вероятно, появится в следующем выпуске.

Следующий релиз, скорее всего, выйдет совсем скоро, то есть к концу следующей недели. Я пока чищу документацию.

Сокращения будут включены в их текущее неполное состояние. Я не хочу публиковать или документировать их, пока мы не получим команду abbrev (или изменим назначение alias ). По этой причине я возвращаю это к следующему мажору.

Я не думаю, что alias - хороший термин. Для меня alias - это альтернативное имя ... не то, что нужно расширять.

Мне тоже не нравятся abbr по той же причине.

Я думал о expand foo "foobar" ... но похоже, что команда expand уже существует: / Жаль, я думаю, что expand было бы лучшим термином.

Как насчет объединения псевдонимов и сокращений? Вместо того, чтобы вводить новую функцию или исключать alias , введите параметр конфигурации для «расширения псевдонимов». Обратной стороной является то, что нам не нравятся параметры конфигурации в fish (но мы могли бы пропустить параметр конфигурации) и (возможно, это хорошо) это означает, что мы не можем смешивать два поведения, хотя вы все равно можете писать обычные функции, чтобы получить старую поведение псевдонима ... Плюс в том, что у нас нет двух способов делать похожие вещи, это легко объяснить («псевдонимы расширяются в рыбе»), а сокращения действительно будут работать в сценариях (потому что они также являются псевдонимами), которые также означает, что они также не должны быть выделены специальным регистром в выделителе синтаксиса. И, переместив механизм псевдонима в код C ++, мы можем избежать медлительности текущей реализации псевдонима. Тем не менее, все еще нужно выяснить, как заставить завершение работать для нерасширенных псевдонимов.

Один запрос функции ...

Раньше я использовал функции для выдачи часто используемых комбинаций команд в одной команде, таких как git add, git commit и git push, за одну операцию.

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

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

Не могу дождаться, когда эта функция появится в официальном выпуске!

Для меня это имеет смысл.

1a7b33e8fb75dd702730ca9637d760fbd23a4000 расширяет сокращения до точек с запятой.

Спасибо!

Где хранятся сокращения fish_user_abbrevations? Я хочу добавить их в свой репозиторий точечных файлов.

В настоящее время это универсальная переменная, поэтому она хранится в ~ / .config / fish / config.fish. Но это всего лишь временная хитрость, пока мы не выясним, как их правильно хранить. Отзывы здесь приветствуются.

Если хотите, вы можете просто добавить строку в config.fish, например set -g fish_user_abbreviations... чтобы установить ее вручную.

Хм, я не вижу там этой переменной.

Я использовал set -U fish_user_abbreviations 'g=git' . Это правильный способ добавить его в config.fish?

Извините, я имел в виду, что он будет храниться в ~/.config/fish/fishd.[mac_address] . Очевидно, что синхронизация не будет работать (по замыслу), поскольку она отключена от MAC.

Чтобы поместить его в config.fish, вы должны написать `set -g fish_user_abbreviations 'g = git'. -g для глобального, так как вы устанавливаете его каждый раз.

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

Если мы используем его как массив, либо с = для разделения ключей и значений, либо с ASCII FS ( \x1c ), тогда функция рыбы для управления им ( abbr ) + / - была бы полезна страница веб-интерфейса.

Следует подумать о производстве соответствующей продукции для экспорта / передачи.

@ridiculousfish Ах, спасибо, это очень помогло! Я буду делать это пока, пока не будет процесс экспорта.

Кстати, я нейтрально отношусь к тому, чтобы иметь либо А) один файл со всеми сокращениями, либо Б) отдельный файл для каждого сокращения. Может быть, склоняясь к А, но не сильно.

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

Вместо использования = в качестве разделителя мы могли бы просто использовать первый токен (разделенный пробелами?) Каждого элемента массива - это упростило бы реализацию.

Универсальная переменная удобна, но если мы не раскрываем ее напрямую, может быть лучше переместить ее в __fish_user_abbreviations (и, возможно, предупредить об установке на локальном или глобальном уровне).

Я бы предпочел space-separated вместо использования = качестве разделителя. Тем более, что этот стиль больше нигде внутри fish .

Я согласен с тем, что это должно быть разделено пробелами. Это имеет немного больше смысла, и это означает, что = может быть частью аббревиатуры, если это необходимо. Команду abbr вероятно, следует изменить, чтобы убрать флаг --add и вместо этого просто принять два аргумента.

Что касается $__fish_user_abbreviations , я могу посочувствовать этому предложению, но вполне вероятно, что пользователи могут захотеть изменить $fish_user_abbreviations сами, не используя команду abbr , и я бы не стал поощрять кто угодно может напрямую изменить переменную $__fish_* . Точно так же установка его на локальном или глобальном уровне вполне законна; не все хотят использовать универсальные переменные для подобных вещей.

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

Мое беспокойство по поводу поощрения модификации переменной вне команды abbr заключается в том, что расширение команды для поддержки области видимости увеличивает ее сложность с точки зрения пользовательского интерфейса, но невыполнение этого приводит к потенциально вводящим в заблуждение результатам. В настоящее время не происходит слияния областей видимости переменных, что может сбивать с толку - если вы установите универсальное расширение и (другое) глобальное расширение, должны ли они оба работать? Как же тогда остановить всеобщую экспансию в глобальном масштабе? Хотели бы люди когда-нибудь этим заниматься?

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

Нет необходимости выполнять какую-либо работу, чтобы «поддержать определение объема работ». Если abbr просто использует $fish_user_abbreviations , он будет использовать глобальную переменную, если она есть, или универсальную в противном случае. Именно так работает читатель. Единственная проблема заключается в том, что если пользователь устанавливает $fish_user_abbreviations в качестве локальной переменной на верхнем уровне, читатель на самом деле тоже это увидит. И простое исправление - добавить флаг -S к объявлению функции abbr , что позволит ему видеть локальные переменные, определенные в его родительском элементе. Но определенно нет необходимости пытаться объединить аббревиатуры (или каким-либо способом сделать это, за исключением временного удаления переменной в других областях).

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

Поддержка разделителя пробелов находится в fbade198b942a666d3fc1110804a7da2c47918f1

Если вы нажмете пробел, а он не расширяется, значит, вы знаете, что набрали его неправильно. Я не против подчеркивания или выделения (это, безусловно, было бы дополнительной подсказкой, чтобы сообщить пользователю, почему его командная строка просто изменилась), но я не уверен, что понимаю, почему вам нужно быть уверенным, прежде чем нажимать пробел.

@ridiculousfish Что касается fbade198b942a666d3fc1110804a7da2c47918f1, аббревиатуры достаточно новы (и недокументированы до недавнего мастера), поэтому мы должны просто удалить поддержку = .

Я думаю о случае до возврата, а не о случае до пробела

Звучит неплохо. Я полагаю, что _is_ возможно переборщить с выделением, что приведет к медлительности и дезориентирующей информационной перегрузке, но я не думаю, что здесь дело обстоит именно так. Кроме того, я предполагаю, что он будет использовать некоторую переменную $fish_color_abbr-or-whatever поэтому его могут легко отключить те, кто этого пожелает, по любой причине.

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

Мое замешательство возникло из-за того, что я смешивал выделение и функцию предлагаемого завершения.

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

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

Фактически, моя цель состоит в том, чтобы упаковать широкий спектр команд в небольшое пространство имен (я стараюсь использовать аббревиатуры примерно из 5 символов, а их сотни). Из-за этого я еще больше полагаюсь на руководство оболочки, которое я собираюсь ввести правильную команду. Что-то, что выполняет роль, которую занимает предполагаемое завершение, но для сокращений вместо обычных команд, действительно было бы полезно, даже для меня, больше, чем для стандартных команд.

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

По крайней мере, для меня включение самой аббревиатуры (а не расширения) в предлагаемые дополнения почесало бы мне зуд. Я просто хочу убедиться, что я правильно набираю префикс определенного сокращения. Этого достаточно, чтобы сказать мне, что я печатаю не напрасно, потому что неправильно запомнил или неправильно набрал свое сокращение.

Я попытался расширить abbr.fish для обработки как пробелов, так и разделителей = , но мне не удалось найти надежное решение без использования внешних инструментов.

Я думал, что план состоит в том, чтобы удалить = support? Я думал просто сделать это, а затем отправить сообщение в список рассылки fish со сценарием, который изменяет $ fish_user_abbreviations, которые люди могут запускать, чтобы переключиться на пробелы.

Эй, ребята,

Я хотел сделать заметку после того, как довольно давно использовал сокращения.

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

Единственное, что мне не нравится, это то, что для сокращений нет истории. Поскольку я использую сокращения почти для каждой команды, в результате я по большей части теряю функциональность истории. Хотя вы можете подумать, что сокращения должны быть достаточно короткими, чтобы не нуждаться в функциях истории, я обнаружил, что мне их совсем не хватает. У меня определено более 200 сокращений, и некоторые из них отличаются незначительно. Например, если история покажет мне тот, который я опубликовал вчера, было бы чрезвычайно полезно для более сложных и менее часто используемых сокращений. Поскольку я практически живу с сокращениями, мне пришлось прибегнуть к использованию функций вместо них, когда мне нужна поддержка истории, поскольку в противном случае у меня действительно нет истории.

Еще раз спасибо за эту функцию.

@binaryphile Очень интересно. Похоже, вы имеете представление о том, как это должно выглядеть (например, пользовательский интерфейс). Хотели бы вы описать это поподробнее?

Хороший вопрос. Думаю, мне бы просто хотелось, чтобы при запуске какого-либо расширения аббревиатура попадала в список истории. Итак, если бы я использовал аббревиатуру «gclon» вместо «git clone», то, когда я нажимал пробел (или точку с запятой), «gclon» добавлялся бы в мою историю. Я бы не стал изменять нормальное поведение сохранения расширенной команды в истории, поэтому обе будут доступны.

После этого, когда я начал набирать префикс аббревиатуры (например, «gcl»), я ожидал, что «gclon» будет первым всплывающим параметром автозаполнения.

В идеале, в этот момент я мог бы нажать alt-f, и они оба автоматически завершились до расширенной версии, а также предлагали новое автозаполнение этой расширенной команды из истории. Я бы хотел этого, потому что я мог ввести дополнительные аргументы после расширения и хотел бы, чтобы они были доступны как можно меньшим количеством нажатий клавиш по тому же маршруту, который я ввел в первую очередь (сокращенно, затем аргументы). Поскольку у аббревиатуры в истории не будет аргументов, для меня наиболее естественным способом продвинуться дальше по аргументу завершения за аргументом будет alt-f.

Я думаю, что ctrl-f не изменится и просто переместится к концу аббревиатуры, а не к расширенной версии, поскольку не будет визуальной подсказки относительно того, до чего вы расширяетесь.

Я только что подготовил и запустил каждую ночь, чтобы наконец проверить это! Мне очень нравится эта функция, и мне нравится тот факт, что с ней поставляется команда abbr .

Мой отзыв заключается в том, что нам нужен хороший способ экспорта для резервной копии точечных файлов. Я думаю, что все они должны быть помещены в один файл в формате abbr --show output. abbr --show мне пока достаточно, я просто собираюсь передать их в точечный файл. Но мне нужен простой способ импортировать их снова, когда придет время. Так что, если бы Fish могла импортировать этот формат сейчас, это было бы хорошим следующим шагом.

После выполнения команды в справке по добавлению нового сокращения возникает эта ошибка.

В настоящее время вам нужно ввести abbr -a "gco git checkout" но я думаю, что было бы разумнее поддержать случай, описанный в руководстве.

Ах, спасибо!

48d3536 вносит это изменение.

Я думаю, мы должны либо оставить поддержку разделителя '=' в следующем второстепенном выпуске и отключить его после этого, либо (молча?) Обновить людей fish_user_abbreviations .

Я собираюсь закрыть это как исправленное; Я подал №2051, чтобы отследить миграцию. Большое спасибо @dag за концепцию и всем тем, кто ее тестировал - с нетерпением жду ее выхода в ближайшее время!

W00t, спасибо всем, мне очень нравится эта функция !!

Я люблю сокращения, это гораздо приятнее, чем псевдонимы. Огромное спасибо!

Я наткнулся на эту ветку ^, когда искал, как хранить сокращения в файлах
Если кто-то здесь по той же причине споткнется, вы можете использовать abbr -s/--show . Например

abbr --show >> ~/.config/fish/config.fish

@dideler Я использую что-то похожее на то, что используется для автоматического резервного копирования, я также рекомендую использовать конвейер до sort .

abbr --show | sort > fish_abbreviation_backup;

Я помещаю все в файл fish_abbreviation_backup, а затем добавляю его в Homeshick для резервного копирования. Однако все это автоматизировано и работает на cron. После резервного копирования я source fish_abbreviation_backup чтобы рыба показывала алфавитный порядок при выполнении abbr --show .

Было бы неплохо, если бы рыба сохраняла сокращения в файле, как это происходит с функциями.

обновление: проблема с сортировкой сокращений при их сохранении -> https://github.com/fish-shell/fish-shell/issues/2156

Было бы неплохо, если бы рыба хранила аббревиатуры в файле ...

На странице руководства: «Сокращения хранятся с использованием универсальных переменных». Это означает, что вы найдете их в файле _ ~ / .config / fish / fishd.macaddr_ под именем переменной fish_user_abbreviations . Команда abbr просто манипулирует этой универсальной переменной.

Спасибо, можно ли было бы рассмотреть идею сохранить их в ~ / .config / fish / abbreviations.fish, чтобы мы могли легко добавлять их в наши точечные файлы?

@ElijahLynn : У меня есть файл abbrs.fish в ~ / .config / fish / conf.d / со следующим содержимым:

if not set -q fish_initialized
    abbr -a alsamixer alsamixer -c0
    abbr -a e emacs -nw
    abbr -a \$PAGER less
    abbr -a mu4e emacs --eval "\(mu4e\)"
    abbr -a pm pulsemixer
    abbr -a rm rm -I
    abbr -a sc systemctl
    abbr -a upo upower -i /org/freedesktop/UPower/devices/battery_BAT0
    abbr -a usc systemctl --user
    # Double-escaping needed
    abbr -a d2 env WINEPREFIX=/home/alfa/.wine32/ wine ~/.wine/drive_c/Program\\ Files\\ \\(x86\\)/Diablo\\ II/Diablo\\ II.exe
    abbr -a c curl -LO -C -
    set -U  fish_user_paths ~alfa/.local/bin $GOPATH/bin
    set -U fish_initialized
end

У меня есть это в моих точечных файлах , и я могу просто set -e fish_user_abbreviations; set -e fish_initialized ) и перезапустить рыбу.

Спасибо, мне может не хватать этого, но похоже, что вам нужно поддерживать это вручную и не добавлять легко управлять ими с помощью команды abbr .

Вы добавляете туда команду abbr. Это может быть даже результат вызова abbr --show .

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

Я думаю, что не только позиция в начале будет горсткой, например: s для sudo и n для nano которое может расширяться с s n to sudo nano , но не в текущей реализации.