Skip to content
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

E37: Can't open link before you've saved the current buffer. #51

Closed
ohtogo opened this issue Jan 23, 2020 · 2 comments
Closed

E37: Can't open link before you've saved the current buffer. #51

ohtogo opened this issue Jan 23, 2020 · 2 comments

Comments

@ohtogo
Copy link

ohtogo commented Jan 23, 2020

Thank you for creating and supporting this plugin.

I have a question about the way that the plugin works to create a new link, navigate to the link target, and return to the original page. New user of n/vim.

Environment: macos catalina 10.15.3, nvim 0.4.3, wiki.vim, wiki-ft.vim; plugins loaded by nvim default package manager.

Description

  1. I expected this process to work in the same way as vimwiki, without having to manually save files before traversing new links. Namely, [cr] on text in normal mode to create link, [cr] to follow link to new page, enter text, [bs] in normal mode to return to the original page.

  2. In my wiki.vim installation, however, it seems that the files must be manually saved before traversing links. On creating a link using [cr] and trying to navigate to the target with a second [cr], an error is thrown:

Error detected while processing function wiki#link#open:
line    8:
E37: Can't open link before you've saved the current buffer.
Press ENTER or type command to continue

Similarly, choosing backspace from the target page before the page is saved throws:

E37: No write since last change (add ! to override)

Therefore, my process in wiki.vim is more like [cr], :w, [cr], insert text, :w, [bs].

My question is whether this is the correct behavior (and usage) or not.

Minimal working example

Directory structure:

~/wiki
├── index.wiki
└── test.wiki

Tested with a minimal init.vim:

set nocompatible
filetype plugin indent on
syntax on
let mapleader=','
let g:wiki_root = '~/wiki'

Thanks for your help.

@lervag
Copy link
Owner

lervag commented Jan 27, 2020

If you add set hidden to your init.vim, then I think this is not a problem.

New user of n/vim.

I suggest you read up on the use of buffers. The default settings is to remove a buffer in vim when you leave it. With set hidden, the buffer is not removed, but hidden. You can come back to it. Thus, when you follow a link in wiki.vim, things work as expected.

I'll close this issue. After reading about buffers (see suggested help pages), feel free to reopen or continue the discussion if you want more input.

Following help pages are good:

  • :help 'hidden'
  • :help usr_07.txt
  • :help usr_08.txt
  • :help windows.txt (quite long, but includes most of the main details)

@lervag lervag closed this as completed Jan 27, 2020
@lervag
Copy link
Owner

lervag commented Jan 27, 2020

I expected this process to work in the same way as vimwiki, without having to manually save files before traversing new links. Namely, [cr] on text in normal mode to create link, [cr] to follow link to new page, enter text, [bs] in normal mode to return to the original page.

I am not sure how Vimwiki solves this particular "kink", but I guess Vimwiki instead saves the buffer for you automatically. I don't think that is the best idea, because it makes the assumption that you want to save the file. I don't want to make the assumption. If you use set hidden, then you explicitly allow to follow the link even if the buffer is not saved. If you do not use set hidden, then that might be a real preference, in which case I would expect you to also save your files manually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants