share/functions/__fish_anyeditor.fish

# localization: tier1
function __fish_anyeditor
    set -l editor
    if set -q VISUAL
        echo $VISUAL | read -at editor
    else if set -q EDITOR
        echo $EDITOR | read -at editor
    else
        __fish_echo string join \n -- \
            (_ 'External editor requested but $VISUAL or $EDITOR not set.') \
            (_ 'Please set VISUAL or EDITOR to your preferred editor.')
        return 1
    end
    string join \n -- $editor
    return 0
end
Prepare to not localize private function descriptions The overwhelming majority of localizable messages comes from completions: $ ls share/completions/ \| wc -l $ 1048 OTOH functions also contribute a small amount, mostly via their descriptions (so usually just one per file). $ ls share/functions/ \| wc -l $ 237 Most of these are private and almost never shown to the user, so it's not worth bothering translators with them. So: - Skip private (see the parent commit) and deprecated functions. - Skip wrapper functions like grep (where the translation seems to be provided by apropos), and even the English description is not helpful. - Assume that most real systems have "seq", "realpath" etc., so it's no use providing our own translations for our fallbacks. - Mark fish's own functions as tier1, and some barely-used functiosn and completions as tier3, so we can order them that way in po/*.po. Most translators should only look at tier1 and tier2. In future we could disable localization for tier3. See the explanation at the bottom of tests/checks/message-localization-tier-is-declared.fish Part of #11833 2025-09-29 09:30:35 +02:00			`# localization: tier1`
			`function __fish_anyeditor`
Open command script in external editor on Alt+o Fish functions are great for configuring fish but they don't integrate seamlessly with the rest of the system. For tasks that can run outside fish, writing scripts is the natural approach. To edit my scripts I frequently run $EDITOR (which my-script) Would be great to reduce the amount typing for this common case (the names of editor and scripts are usually short, so that's a lot of typing spent on the boring part). Our Alt+o binding opens the file at the cursor in a pager. When the cursor is in command position, it doesn't do anything (unless the command is actually a valid file path). Let's make it open the resolved file path in an editor. In future, we should teach this binding to delegate to "funced" upon seeing a function instead of a script. I didn't do it yet because funced prints messages, so it will mess with the commandline rendering if used from a binding. (The fact that funced encourages overwriting functions that ship with fish is worrysome. Also I'm not sure why funced doesn't open the function's source file directly (if not sourced from stdin). Persisting the function should probably be the default.) Alternative approach: I think other shells expand "=my-script" to "/path/to/my-script". That is certainly an option -- if we do that we'd want to teach fish to complete command names after "=". Since I don't remember scenarios where I care about the full path of a script beyond opening it in my editor, I didn't look further into this. Closes #10266 2024-01-26 11:06:17 +01:00			`set -l editor`
			`if set -q VISUAL`
			`echo $VISUAL \| read -at editor`
			`else if set -q EDITOR`
			`echo $EDITOR \| read -at editor`
			`else`
Fix __fish_list_current_token and friends for multiline commandlines Some of these handled multiline prompts but not multiline command lines. We first need to move the cursor to the end of the commandline, then we can print a message. Finally, we need to move the cursor back to where it was. 2024-04-11 12:34:58 +02:00			`__fish_echo string join \n -- \`
			`(_ 'External editor requested but $VISUAL or $EDITOR not set.') \`
			`(_ 'Please set VISUAL or EDITOR to your preferred editor.')`
Open command script in external editor on Alt+o Fish functions are great for configuring fish but they don't integrate seamlessly with the rest of the system. For tasks that can run outside fish, writing scripts is the natural approach. To edit my scripts I frequently run $EDITOR (which my-script) Would be great to reduce the amount typing for this common case (the names of editor and scripts are usually short, so that's a lot of typing spent on the boring part). Our Alt+o binding opens the file at the cursor in a pager. When the cursor is in command position, it doesn't do anything (unless the command is actually a valid file path). Let's make it open the resolved file path in an editor. In future, we should teach this binding to delegate to "funced" upon seeing a function instead of a script. I didn't do it yet because funced prints messages, so it will mess with the commandline rendering if used from a binding. (The fact that funced encourages overwriting functions that ship with fish is worrysome. Also I'm not sure why funced doesn't open the function's source file directly (if not sourced from stdin). Persisting the function should probably be the default.) Alternative approach: I think other shells expand "=my-script" to "/path/to/my-script". That is certainly an option -- if we do that we'd want to teach fish to complete command names after "=". Since I don't remember scenarios where I care about the full path of a script beyond opening it in my editor, I didn't look further into this. Closes #10266 2024-01-26 11:06:17 +01:00			`return 1`
			`end`
__fish_anyeditor: Add missing -- separator My $EDITOR is set to "emacs" and "-nw", which breaks this 2024-07-20 16:36:20 +02:00			`string join \n -- $editor`
Open command script in external editor on Alt+o Fish functions are great for configuring fish but they don't integrate seamlessly with the rest of the system. For tasks that can run outside fish, writing scripts is the natural approach. To edit my scripts I frequently run $EDITOR (which my-script) Would be great to reduce the amount typing for this common case (the names of editor and scripts are usually short, so that's a lot of typing spent on the boring part). Our Alt+o binding opens the file at the cursor in a pager. When the cursor is in command position, it doesn't do anything (unless the command is actually a valid file path). Let's make it open the resolved file path in an editor. In future, we should teach this binding to delegate to "funced" upon seeing a function instead of a script. I didn't do it yet because funced prints messages, so it will mess with the commandline rendering if used from a binding. (The fact that funced encourages overwriting functions that ship with fish is worrysome. Also I'm not sure why funced doesn't open the function's source file directly (if not sourced from stdin). Persisting the function should probably be the default.) Alternative approach: I think other shells expand "=my-script" to "/path/to/my-script". That is certainly an option -- if we do that we'd want to teach fish to complete command names after "=". Since I don't remember scenarios where I care about the full path of a script beyond opening it in my editor, I didn't look further into this. Closes #10266 2024-01-26 11:06:17 +01:00			`return 0`
			`end`