Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out what to do about comments, metadata, tagged literals #38

Open
mkremins opened this issue Sep 16, 2014 · 2 comments
Open

Figure out what to do about comments, metadata, tagged literals #38

mkremins opened this issue Sep 16, 2014 · 2 comments
Labels

Comments

@mkremins
Copy link
Owner

There are a number of constructs in Clojure source code that don't map directly to forms. Do we need to represent them somehow? (The answer is probably yes.) How should we represent them, if we choose to do so? (As of yet, I have no idea what to do on this front.)

codn aims to provide parse tree representations of non-form source constructs. We could perhaps draw some inspiration from there.

@mkremins
Copy link
Owner Author

mkremins commented Nov 3, 2014

A bit more background on this issue: comments, metadata and tags are all weird because they don't behave like concrete forms. There's a textual notation for them – comments stretch from the first ; character to the next newline, and metadata/tags attach to the immediately following form – but it's unclear how to modify this behavior for a structural editing context.

I've considered adding :comment, :meta and :tag keys to parse tree nodes. The rendering layer would note the presence of these keys and render the appropriate representations. Nothing too terribly difficult, but requires lots of special-casing, especially when the time comes to give the user a smooth way to edit the comment/metadata/tag attached to the selected form. Preserving attached comments/metadata/tags over the course of complicated structural transformations (e.g. many of the refactoring actions defined in flense.actions.clojure) might also prove problematic.

@darwin
Copy link
Contributor

darwin commented Jan 19, 2015

Just a quick idea. What about having two editors side-by-side?

Look at generated documentation for underscore.js[1] from this source[2] via Docco[3].

This is just one-way translation, but I believe the documentation side (left) could be made editable and the mapping could be defined as 2-way without ambiguity.

Additionally flense could help syncing left and right side. For example deleting a form would delete corresponding documentation blob. Adding/removing lines in documentation blob would shift forms to align properly. etc.

[1] http://documentcloud.github.io/underscore/docs/underscore.html
[2] https://github.com/jashkenas/underscore/blob/master/underscore.js
[3] http://jashkenas.github.io/docco

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants