Hi Ihor, Chiming in here with a slight variant on what others have said. Best! Tom
I don't think this should be handled at the syntactic layer at all. The empty string block language should be syntactically valid with any special behavior needed being handled later. Linters could treat it as a warning/error though, but the parsing is made significantly easier if the empty string is present allowing the grammar to be fully closed and regular. Thus, I don't think we need to make this a syntactic error or pun a src block without a lang to another type. I think we can add an implementation for when the block language is the empty string. This keeps the grammar regular by removing a special case. I assume that internally the empty string block lang would mostly call the example block codepaths, except that it should probably issue a warning or fail if someone tries to org-src-edit the block so that we can alert them that they are missing the lang. Treating src blocks missing a lang as paragraphs is incorrect because according to the syntax spec they are syntactically still blocks (greater or lesser depending on your inclinations). I think the general principle we want to follow here is that a block (or any entity in general) should not lose its type because some part of its syntax is malformed (I have made similar arguments about property drawers). That is, if something starts with #+begin_NAME stuff and there is a corresponding #+end_NAME, then it is a block. The choice of how a src block without a lang should behave is a bit more complex as there are multiple consumers of src blocks that make different assumptions. As mentioned above. I think that if a block is missing the lang we could think of it instead as the null language. If we have the :var language because someone has other contents on the line they have a well formed src block, but will get a different error because there is currently no known language ":var".
