CodeContent component

[Gozala]

It mostly attempt to resurrect previously existing TextContent component but as a separate entity. Unlike previous version this one allows editing of doc.title (which defaults to note.md) in list context, which is treating as filename from which syntax mode is derived & activated

[Gozala]

I would like to use file-code icon instead but it does not seem to load, I'm guessing version of font in the pushpin doesn't include it. Based on feeback I might attempt to address that or leave it as is.

[todrobbins]

I love this! Nice work, @Gozala!

[Gozala]

@pvh how do we make progress here ? After reading the pushpin design notes I'm wondering if there is a room for intentionally less discoverable features e.g. "view source" had being super power of early web although it was out of sight for most users. Is there room for this kind of things in pushpin ?

I have being thinking more about the fact that indeed existing Text widget and this Code widget are pretty much similar. What if we merged them into one ? What if we don't surface code editor (codemirror) unless user opts-in manually ? I have few ideas in that regard but I do not believe either of them align with "Interactions must be discoverable" goal, but maybe there is room for things that don't need to be all that visible ?

Below are few ideas how we can allow switch from plain text to code.

Derive syntax from the doc title

Unlike Text widget Code widget has optional title field from which title is derived. What if we Text widget had an optional title as well, if not specified it could render text summary (current behavior) but if user manually enters one syntax mode / editor component could be derived from the extension. e.g.

• code.js we derive to use codemirror with javascript syntax mode.
• hello we derive to use quill
• note.quill we derive to use quill
• notes.md we derive to use codemirror with markdown syntax mode.
• no title we use quill

Subtle controls

At the moment text widget has no controls & no clutter is great. What if we had both ? I think iA Writer does a great job in accomplishing exactly that

What if we added either status bar similar to it except with syntax mode selector similar to vscode. Alternatively we could surface that selector only in list mode & in fact we could do so only when hovered as well.

Multiple content type registrations

Alternatively we could allow conflicting content type registrations, meaning code component could also register itself as handler of text content type. And introduce a general mechanism for switching between handlers for type compatible handlers. e.g clicking the icon in the list context could provide a drop down of all compatible handlers to allow switching between them. In the board view I propose to surface focused widget in the top bar e.g. (pardon my drawing skills)

In fact it is also worth considering if just surfacing focused widget header in the top bar is a better than surfacing a board itself.

[pvh]

Link to why we stopped using CodeMirror for posterity (as we talked about) https://github.com/inkandswitch/pushpin/pull/250