Windows and frames, killing and yanking, point and mark, slurping and barfing -- there's a lot of Emacs nomenclature that confuses people initially.

This is poetry. I almost could fit it to the tune of Favourite Things, which coincidentally these thing are. My favourite things, I mean.

My instinct was to deny, but actually yeah every one of these confused me when I started.

I do not catch your meaning.

Every text editor I know of makes its edits to an in-memory copy of the file. If interactive edit commands operated directly on the file, the Save command would make no sense.

Emacs calls the in-memory copy a buffer. (VSCode calls it an editor.)

Most text editors call it "file" or "document," even if it's not yet backed by disk.

It's a subtle difference, but I think emacs's decision to call them "buffers" (though it makes the editor a space-alien by modern standards, that much harder to learn) makes more clear that the user should have no expectation that any of the buffers ever get backed to long-term storage. Once one wraps one's head around that, a lot of things get much easier (including and especially writing document editing functions; where most systems would have you store blobs of text in string variables, emacs really wants you to pop up temporary buffers and manipulate them like any other buffer, with the added benefit that if a function fails mid-execution, the regular buffer editing tools make it easy to inspect the failed state).

The distinction is that buffers are by no means necessarily in-memory copies of files. When you start up emacs, you will have more buffers active that are not backed by files than buffers that are.

The distinction becomes clearer once you start using emacs buffers for things other than text editing; like, say, an IRC client or a command shell, or elisp eval.

It is a direct manipulation interface based around interacting with text. The buffer is where it happens. "Files" or "documents" can be in those buffers. But so can textual sessions of many other kinds.

There is the slight difference, that buffers are directly accessible for the user, while other editors only indirectly let you use the in-memory-data. So, what VS Code calls an editor, is in Emacs a window, not the buffer.

This subtle difference becomes relevant for example when working with multiple views on the same buffer. In VS Code, those views are only getting synced when it's a file on space. But open a new editor without an associated file, and every new view on that content, will become an independent copy.

I use my own custom text editor, but came from emacs, and one of the best choices I made was to copy that bit.