Fish-shell: Abreviaturas

Otra idea es nombrar estas "abreviaturas" como en Vim, y luego decidir qué hacer con los alias en otro número [tiendo a pensar que deberían eliminarse].

Pensé en otro argumento en contra:

• No se pueden utilizar estos "alias" en los scripts. No estoy seguro de que sea una buena idea usar alias en los scripts de todos modos, pero podríamos tener una función para expandir las "abreviaturas" y / o podríamos enganchar las abreviaturas de Fish en los editores para que también expandan la entrada allí.

Me gusta tu propuesta, suena genial y sospechosa: +1:

También me gusta esto.
Es una solución muy limpia para el problema de "terminaciones de alias" # 393 que es bastante molesto.
Esto combinado con una impresión ll (Alias) cuando hacer un ll<tab> sería perfecto.

Como alias es solo una envoltura de script alrededor de function hoy, me gustaría que eso también cambiara para que haya una diferencia clara entre las funciones y los alias, ya que difieren de muchas maneras después de esto, ex :

• Sintaxis
• Expresibilidad
• Uso

@gustafj Creo que probablemente sea mejor llamar a esta idea "abreviaturas" y reemplazar alias con algo que muestre un mensaje de error útil apuntando a function y abbreviate . ¿Pensamientos?

Otra nota:

Quería que esto solo afectara al comando en una línea de comando, porque sería realmente molesto si g siguiera expandiéndose a git en la posición del argumento. Sin embargo, es posible que también deseemos una expansión en las posiciones de los argumentos, por ejemplo, con sudo (lo que significaría que podría usar sudo con abreviaturas, ¡algo que no puede hacer con alias!) Y ciertos casos de terminaciones no ambiguas, como como para los propios alias de git o si escribe parte de una opción larga. Sin embargo, hacer esto bien podría ser complicado y solo se interpondría en el camino si las finalizaciones están desactualizadas, y si realmente quisiera sudo g no sudo git ahora tiene que hacer algo como sudo (echo git) . Quizás podríamos decir que los argumentos citados nunca se expanden, por lo que podría decir sudo "g" . No estoy seguro de si eso sería demasiado mágico y sorprendente o, de hecho, exactamente lo que uno esperaría e intuiría. ¿Pensamientos? :-)

Las abreviaturas me suenan bien (pero soy un usuario habitual de vim, por lo que podría ser parcial ...).
Cuando lo pienso, hay bastantes cosas "interesantes" que se pueden hacer con esto, pero (como ya has señalado) también hay trampas escondidas en este campo minado: /

Creo que podría ser problemático / molesto si es completamente automático y en cualquier lugar de la línea de comandos, principalmente porque deshacer la abreviatura podría ser tedioso si se expande a algo que no desea y particularmente si se expande a una cadena larga.

Algunos pensamientos míos:
¿Debería ser automático usando space o debería activarse mediante una opción a través de tab , u otra cosa?
¿Debería ser solo para cadenas simples ex g por git ?
¿Debería ser aplicable solo para el primer elemento de la línea de comandos o en cualquier lugar?
¿Debería ser posible realizar conversiones de cadena -> valor ex d para la fecha actual Tue May 14 20:23:03 CEST 2013 ?
¿Debería ser posible expandir subcapas ex vim (find . -iname '*cfg')<tab> da

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

¡Pensamientos sobre tus pensamientos!

¿Debería ser automático mediante el uso del espacio o debería activarse mediante una opción a través de una pestaña o algo más?

No creo que esto funcione con nada _pero_ espacio (e ingresar) porque el objetivo es obtener la experiencia perfecta que obtienes con los alias en los que no tienes que pensar en que algo sea un alias o no, y la pestaña no funciona ya sea porque g<Tab> debe completar los comandos que comienzan con g . Si agregamos un nuevo enlace, digamos CTRL-X, ahora tenemos tres tipos de terminaciones: normales, autosugestiones y abreviaturas. Realmente creo que esto debe hacerse con espacio o no hacerlo en absoluto.

¿Debería ser solo para cadenas simples ex g para git?

En la posición de mando debería ser posible incluir argumentos en una abreviatura. Por ejemplo gc expandiéndose a git commit --all o lo que sea. Básicamente, creo que las abreviaturas son exactamente como alias, excepto que se expanden en vivo en la línea de comandos.

¿Debería ser aplicable solo para el primer elemento de la línea de comandos o en cualquier lugar?

Solo en la posición de mando es probablemente un buen comienzo. Entonces podemos _quizás_ experimentar con los casos de uso de la posición del argumento que sugerí antes.

¿Debería ser posible realizar conversiones de cadena -> valor ex d para la fecha actual Martes 14 de mayo 20:23:03 CEST 2013?

¿Te refieres en posición de argumento? echo d expandiéndose para hacer eco de la fecha? Realmente creo que si hacemos abreviaturas de posición de argumento, debe usarse de manera muy conservadora y _sólo_ cuando el argumento es un comando (como en el caso de sudo ) o cuando el comando tiene su propio sistema de alias (como en el caso de git ) y expandir tendría exactamente el mismo efecto que no expandir (por lo que solo expandimos por usabilidad).

¿Debería ser posible expandir subcapas ex vim (find . -iname '*cfg')<tab>

Creo que esa es una pregunta para completaciones y no abreviaturas, ya que no creo que las abreviaturas involucren tabulaciones y expandir subcapas en el espacio probablemente sea una mala idea. Sin embargo, tampoco estoy seguro de que pueda funcionar para las terminaciones porque ya puede completar los nombres de las variables sin expandirlos.

Sin embargo, podría ser útil. Como me imagino haciendo rm *.png , expandiendo el comodín y eliminando algunos de los archivos de la lista.

Qué tal esto: tenemos un sistema de "expansión" o "abreviatura" genérico similar al sistema de terminaciones; vinculamos CTRL-X o algo para expandir tokens; y en la posición de mando también ampliamos las abreviaturas automáticamente. Eso también podría hacer que los casos de uso sudo y git funcionen de manera menos molesta al hacer explícitas esas expansiones.

Sin embargo, es una propuesta mucho más grande que mi idea original. :guiño:

El espacio como disparador me suena bien, probablemente brinda la mejor experiencia de usuario.
Expandir *.png suena interesante;)
A mí mismo no me gustan muchos enlaces diferentes para cosas diferentes, tal vez se podría usar "doble pestaña" en lugar de un nuevo enlace.
Ex ....*.png<tab> da press <tab> again to expand *.png (lo mismo para las subcapas).

Pero podría ser mejor limitar esta propuesta a: abreviaturas para el puesto de mando, expandir usando el espacio.
¿Y tiene "expandir subcapas / comodines" y soporte de sudo como uno separado?

No estoy seguro de que la doble pestaña funcione, ya que actualmente cambia entre finalizaciones. Vim parece tener CTRL +] para expandir abreviaturas sin escribir un espacio ...

Creo que si realizamos expansiones en vivo, entonces las abreviaturas deberían implementarse con eso de alguna manera, para que las ideas estén relacionadas. Pero si no hacemos expansiones en vivo, las abreviaturas deben considerarse solas. Así que no estoy seguro de qué hacer aquí. :-)

Sí, tienes razón sobre <tab> , solo estaba pensando en subcapas (donde actualmente no hace nada).
Podría ser posible cambiar el comportamiento actual de <anything><space><tab> que actualmente recorre todos los archivos disponibles en el directorio actual (primero imprimiéndolos todos).
Ex

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

Pero preferiría tener "expansiones en vivo" con una nueva combinación de teclas que vivir sin ella;)
Expandir *.cfg a a.cfg b.cfg c.cfg d.cfg siente realmente útil.
Pero luego todas las formas de posibles expansiones deberían ser expandibles, no solo comodines, finalización ex brace (que preferiría ver eliminado ... pero ese es un problema diferente # 354)

Pero luego todas las formas de posibles expansiones deberían ser expandibles, no solo comodines, finalización ex brace (que preferiría ver eliminado ... pero ese es un problema diferente # 354)

Acordado en ambas cuentas. Me pregunto si las comillas dobles también deberían ser expandibles ... echo "hello $USER" -> echo "hello dag" .

Creo que de lo que estamos hablando aquí es en realidad de "evaluación" más que de "expansión", mientras que, por otro lado, las abreviaturas no se refieren a la evaluación, por lo que estas ideas probablemente estén separadas y haré un nuevo número para el otro y editaré este un poco.

Aquí hay un prototipo de trabajo básico:

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'

Un problema que noté es que si presiona enter para ejecutar una línea de comando abreviada, la forma expandida se resalta como un error (comando desconocido), incluso incluyendo los argumentos.

Me gustó mucho esto, así que implementé una forma de administrar estas abreviaturas.

Al final, creo que estos deben manejarse de la misma manera que se manejan las finalizaciones y las funciones. Con su propia carpeta de abreviaturas donde se puede guardar.

Esta es la implementación actual:

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

Entonces haces algo como esto:

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

Actualización 1: agregue la capacidad de eliminar abreviaturas y almacenarlas en una variable universal.
Actualización 2: crear funciones para abreviaturas también

Mirando cómo funcionan las funciones, podríamos presentar:

• abbred
• abbrsave

Lo que básicamente sería clonar esas funciones.

¡Bonito! Sin embargo, no estoy _muy_ convencido de que necesitemos un directorio ~/.config/fish/abbreviations y el abbr{ed,save} acompaña. A diferencia de las funciones y finalizaciones, no son realmente lentas para cargar individualmente y solo necesitan una línea para ser definida. Creo que son más como bind , ¿quizás podríamos tener una función fish_[user_]abbreviations como la función fish_user_key_bindings , que se carga la primera vez que fish intenta expandir una abreviatura? ( [user_] por coherencia, pero no estoy seguro de que debamos enviar las abreviaturas predeterminadas)

La única razón por la que puedo pensar para tener varios archivos para abreviaturas es si tiene una abreviatura para cada comando git existente y algunos con argumentos, por lo que los quiere separados de los demás. Pero no es así como funcionan las funciones y finalizaciones de carga diferida: se cargan en función del nombre del comando, por lo que si hiciéramos eso para las abreviaturas, terminaríamos con un archivo para cada abreviatura, cada archivo conteniendo solo una línea de código. !

Otra idea es hacer algo como las variables universales, quizás incluso usando universales (como set -U fish_abbreviations ). ¿Quizás exista un caso de uso para las abreviaturas locales de host? No estoy seguro.

Tienes algunos buenos puntos y me estoy inclinando por el camino fish_user_abbreviations .

El otro enfoque sería tener compleciones similares en las que coloque todas las abreviaturas relacionadas en un archivo, pero eso podría ser más difícil de mapear.

Estaba planeando usar set -U fish_abbreviations al principio, pero me gusta que git mantenga la configuración, así que prefiero configurarlos en algún lugar, como una configuración. Pero lo bueno con una variable universal sería que puede agregar terminaciones sobre la marcha sin ningún tipo de atasco, como ( abbred , abbrsave ). Solo haz un abbreviate .

Una solución sería permitir que el comando se asegure de que las abreviaturas se agreguen de forma única y sobrescriba las existentes. Luego se arrancaría con el fish_user_abbreviations y los usuarios pueden agregar algunos personalizados a la variable universal si así lo desean.

Tengo esto ahora mismo:
set -q fish_abbreviations ; or fish_user_abbreviations

Pero eso no funcionará si sigo manteniendo el archivo.

Actualicé mis funciones anteriores para usar la variable universal y agregué la posibilidad de borrarlas y también verificar antes de agregar nuevas si existen.

Estaba pensando en hacerlo más interactivo, como preguntar si debería reemplazar la abreviatura actual. Pero como también podría estar escrito, no quería hacer eso. Examinaré la determinación del modo interactivo.

Bueno, lo que pasa con las terminaciones es que incluso están cargadas para un solo comando. Si el proceso de línea de comando actual es git completions/git.fish se carga [ef]grep que en realidad están en una función que se llama desde cada uno de esos tres archivos de finalización.

Con las abreviaturas, no veo ninguna forma de saber por la abreviatura qué archivo cargar, a menos que el nombre del archivo _es_ la abreviatura. Y luego no puede tener varias abreviaturas en un archivo. Supongo que podríamos cargar todos los archivos de abreviaturas al inicio, o en el primer intento de expandir las abreviaturas, pero eso es diferente de cómo se cargan las funciones y finalizaciones, y podría ser potencialmente lento si tiene muchos archivos de abreviaturas.

Nueva idea: abbreviate -U para hacer una abreviatura universal, y abbreviate -g o simplemente abbreviate para hacer una abreviatura global. Si hacemos eso, quizás deberíamos considerar hacerlo por bind también ...

También creo que abbreviate debería sobrescribir cualquier abreviatura existente, igual que bind y function y set ...

Todos son puntos válidos. Creo que tiene sentido simplemente sobrescribir como lo hacen todas las demás funciones.

También me gusta la sugerencia con universal y global, que brinda flexibilidad para elegir cómo manejar sus abreviaturas / enlaces. Sin embargo, no estoy completamente seguro de cómo implementar eso, y estoy pensando que tal vez esto debería ser una función incorporada para mejorar el rendimiento.

Sí, solo estaba creando un prototipo en scripts de peces para probarlo. Probablemente no desee que se active una secuencia de comandos lenta cada vez que escribe un espacio. :guiño:

Sí, todavía funciona muy bien. Lo he estado usando durante aproximadamente 1 día y ya no puedo imaginarme viviendo sin él, jaja: sonrisa:

:rubor:

Sin embargo, otro problema que he notado es que si haces C-a en una línea de comandos no vacía y escribes una abreviatura, no se expande en el espacio ya que estás en medio de una palabra. Entonces, digamos que sí make install oops necesita raíz C-a ! ahora tiene ![cursor]make install y escribir el espacio no expande la abreviatura ! . Voy a intentar solucionar esto con commandline -C .

Un tercer problema, que podría ser una característica, es que solo se expande cuando escribe un espacio o ingresa después de una abreviatura. Así que no, por ejemplo, si escribe un espacio, entonces C-a ! C-e . Esto podría ser una característica porque permite evitar la expansión de abreviaturas, pero creo que no es un poco complicado y, en su lugar, deberíamos tener un comando para ejecutar una línea de comando literalmente, un poco como el comando command pero también contabilidad para funciones de shell y funciones incorporadas. O alguna sintaxis especial, como \g en la posición de comando se interpreta como g y no se expande. La sintaxis especial tampoco es muy sospechosa, pero ya tenemos espacio antes del comando en mayúsculas y minúsculas para que signifique "no iniciar sesión en el historial", así que encoja los hombros.

Cuarto, y este es oscuro, si le gusta en el párrafo anterior, por lo que tiene una abreviatura sin expandir seguida de un espacio, luego haga C-a y espacio, la abreviatura se expande y se inserta un espacio adicional ¡después de! Nuevamente, es posible que deba verificar la posición del cursor con commandline -C .

Ah, y el primer problema que mencioné en un comentario anterior, solo ocurre si la abreviatura no ampliada es un comando desconocido. Entonces, una abreviatura gc expande a git commit y todo se resalta como un error, al presionar enter (sin un espacio), pero una abreviatura gs expande a git status y resalta correctamente, porque aparentemente tengo instalado ghostscript:

> which gs
/usr/bin/gs

También me pregunto si tal vez las abreviaturas deberían resaltarse como "comandos" conocidos incluso antes de presionar el espacio ... Actualmente, si escribo g es rojo hasta que escriba un espacio, pero si escribo git destaca como conocido incluso antes de un espacio.

Todos estos problemas probablemente podrían resolverse mejor si hacemos esto en las partes de C ++.

Solución tonta para los problemas de resaltado de sintaxis: cree un alias / función para cada abreviatura. :risa:

En realidad, tal vez sea una buena idea hacerlo de todos modos, hm ... Significa que las abreviaturas funcionarán en los scripts, en eval , con type ... No estoy seguro.

Su solución es la que estoy usando actualmente, pero no estoy seguro de si eso es lo que debería hacer al final, o si deberían estar destinados a usarse dentro de eval o type . Para mí, deberían ser solo una entrada. Pero supongo que no estaría de más dejar que se ejecuten también para obtener un soporte fácil para say sudo.

Así que he estado usando la implementación actual por un tiempo y estos son los problemas descubiertos con esta solución hasta ahora (no están relacionados con el enfoque: +1 :):

1. Al pegar texto, el último espacio se inserta al principio de la línea, por ejemplo, echo this is a test convierte en _echo this is atest cuando se pega, donde _ es un espacio.
2. Cuando se usa read incorporado, los enlaces en enter y space también se aplican allí. Entonces, por ejemplo, si quiero ingresar algún comando que no sea para leer, se expandirá. Supongo que en la implementación final esto debería estar desactivado de forma predeterminada y habilitado por read -s
3. Es un poco lento (~ 0.25-0.5 segundos)

Puede solucionar 1. pegando con C-y .

Para mí, C-y solo pega dentro del pescado (de lo que se corta dentro del pescado) y no del portapapeles de mi sistema. Copiar entre terminales u otras aplicaciones.

Creo que las abreviaturas son una idea genial.

Quiero permitir que las personas experimenten con abreviaturas para refinar cuáles deberían ser los comportamientos correctos. Revisé el soporte inicial para abreviaturas en maestro como 92099c7af23d0cebf52f89de4f9d829825e53ac8 y f9c2a77c67754324f3036ec79501c6131d19562b.

Un ejemplo de cómo usarlo:

set -U fish_user_abbreviations 'gc=git checkout'
gc

gc se expandirá a "git checkout" en el espacio o return.

Las abreviaturas son una lista, así que para agregar una nueva:

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

Las abreviaturas se expanden en "posiciones de comando" (por ejemplo, en subcapas o como argumentos para si), pero no como argumentos. Las abreviaturas tampoco se expanden en los guiones.

A continuación, se muestran algunos problemas sin resolver para debatir:

1. La "abreviatura" es larga y difícil de deletrear. ¿Podemos encontrar un nombre mejor? "Alias" sería bueno si no se hubiera usado para otras cosas. Una posibilidad es invertirlo, por ejemplo, "expansión". fish_user_expansions suena bien.
2. ¿Cómo se deben especificar las abreviaturas? La sintaxis gc=git checkout es liviana pero no se usa en ningún otro lugar en fish.
3. Es posible que no deseemos expandirnos al ingresar, solo el espacio. Expandir al ingresar tiene la desventaja de que el usuario no ve qué comando ejecutó hasta después de haberse comprometido a ejecutarlo. Si expandimos solo en el espacio, entonces los usuarios podrían escribir la abreviatura, seguida de espacio, seguido de enter, lo que no parece demasiado oneroso. Una segunda posibilidad es hacer que la primera entrada active la expansión y la segunda, la ejecute realmente.

Por otro lado, si el usuario especifica todas las abreviaturas, entonces la posibilidad de que el usuario ejecute algo accidentalmente es baja, por lo que expandir en enter puede estar bien.

1. La forma expandida de una abreviatura es solo una sustitución textual y no tiene por qué ser en sí misma un comando válido. Por ejemplo, puede hacer una abreviatura que resulte en comillas o paréntesis que no coincidan. Creo que esta es una característica potencialmente útil, pero significa que Fish no puede verificar la sintaxis del código que contiene abreviaturas, lo que significa que es posible que nunca podamos usarlas en scripts.
2. ¿Debería la expansión de la abreviatura experimentar una expansión de subcapa y variable antes de la sustitución? Creo que sí, porque eso los haría inmensamente flexibles. Las abreviaturas podrían ejecutar códigos de peces arbitrarios.
3. Si presiono el espacio, y la abreviatura se expande y cambié de opinión, tal vez debería poder presionar eliminar y expandirla.

Con suerte, después de vivir de ellos durante un tiempo, sabremos qué se siente bien.

Gracias, lo estoy ejecutando ahora y parece que funciona muy bien hasta ahora.

1. Podríamos usar la abreviatura abbr para abreviar. En cuanto a alias , si pensamos que es mejor, tal vez podría reemplazarse con este comportamiento. Si la gente quiere usar alias en sus scripts, simplemente puede hacer la función de ajuste. Las abreviaturas me parecen exactamente para lo que la gente usa alias normalmente.
2. Creo que sería bueno tener algunas funciones auxiliares para definir y también eliminar abreviaturas.
   Por ejemplo: abbr gc 'git checkout' y abbr -e gc .
   En mi opinión, es un poco engorroso hacer esta manipulación a través de la variable. También sería bueno asegurar que las abreviaturas son únicas. Así que solo tienes que definir uno nuevo para actualizarlo.
3. Prefiero el comportamiento que es ahora, muchas de mis abreviaturas como gs por git status no serían tan útiles si tuvieras que presionar la barra espaciadora. Sin embargo, estaría bien con la doble entrada para ejecutarlo como mencionaste.
4. Personalmente, estoy de acuerdo con no usarlos en scripts.
5. Sí, esto sería genial. Sin embargo, no puedo pensar en ninguna abreviatura para usar eso en la parte superior de mi cabeza.
6. Esta también es una buena idea, si presioné el espacio demasiado pronto para una abreviatura, por ejemplo. Esto también iría bien junto con la sugerencia número 3 como doble entrada (aunque todavía no estoy seguro de si quiero esa entrada adicional).

alias es el contenedor de compatibilidad POSIX de todos modos. No tengo ningún problema con que haga abreviaturas. Si escribe abbr gc 'git checkout' o algo por el estilo, quiere completar por git checkout todos modos.

Usé la implementación del script de terlar durante las últimas semanas y cambié a la nueva versión nativa hoy, así que aquí están mis dos centavos en los puntos abiertos

1. Creo que sería una gran idea dejar que alias haga abreviaturas ahora. Como bonificación, solucionaría las finalizaciones que no funcionan en los alias actuales.
2. lo que dijo terlar suena bien
3. Realmente me molestaría si tuviera que presionar dos veces Intro en las abreviaturas para ejecutarlas. Estaría bastante bien si también funcionaran sin expandir como alias con una sola pulsación de enter, pero luego tengo abreviaturas sin expandir en mi historial
4. -
5. ¿No significaría la expansión de variables que el contenido de las variables se incluirá en el comando y, por lo tanto, en su historial? Esto haría que la reutilización de dichos comandos del historial sea mucho menor, ya que ya no contienen la variable, sino solo su contenido anterior. ¿O entendí mal este punto?
6. No me veo usando la función de expansión porque no uso abbreviation más de 3 caracteres, lo que significa que todos están básicamente en la memoria muscular y sería más rápido borrar la línea actual. Esto podría ser diferente ahora, ya que la implementación nativa se puede usar en cualquier lugar y no solo al principio de la línea. Pero probablemente sea una buena idea si no significa que siempre tengo que presionar la barra espaciadora o presionar dos veces enter para expandirlos.

La "abreviatura" es larga y difícil de deletrear. ¿Podemos encontrar un nombre mejor? "Alias" sería bueno si no se hubiera usado para otras cosas. Una posibilidad es invertirlo, por ejemplo, "expansión". fish_user_expansions me suena bien.

De acuerdo, pero no vendido en "expansión".

¿Cómo se deben especificar las abreviaturas? La sintaxis gc = git checkout es liviana pero no se usa en ningún otro lugar de fish.

Simplemente debería ser una nueva incorporada, como complete y bind o para el caso function que el usuario puede llamar pero cuyo almacenamiento subyacente es opaco.

Es posible que no deseemos expandirnos al ingresar, solo el espacio. Expandir al ingresar tiene la desventaja de que el usuario no ve qué comando ejecutó hasta después de haberse comprometido a ejecutarlo. Si expandimos solo en el espacio, entonces los usuarios podrían escribir la abreviatura, seguida de espacio, seguido de enter, lo que no parece demasiado oneroso. Una segunda posibilidad es hacer que la primera entrada active la expansión y la segunda, la ejecute realmente.

Realmente creo que queremos expandirnos en Enter . Me imagino que me frustraría mucho fish: Unknown command “gc” y no me imagino que estaría solo en eso. Sin embargo, la expansión debería ocurrir en la línea de comando, antes de que se ejecute, de modo que verá la expansión en scrollback y es la forma expandida la que termina en el historial.

¿Debería la expansión de la abreviatura experimentar una expansión de subcapa y variable antes de la sustitución? Creo que sí, porque eso los haría inmensamente flexibles. Las abreviaturas podrían ejecutar códigos de peces arbitrarios.

Creo que no debería. Por lo general, sería preferible que se expandieran en el momento en que se ejecuta la línea de comando. Digamos que tengo una abreviatura para crear notas con sello de tiempo. Escribo la abreviatura y un espacio, y se expande a algo como vim 12:34:56.txt . Ahora, no ejecuto este comando durante unos segundos y la marca de tiempo será incorrecta. Sería mejor si la abreviatura se expandiera a vim (time +%T).txt . Esto hace lo correcto y también significa que tengo la opción de editar la línea de comando antes de ejecutarla, por ejemplo, para usar un formato de hora diferente. También lo hace repetible; por ejemplo, kill %firefox se pueden recuperar del historial y volver a ejecutar incluso cuando el PID haya cambiado. Por último, diría que es más consistente con el resto de peces, donde los tokens en la línea de comando solo se evalúan en el momento de la ejecución.

Por otro lado, evaluar en tiempo de expansión es estrictamente más poderoso porque podemos optar por no participar, por ejemplo, con escapes, pero sin él no podemos realmente _opt in_. Sin embargo, creo que esto se resolvería mejor con el # 751, ya que pone al usuario en control de la evaluación. Sin embargo, eso todavía no proporciona una manera de obtener el momento _exacto_ de expansión de abreviaturas; sería el momento en que el usuario ampliara el token individual. Aún así, creo que sería más útil y más coherente, ya que funcionaría no solo con abreviaturas sino con cualquier token en la línea de comandos que se pueda evaluar, sin embargo, se agregó a la línea de comandos.

Si presiono el espacio, y la abreviatura se expande y cambié de opinión, tal vez debería poder presionar eliminar y expandirla.

Creo que esto no debería estar en eliminar o retroceder, porque parte de mi motivación para las abreviaturas es la capacidad de editar posteriormente _partes_ de la expansión antes de la ejecución. Quizás una mejor idea sería agregar un enlace para "eliminar hacia atrás del cursor al proceso actual" como se define en commandline -p . Esto resolvería el problema con las abreviaturas (ya que solo se expanden en la posición de comando) pero al mismo tiempo sería realmente útil sin abreviaturas. Esto funcionaría básicamente como Ctrl-U pero se detendría al comienzo del "proceso" actual. Una variante correspondiente a Ctrl-K que se detiene al final del proceso actual podría agregarse para mantener la coherencia y también podría ser útil.

Esto podría ser diferente ahora, ya que la implementación nativa se puede usar en cualquier lugar y no solo al principio de la línea.

No he probado la implementación de @terlar , pero se basa en la mía, donde las expansiones realmente funcionan correctamente en la posición de comando _cualquier_, no solo al comienzo de la línea, felicitaciones commandline -p . ¡De hecho, estoy asombrado de lo bien que funciona mi crudo código de prueba de concepto! : pescado:: corazón:

hmm supongo que nunca intenté usar abreviaturas en otras posiciones de mando.
Sí, los prototipos funcionaron muy bien, el único inconveniente que tuve fue el problema de pegado mencionado, pero la función era demasiado buena para no usarla.

@ sch1zo Pegar debería funcionar si usa Ctrl-Y .

Ese podría ser el caso, pero la mayoría de las veces copio / pego seleccionando / haciendo clic en el medio y allí estaba el problema. Pero la implementación nativa ya no tiene ese problema y ya actualicé todas mis máquinas para usar esa.

Entonces, después de ~ 10 días de usar las abreviaturas nativas, encontré una cosa que me molesta. Si ya ha escrito un comando y luego salta al principio de la línea para anteponerlo con una abreviatura, no se expande y no funcionará en su estado no expandido. Una situación común para mí es la siguiente:
Una de mis abreviaturas es !=sudo así que ahora, cuando quiero editar algún archivo de configuración del sistema como en vim /path/to/some/file/I/am/not/allowed/to/write , a menudo me doy cuenta tarde de que necesito sudo, por lo que normalmente salto al principio y antepongo ! desafortunadamente eso no expandirá la abreviatura y me dejará con un mensaje command not found .
Mi solución actual para esto es simplemente agregar un alias para la abreviatura, pero porque sería mejor si se expandiera correctamente.

Acordado; necesitamos mirar la posición del cursor cuando se ingresa un espacio, no simplemente "el primer token". Alternativamente, primero inserte el espacio y luego analice la línea de comando y expanda la abreviatura.

Commit b6f495d1077b7627ea851da33936c77b2d594bb2 debería solucionar el problema que @ sch1zo identificó (con! Para sudo)

Otra cosa para agregar a esto: probablemente deberíamos hacer ll , la , y similares alias por defecto en lugar de funciones.

Estoy reorientando esto a next-minor ya que esta función probablemente se enviará con la próxima versión.

Es probable que el próximo lanzamiento sea muy pronto, es decir, a finales de la próxima semana. Solo estoy limpiando la documentación en este momento.

Las abreviaturas se incluirán en su estado actual, incompleto. No quiero publicitarlos ni documentarlos hasta que tengamos el comando abbrev (o reutilizar alias ). Por esa razón, estoy empujando esto de nuevo a la siguiente especialidad.

No creo que alias sea ​​un buen término. Para mí, un alias es un nombre alternativo ... no es algo que deba expandirse.

Tampoco me gusta abbr , por la misma razón.

Pensé en expand foo "foobar" ... pero parece que el comando expand ya existe: / Lástima, creo que expand habría sido el mejor término.

¿Qué tal unificar alias y abreviaturas? En lugar de introducir una nueva función o desaprobar alias , introduzca una opción de configuración para "expandir los alias". La desventaja aquí es que no nos gustan las opciones de configuración en fish (pero posiblemente podríamos omitir la opción de configuración) y (tal vez sea algo bueno) significa que no podemos mezclar los dos comportamientos, aunque aún puede escribir funciones normales para obtener la antigua. comportamiento de alias ... La ventaja es que no tenemos dos formas de hacer cosas similares, es fácil de explicar ("los alias se expanden en peces") y las abreviaturas realmente funcionan en los scripts (porque también son alias) que también significa que tampoco tienen que estar en mayúsculas especiales en el resaltador de sintaxis. Y al mover la maquinaria de alias al código C ++ podemos evitar la lentitud de la implementación de alias actual. Sin embargo, todavía necesito descubrir cómo hacer que las terminaciones funcionen para los alias no expandidos.

Solicitud de una función ...

Anteriormente usaba funciones para emitir combinaciones de comandos de uso frecuente en un solo comando, como git add, git commit y git push en una sola operación.

Me encanta la nueva función de abreviaturas. Creo que es enorme y estoy tratando de cambiarlo. Estoy de acuerdo con el hecho de que está limitado a una sola expansión de comando. Sin embargo, todavía quiero emitir varios comandos de una vez. Ahora puedo usar una abreviatura para el primer comando, seguida de un punto y coma, luego la abreviatura del segundo comando, etc. Funciona bien, de hecho creo que es mejor así.

Mi solicitud es que la expansión se active no solo con el espacio o la entrada, sino también con el punto y coma. Dado que el punto y coma es básicamente equivalente a una entrada diferida, supongo que esto también tendrá sentido para todos ustedes.

¡No puedo esperar a que esta función se publique en un lanzamiento oficial!

Tiene sentido para mi.

1a7b33e8fb75dd702730ca9637d760fbd23a4000 expande las abreviaturas en punto y coma.

¡Gracias!

¿Dónde se almacenan las abreviaturas_usuario_peces? Quiero agregarlos a mi repositorio de archivos de puntos.

Actualmente es una variable universal, por lo que se almacena en ~ / .config / fish / config.fish. Pero esto es solo un truco temporal hasta que descubramos la forma correcta de almacenarlos. Los comentarios aquí son bienvenidos.

Si lo desea, puede agregar una línea a config.fish como set -g fish_user_abbreviations... para configurarlo manualmente.

Hrm, no veo esa variable ahí.

Usé set -U fish_user_abbreviations 'g=git' . ¿Es esa la forma correcta de introducirlo en config.fish?

Lo siento, quise decir que se almacenaría en ~/.config/fish/fishd.[mac_address] . Obviamente, la sincronización no funcionará (por diseño) ya que está desconectada del MAC.

Para ponerlo en config.fish, escribiría `set -g fish_user_abbreviations 'g = git'. -g para global, ya que lo configura cada vez.

Creo que la variable universal es razonablemente ordenada, solo necesita una mejor interfaz de usuario envuelta alrededor.

Si lo usamos como una matriz, ya sea con = para dividir claves y valores, o ASCII FS ( \x1c ), entonces una función fish para administrarlo ( abbr ) + / - una página de interfaz web sería útil.

Debería pensarse en producir una producción adecuada para la exportación / transferencia.

@ridiculousfish Ahh, gracias, ¡eso es muy útil! Lo haré por ahora hasta que haya un proceso de exportación.

Por cierto, soy neutral en tener A) un solo archivo con todas las abreviaturas o B) un archivo separado para cada abreviatura. Quizás inclinándose hacia A pero no fuertemente.

Agregué una interfaz de usuario básica alrededor de la implementación existente como abbr ; use abbr -h para ver más. También agregué una interfaz de usuario de solo lectura a la interfaz web, pero sería bueno que eso hiciera más.

En lugar de usar = como separador, podríamos usar el primer token (¿separado por espacios?) De cada elemento de la matriz; esto simplificaría la implementación.

La variable universal está ordenada, pero si no la estamos exponiendo directamente, sería mejor moverla a __fish_user_abbreviations (y posiblemente advertir sobre su configuración a nivel local o global).

Preferiría space-separated lugar de usar = como separador. Especialmente porque ese estilo no se usa en ningún otro lugar dentro de fish .

Estoy de acuerdo en que esto debería estar separado por espacios. Tiene un poco más de sentido, y significa que = podría ser parte de la abreviatura si se desea. El comando abbr probablemente debería modificarse para eliminar el indicador --add y solo tomar dos argumentos en su lugar.

Con respecto a $__fish_user_abbreviations , puedo simpatizar con esta sugerencia, pero es plausible que los usuarios quieran modificar $fish_user_abbreviations ellos mismos sin usar el comando abbr , y prefiero no alentar que alguien modifique directamente una variable $__fish_* . Del mismo modo, establecerlo a nivel local o global es perfectamente legítimo; no todo el mundo quiere usar variables universales para cosas como esta.

En una nota relacionada, read probablemente debería expandir las abreviaturas en la entrada interactiva cuando se usa la bandera --shell .

Mi preocupación por alentar la modificación de la variable fuera del comando abbr es que extender el comando para admitir el alcance aumenta su complejidad en términos de interfaz de usuario, pero no hacerlo conduce a resultados potencialmente engañosos. No hay fusión de los alcances variables en la actualidad, lo que puede resultar confuso: si establece una expansión universal y una expansión global (diferente), ¿deberían funcionar ambas? Entonces, ¿cómo se desarma una expansión universal en el ámbito global? ¿Es esto algo que la gente querría hacer alguna vez?

La separación de espacios parece una buena idea. Para evitar confusiones, agregar una nueva abreviatura probablemente debería requerir un número ilimitado de argumentos, siendo el primero la "palabra" y el resto unido para convertirse en la "frase".

No es necesario realizar ningún trabajo para "respaldar el alcance". Si abbr simplemente usa $fish_user_abbreviations , usará la variable global si está presente, o la universal en caso contrario. Que es exactamente como trabaja el lector. El único inconveniente es que si el usuario establece $fish_user_abbreviations como una variable local en el nivel superior, el lector también lo verá. Y la solución simple consiste en añadir el -S bandera para el abbr declaración de la función, que le permitirá ver que las variables locales definidas en su matriz. Pero definitivamente no hay necesidad de intentar fusionar abreviaturas (ni ninguna forma de hacerlo, salvo eliminar temporalmente la variable en otros ámbitos).

Después de vivir en esto, creo que me gustaría ver las abreviaturas subrayadas o resaltadas de manera diferente, antes de expandirlas. Esto me da cierta confianza en que los escribí correctamente. ¿Pensamientos?

El soporte del separador de espacio está en fbade198b942a666d3fc1110804a7da2c47918f1

Si presiona el espacio y no se expande, entonces sabrá que no lo escribió correctamente. No me opongo a subrayar o resaltar (ciertamente sería una señal adicional para que el usuario sepa por qué su línea de comandos acaba de cambiar), pero no estoy seguro de entender por qué necesita tener confianza antes de presionar el espacio.

@ridiculousfish Con respecto a fbade198b942a666d3fc1110804a7da2c47918f1, las abreviaturas son lo suficientemente nuevas (e indocumentadas hasta el master reciente) que deberíamos eliminar el soporte = .

Estoy pensando en el caso antes del retorno, no en el caso antes del espacio

Suena bien para mí. Supongo que es posible exagerar con el resaltado, lo que resulta en lentitud y sobrecarga de información desorientadora, pero no creo que ese sea el caso aquí. Además, supongo que usaría alguna variable $fish_color_abbr-or-whatever para que aquellos que lo deseen pudieran deshabilitarla fácilmente, por cualquier motivo.

Al principio, iba a comentar que me parecía poco intuitivo que el comportamiento de resaltado sea diferente para las abreviaturas y los comandos normales, hasta que me di cuenta de que era incorrecto y que era coherente.

Mi confusión provino del hecho de que estaba mezclando el resaltado y la función de finalización sugerida.

Por ejemplo, cuando escribo "echo", el resaltado es rojo hasta que escribo el comando completo, que es como debería ser. Sin embargo, la finalización sugerida anticipa con éxito lo que estaba a punto de escribir y me asegura que voy en la dirección deseada.

No recibo tal retroalimentación para las abreviaturas, lo cual es desafortunado ya que con frecuencia no puedo encontrar acortamientos memorables de comandos, particularmente aquellos que se expanden a comandos complejos.

De hecho, el objetivo para mí es empaquetar una amplia gama de comandos en un espacio de nombres pequeño (busco ~ 5 abreviaturas de caracteres y tengo cientos de ellas). Debido a esto, confío aún más en la guía del shell que me dirijo a escribir un comando válido. Algo que cumpla la función que sugiere que ocupa la finalización, pero para abreviaturas en lugar de comandos regulares, sería realmente útil, más que para los comandos estándar, incluso para mí.

Puedo ver la dificultad que presentan las abreviaturas para las terminaciones sugeridas. No sería intuitivo que la abreviatura se expandiera a los comandos reales, ya que ya no sería contigua a lo que está escribiendo. Aún así, siento que podría ser mejor de lo que es ahora.

Al menos para mí, incluir la abreviatura en sí (no la expansión) en las terminaciones sugeridas me rascaría la picazón. Solo quiero ver que estoy escribiendo correctamente un prefijo de una abreviatura definida. Eso es suficiente para decirme que no estoy escribiendo en vano porque me olvidé o escribí mal mi abreviatura.

Intenté extender abbr.fish para manejar tanto los espacios como los separadores = , pero no he tenido mucho éxito al encontrar una solución sólida sin utilizar herramientas externas.

Pensé que el plan era eliminar el = soporte? Estaba pensando en hacerlo y luego publicar un mensaje en la lista de correo de peces con un script que contiene $ fish_user_abbreviations que la gente podría ejecutar para cambiar a espacios.

Hey gente,

Quería tomar nota después de haber usado abreviaturas durante bastante tiempo.

Soy un gran admirador y me hacen la vida mucho más fácil. Me gusta especialmente el hecho de que otras personas puedan ver los comandos que estoy emitiendo, de una forma familiar.

Lo único que me disgusta es que no hay historial de abreviaturas. Dado que utilizo abreviaturas para casi todos los comandos, esto ha terminado perdiendo la funcionalidad del historial en su mayor parte. Si bien puede pensar que las abreviaturas deben ser lo suficientemente cortas como para no necesitar la funcionalidad de historial, me parece que la extraño un poco. Tengo más de 200 abreviaturas definidas y algunas de ellas difieren solo ligeramente. Que la historia me muestre el que emití ayer, por ejemplo, sería inmensamente útil para las abreviaturas más complicadas y menos utilizadas. Como prácticamente vivo con abreviaturas, he tenido que recurrir al uso de funciones en las que necesito soporte de historial, ya que de lo contrario no tengo historial.

Gracias de nuevo por la función.

@binaryphile Muy interesante. Parece que tiene una idea en mente de cómo debería verse (es decir, la interfaz de usuario). ¿Le gustaría describirlo con más detalle?

Buena pregunta. Supongo que me gustaría que, si se activara alguna expansión, la abreviatura se incluyera en la lista del historial. Entonces, si mi abreviatura fuera "gclon" para "git clone", cuando presiono el espacio (o punto y coma), "gclon" se agregaría a mi historial. No alteraría el comportamiento normal de almacenar el comando expandido en el historial, por lo que ambos estarían disponibles.

Después de eso, cuando comencé a escribir un prefijo de la abreviatura (como "gcl"), esperaba que "gclon" fuera la primera opción para que apareciera el autocompletado.

Idealmente, en ese punto podría presionar alt-f y hacer que ambos se completen automáticamente en la versión expandida, además de ofrecer una nueva autocompletación de ese comando expandido del historial. Me gustaría eso porque es posible que haya ingresado más argumentos después de la expansión, y querría tenerlo disponible en la menor cantidad de pulsaciones de tecla posible a través de la misma ruta que ingresé en primer lugar (abreviatura y luego argumentos). Dado que la abreviatura en el historial no tendría los argumentos, alt-f sería el método más natural para avanzar más en la finalización argumento por argumento.

Creo que ctrl-f no cambiaría y solo avanzaría hasta el final de la abreviatura, no la versión expandida, ya que no habría una indicación visual de a qué se expandiría.

¡Acabo de hacer una acumulación nocturna para finalmente probar esto! Realmente me gusta esta función y me encanta el hecho de que tiene el comando abbr que la acompaña.

Mi opinión es que necesitamos una buena forma de exportar para la copia de seguridad de archivos dot. Creo que todos estos deberían ir en un archivo en el formato abbr --show salidas. abbr --show es lo suficientemente bueno para mí por ahora, solo los voy a canalizar en un archivo de puntos por ahora. Pero quiero una manera fácil de importarlos nuevamente cuando llegue ese momento. Entonces, si Fish pudiera importar ese formato ahora, sería un buen paso siguiente.

Siguiendo el comando en la ayuda para agregar una nueva abreviatura falla con este error.

Actualmente, debe ingresar abbr -a "gco git checkout" pero creo que tendría más sentido respaldar el caso descrito en el manual.

¡Ahh, gracias!

48d3536 hace ese cambio.

Creo que deberíamos dejar el soporte del separador '=' en la próxima versión menor y deshabilitarlo después de eso, o (¿en silencio?) Actualizar el fish_user_abbreviations .

Voy a cerrar esto como arreglado; Presenté # 2051 para rastrear la migración. Muchas gracias a @dag por el concepto y a todos los que lo probaron. ¡Esperamos ver este lanzamiento pronto!

¡W00t, gracias a todos, realmente AMO esta función!

Me encantan las abreviaturas, es una experiencia mucho más amigable que los alias. ¡Muchas gracias!

Me encontré con este hilo mientras buscaba cómo almacenar abreviaturas en los archivos ^de puntos
Si alguien tropieza aquí por la misma razón, puede usar abbr -s/--show . Por ejemplo

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

@dideler Estoy usando algo similar a eso para la copia de seguridad automatizada, también recomiendo canalizar a sort .

abbr --show | sort > fish_abbreviation_backup;

Pongo todo en un archivo fish_abbreviation_backup y luego lo agrego a Homeshick para hacer una copia de seguridad. Sin embargo, todo está automatizado y se ejecuta en cron. Después de hacer una copia de seguridad, source fish_abbreviation_backup para que el pez se muestre en orden alfabético al hacer un abbr --show .

Sería bueno que Fish mantuviera las abreviaturas en un archivo, similar a cómo hace las cosas con las funciones.

actualización: Problema para ordenar las abreviaturas al almacenarlas -> https://github.com/fish-shell/fish-shell/issues/2156

Sería bueno que los peces mantuvieran las abreviaturas en un archivo ...

Desde la página de manual: "Las abreviaturas se almacenan mediante variables universales". Lo que significa que los encontrará en el archivo _ ~ / .config / fish / fishd.macaddr_ con el nombre var fish_user_abbreviations . El comando abbr simplemente manipula esa var universal.

Gracias, ¿estaría bien considerar la idea de mantenerlos en ~ / .config / fish / abbreviations.fish para que podamos agregarlos fácilmente a nuestros archivos de puntos?

@ElijahLynn : Lo que hago es tener un archivo llamado "abbrs.fish" en ~ / .config / fish / conf.d /, con el siguiente contenido:

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

Tengo esto en mis archivos de puntos , y puedo colocarlo en cualquier máquina en la que aún no lo haya usado, y si quiero restablecer los abbrs, puedo borrarlos todos (hago set -e fish_user_abbreviations; set -e fish_initialized ) y reiniciar el pescado.

Gracias, puede que me esté perdiendo esto, pero parece que necesita mantenerlo manualmente y no puede agregar administrarlos fácilmente con el comando abbr .

Agrega el comando abbr allí. Esto incluso puede ser el resultado de una llamada abbr --show .

Solo en la posición de mando es probablemente un buen comienzo. Entonces, tal vez podamos experimentar con los casos de uso de la posición del argumento que sugerí antes.

Creo que no solo una posición en el inicio sería un puñado, por ejemplo: s por sudo y n por nano que puede expandirse desde s n a sudo nano , pero no en la implementación actual.