Quality of life: Improve the way a file extension is assigned to a code block

[stratosgear]

This is not a bug, but rather a suggestion for an enhancement.

Current situation

Currently code blocks are defined as:

``` {.python file=some/path/hello.py} 
# some comment
print("Hello world!")
```

This prevents certain editors (VS code) to be able to identify the type of code enclosed the backticks. Lacking this, your are missing major features like code hilighting and basic editing facilities, while editing the markdown files.

For example with CTRL+/ you can comment the current line, which is a quick way to turn things on/off. With Vscode not knowing how to comment lines off, it will default to some weird/undefined comment techniques (for example, surrounding the lines with <!-- and -->, that might not make sense for the current code block. I have not found a way to force Vscode to recognize the code block given the current matching pattern ({.ext file=some/path})

Suggestion

It seems that the current "standard" for marking these code blocks as a specific extension is like:

```python 
# some comment
print("Hello world!")
```

Will it be possible to change the way codeblocks are defined so they are more compatible to what (maybe I erroneously) consider a more "standardished" way?

So basically the pattern would be:

```python {file=some/path/hello.py} 
# some comment
print("Hello world!")
```

This potentially could be a breaking change, but it should not be impossible (I think) to support both formats and derive the extension for the one or the other location.

Of course if there is way to achieve the above "feeatures" simply by reconfiguring, I would not mind it, but I consider it a benefit if the extension marking was following a more "traditional" way of doing things. I already know that Obsidian is using the same pattern (```extension) to mark codeblocks (for mermaid, plantext diagramming etc)

Am I asking for too much... :)

[jhidding]

In general, when developing code (and using lots of IDE features) I do so in the tangled code form. Language support within code blocks is terribly inconsisent, even with the 'accepted' syntax. For instance, Haskell codeblocks are recognized when in ``` {.haskell} form in VSCode. The thing is,

``` {.python file=my_module/__init__.py}
...
```

is the more consistent way to set attributes on code blocks, and extends to other elements as well (like headers, and fenced divs).

All that being said, the code block syntax is already configurable in Entangled, although that feature is not yet documented. In entangled.toml we can define markers.open and markers.close regular expressions. Those are expected to have an indent and properties subexpression. This format is not flexible enough to allow the syntax you're suggesting, but its getting close.

version = "2.0"

[markers]
open = "^(?P<indent>\\s*)```\\s*{(?P<properties>[^{}]*)}\\s*$"
close = "^(?P<indent>\\s*)```\\s*$"

What is still lacking is a way to extract a file attribute or identifier from the properties group. We could add separate regex groups for those and have a fall-back into properties.

The more important question is: what document generator supports your new markdown dialect?

[stratosgear]

I do not think I have an answer about which document generator supports a new markdown dialect, but your reasoning about working on the tangled files makes perfect sense.

It is one of the most import features of entangled and being able to change the tangled files, and see your changes in the markdown files makes total sense. I was caught up in the process of authoring the markdown files (and writing code there). Eventually I would have to actually run the generated/tangled code and I am sure that I would find bugs or issues that need fixing, in which case I would be doing it from the tangled files, where I have total IDE support. So yes! It is not important to have a perfect editing experience while authoring markdown, when the majority of "coding" will be done through the tangled files.

I consider this as a no-issue anymore. Thanks for taking the time to align my mental picture of entangled usage amnd altering my workflow!