share/functions/__fish_anyeditor.fish

function __fish_anyeditor --description "Print a editor to use, or an error message"
    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
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			`function __fish_anyeditor --description "Print a editor to use, or an error message"`
			`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`