skip save dialog on quit if buffer is shared

[matthias314]

Currently, when a modified buffer is closed, the user is asked if the buffer should be saved. This happens even if the same file is opened in another buffer. With this PR, the save dialog is skipped in this case. I personally like to open a file in a second buffers when I made modifications that affect two locations. Then this issue pops up.

[dmaluka]

Thanks for addressing this, this issue has been occasionally annoying me as well.

[dmaluka]

1. We don't need to traverse tabs and panes, we can just traverse buffer.OpenBuffers.
2. We don't need to count all the copies, we just need to check if there is at least one copy.

Something like this?

for _, b := range buffer.OpenBuffers {
	if b != h.Buf && b.SharedBuffer == h.Buf.SharedBuffer {
		h.ForceQuit()
		return true
	}
}

3. This fix applies to the above if config.GlobalSettings["autosave"].(float64) > 0 branch as well, right?

[matthias314]

we can just traverse buffer.OpenBuffers

Can we? I'm using the Lua function

function hsplit(bp)
    bp:HSplitBuf(bp.Buf)
end

(bound to some key) to quickly get a second bufpane with the same buffer. Closing such a bufpane currently leads to the "save?" prompt, and it would still do that with your suggestion. That's why I did it differently. Or is the function I wrote not allowed? (I may not fully grasp the difference between BufPane and Buffer. My thinking was that sharing a Buffer is allowed for otherwise one could combine these two types.)

we just need to check if there is at least one copy

That's true. I thought the other version conveys the intention more clearly. But no problem, I can change this.

This fix applies to the above [...] branch as well, right?

One may or may not do it. Given that autosave saves the file regularly anyway and the user is not prompted, I don't see a necessity for a change. Would you prefer one?

[dmaluka]

The SharedBuffer structure represents an open buffer (which may be shared between multiple panes). The Buffer structure represents an "instance" of an open buffer in a particular pane. So for example, the contents of the buffer text are stored in SharedBuffer, since those contents are the same in all panes where the buffer is opened, but for example the cursor position is stored in Buffer, since it is different in each pane. The BufPane structure represents a pane (a window) where a buffer is opened. So there is a 1:1 correspondence between a BufPane and a Buffer.

I'm not sure what does your hsplit example have to do with this issue, what do you mean by "not allowed" and so on.

Given that autosave saves the file regularly anyway and the user is not prompted, I don't see a necessity for a change.

There is just no point in this extra autosave in Quit() in the case when we don't really close the buffer, since it is still opened in another pane. We want to keep the logic consistent, right?

[matthias314]

So there is a 1:1 correspondence between a BufPane and a Buffer.

I gather that the function hsplit I wrote above is not a correct way of creating a second bufpane for the same buffer (or rather SharedBuffer). That's what I meant by "not allowed". If it had been a correct way of creating a new bufpane, then your code wouldn't have worked in all cases.

Out of curiosity, what is the correct way of opening a second bufpane? I think that for files one can use buffer.NewBufferFromFile. Is there a way that also works newly created buffers without a filename?

[dmaluka]

Ah, just noticed that you pass bp.Buf to HSplitBuf()... Yep, that is not a correct thing to do, it is gonna break things. A correct way would be something like bp:HSplitBuf(buffer.NewBufferFromFile(bp.Buf.AbsPath)).

Is there a way that also works newly created buffers without a filename?

Good question. I think there isn't.