-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Formatting large objects #2095
Comments
That seems fine to me, altho i'd hope ecmarkup could indent it more like this: 12. Return the Source Text Module Record {
[[Realm]]: realm,
[[Environment]]: undefined,
[[Namespace]]: undefined,
[[Status]]: unlinked,
[[EvaluationError]]: undefined,
[[HostDefined]]: hostDefined,
[[ECMAScriptCode]]: body,
[[Context]]: empty,
[[ImportMeta]]: empty,
[[RequestedModules]]: requestedModules,
[[ImportEntries]]: importEntries,
[[LocalExportEntries]]: localExportEntries,
[[IndirectExportEntries]]: indirectExportEntries,
[[StarExportEntries]]: starExportEntries,
[[DFSIndex]]: undefined,
[[DFSAncestorIndex]]: undefined
}. |
This comment has been minimized.
This comment has been minimized.
Sounds good to the editors, but I suspect we'd need support in ecmarkdown for multi-line steps (or Records explicitly), which I'm not going to prioritize right away. |
Note that there are two possibly-independent issues:
I think the discussion so far has been mostly about the HTML rendering, but it's not always clear. |
Note that there are a few places in the spec (e.g., CreateHTML) where the 'content' of an algorithm step includes a bulleted list. So I'm guessing that if the source were changed to something like this:
then ecmarkup (without any changes) would render it more-or-less as @codehag suggests. (We'd just have to update the Record type clause to say that this is another syntax for defining records.) |
Yeah, I'm concerned only about the HTML rendering. It'd be nice to also have the source text look good, but that's a much lesser concern since it affects far fewer people. |
We could also define an 1. Return the <emu-record name="Source Text Module Record">
* [[Realm]]: _realm_
* [[Environment]]: *undefined*
* [[Namespace]]: *undefined*
* [[Status]]: ~unlinked~
</emu-record>. Which would get rendered into: <li>Return the <emu-record name="Source Text Module Record">
<emu-xref href="#sourctextmodule-record"
><a href="#sourctextmodule-record">Source Text Module Record</a
></emu-xref> {
<ul class="emu-record-fields">
<li>[[Realm]]: <var>realm</var>,</li>
<li>[[Environment]]: <emu-val>undefined</emu-val>,</li>
<li>[[Namespace]]: <emu-val>undefined</emu-val>,</li>
<li>[[Status]]: <emu-const>unlinked</emu-const></li>
</ul>
}</emu-record>.</li> With the CSS: .emu-record-fields {
list-style: none;
margin-block-start: 0;
margin-block-end: 0;
}
.emu-record-fields > li {
display: block;
} |
This isn't a bug, its a formatting question/request. (cc @ljharb)
I am currently reading https://tc39.es/ecma262/#sec-parsemodule and the last instruction here returns a complex object with a number of fields. It looks like this in the text:
I imagin this has been discussed in the past. Are there ideas of how to make this easier to read? For example:
It takes up a lot more space, but it is also much easier to see what is going on.
The text was updated successfully, but these errors were encountered: