Execute system commands via hotkeys or command palette in Obsidian (https://obsidian.md). Some automated events are also supported, and execution via URI links.
GNU General Public License v3.0
348
stars
11
forks
source link
Internal: Split variable parsing process to multiple phases #185
Input prompt modal (#37) needs a way to do variable parsing in stages. When showing up a modal that asks values from a user, the modal reserves some custom variables whose value will be known only after the user has submitted them. So, this reserving means that the variables cannot be parsed before the prompt fields are filled and the prompt modal closed.
Then again, previewing variable values in the command palette, context menus or in the prompt modal requires that even if all variables cannot be parsed before the modal is filled and closed, at least the variables that are not dependent of the Prompt's inputs, should be parsed before opening the modal.
So the parsing process should be split into (at least) two phases. Later, more phases can be added to allow more granular control over which variables can be available at which stages of program execution (= I don't mean shell command execution, I mean the plugin's JavaScript code's execution).
I've already programmed a lot of this change. I just made this issue so I can group the related commits better togerther, so that I won't refer the commits to #37 like I was going to do (or #159).
TODO:
[x] Fix This custom variable does not have a value yet error when the custom variable is used in a shell command and it gets its value from a Prompt. (Executing via the command palette fails, but works via the Execute now button). Seems that prompt opening is sometimes skipped.
Input prompt modal (#37) needs a way to do variable parsing in stages. When showing up a modal that asks values from a user, the modal reserves some custom variables whose value will be known only after the user has submitted them. So, this reserving means that the variables cannot be parsed before the prompt fields are filled and the prompt modal closed.
Then again, previewing variable values in the command palette, context menus or in the prompt modal requires that even if all variables cannot be parsed before the modal is filled and closed, at least the variables that are not dependent of the Prompt's inputs, should be parsed before opening the modal.
So the parsing process should be split into (at least) two phases. Later, more phases can be added to allow more granular control over which variables can be available at which stages of program execution (= I don't mean shell command execution, I mean the plugin's JavaScript code's execution).
I've already programmed a lot of this change. I just made this issue so I can group the related commits better togerther, so that I won't refer the commits to #37 like I was going to do (or #159).
TODO: