| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
Rename from _private_chat_handler() to _handle_muc_private_message() to
be more consistent with other handler names.
|
|
|
|
|
| |
People could change messages of other people if the nick isn't
registered.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
XEP-0308 Version 1.1.0 (2019-05-15) states "It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages"
```
10:12:47 - jubalh: Do clients actually check whether other clients support xep0308 (LMC) before sending?
10:13:13 - pep.: not poezio, and I doubt anybody does. it's the "but carbons/MAM" argument
10:13:49 - jubalh: Profanity doesnt support this yet. So I always get the message twice. One time the message, and then the corrected ones. And I think that's right. But I understood xep0308 correctly it sais a
client shouldnt sent a message with 'replace' if the client doesnt support it? I don't see why
10:14:50 - Ge0rG: jubalh: because you might also use Conversations and read the backlog from MAM on conversations
10:15:51 - jubalh: Ge0rG: sorry?
10:16:36 - Ge0rG: jubalh: when I'm sending you a message, I don't know which client you'll use to read it. So it doesn't make sense to limit the features I use
10:27:57 - jubalh: Yes. That's why I'm confused by thestatement in the XEP
10:28:13 - jubalh: "It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages. "
10:28:37 - Holger: Yes, you're both saying the same thing. And yes I agree, that part of the XEP is nonsense. We have that "check whether the peer's client supports it" stuff in various XEPs that depend on
recipient's features and it never makes sense as it doesn't cope with multi-device, MAM, groupchat.
10:28:53 - jubalh: First: You don't know if he is connected with several clients. Some supporting it and some not. Second: Why not just resend the new corrected message? Then he has both messages and no
information is lost. If he only gets the first one information is lost
10:29:20 - jubalh: Okay
10:29:30 - jubalh: Then I won't implement it this way. Thanks guys!
10:29:34 - Holger: Well UX is a bit meh if the recipient doesn't support it (I'm an MCabber user and know what I'm talking about) but I see no better solution, yes.
```
So it makes more sense to just always send it. Non supporting clients will then get the message and the corrected message. So they get it "twice". Which is the right thing to do in my opinion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_win_print() and _win_printf() sound like they are the same. But
actually they are something totally different.
I renamed _win_print() to _win_print_internal() for that reason. It's
more about actually drawing to the ncurses window.
_win_printf() calls _win_print() and also writes the text to the window
buffer. Which _win_print() didn't, it was really just the ncurses
specific things.
In some cases there is _win_print_internal() called after a
buffer_append() in those cases it might be more correct to actually call
_win_printf().
It was not done so far. But probably is better. But will mean a bit more
operations.
I'll have to check this later.
|
|
|
|
| |
and make it static.
|
|
|
|
|
| |
So far we don't do this for encrypted messages. Still needs to be done.
And MUC also needs to be done.
|
|
|
|
|
|
|
|
| |
So far the correction is sent. But the UI in Profanity itself is not
updated.
Also autocompletion for `/correct` with the last sent message is
missing.
|
| |
|
|
|
|
| |
and print settings if only `/correction` is run.
|
| |
|
| |
|
| |
|
|
|
|
| |
"retrieve1" should have been only for testing.
|
|
|
|
|
|
|
|
| |
I think both the window and the buffer should also be cleared in case
`/clear` is issue and persist_history is off.
Otherwise it could happen that win_redraw() redraws the whole content of
the buffer again.
|
| |
|
|
|
|
| |
Fix a segfault if corresponding preference is not saved in config file.
|
|
|
|
|
| |
Actually presence_colour should be stopped there.
Thanks to rumin-miller for finding this.
|
|
|
|
| |
Seems this got forgotten.
|
|
|
|
| |
Fix #1068
|
| |
|
|
|
|
| |
Introduced in bf2e09feee1697c570fcfb9e1e44a8ec991bd196.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far we saved the timestamp which also had the `from`.
But we need this only to find out whether it's MUC history.
For displaying we should use the oldest delay timestamp.
Also in
https://github.com/profanity-im/profanity/commit/61f66966ddfe8ebd8bae26dd7ff92d777004edda#diff-4926fd4577a336bd3eb240f8104a5c5bL837
a error was introduced.
Before we saved the timestamp in all cases. And only if timestamp AND
from was given we went into MUC history case.
Normal timestamp saving was not done anymore only if it also had a from
attribute.
Regards https://github.com/profanity-im/profanity/issues/1254
|
|
|
|
| |
Have two helper functions one for XEP-0203 and one for XEP-0091.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far when loading a theme it also overwrote the preferences the user
set.
Lengthy discussion can be found at
https://github.com/profanity-im/profanity/issues/1077
Now we use `/theme load themename` to load the [colours] part of a
themem only.
`/theme full-load themename` will load the complete theme including
preferences set in there.
Regards https://github.com/profanity-im/profanity/issues/1077
|
| |
|
|
|
|
|
|
| |
Make _theme_list_dir() static.
Sort _load_preferences() loadings accoding to type.
Add comments.
|
|
|
|
|
|
|
|
| |
This reverts commit ef00b10c90aef8b75415fae558789d21bb975d75.
According to reply by user in
https://github.com/profanity-im/profanity/issues/1254#issuecomment-578389784
it didn't help.
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far we got the first delay with a from that comes from the server.
This way we know it's MUC history.
Now we take the first time stamp we actually find. Which is likely the
one being added first. And should contain the correct time to display.
It would be nicer to actually compare the dates though.
Regards https://github.com/profanity-im/profanity/issues/1254
|
|
|
|
|
| |
`/os on|off` now let's one choose whether to include the OS name once
`/software` (XEP-0092) is ran on us.
|
| |
|
|
|
|
|
|
| |
Default is on. `revail.os=false` in the `connection` section of the
config can disable it.
A command to configure this will follow.
|
|
|
|
|
| |
So far we only sent client name and version. Let's also send the OS
name.
|
|
|
|
|
|
|
|
|
|
| |
Cannot be configured for now.
Can be set via `adv.notify.discoversion` in the `notification` section.
Will notify about version requests via XEP-0092 and XEP-0232.
Client version can still be seen via caps (capabilities).
See `stanza_attach_caps()`.
|
| |
|
|
|
|
| |
Use helper function for duplicate code.
|
| |
|
|
|
|
| |
Add `/titlebar use [name|jid]`.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
`/roster room use name` to use the name of the MUC in the roster list.
`/roster room use jid` to use the jid of the MUC in the roster list.
Display it only in case `/roster room by none` is set so far.
|
|
|
|
| |
We will need this if we want to display the Name instead of the JID.
|
| |
|
|
|
|
|
|
|
| |
So far we just used -1 (default color). Now we actually check whether
`bkgnd` is set in the theme file and use this if available.
Fix https://github.com/profanity-im/profanity/issues/1255
|