define message methods for `SharedBuffer` instead of `Buffer`
AddMessage and the like are defined for Buffer although they only use the SharedBuffer part. This PR defines them for SharedBuffer. As a consequence, these methods can now be used from within the onBeforeTextEvent callback, which receives a SharedBuffer as argument.
As a consequence, these methods can now be used from within the onBeforeTextEvent callback, which receives a SharedBuffer as argument
With this PR, how a plugin can differentiate between a text event in the buffer and a message added?
~~What exactly do you mean? Everything that a plugin could do without this PR is still possible with it.~~
OK, now I believe I know what you mean. The idea is that text events can trigger messages. For example, the bookmark plugin uses messages to define bookmarks. Currently, it needs a lot of code to adjust the position of those bookmarks when text is added or deleted. With onBeforeTextEvent, this becomes much simpler in my opinion. See the proof of concept here.
I misread your first message.
What I was asking was whether adding a Message, etc., now triggers the onBeforeTextEvent() callback.
Now I see that what you are doing is checking if the text events are affecting your bookmarks (by moving them through removing/inserting lines, etc.).
Looks like a whack-a-mole approach. I.e. what about any other Buffer methods that onBeforeTextEvent may want to use?
This shows once again that this onBeforeTextEvent interface is poorly thought out (so it's a good thing that we still haven't documented it), OTOH I don't know what interface to replace it with...
I agree that it makes sense to reconsider onBeforeTextEvent. Nevertheless, from the point of view of code hygiene, shouldn't methods that use a SharedBuffer be defined for SharedBuffer instead of Buffer?
I have a counter-question: are we sure that Messages really belongs in SharedBuffer, not in Buffer?
And same about Suggestions, Completions, many of Settings (such as ruler, softwrap and so on)...