joostkremers/ebib

C-x C-s in a notes buffer causes the position to be reset

Closed this issue · 14 comments

With ebib-show-notes-method is set to all, upon save, the point, mark, narrowing, and tree-collapse state of the notes buffer is reset. It looks like this is being done by ebib--update-entry-buffer, but it's not clear why.

Could you elaborate a bit more? What steps do I need to reproduce the issue?

It looks like it may be a combination of the note file's buffer being killed (unclear what the reason for that is), and a call to goto-char in ebib-open-note. That being said, here is a minimum configuration to replicate this behavior:

(add-to-list 'load-path (locate-user-emacs-file "compat"))
(add-to-list 'load-path (locate-user-emacs-file "async"))
(add-to-list 'load-path (locate-user-emacs-file "parsebib"))
(add-to-list 'load-path (locate-user-emacs-file "citar"))
(add-to-list 'load-path (locate-user-emacs-file "helm"))
(add-to-list 'load-path (locate-user-emacs-file "ebib"))

(require 'ebib)
(setopt ebib-notes-new-note-hook nil
        ebib-notes-open-note-after-hook nil
	ebib-notes-show-note-method 'all
	ebib-notes-directory "~/literature-notes/")

Then, open a bibliography buffer for which you have at least one entry with notes in ~/literature-notes/, navigate to the notes buffer, make a change at the end of the buffer, and save with C-x C-s. Note that point is now at (point-min).

Hmm, yes, I see... What's happening is that when a note is opened, after-save-hook is set to ebib--maybe-update-entry-buffer, which calls ebib--update-entry-buffer, which in turn kills the note buffer when ebib-notes-storage is set to one-file-per-note (which is the default).

I'm not entirely sure why I did it that way, but I suspect it was just to avoid having dozens of buffers open with just a single note in them. If that's the case, then it would be an easy fix, but I'll have to dive into the code a bit more to be certain.

I figured it was something along those lines. Would it be possible to make that behavior configurable?

I've just pushed a commit that removes the kill-buffer from ebib--update-entry-buffer. I don't think it has any adverse effect except the one I mentioned. But please keep an eye out for any issues, because I don't use the one-file-per-note setting myself, so I can't really test it.

A user option is a good idea. If users complain that so many note buffer remain open, I'll implement it.

The buffer doesn't appear to be killed, but point is still being reset to (point-min). I think I saw somewhere in the note display code that it always resets the point location.

Wait, it seems like it's inconsistent. But I'm not sure if it isn't updating point.

Point is definitively still being reset.

Additionally, the entry buffer (not the notes buffer) still receives focus after save.

Point is definitively still being reset.

This should now be fixed with the latest update.

Additionally, the entry buffer (not the notes buffer) still receives focus after save.

This requires a more fundamental change. We'd need a way to update the contents of the entry buffer without killing and recreating the window displaying the note. Allow me a little bit of time to decide whether to just bolt that onto the existing function ebib--update-entry-buffer, or whether there's a better way to do it. (ebib--update-entry-buffer is already a bit of a hack, in my opinion...)

I added an optional argument to ebib--update-entry-buffer to keep the note window, which is now used in the after-save-hook in note buffers. This in itself doesn't change the focus issue, but before I work on that, I'd like to be sure that things still work the way they did before this change. Could you please check and let me know?

It seems to work! Thank you!

It seems to work!

Including the focus issue?

Yes!