| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ |
|
| |\
| | |
| | | |
Add builds.sr.ht badge for Profanity builds
|
| |/ |
|
| |
| |
| |
| | |
Fix https://github.com/profanity-im/profanity/issues/1261
|
| |
| |
| |
| |
| |
| | |
So we can use it somewhere else too.
Regards https://github.com/profanity-im/profanity/issues/1261
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`/logging group color` has:
* `unanimous` which will color it with one unanimous color. Like it was
done always.
* `regular` which colors it like regular incoming messages.
Regards https://github.com/profanity-im/profanity/issues/1261
|
| |
| |
| |
| | |
Just pass ProfMessage.
|
|/ |
|
|\
| |
| | |
Add builds.sr.ht CI for OpenBSD
|
| |
| |
| |
| |
| |
| |
| |
| | |
* Add .builds/openbsd.yml for builds.sr.ht
* Update travis-build.sh -> ci-build.sh with OpenBSD case
* Fix libdl check in configure.ac (OpenBSD has libdl built-in)
* Fix some minor issues found when compiling on OpenBSD with GCC (e.g.
uninitialized variables)
|
| |
| |
| |
| |
| |
| |
| | |
We decrypt both 12 and 16 bytes.
And send 12 instead of 16 bytes now.
Close https://github.com/profanity-im/profanity/issues/1272
|
| |
| |
| |
| | |
We never use the printf like behaviour anyways.
|
| |
| |
| |
| | |
We never use the printf like behaviour anyways.
|
| |
| |
| |
| | |
We never use the printf like behaviour anyways.
|
| |
| |
| |
| | |
We never use the printf like behaviour anyways.
|
| | |
|
|\ \
| |/
|/|
| | |
Close https://github.com/profanity-im/profanity/pull/1270
|
| |
| |
| |
| | |
Regards https://github.com/profanity-im/profanity/pull/1270
|
| |
| |
| |
| |
| |
| | |
`/pgp sendfile on` allows unencrypted file transfer in an PGP session.
Regards https://github.com/profanity-im/profanity/pull/1270
|
| |
| |
| |
| |
| |
| | |
`/otr sendfile on` allows unencrypted file transfer in an OMEMO session.
Regards https://github.com/profanity-im/profanity/pull/1270
|
| |
| |
| |
| |
| |
| |
| | |
`/omemo sendfile on` allows unencrypted file transfer in an OMEMO
session.
Regards https://github.com/profanity-im/profanity/pull/1270
|
|/ |
|
|
|
|
|
| |
Fix tests/unittests/test_cmd_otr.c:415: warning: 'window.layout' is used
uninitialized in this function on openbsd (thanks optmzr)
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1265
|
| |
|
| |
|
| |
|
|\
| |
| | |
XEP-0308 Last Message Correction
|
| |
| |
| |
| |
| | |
We need to change the buffer structure first, so that we save the from
field there.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
If we are connected with another client and send a message, then correct
it. We now display it correctly in Profanity.
Id wasn't saved for carbon copied messages too so far.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
So far receipts are only send if we have enabled it and the other client
supports it.
But it could be that the other person is connected with several clients.
One supporting it and the other which doesn't. If the not supporting one
is active and we send to a fulljid, then we won't get receipts.
Probably it's best to just always send them if they are enabled in
Profanity. And not try to find out the capabilities of the other client.
Fix https://github.com/profanity-im/profanity/issues/1268
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
In aa3693daa211b36c78d136d5a1ee9f3258e21352 I renamed
`win_println_me_message()` -> `win_print_outgoing_muc_msg()`.
Now: `win_println_them_message()` -> `win_println_incoming_muc_msg()`
to be more consistent and descriptive.
|
| | |
|
| |
| |
| |
| | |
No `/correct` allowed in privwins
|
| | |
|
| |
| |
| |
| | |
Outgoing `/correct` will still work.
|
| |
| |
| |
| |
| |
| | |
Now we can specify an unlimited amount of arguments for commands.
Maybe this is also helpful for other commands that use quotation marks
so far.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Including OMEMO encrypted ones.
Also rename `win_println_me_message()` to `win_print_outgoing_muc_msg()
as I think it's a more descriptive name.
|
| |
| |
| |
| |
| | |
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.
|
| | |
|