-
-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tp.file.cursor should change the mode to edit mode if in reading mode #1232
Comments
Could be related to #1112 |
I am experiencing this as well with same versions but macOS 13.4.1 (a). edit: Sorry I might have misread the original issue,
No longer works for me |
I'd argue that this is expected and desired behavior. It would be weird if a user setup multiple cursors and suddenly they're all gone because they were accidentally in reading mode instead of editing mode. Note Example of multiple cursors.
I recommend switching to edit mode and run the |
True, for multiple cursors this would be weird. But even for a single cursor with |
I also have this issue. When creating a new node from the calendar widget, and either of these conditions are pressent:
Then I propose that when creating a new note and Templater is engaged, then it should switch to edit mode automatically. |
I don't think it's a good idea to switch the mode on the user. Part of the benefit of Templater is you can bind templates to a hotkey to quickly run a script on the current note to manipulate it, without having to be in edit mode. I know of users who stay in reading mode and run hotkeys to mark a note as reviewed before moving on to the next note. I would be open to a contribution for a new Templater function in the file module or something that can switch the mode explicitly. |
Maybe |
I like that, should be easy enough to implement. Even just making the change to have |
In the meantime, one can add a user function following the doc. Script above exporting the function: function switch_to_editmode () {
/* Be sure to switch to edit mode first (live preview)
It is required so it can insert the template in existing file. */
const view = app.workspace.activeLeaf.getViewState()
view.state.mode = 'source'
view.state.source = false
app.workspace.activeLeaf.setViewState(view)
}
module.exports = switch_to_editmode; Then you call it in your template: <%*
/* Be sure to switch to edit mode first (live preview)
It is required so it can insert the template in existing file. */
tp.user.Switch_to_edit_mode();
// start of template construct
// insert your logic here
if (title.startsWith("Untitled")) {
title = await tp.system.prompt("What is the plugin name ?");
await tp.file.rename(title);
}
// and so on
%> Further in the template, add this to jump to the cursor on any case. It is necessary if create a new note from the template where the focus is on the note title. You just press enter to validate it and the cursor jumps to the anchor. # Description
<% tp.file.cursor(1) %><%* app.workspace.activeLeaf.view.editor?.focus(); %> Source: https://forum.obsidian.md/t/easily-switch-between-source-mode-live-preview-preview/27151/25 |
Plugin information (please complete the following information):
Template folder location: "templates/"
Automatic jump to cursor: on
Trigger Templater on new file creation: on
Daily Notes: on
Format:
YYYY-MM-DD-dddd
Daily Note Template:
templates/daily-template.md
Note Folder:
diary
Daily note template:
To reproduce:
These steps worked for me in a new vault with the minimal setup from above.
Describe the bug
When I trigger the "Periodic Notes: Open daily note" command from the active tab which is in reading view, the diary page is getting created and commands are replaced, except for
<% tp.file.cursor(1) %>
. This command remains on the diary page without being replaced.Expected behavior
I understand that there can not be a cursor position when the diary page is in reading view, but I expect the templater code to be replaced with nothing.
Screenshots
This is the result of the daily note creation. The creation date is replaced, but
<% tp.file.cursor(1) %>
remains as is.The text was updated successfully, but these errors were encountered: