| 00:01 | <bakkot> | changing that would be consistent with https://github.com/tc39/ecma262/pull/3330 etc |
| 00:02 | <jmdyck> | So I think eliding all is *true* is possible without ambiguities. Mind you, some things don't read as well, so you'd probably want to do some renaming. |
| 00:02 | <bakkot> | anyway I definitely do not want to drop this everywhere |
| 00:03 | <bakkot> | I am maybe pursuadable that we can drop it for specifically If AO(...) where AO is a predicate |
| 00:03 | <bakkot> | but personally I would be inclined not to |
| 00:03 | <bakkot> | especially since there's not a good way to do the negated case |
| 00:04 | <shu> | i also definitely do not want to drop this everywhere |
| 00:04 | <shu> | i basically just want to drop it for If IsFoo() |
| 00:05 | <jmdyck> | Personally, I don't much like dropping it anywhere, but I think I can deal with it, so shrug. |
| 00:08 | <jmdyck> | Note that there are already 11 places in the spec where we elide is *true*. E.g. It is a Syntax Error if the <sub>[Tagged]</sub> parameter was not set and |NoSubstitutionTemplate| Contains |NotEscapeSequence|. |
| 00:18 | <jmdyck> | Oh, I should have said earlier, I use a dynamic parsing algorithm, so it's possible for the grammar to have formal ambiguities that I don't know about, simply because the current pseudocode doesn't encounter them. |
| 01:16 | <Michael Ficarra> | btw I will have to leave editor call tomorrow at 15:00 |
| 01:17 | <Michael Ficarra> | @shu we can start a half hour earlier if you like and are free, otherwise we'll just have to do 30 minutes |
| 16:31 | <Michael Ficarra> | @shu all your comments on this thread are duplicated https://github.com/tc39/ecma262/pull/3396#pullrequestreview-2249195201 |
| 16:31 | <Michael Ficarra> | what did you do to make this happen? |
| 17:00 | <shu> | oh wow, i have no idea |
| 17:00 | <shu> | @shu we can start a half hour earlier if you like and are free, otherwise we'll just have to do 30 minutes |
| 17:09 | <Michael Ficarra> | this isn't the first time it's happened to you |
| 17:10 | <Michael Ficarra> | something about your review workflow causes this |
| 17:12 | <shu> | this happened before? i don't recall |
| 17:13 | <shu> | wait i'm looking at this issue more closely, what's duplicated? |
| 17:13 | <shu> | are you talking about how replies to a previous review comment show up both in that original review's thread, and in the new review? |
| 17:14 | <shu> | i feel like that's a GH issue, and i'm using the workflow as intended. if i reply to a previous review's comment thread in a new review, and submit that review, that's what happens |
| 17:19 | <ljharb> | yeah that's how github works - specifically, when you reply to a comment as part of a review instead of as an immediate comment |
| 17:21 | <Michael Ficarra> | that's gross |
| 17:21 | <Michael Ficarra> | why would I want to see the replies both inline and completely out of context with no indicator that they're even replies? |
| 17:22 | <Michael Ficarra> | like this is useless to me |
| 17:22 | <shu> | https://github.com/community/community |
| 17:24 | <ljharb> | sent an image. |
| 17:26 | <shu> | i take it F5 doesn't use GH internally? what do you use? |
| 17:48 | <Michael Ficarra> | we used to but we use GitLab now |
| 17:49 | <Michael Ficarra> | also, I think the difference is I never use the "review" feature on PRs |
| 17:49 | <Michael Ficarra> | and I guess I don't really see other people use it either |
| 17:54 | <shu> | how do you review PRs? you leave single comments one at a time? |
| 17:54 | <shu> | i'm used to review workflows where you leave draft comments and submit the review |
| 17:55 | <jmdyck> | How do people submit multiple comments in one go if not via a review? |
| 18:31 | <bakkot> | michael is mistaken; he definitely used the review feature and encountered other people using it |
| 18:32 | <bakkot> | but you only notice this if you reply to existing comments as part of a review, which is much less common |
| 18:32 | <Michael Ficarra> | I just do one comment at a time, dude |
| 18:32 | <bakkot> | impossible if you're the first review |
| 18:32 | <shu> | 🍿 |
| 18:32 | <Michael Ficarra> | but you only notice this if you reply to existing comments as part of a review, which is much less common |
| 18:33 | <shu> | does michael lack a reflexive theory of mind to understand his own workflows?? |
| 18:34 | <shu> | but you only notice this if you reply to existing comments as part of a review, which is much less common |
| 18:35 | <bakkot> | you don't get the button to add a comment-reply to a review unless you're already starting a review, I think |
| 18:36 | <bakkot> | so if you just go through responding to comments you won't even be offered the chance |
| 18:36 | <shu> | yeah, i always click the Start a Review button |
| 18:36 | <shu> | should i not? |
| 18:36 | <bakkot> | ¯\_(ツ)_/¯ |
| 18:36 | <bakkot> | I don't personally care |
| 18:37 | <bakkot> | it is a bit silly on github's part |
| 19:27 | <ljharb> | i only "start a review" when i'm going to be doing one asap; i send my reply as a comment otherwise so that the reply can be read in a timely fashion, instead of whenever i get around to finishing the review |
| 19:34 | <jmdyck> | I submit reviews rather than individual comments because Domenic asked me to: https://github.com/tc39/ecma262/pull/1460#issuecomment-468960387 |
| 21:04 | <Michael Ficarra> | this is a really quick one that could use a second stamp: https://github.com/tc39/ecma262/pull/3375 |
| 21:05 | <jmdyck> | editor call in ~55min? |
| 21:05 | <Michael Ficarra> | @jmdyck yes |
| 21:06 | <Michael Ficarra> | I actually can't even find the start review button |
| 21:07 | <jmdyck> | I see it when I click on a line in the diff. |
| 21:20 | <Michael Ficarra> | oh wow okay |
| 21:29 | <Michael Ficarra> | editor call in ~55min? |
| 23:13 | <bakkot> | remind me what https://github.com/tc39/ecma262/pull/2721 is waiting on? been stage 4 since april |