compose: Quote and reply #116

chrisbobbe · 2023-05-26T22:33:51Z

No description provided.

chrisbobbe · 2023-05-27T00:49:19Z

It might be helpful to add a quote_and_reply.dart file somewhere. Generating the quote-and-reply text has some nontrivial subtasks:

Silent @ mention of the sender
Link to the message (different for PM and stream messages)
Fencing with ```, but with the right number of `'s depending on the message content
(Leading and trailing newlines, if they're considered part of the text.)

And a new file with that name could be a good home for all that code. Where might be a good place to put that file? Maybe not "model"…or "widgets"…etc.

chrisbobbe · 2023-05-27T00:50:38Z

Greg points out in the office just now, model would be a fine place for it.

chrisbobbe · 2023-06-01T00:24:57Z

#140 will be helpful as a way to get the message's raw Markdown content.

chrisbobbe · 2023-06-01T00:33:20Z

With #139 being merged, we can consult store.streams when writing a stream-message link. (Then when we update store.streams on stream events, tracked in #135, those links will naturally get written with up-to-date data.)

We can use this to get raw Markdown content for quote-and-reply (zulip#116) and for the "Share" option on a message. For those, we only care about the raw Markdown content and so could just as well have used the `raw_content` field on the get-single-message response, for servers pre-120. But... We can also use this for zulip#73, "Handle Zulip-internal links by navigation", to follow /near/<id> links through topic/stream moves (see implementation in zulip-mobile). For that, we'll need more than just the message's raw Markdown.

TODO tests. For the corresponding logic used in the web app and zulip-mobile, see web/shared/src/fenced_code.ts. I believe the logic here differs from that in just this way: it follows the CommonMark spec more closely by disqualifying backtick-fence lines where the "info string" has a backtick, since that's not allowed: > If the info string comes after a backtick fence, it may not > contain any backtick characters. (The reason for this restriction > is that otherwise some inline code would be incorrectly > interpreted as the beginning of a fenced code block.) Regarding the new file lib/model/compose.dart, we do have existing code that could reasonably move here, but it's pretty simple. It's the code that gives the upload-file Markdown; see registerUploadStart and registerUploadEnd in [ContentTextEditingController]. Related: zulip#116

For the corresponding logic used in the web app and zulip-mobile, see web/shared/src/fenced_code.ts. I believe the logic here differs from that in just this way: it follows the CommonMark spec more closely by disqualifying backtick-fence lines where the "info string" has a backtick, since that's not allowed: > If the info string comes after a backtick fence, it may not > contain any backtick characters. (The reason for this restriction > is that otherwise some inline code would be incorrectly > interpreted as the beginning of a fenced code block.) Regarding the new file lib/model/compose.dart, we do have existing code that could reasonably move here, but it's pretty simple. It's the code that gives the upload-file Markdown; see registerUploadStart and registerUploadEnd in [ContentTextEditingController]. Related: zulip#116

We can use this to get raw Markdown content for quote-and-reply (zulip#116) and for the "Share" option on a message. For those, we only care about the raw Markdown content and so could just as well have used the `raw_content` field on the get-single-message response, for servers pre-120. But... We can also use this for zulip#73, "Handle Zulip-internal links by navigation", to follow /near/<id> links through topic/stream moves (see implementation in zulip-mobile). For that, we'll need more than just the message's raw Markdown.

For the corresponding logic used in the web app and zulip-mobile, see web/shared/src/fenced_code.ts. I believe the logic here differs from that in just this way: it follows the CommonMark spec more closely by disqualifying backtick-fence lines where the "info string" has a backtick, since that's not allowed: > If the info string comes after a backtick fence, it may not > contain any backtick characters. (The reason for this restriction > is that otherwise some inline code would be incorrectly > interpreted as the beginning of a fenced code block.) Regarding the new file lib/model/compose.dart, we do have existing code that could reasonably move here, but it's pretty simple. It's the code that gives the upload-file Markdown; see registerUploadStart and registerUploadEnd in [ContentTextEditingController]. Related: zulip#116

We'll use this soon, for quote-and-reply zulip#116. With the recent commit 4e11ea7, PerAccountStoreTestExtension now has `addStream`, which we use in the tests.

For the corresponding logic used in the web app and zulip-mobile, see web/shared/src/fenced_code.ts. I believe the logic here differs from that in just this way: it follows the CommonMark spec more closely by disqualifying backtick-fence lines where the "info string" has a backtick, since that's not allowed: > If the info string comes after a backtick fence, it may not > contain any backtick characters. (The reason for this restriction > is that otherwise some inline code would be incorrectly > interpreted as the beginning of a fenced code block.) Regarding the new file lib/model/compose.dart, we do have existing code that could reasonably move here, but it's pretty simple. It's the code that gives the upload-file Markdown; see registerUploadStart and registerUploadEnd in [ContentTextEditingController]. Related: zulip#116

We'll use this soon, for quote-and-reply zulip#116. With the recent commit 4e11ea7, PerAccountStoreTestExtension now has `addStream`, which we use in the tests.

For the corresponding logic used in the web app and zulip-mobile, see web/shared/src/fenced_code.ts. I believe the logic here differs from that in just this way: it follows the CommonMark spec more closely by disqualifying backtick-fence lines where the "info string" has a backtick, since that's not allowed: > If the info string comes after a backtick fence, it may not > contain any backtick characters. (The reason for this restriction > is that otherwise some inline code would be incorrectly > interpreted as the beginning of a fenced code block.) Regarding the new file lib/model/compose.dart, we do have existing code that could reasonably move here, but it's pretty simple. It's the code that gives the upload-file Markdown; see registerUploadStart and registerUploadEnd in [ContentTextEditingController]. Related: zulip#116

We'll use this soon, for quote-and-reply zulip#116. With the recent commit 4e11ea7, PerAccountStoreTestExtension now has `addStream`, which we use in the tests.

For the corresponding logic used in the web app and zulip-mobile, see web/shared/src/fenced_code.ts. I believe the logic here differs from that in just this way: it follows the CommonMark spec more closely by disqualifying backtick-fence lines where the "info string" has a backtick, since that's not allowed: > If the info string comes after a backtick fence, it may not > contain any backtick characters. (The reason for this restriction > is that otherwise some inline code would be incorrectly > interpreted as the beginning of a fenced code block.) Regarding the new file lib/model/compose.dart, we do have existing code that could reasonably move here, but it's pretty simple. It's the code that gives the upload-file Markdown; see registerUploadStart and registerUploadEnd in [ContentTextEditingController]. Related: zulip#116

We'll use this soon, for quote-and-reply zulip#116. With the recent commit 4e11ea7, PerAccountStoreTestExtension now has `addStream`, which we use in the tests.

And use it in the one place where we've been creating inline links. This is a small amount of code, but drawing it out into a helper gives a convenient place to write down its shortcomings. We'll also use this for zulip#116 quote-and-reply, coming up.