| 03:33 | <bakkot> | here is a build of the spec where [[FieldNames]] are clickable to highlight like variable names: https://bakkot.github.io/ecma262-previews/highlight-brackets/ |
| 03:34 | <bakkot> | it's mostly intended for Temporal and 402, which have a lot more algorithms with a lot of different field names |
| 03:34 | <bakkot> | but it seems like it is not harmful for 262? |
| 03:34 | <bakkot> | anyway requesting feedback before I commit to this in ecmarkup |
| 04:55 | <ljharb> | where’s the diff for 262? |
| 05:02 | <bakkot> | I don't understand the question |
| 05:58 | <ljharb> | like what's different in 262 from that change |
| 06:18 | <bakkot> | if you click [[FieldNames]] they highlight like variables do |
| 16:15 | <ljharb> | oh interesting, but they highlight across the entire spec, not just one algorithm |
| 16:15 | <ljharb> | that seems useful but also sort of implies that field names should be unique for a given purpose? |
| 16:16 | <Michael Ficarra> | ljharb: there's no way to tell two fields apart if they have the same name though |
| 16:16 | <Michael Ficarra> | since it's a dynamic concept |
| 16:16 | <ljharb> | right, hence implying they should be unique :-) |
| 16:16 | <Michael Ficarra> | PRs welcome |
| 16:16 | <ljharb> | like AB and SAB should share a name but like [[Value]] shouldn't be used for more than just completion records, or something |
| 16:17 | <Michael Ficarra> | I think it will be hard to make the field names globally unique while also not making them super verbose |
| 16:17 | <ljharb> | fair |
| 16:19 | <Michael Ficarra> | ljharb: though now that I check it out, I only see it highlighting a field in a single algorithm at any given time |
| 16:19 | <Michael Ficarra> | that makes this much less of a problem |
| 16:20 | <ljharb> | hm, if that's true then ok, but i grepped for the first [[ and clicked on it and it went across more than one algo |
| 16:20 | <ljharb> | it was a [[Value]] in the returnabrupt macro iirc |
| 16:21 | <Michael Ficarra> | well highlights inside an AO seem to be bounded to the AO |
| 16:22 | <Richard Gibson> | ljharb: that behavior is shared with spec-alias variables such as argument in the same section |
| 16:23 | <ljharb> | ah ok |
| 16:23 | <Michael Ficarra> | here's a good section for testing it out: https://bakkot.github.io/ecma262-previews/highlight-brackets/#sec-property-descriptor-specification-type |
| 16:24 | <ljharb> | ah ok makes sense |
| 16:25 | <Richard Gibson> | I believe it stems from findContainer looking for ancestor emu-{clause,intro,annex} elements via toggleFindLocalReferences at https://github.com/tc39/ecmarkup/blob/4e43574fb6f8efab80aa74d79d58f7bfee97b6a5/js/menu.js#L573 |
| 16:27 | <bakkot> | note that this also applies to the MOP methods, since they look exactly the same as fields |
| 16:27 | <bakkot> | but again, not harmful |
| 16:37 | <jmdyck> | so anything that uses the [[Foo]] notation (but not [[%Foo%]]): a field of a record, an internal slot/method of an object, an attribute of a property, the [[Description]] of a Symbol. |