| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
`/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
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
We need to change the buffer structure first, so that we save the from
field there.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
Seems this got forgotten.
|
|
|
|
| |
Fix #1068
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
`/os on|off` now let's one choose whether to include the OS name once
`/software` (XEP-0092) is ran on us.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Refactor /roster show/hide
|
| |
|
|
|
|
| |
Only compute string if necessary.
|
|
|
|
|
|
|
|
| |
`/occupants color on|off` to enable or disable XEP-0392 also for the
MUC occupants.
Regards
https://github.com/profanity-im/profanity/issues/1191
|
|
|
|
|
|
|
| |
`/roster color on|off` to enable or disable XEP-0392 also for the
roster.
Regards https://github.com/profanity-im/profanity/issues/1191
|
| |
|
| |
|
|
|
|
| |
Add a `/avatar` command.
|
|
|
|
|
|
| |
Implement settings for redgreen and blue blindness.
Regards https://github.com/profanity-im/profanity/issues/1191
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The last 3 commits added basic support.
Thanks @aaptel!
This commit adds basic settings interface to use it.
See `/color on|off`.
We still have to enable settings for color blindness.
And maybe another setting to decide whether to color the
occupantslist/roster with the same algo.
Regards https://github.com/profanity-im/profanity/issues/1191
|
|
|
|
|
| |
Fix https://github.com/profanity-im/profanity/issues/1229
Regards https://github.com/profanity-im/profanity/issues/1116
|
| |
|
|
|
|
|
|
|
| |
Instead of `/chlog on` we now have `/logging chat on`.
Instead of `/grlog on` we now have `/logging group on`.
Fix https://github.com/profanity-im/profanity/issues/1224
|
| |
|
|
|
|
|
|
|
|
|
| |
Seems this actually never worked.
Now it does.
`/status set online "This is my text"`
`/status set away bye`
`/status set away`
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before we had `/online`, `/away`, `/dnd`, `/chat`, `/xa`.
These commands are no longer available.
We have `/status set online` etc now.
Before `/status` was used to get the status of a contact.
This now moved to `/status get`.
Regards https://github.com/profanity-im/profanity/issues/1116
|
| |
|
|
|
|
|
|
|
|
|
|
| |
`/invite <contact>` became `/invite send <contact>.
`/invites` became `/invite list`.
`/decline` became `/invite decline`.
Accept is still done via `/join`.
Regards https://github.com/profanity-im/profanity/issues/1116
|
|
|
|
|
|
|
| |
Additionally to `/presence titlebar on` we now allow the setting via
/titlebar show|hide presence` since it's about the titlebar.
Regards https://github.com/profanity-im/profanity/issues/1116
|
|
|
|
|
|
|
|
|
|
|
| |
Additionally to `/resource titlebar on` we now allow the setting via
/titlebar show|hide resource` since it's about the titlebar.
But makes sense to have it in `/resource` too because there is
`/resource message on|off` too. And this one doesnt have an setting of
it's own.
Regards https://github.com/profanity-im/profanity/issues/1116
|
|
|
|
|
|
| |
Instead of `/encwarn on|off` we now have `/titlebar show|hide encwarn`.
Regards https://github.com/profanity-im/profanity/issues/1116
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we had `/tls show on|off` to manipulate the UI setting for
the title bar. To decide whether to show TLS info there or not.
This should go into `/titlebar`.
Now we have `/titlebar show|hide tls` for this.
Regards https://github.com/profanity-im/profanity/issues/1116
|
|
|
|
|
|
| |
New command `/paste` that sends the clipboard in MUC, Chat etc windows.
Fix https://github.com/profanity-im/profanity/issues/156
|