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

Better Edit/Reply outputs for IRC #86

Open
llmII opened this issue Feb 15, 2021 · 6 comments
Open

Better Edit/Reply outputs for IRC #86

llmII opened this issue Feb 15, 2021 · 6 comments

Comments

@llmII
Copy link
Contributor

llmII commented Feb 15, 2021

Looking at docs I believe we should be able to fetch the referenced message (we have the channel and message id's already I think). If we do this, we could include that in the reply/edit output so it doesn't simply say "[reply]" or "[edit]" and no one knows what was it that was edited or replied to. From there assuming #76 and associated PRs get merged we could add a few fields into the DiscordMessage struct (a "referenced" field for the content of the referenced message) and then apply formatting to the message based on if the message is a reply or edit or original when calling the formatting functions.

I was noticing a "[reply]" message today and it happened to annoy me I had no idea to what was replied.

@qaisjp
Copy link
Owner

qaisjp commented Feb 16, 2021

How would this look on the IRC side? If many people are replying to the same message, we wouldn't want the same message appearing multiple times next to each other.

@llmII
Copy link
Contributor Author

llmII commented Feb 16, 2021

REPLY=${CONTENT} (re: ${ITALIC}${REFERENCED}${ITALIC})
EDIT=${UNDERLINE}${REFERENCED}${UNDERLINE} ${ITALIC}->${ITALIC}${BOLD}${CONTENT}${BOLD}

For edit I'd prefer strikethrough to underline but weechat doesn't support strikethrough and underline is sort of close to it... I'm open to other formatting options. That said, if we want to do it without control codes you can mostly strip out the control code stuff in the above and it'll look ok, just a little more of a mental effort (especially for EDIT, where instead of wrapping in control codes might need to wrap in quotes ".

@qaisjp
Copy link
Owner

qaisjp commented Feb 16, 2021

I think the edit line is too verbose. I've found that for edits you can usually tell which message has been edited.

For replies, maybe we can include a heavily truncated part of the message (and eventually add support for ircv3 threads/replies, even though many ircds and most clients don't support it).

@llmII
Copy link
Contributor Author

llmII commented Feb 16, 2021

The option for that verbosity isn't a bad thing, and that definitely not be the default (even if it is what I plan to use in configurations until I figure out if it looks too noisy or whatnot).

Truncation for replies might work... should truncation be configurable or static (I'd lean configurable with a sane default I think).
That said, retaining the option for the user to configure a full reference or a truncated version means I'd need to include 2 new interpolation formatters "${REFERENCED}" and "${TRUNCATED}".

Using IRCv3 threads/replies would mean keeping a history of messages we send and correlating them to messages from Discord? Then we would need a history setting?

@llmII
Copy link
Contributor Author

llmII commented Feb 16, 2021

Think through this further, the best way IMO to handle the interpolation is to use the current IRC Format interpolation formatters in #76 and then add a interpolation formatter for TRUNCATE .

Whenever a message is a referred to message it'd use a new format key "REFERRED" and could in turn be handled just like regular message by the formatter. It would be up to the code calling the formatter to tell the formatter that it should be using the "REFERRED" key. Maybe there should be a "REFREPLY" and "REFEDIT" keyset instead (in case one would want the message formatted differently when handling it?

So the code calling the formatting functions would first call the formatter with the referred content with the proper format keys, and would get back a referred_content line. Then it would call the formatter again with either the new "REPLY" or "EDIT" format key, the content line, and the previously obtained referred_content. The formatter remains unaware of anything but formatting a line.

@madsl
Copy link

madsl commented Apr 20, 2022

I can't quite figure out if the code as it stands now is configurable in a way that can show us replies in IRC like llmII suggests. I'm guessing there's some work that needs to be done :p But it would be great to be able to see replies in IRC too, it's a feature that's quite often used.

Great work btw!

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

No branches or pull requests

3 participants