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 أو أي شيء آخر؟
هل يجب أن يكون فقط للسلاسل البسيطة مثل g مقابل git ؟
هل يجب أن يكون قابلاً للتطبيق فقط على العنصر الأول في سطر الأوامر ، أم في أي مكان؟
هل من الممكن عمل سلسلة -> تحويلات قيمة مثل d للتاريخ الحالي Tue May 14 20:23:03 CEST 2013 ؟
إذا كان من الممكن توسيع الأجزاء الفرعية مثل vim (find . -iname '*cfg')<tab> يعطي

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

افكار على افكارك!

هل يجب أن يكون تلقائيًا باستخدام المساحة أم يجب تشغيله بواسطة خيار عبر علامة تبويب ، أو أي شيء آخر؟

لا أعتقد أن هذا يعمل مع أي شيء _but_ (وإدخال) لأن بيت القصيد هو الحصول على التجربة السلسة التي تحصل عليها مع الأسماء المستعارة حيث لا يتعين عليك التفكير في شيء ما باعتباره اسمًا مستعارًا أم لا ، وعلامة التبويب لا العمل إما لأن g<Tab> يجب أن يكمل الأوامر التي تبدأ بـ g . إذا أضفنا رابطًا جديدًا يقول CTRL-X ، فلدينا الآن ثلاثة أنواع من الإكمالات: العادية والاقتراحات التلقائية والاختصارات. أعتقد حقًا أن هذا يحتاج إلى مساحة أو لا يجب القيام به على الإطلاق.

هل يجب أن يكون فقط لسلاسل بسيطة مثل g لـ git؟

في موقع القيادة ، يجب أن يكون من الممكن تضمين الحجج في الاختصار. على سبيل المثال gc يتوسع إلى git commit --all أو ماذا لديك. في الأساس ، أعتقد أن الاختصارات تشبه تمامًا الأسماء المستعارة ، إلا أنها تتوسع مباشرة في سطر الأوامر.

هل يجب أن يكون قابلاً للتطبيق فقط على العنصر الأول في سطر الأوامر ، أم في أي مكان؟

فقط في موقع القيادة ربما يكون بداية جيدة. ثم يمكننا _ ربما_ تجربة حالات استخدام موضع الوسيطة التي اقترحتها من قبل.

هل ينبغي أن يكون من الممكن عمل سلسلة -> تحويلات القيمة السابقة للتاريخ الحالي الثلاثاء 14 مايو 20:23:03 بتوقيت وسط أوروبا الصيفي 2013؟

تقصد في موقف الحجة؟ echo d تتوسع لتردد التاريخ؟ أعتقد حقًا أنه إذا استخدمنا اختصارات موضع المناقشة على الإطلاق ، فيجب استخدامها بحذر شديد و _ فقط_ عندما تكون الوسيطة أمرًا (كما في حالة sudo ) أو عندما يكون للأمر نظام اسم مستعار خاص به (كما في حالة git ) والتوسيع سيكون له نفس التأثير تمامًا مثل عدم التوسع (لذلك نحن نتوسع فقط لقابلية الاستخدام).

هل من الممكن توسيع الأقسام الفرعية مثل vim (find . -iname '*cfg')<tab>

أعتقد أن هذا سؤال يتعلق بالإكمال وليس الاختصارات ، لأنني لا أعتقد أن الاختصارات تتضمن علامات تبويب وتوسيع الأجزاء الفرعية على الفضاء ربما تكون فكرة سيئة. ومع ذلك ، لست متأكدًا من أنه يمكن أن يعمل مع الإكمالات إما لأنه يمكنك بالفعل إكمال أسماء المتغيرات دون توسيعها.

يمكن أن يكون مفيدا بالرغم من ذلك. كما أتخيل القيام بـ rm *.png ، وتوسيع حرف البدل وإزالة بعض الملفات من القائمة.

ماذا عن هذا: لدينا نظام "توسع" أو "اختصار" عام مشابه لنظام الإكمال ؛ نربط CTRL-X أو شيء ما لتوسيع الرموز ؛ وفي موقع القيادة نقوم أيضًا بتوسيع الاختصارات تلقائيًا. قد يؤدي ذلك أيضًا إلى جعل حالات الاستخدام sudo و git تعمل بشكل أقل اقتحامًا من خلال جعل هذه التوسعات صريحة.

إنه اقتراح أكبر بكثير من فكرتي الأصلية. :غمزة:

تبدو المساحة كمشغل جيدة بالنسبة لي ، وربما تعطي أفضل تجربة للمستخدم.
يبدو توسيع *.png مثيرًا للاهتمام ؛)
أنا شخصياً لا أحب الكثير من الروابط المختلفة لأشياء مختلفة ، ربما يمكن استخدام "علامة تبويب مزدوجة" بدلاً من ربط جديد.
Ex ....*.png<tab> يعطي press <tab> again to expand *.png (نفس الشيء بالنسبة للقطاعات الفرعية).

ولكن قد يكون من الأفضل قصر هذا الاقتراح على: اختصارات لموضع القيادة ، والتوسع باستخدام الفضاء.
ولديك "توسيع subshells / wildcards" ودعم sudo كواحد منفصل؟

لست متأكدًا من أن علامة التبويب المزدوجة ستعمل نظرًا لأن الدورات الحالية بين الإكمالات. يبدو أن Vim يحتوي على CTRL +] لتوسيع الاختصارات دون كتابة مسافة ...

أعتقد أنه إذا كنا نعيش توسعات على الإطلاق ، فيجب تنفيذ الاختصارات بذلك بطريقة أو بأخرى ، وبالتالي فإن الأفكار مرتبطة. ولكن إذا لم نقم بتوسعات حية ، فلا يزال يتعين النظر في الاختصارات بمفردها. لذلك لست متأكدًا مما يجب فعله هنا. :-)

نعم ، حقك في <tab> ، كان يفكر فقط في الأجزاء الفرعية (حيث لا يفعل شيئًا حاليًا).
قد يكون من الممكن تغيير السلوك الحالي لـ <anything><space><tab> والذي يتنقل حاليًا بين جميع الملفات المتاحة في dir الحالي (أولًا طباعتها جميعًا).
السابق

> 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 والتي هي في الواقع في وظيفة يتم استدعاؤها من كل من ملفات الإكمال الثلاثة هذه.

مع الاختصارات لا أرى أي طريقة لمعرفة من الاختصار أي ملف يتم تحميله ، ما لم يكن اسم الملف _is_ هو الاختصار. وبعد ذلك لا يمكنك الحصول على اختصارات متعددة في ملف واحد. أعتقد أنه يمكننا تحميل جميع ملفات الاختصارات عند البدء ، أو عند المحاولة الأولى لتوسيع الاختصارات ، ولكن هذا يختلف عن كيفية تحميل الوظائف والإكمال ، ومن المحتمل أن يكون بطيئًا إذا كان لديك العديد من ملفات الاختصارات.

فكرة جديدة: abbreviate -U لإنشاء اختصار عالمي ، و abbreviate -g أو abbreviate فقط لإنشاء اختصار عالمي؟ إذا فعلنا ذلك ، فربما يجب أن نفكر في القيام بذلك مقابل bind أيضًا ...

أعتقد أيضًا أن abbreviate يجب أن يقوم فقط بالكتابة فوق أي اختصار موجود ، مثل bind و function و set ...

كلها نقاط صالحة. أعتقد أنه من المنطقي الكتابة فوق مثل جميع الوظائف الأخرى.

يعجبني أيضًا الاقتراح العام والعالمي ، والذي يمنح المرونة لاختيار كيفية التعامل مع الاختصارات / الارتباطات الخاصة بك. لست متأكدًا تمامًا من كيفية تنفيذ ذلك ، وأعتقد أنه ربما ينبغي أن يكون هذا مدمجًا لتحسين الأداء؟

نعم ، كنت فقط أقوم بعمل نماذج أولية لها في البرمجة النصية للأسماك لتجربتها. ربما لا تريد إطلاق برمجة نصية بطيئة في كل مرة تكتب فيها مسافة. :غمزة:

نعم ، ما زلت تعمل بشكل رائع. لقد كنت أستخدمه منذ يوم واحد تقريبًا ولا أستطيع أن أتخيل نفسي أعيش بدونه بعد الآن ، هاها: ابتسامة:

:احمر خدود:

هناك مشكلة أخرى لاحظتها وهي أنك إذا قمت بعمل C-a على سطر أوامر غير فارغ وقمت بكتابة اختصار ، فلن يتم توسيعه على مساحة نظرًا لأنك في منتصف الكلمة. لنفترض أنك تحتاج make install عفوًا إلى الجذر 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 . بالنسبة لي يجب أن تكون مجرد مدخلات. لكنني أعتقد أنه قد لا يضر السماح لهم بالركض للحصول على دعم سهل لـ say sudo.

لذلك كنت أستخدم التنفيذ الحالي لفترة من الوقت الآن وهذه هي المشكلات التي تم اكتشافها مع هذا الحل حتى الآن (لا تتعلق بالنهج: +1 :):

1. عند لصق النص ، يتم إدخال المساحة الأخيرة في بداية السطر ، على سبيل المثال ، يصبح _echo this is atest 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 فقط داخل الأسماك (من ما يتم قطعه داخل الأسماك) وليس من حافظة النظام. النسخ بين المحطات أو التطبيقات الأخرى.

أعتقد أن الاختصارات فكرة رائعة حقًا.

أريد تمكين الناس من تجربة الاختصارات لتحسين السلوكيات الصحيحة. لقد تحققت من الدعم الأولي للاختصارات في Master كـ 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 خفيفة الوزن ولكنها لا تستخدم في أي مكان آخر في الأسماك.
3. قد نرغب في عدم التوسع في الإدخال ، فقط المساحة. التوسيع عند الإدخال له عيب يتمثل في أن المستخدم لا يرى الأمر الذي تم تنفيذه إلا بعد التزامه بتشغيله. إذا قمنا بالتوسع في المساحة فقط ، فيمكن للمستخدمين كتابة الاختصار ، متبوعًا بمسافة ، متبوعةً بإدخال ، والذي لا يبدو مرهقًا للغاية. الاحتمال الثاني هو جعل أول إدخال للتوسع في المشغل ، والإدخال الثاني ينفذه بالفعل.

من ناحية أخرى ، إذا تم تحديد جميع الاختصارات من قبل المستخدم ، فإن فرصة تشغيل المستخدم لشيء ما عن طريق الخطأ تكون منخفضة ، لذا قد يكون التوسيع عند الإدخال أمرًا جيدًا.

1. الشكل الموسع للاختصار هو مجرد استبدال نصي ، وليس بالضرورة أن يكون أمرًا صالحًا. على سبيل المثال ، يمكنك عمل اختصار يؤدي إلى عدم تطابق علامات الاقتباس أو الأقواس. أعتقد أن هذه ميزة يمكن أن تكون مفيدة ، لكنها تعني أن الأسماك لا يمكنها التحقق من بناء الجملة على التعليمات البرمجية التي تحتوي على الاختصارات ، مما يعني أننا قد لا نتمكن من استخدامها في البرامج النصية.
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. ما قاله terlar يبدو جيدًا
3. سوف يزعجني حقًا إذا كنت بحاجة إلى الضغط مرتين على الاختصارات لتنفيذها. سيكون من الجيد نوعًا ما إذا كانت تعمل أيضًا بدون توسيع مثل الأسماء المستعارة بضغطة واحدة على الإدخال ، ولكن بعد ذلك لدي اختصارات غير موسعة في تاريخي
4. -
5. ألا يعني التوسع المتغير أن محتوى المتغيرات سيتم وضعه في الأمر وبالتالي في السجل الخاص بك؟ هذا من شأنه أن يجعل إعادة استخدام مثل هذه الأوامر من التاريخ أقل بكثير لأنها لم تعد تحتوي على المتغير ولكن محتواها السابق فقط. أم أنني أسأت فهم هذه النقطة؟
6. لا أرى نفسي أستخدم ميزة unexpand لأنني لا أستخدم abbreviation أطول من 3 أحرف مما يعني أنهم جميعًا في ذاكرة العضلات وسيكون من الأسرع مسح السطر الحالي فقط. قد يكون هذا مختلفًا الآن نظرًا لأنه يمكن استخدام التنفيذ الأصلي في أي مكان وليس فقط في بداية السطر. ولكن ربما تكون فكرة جيدة إذا كان ذلك لا يعني أنه يجب علي دائمًا الضغط على مسافة أو الضغط مرتين على مفتاح الإدخال لتوسيعها.

كلمة "الاختصار" طويلة ويصعب تهجئتها - هل يمكننا العثور على اسم أفضل؟ سيكون "الاسم المستعار" جيدًا إذا لم يتم استخدامه بالفعل لأشياء أخرى. أحد الاحتمالات هو عكسها ، على سبيل المثال "التوسع". fish_user_expansions يبدو جيدًا بالنسبة لي.

متفق عليه ، لكنه لم يباع عند "توسع".

كيف يجب تحديد الاختصارات؟ تعتبر صيغة gc = git checkout خفيفة الوزن ولكنها لا تستخدم في أي مكان آخر في الأسماك.

يجب أن يكون ببساطة مدمجًا جديدًا ، تمامًا مثل complete و bind أو لهذا الأمر function يمكن للمستخدم الاتصال به ولكن التخزين الأساسي الخاص به غير شفاف.

قد نرغب في عدم التوسع في الإدخال ، فقط المساحة. التوسيع عند الإدخال له عيب يتمثل في أن المستخدم لا يرى الأمر الذي تم تنفيذه إلا بعد التزامه بتشغيله. إذا قمنا بالتوسع في المساحة فقط ، فيمكن للمستخدمين كتابة الاختصار ، متبوعًا بمسافة ، متبوعةً بإدخال ، والذي لا يبدو مرهقًا للغاية. الاحتمال الثاني هو جعل أول إدخال للتوسع في المشغل ، والإدخال الثاني ينفذه بالفعل.

أعتقد حقًا أننا نريد التوسع في Enter . أتخيل أنني سأحصل على الكثير من الإحباط fish: Unknown command “gc” ولا أتخيل أنني سأكون وحدي في ذلك. ومع ذلك ، يجب أن يحدث التوسيع في سطر الأوامر ، قبل أن يتم تنفيذه ، بحيث ترى التوسيع في التمرير الخلفي وهو الشكل الموسع الذي ينتهي به المطاف في السجل.

هل يجب أن يخضع توسيع الاختصار نفسه لقشرة فرعية وتوسع متغير قبل الاستبدال؟ أعتقد نعم ، لأن ذلك سيجعلهم أكثر مرونة. يمكن بعد ذلك تشغيل الاختصارات في رمز الأسماك العشوائي.

أعتقد أنه لا ينبغي. سيكون من الأفضل عادةً أن يتم توسيعها في وقت تنفيذ سطر الأوامر. لنفترض أن لدي اختصارًا لإنشاء ملاحظات مختومة بالوقت. أكتب الاختصار والمسافة ، ويتم توسيعها إلى شيء مثل vim 12:34:56.txt . الآن ، لا أقوم بتشغيل هذا الأمر لبضع ثوانٍ ، وسيكون الطابع الزمني خاطئًا. سيكون من الأفضل توسيع الاختصار إلى vim (time +%T).txt . هذا يفعل الشيء الصحيح ، ويعني أيضًا أن لدي خيار تحرير سطر الأوامر قبل تنفيذه ، على سبيل المثال لاستخدام تنسيق وقت مختلف. كما يجعلها قابلة للتكرار ؛ على سبيل المثال ، يمكن استدعاء kill %firefox من السجل وإعادة تشغيله حتى عندما يتغير PID. أخيرًا ، أود أن أزعم أنه أكثر اتساقًا مع بقية الأسماك ، حيث يتم تقييم الرموز المميزة في سطر الأوامر فقط في وقت التنفيذ.

من ناحية أخرى ، يعتبر التقييم في وقت التوسيع أكثر قوة لأنه يمكننا إلغاء الاشتراك فيه على سبيل المثال ، ولكن بدونه لا يمكننا فعلاً أن نختار. أعتقد أنه سيتم حل هذا بشكل أفضل من خلال الرقم 751 ، لأنه يضع المستخدم في التحكم في التقييم. هذا لا يزال لا يوفر طريقة للحصول على لحظة _exact_ لتوسيع الاختصار بالرغم من ذلك ؛ ستكون لحظة قيام المستخدم بتوسيع الرمز المميز الفردي. ومع ذلك ، أعتقد أنه سيكون أكثر فائدة وأكثر اتساقًا ، لأنه لن يعمل فقط مع الاختصارات ولكن مع أي رمز مميز في سطر الأوامر يمكن تقييمه ، ولكن تمت إضافته إلى سطر الأوامر.

إذا وصلت إلى الفضاء ، وتوسع الاختصار وغيرت رأيي ، فربما أتمكن من الضغط على حذف وإلغاء توسيعه.

أعتقد أن هذا لا يجب أن يكون عند الحذف أو مسافة للخلف ، لأن جزءًا من حافزي للاختصارات هو القدرة على تعديل أجزاء_ من التوسيع قبل التنفيذ. ربما تكون الفكرة الأفضل هي إضافة ارتباط لـ "حذف عكسيًا من المؤشر إلى العملية الحالية" كما هو محدد بواسطة 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 إلى إصلاح المشكلة التي حددها @ sch1zo (باستخدام! لـ sudo)

شيء آخر نضيفه إلى هذا: من المحتمل أن نجعل ll ، la ، والأسماء المستعارة المشابهة افتراضيًا بدلاً من الوظائف.

سأعيد توجيه هذا إلى next-minor حيث من المحتمل أن يتم شحن هذه الميزة مع الإصدار التالي.

من المحتمل أن يكون الإصدار القادم قريبًا جدًا ، أي بنهاية الأسبوع المقبل. أنا فقط أقوم بتنظيف الوثائق في الوقت الحالي.

سيتم تضمين الاختصارات في حالتها الحالية غير المكتملة. لا أرغب في نشرها أو توثيقها حتى يكون لدينا الأمر abbrev (أو إعادة الغرض من alias ). لهذا السبب أنا أعيد هذا إلى التخصص التالي.

لا أعتقد أن مصطلح alias هو مصطلح جيد. بالنسبة لي ، alias هو اسم بديل ... ليس شيئًا يمكن توسيعه.

لا أحب أيضًا abbr لنفس السبب.

فكرت في expand foo "foobar" ... لكن يبدو أن الأمر expand موجود بالفعل: / سيء جدًا ، أعتقد أن expand كان من الممكن أن يكون المصطلح الأفضل.

ماذا عن توحيد الأسماء المستعارة والاختصارات؟ بدلاً من إدخال وظيفة جديدة أو إهمال alias ، أدخل خيار تكوين "لتوسيع الأسماء المستعارة". الجانب السلبي هنا هو أننا لا نحب خيارات التكوين في الأسماك (ولكن ربما يمكننا تخطي خيار التكوين) و (ربما شيء جيد) هذا يعني أنه لا يمكننا مزج السلوكين على الرغم من أنه لا يزال بإمكانك كتابة وظائف عادية للحصول على القديم سلوك الاسم المستعار ... الجانب الإيجابي هو أنه ليس لدينا طريقتان للقيام بأشياء مماثلة ، فمن السهل شرح ("الأسماء المستعارة تتوسع في الأسماك") وستعمل الاختصارات في الواقع في النصوص (لأنها أيضًا أسماء مستعارة) والتي يعني أنه ليس من الضروري أن تكون مغلفة بشكل خاص في أداة تمييز بناء الجملة أيضًا. ومن خلال نقل آلية الاسم المستعار إلى كود C ++ ، يمكننا تجنب بطء تطبيق الاسم المستعار الحالي. ما زلت بحاجة إلى معرفة كيفية جعل عمليات الإكمال تعمل مع الأسماء المستعارة غير الموسعة.

طلب ميزة واحد ...

كنت أستخدم في السابق وظائف لإصدار مجموعات أوامر مستخدمة بشكل متكرر في أمر واحد ، مثل git add و git الالتزام و git push في عملية واحدة.

أحب ميزة الاختصار الجديدة. أعتقد أنها ضخمة وأحاول التحول إليها. أنا موافق على حقيقة أنه يقتصر على توسيع أمر واحد. ومع ذلك ، ما زلت أرغب في إصدار أوامر متعددة دفعة واحدة. الآن يمكنني فقط استخدام اختصار للأمر الأول ، متبوعًا بفاصلة منقوطة ، ثم اختصار الأمر الثاني ، إلخ. إنه يعمل بشكل جيد ، في الحقيقة أعتقد أنه من الأفضل بهذه الطريقة.

طلبي هو أن يتم تشغيل التوسيع ليس فقط عن طريق المسافة أو الإدخال ولكن أيضًا بفاصلة منقوطة. نظرًا لأن الفاصلة المنقوطة تعادل بشكل أساسي الإدخال المتأخر ، أعتقد أن هذا سيكون منطقيًا لكم جميعًا أيضًا.

لا يمكنك الانتظار حتى يتم إسقاط هذه الميزة في إصدار رسمي!

له معنى بالنسبة لي.

1a7b33e8fb75dd702730ca9637d760fbd23a4000 يوسع الاختصارات على الفواصل المنقوطة.

شكرا!

أين يتم تخزين fish_user_abbreviations؟ أريد إضافتها إلى ملفات الريبو الخاصة بي.

إنه حاليًا متغير عالمي ، لذلك يتم تخزينه في ~ / .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 آه ، شكرًا ، هذا مفيد جدًا! سأفعل ذلك الآن حتى تكون هناك عملية للتصدير.

راجع للشغل ، أنا محايد لامتلاك إما أ) ملف واحد مع جميع الاختصارات أو ب) ملف منفصل لكل اختصار. ربما يميل نحو A ولكن ليس بقوة.

أضفت واجهة مستخدم أساسية حول التطبيق الحالي مثل 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 ، الاختصارات جديدة بما فيه الكفاية (وغير موثقة حتى المعلم الحديث) يجب علينا فقط إزالة الدعم = .

أفكر في حالة ما قبل الإرجاع ، وليس حالة ما قبل الفضاء

يبدو أمرا جيدا لي. أفترض أنه _ من الممكن_ المبالغة في تسليط الضوء ، مما يؤدي إلى التباطؤ وإرباك المعلومات الزائدة ، لكنني لا أعتقد أن هذا هو الحال هنا. أيضًا ، أفترض أنه سيستخدم متغيرًا $fish_color_abbr-or-whatever لذلك يمكن بسهولة تعطيله من قبل أولئك الذين يرغبون في ذلك ، لأي سبب من الأسباب.

في البداية كنت سألاحظ أنني وجدت أنه من غير البديهي أن يكون سلوك التمييز مختلفًا للاختصارات عن الأوامر العادية ، حتى أدركت أنني غير صحيح وأنه متسق.

جاء ارتباكي من حقيقة أنني كنت أخلط بين ميزة الإبراز وميزة الإكمال المقترحة.

على سبيل المثال ، عندما أكتب "echo" ، يكون التمييز باللون الأحمر حتى أقوم بكتابة الأمر الكامل ، وهو ما ينبغي أن يكون. ومع ذلك ، فإن الإكمال المقترح يتوقع بنجاح ما كنت على وشك كتابته ويعطيني الطمأنينة بأنني أسير في الاتجاه المقصود.

لا أتلقى مثل هذه التعليقات للاختصارات ، وهو أمر مؤسف لأنني لا أستطيع في كثير من الأحيان التوصل إلى اختصارات لا تنسى للأوامر ، لا سيما تلك التي تمتد إلى أوامر معقدة.

في الواقع ، هدفي هو حزم مجموعة واسعة من الأوامر في مساحة اسم صغيرة (ألتقط ~ 5 اختصارات أحرف ولدي المئات منها). لهذا السبب ، أعتمد بشكل أكبر على توجيهات الصدفة التي أتجه نحو كتابة أمر صالح. هناك شيء يفي بالدور الذي اقترح أن يشغله الإكمال ، ولكن للاختصارات بدلاً من الأوامر العادية ، سيكون مفيدًا حقًا ، أكثر من الأوامر القياسية حتى بالنسبة لي.

أستطيع أن أرى صعوبة الإكمالات المقترحة التي تشكلها الاختصارات. سيكون من غير المنطقي أن يتوسع الاختصار في الأوامر الفعلية لأنه لم يعد متجاورًا مع ما تكتبه. ومع ذلك ، أشعر أنه يمكن أن يكون أفضل مما هو عليه الآن.

على الأقل بالنسبة لي ، فإن تضمين الاختصار نفسه (وليس التوسيع) في الإكمالات المقترحة من شأنه أن يخدش الحكة لدي. أريد فقط أن أرى أنني أكتب بشكل صحيح بادئة لاختصار محدد. هذا يكفي لإخباري أنني لا أكتب عبثًا لأنني أخطأت في تذكر الاختصار أو أخطأت في كتابته.

حاولت توسيع abbr.fish للتعامل مع كلا الفراغين وفواصل = ، لكن لم أحقق نجاحًا كبيرًا في التوصل إلى حل قوي دون الحاجة إلى استخدام أدوات خارجية.

اعتقدت أن الخطة كانت لإزالة = الدعم؟ كنت أفكر في القيام بذلك فقط ، ثم إرسال رسالة إلى القائمة البريدية للأسماك مع نص يقوم بتجميع $ fish_user_abbreviations الذي يمكن للأشخاص تشغيله للتبديل إلى المساحات.

مرحبا يا اصدقاء،

كنت أرغب في تدوين ملاحظة بعد استخدام الاختصارات لبعض الوقت الآن.

أنا معجب كبير ، وهم يجعلون حياتي أسهل بكثير. يعجبني بشكل خاص حقيقة أن الآخرين يمكنهم رؤية الأوامر التي أُصدرها ، في شكل مألوف.

يكرهني الوحيد أنه لا يوجد تاريخ للاختصارات. نظرًا لأنني أستخدم الاختصارات لكل أمر تقريبًا ، فقد انتهى بي الأمر بفقدان وظائف السجل في معظم الأحيان. بينما قد تعتقد أن الاختصارات يجب أن تكون قصيرة بما يكفي لعدم الحاجة إلى وظيفة السجل ، أجد نفسي أفتقدها قليلاً. لدي أكثر من 200 اختصار محدد ، وبعضها يختلف قليلاً فقط. إن وجود التاريخ يوضح لي ما قمت بإصداره بالأمس ، على سبيل المثال ، سيكون مفيدًا للغاية للاختصارات الأكثر مشاركة والأقل استخدامًا. نظرًا لأنني أعيش عمليًا مع الاختصارات ، فقد اضطررت إلى اللجوء إلى استخدام الوظائف بدلاً من ذلك حيث أحتاج إلى دعم التاريخ لأنني لا أملك تاريخًا بخلاف ذلك.

شكرا مرة أخرى على الميزة.

binaryphile مثير جدا للاهتمام. يبدو أن لديك فكرة عن الشكل الذي يجب أن يبدو عليه (مثل واجهة المستخدم). هل ترغب في وصفها بمزيد من التفصيل؟

سؤال جيد. أعتقد أنني أحب ذلك تمامًا إذا تم تشغيل أي توسع ، فحينئذٍ ينتقل الاختصار إلى قائمة المحفوظات. لذلك إذا كان الاختصار الخاص بي هو "gclon" لـ "git clone" ، فعند الضغط على مسافة (أو فاصلة منقوطة) ، ستتم إضافة "gclon" إلى سجلي. لن أغير السلوك الطبيعي لتخزين الأمر الموسع في التاريخ ، لذلك سيكون كلاهما متاحًا.

بعد ذلك ، عندما بدأت في كتابة بادئة من الاختصار (مثل "gcl") ، كنت أتوقع أن يكون "gclon" هو الخيار الأول المنبثق للإكمال التلقائي.

من الناحية المثالية ، في هذه المرحلة ، سأكون قادرًا على الوصول إلى alt-f وإكماله تلقائيًا إلى الإصدار الموسع ، بالإضافة إلى تقديم المزيد من الإكمال التلقائي الجديد لهذا الأمر الموسع من التاريخ. أرغب في ذلك لأنني ربما أدخلت حججًا إضافية بعد التوسيع ، وأريد أن يكون ذلك متاحًا في أقل عدد ممكن من ضغطات المفاتيح عبر نفس المسار الذي أدخلته في المقام الأول (اختصار ثم الوسيطات). نظرًا لأن الاختصار في التاريخ لن يحتوي على الحجج ، فإن طريقة alt-f ستكون الطريقة الأكثر طبيعية بالنسبة لي للمضي قدمًا في حجة الإكمال بالحجة.

أعتقد أن ctrl-f لن يتغير وسيتقدم فقط إلى نهاية الاختصار ، وليس النسخة الموسعة ، حيث لن يكون هناك دليل مرئي لما سوف تتوسع إليه.

لقد حصلت للتو على بناء وتشغيل ليلي لاختبار هذا أخيرًا! تعجبني هذه الميزة حقًا وأحب حقيقة أنها تحتوي على الأمر abbr الذي يأتي معها.

ملاحظاتي هي أننا بحاجة إلى طريقة جيدة للتصدير للنسخ الاحتياطي dotfile. أعتقد أن كل هذه الأمور يجب أن تنتقل إلى ملف واحد بتنسيق المخرجات abbr --show . abbr --show جيد بما يكفي بالنسبة لي في الوقت الحالي ، سأقوم فقط بتوجيههم إلى ملف نقطي في الوقت الحالي. لكني أريد طريقة سهلة لاستيرادها مرة أخرى عندما يحين ذلك الوقت. لذا ، إذا كان بإمكان Fish استيراد هذا التنسيق الآن ، فستكون هذه خطوة تالية جيدة.

فشل اتباع الأمر في المساعدة لإضافة اختصار جديد مع هذا الخطأ.

تحتاج حاليًا إلى إدخال abbr -a "gco git checkout" لكنني أعتقد أنه سيكون من المنطقي دعم الحالة الموضحة في الدليل.

آه ، شكرا!

48d3536 يجعل هذا التغيير.

أعتقد أنه يجب علينا إما ترك دعم الفاصل '=' في الإصدار الثانوي التالي وتعطيله بعد ذلك ، أو (بصمت؟) ترقية الأشخاص fish_user_abbreviations .

سأغلق هذا على أنه ثابت ؛ لقد قدمت رقم 2051 لتتبع الهجرة. شكرًا جزيلاً لـ dag على هذا المفهوم وكل من

W00t ، شكرًا للجميع ، أنا حقًا أحب هذه الميزة !!

أنا أحب الاختصارات ، إنها تجربة أكثر ودية من الأسماء المستعارة. شكرا جزيلا!

لقد صادفت هذا الموضوع أثناء البحث عن كيفية تخزين الاختصارات في ملفات dotfiles ^{1 ، 2} .
إذا تعثر أحد هنا للسبب نفسه ، فيمكنك استخدام abbr -s/--show . على سبيل المثال

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

dideler أنا أستخدم شيئًا مشابهًا لذلك للنسخ الاحتياطي الآلي ، أوصي أيضًا sort .

abbr --show | sort > fish_abbreviation_backup;

أضع كل شيء في ملف fish_abbreviation_backup ثم أضفته إلى Homeshick للنسخ الاحتياطي. كل شيء مؤتمت على الرغم من أنه يعمل على كرون. بعد أن أقوم بعمل نسخة احتياطية من I source fish_abbreviation_backup بحيث تظهر السمكة ترتيبًا أبجديًا عند إجراء abbr --show .

سيكون لطيفًا إذا احتفظت الأسماك بالاختصارات في ملف ، على غرار الطريقة التي تعمل بها الأشياء مع الوظائف.

تحديث: مشكلة لفرز الاختصارات عند تخزينها -> https://github.com/fish-shell/fish-shell/issues/2156

سيكون من الرائع إذا احتفظت الأسماك بالاختصارات في ملف ...

من صفحة الدليل: "يتم تخزين الاختصارات باستخدام المتغيرات العامة." مما يعني أنك ستجدهم في ملف _ ~ / .config / fish / fishd.macaddr_ تحت اسم var fish_user_abbreviations . يتعامل الأمر abbr ببساطة مع هذا var العام.

شكرًا ، هل سيكون من المقبول التفكير في فكرة الاحتفاظ بها في ~ / .config / fish / abbreviations.fish حتى نتمكن من إضافتها بسهولة إلى ملفات dotfiles الخاصة بنا؟

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

لدي هذا في dotfiles الخاص بي ، ويمكنني فقط إسقاطه في أي جهاز لم أستخدمه بعد ، وإذا كنت أرغب في إعادة تعيين الاختصارات ، فيمكنني محوها جميعًا (أفعل set -e fish_user_abbreviations; set -e fish_initialized ) و إعادة تشغيل الأسماك.

شكرًا ، قد أفتقد هذا ولكن يبدو أنك بحاجة إلى الحفاظ على ذلك يدويًا ولا يمكنك إضافته بسهولة باستخدام الأمر abbr .

يمكنك إضافة الأمر abbr هناك. يمكن أن يكون هذا ناتجًا لمكالمة abbr --show .

فقط في موقع القيادة ربما يكون بداية جيدة. ثم يمكننا ربما تجربة حالات استخدام موقف الحجة التي اقترحتها من قبل.

لا أعتقد أن المركز في البداية سيكون قليلًا فقط ، على سبيل المثال: s لـ sudo و n لـ nano والذي يمكن أن يتوسع من s n إلى sudo nano ، لكن ليس في التطبيق الحالي.