Last active 1 year, 4 months ago

#219 Multi-line markdown code blocks render expand ticket mentions 5 months ago

Comment by ~anteater on ~sircmpwn/todo.sr.ht

This is performed by render_markup and urlize_ticket in todosrht/filters.py: https://git.sr.ht/~sircmpwn/todo.sr.ht/tree/master/item/todosrht/filters.py

It looks like this is actually going to be a bit painful to fix, because the idea of what ticket/user mentions are in a comment is not computed by a real parser at markdown parse time, but with regex prior to it: see USER_MENTION_PATTERN and TICKET_MENTION_PATTERN here: https://git.sr.ht/~sircmpwn/todo.sr.ht/tree/master/item/todosrht/tickets.py

It seems like it may actually be possible to use these regexes to define new tokens in the actual markdown renderer itself (SrhtRenderer, which inherits from mistletoe.HtmlRenderer): see the docs at https://github.com/miyuchina/mistletoe/blob/master/mistletoe/base_renderer.py

According to those docs, it looks like we can "add additional tokens into the parsing process by passing custom tokens to super().__init__()" and "add additional render functions by appending to self.render_map". The latter seems to happen implicitly based on method name.

So SrhtRenderer would do something like:

class TicketMention(SpanToken):
    Ticket mention ("[[~user/]tracker]#123")
    This is an inline token with a single child of type RawText.
    pattern = re.compile(TICKET_MENTION_PATTERN)
    parse_inner = False
    parse_group = 0

    def __init__(self, match):
        content = match.group(self.parse_group)
        self.delimiter = match.group(1)
        self.padding = " " if not content.isspace() and content.startswith(" ") and content.endswith(" ") else ""
        self.children = (RawText(content),)

    def find(cls, string):
        matches = core_tokens._code_matches
        core_tokens._code_matches = []
        return matches


# this is basically just `urlize_ticket`
def render_ticket_mention(self, token):
        text = token.match.group(0)
        ticket_id = token.match.group('ticket_id')
        tracker_name = token.match.group('tracker_name') or tracker.name
        owner = token.match.group('username') or tracker.owner.username

        ticket_ref = f"~{owner}/{tracker_name}#{ticket_id}"
        if ticket_ref not in tickets_map:
            return text

        ticket = tickets_map[ticket_ref]
        url = urls.ticket_url(ticket)
        title = escape(f"{ticket.ref()}: {ticket.title}")
        return f'<a href="{url}" title="{title}">{text}</a>'

I haven't tested this code, but I think it's within debugging distance of something that would work.

This also requires plumbing tracker, and tickets_map down through srht.markdown and into SrhtRenderer so that we can use them in the render_ticket_mention method. The same should be done for user mentions and urlize_users.

#76 Cannot send 1 year, 3 months ago

integration added by ~anteater on ~anteater/mms-stack-bugs

#76 Cannot send 1 year, 3 months ago

docs added by ~anteater on ~anteater/mms-stack-bugs

#76 Cannot send 1 year, 3 months ago

mmsd added by ~anteater on ~anteater/mms-stack-bugs

#76 Cannot send 1 year, 3 months ago

user support added by ~anteater on ~anteater/mms-stack-bugs

#76 Cannot send 1 year, 3 months ago

Comment by ~anteater on ~anteater/mms-stack-bugs

Thanks for the experience report!


Does wwan0 (the modem) require a DHCP lease in order to send the MMS message? I know it requires a data connection - but does your modem usually need an IP address in "ip addr" to send MMS successfully?

The modem does need an IP address (any IP communication does), but this is usually not assigned with DHCP. Instead, the modem negotiates over GSM for an IP, and makes that known to userspace (ModemManager or Ofono) over AT protocol, QMI (the Qualcomm proprietary interface), or less likely some other modem-specific protocol. ModemManager will talk to NetworkManager, and Ofono can integrate via ofonoctl. This should be explained at https://git.sr.ht/~anteater/mms-stack-meta but isn't currently.

In addition, mmsd/mmsd-tng requires the correct "bearer" to be active. A bearer is one specific network connection via the modem, and its APN (Access Point Name) needs to be the right one for communicating with the MMSC. This is technically only necessary on some service providers, but other restrictions (such as only allowing access over the IPv6 address assigned to the handset) may apply. Generally both bearer and other restrictions exist for billing and authentication reasons (for example, many ISPs share IPv4 addresses among many subscribers, but need to know which subscriber is accessing the MMSC so that they cannot spoof sending messages as someone else). The handling of this is one place where mmsd-tng works much better than legacy mmsd. It's probably worth migrating to mmsd-tng, which I should get around to pointing to in the mms-stack-meta overview.

Also... do you have any suggestions on a better way to get error message to debug what the problem could be?

Any output from mmsd/mmsd-tng is worth looking at; it's likely to have the most context for why MMS does not work. You can also see what printed output vgmms gives when attempting to send the MMS, but it's not likely to see the root cause of the problem.

I was able to get things working on Manjaro, but sending photos doesnt work! the groupchat does work though.

Photos and group messages go via the same machinery: they're attachment files uploaded to or downloaded from the MMSC. The only substantial difference may be that images are more likely to hit MMS size limits. Can you check whether sending a smaller image (or receiving images, since any image the MMSC provides as a download has already passed any size limits) works?

It is some kind of null pointer exception, "expected bytes"

Please post the error message itself and what context you can, removing any personally identifying information if desired.

#277 Strings such as #123 should not be treated as a ticket reference inside a <pre> 1 year, 5 months ago

Comment by ~anteater on ~sircmpwn/todo.sr.ht

I believe this is a duplicate of #219 (unless the distinction is <pre> vs ```). In any case the misbehavior is the same.

#58 Purple-mm-sms: merge request to add MMS receive support. 1 year, 5 months ago

Comment by ~anteater on ~anteater/mms-stack-bugs

The upstream project has moved on past this now.


#74 Could not determine country of subscriber phone number on ModemManager 1 year, 10 months ago

Comment by ~anteater on ~anteater/mms-stack-bugs

~ccf100: Are you using ofono or ModemManager?

#74 Could not determine country of subscriber phone number on ModemManager 1 year, 10 months ago

Comment by ~anteater on ~anteater/mms-stack-bugs

I haven't gotten around to vgmms maintenance in quite some time, but now that I look at your follow-up, the problem is clear: the number as returned from the modem has no country code! We currently obtain the default country for parsing other numbers from the user's number, but in this case we'll need to have a further fallback source of the information. A user could specify a default country in settings, or there may be a locale-based way to default things.