Allow creating named cells for non-javascript cell modes

[JobLeonard]

Currently only JavaScript cell modes allow for creating named cells. This limits the use of the other cell modes a bit. For example, I cannot create named paragraphs of markdown blocks, so I cannot (for example) create links to an appendix from the "main" part of the notebook and back, like I did in my Seam Carving notebook for example.

Describe the solution you'd like

I think the simplest solution would be to detect if the cell starts with an assignment, optionally including {}, just like how Observable JavaScript is different from regular JavaScript:

someVariableName = {
 ...
}

If all cell modes supported this notation that would also make it the easiest to pick up for new users, since the logic would be consistent with any future cell modes too.

[jrus]

Ooh, that’s a good point. I explicitly name a ton of markdown cells (i.e. the md`` type) in my notebooks.

Using {} as delimiters might not work here though. } could easily appear in the middle of text.

[mootari]

@jrus named cells also allow for output modes like plaintext to serve practical applications, because you now have a plaintext cell editor and can decide how to ingest the data (e.g. as python or sql). This can be the basis for a variety of syntax highlight modes.

[JobLeonard]

@jrus isn't that a matter of having a decent parser? Granted, I have zero experience with parsing mixed languages, but I know it exists (and this is a really limited special case anyway)

[JobLeonard]

An even simpler proposal for the syntax: (I don't really know how to write down grammars so this is pseudo-code)

<CELL_NAME_IDENTIFIER> =
... // text in cell body
...
...

Basically, detect if the first line is name =\n. Parsing that would be as simple as adding an extra "pre-parsing" step to the cell that does the following:

1. is the first line in the form of <valid cell name> =\n? (maybe support superfluous whitespace to go easy on the people who make a lot of typos) a. Yes => "remove" the first line from the input and pass all remaining text content to the regular parser for the cell b. No => pass the entire text content of the cell to the regular parser for the cell

Aside from simplicity of parsing, it also would make the rest of the parsing easier. For example, we don't have the awkward situation with the curly braces where we expect indentation:

named_mardown_cell = {
  # This would look weird without indentation

  Adding two spaces to a markdown document 
}

This would be harmless in this example (this bit of markdown would render exactly the same with or without the two extra spaces), but for languages with significant indentation (like python) it could really complicate things.

[CobusT]

We just released the feature to allow naming of all cell types! It is not the solution you requested, and it will go through some UI tweaks (possibly placing the cell name next to the cell) but the core functionality is now supported.

Let me know if you are ok closing this issue.

[JobLeonard]

Can you link to the notebook showing the new UI? I can't find it

[CobusT]

Check out the release note about 'Call naming' here where we show a small video of it in action.

[JobLeonard]

Ah, yeah interface design that works for me! :)