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

Reformat remarks editor #68

Open
kjmahalingam opened this issue Feb 6, 2018 · 6 comments
Open

Reformat remarks editor #68

kjmahalingam opened this issue Feb 6, 2018 · 6 comments

Comments

@kjmahalingam
Copy link
Collaborator

Since remarks are separated in code onto separate lines, they are also separated onto separate lines in the editor. They should be formatted as a continuous paragraph to remove the awkward line breaks.

@arscan
Copy link
Member

arscan commented Aug 10, 2018

We had some conversation in #224 regarding what this would entail. See the following comment and the 3 comments after:

#224 (comment)

@KeeyanGhoreshi
Copy link

There should really be a separate code representation of a line break, like an empty string in the array. Or even better, the remarks should be stored as an array of arrays, with each array being one continuous section with no breaks at the cost of some readability.

@arscan
Copy link
Member

arscan commented Aug 10, 2018

I like empty string representing a forced line break. An array of arrays would be a pain to write by hand and harder to explain.

The other major categories I know of are:

  • Major visual breaks, like ================
  • links
  • lists
  • tables

Basically a subset of markdown. I looked into importing a javascript markdown renderer, and there are some, but didn't take the time to actually do it. Seems a bit overkill, and this is a low priority issue.

@arscan
Copy link
Member

arscan commented Aug 10, 2018

Personally I think that we should be putting a LOT more information into these remarks if we want any hope of future people to edit a module once it has been created. They all need to reference where the numbers come from, assumptions made, etc.

That's why I think putting some thought into making this somewhat robust is worthwhile. But there are a bunch of other, lower hanging fruit that needs to get done too.

@KeeyanGhoreshi
Copy link

The issue is definitely not worth too much stress. I'd implement the empty string as a line break and call it good enough. Though if an empty string is going to be a line break, sections between empty strings will have to be concatenated.

This will probably make a lot of existing remarks that were written in the JSON directly to become weirdly formatted. I don't think there's a way to implement empty strings as line breaks while maintaining the current behavior of making a new line for each element of the array.

@arscan
Copy link
Member

arscan commented Aug 10, 2018

Yes, we would take a pass and manually reformat all existing modules. We have done that before.

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

No branches or pull requests

4 participants