In console autocomplete from roster.
In muc autocomplete from occupants lits.
In 1:1 regular chat autocomplete from active resources of currently
selected user (new).
Also give a hint (/help resource) how to set the resource should a user choose that way.
Fix https://github.com/profanity-im/profanity/issues/1337
For some time users could choose to have the old way "unanimous" where
all the MUC history is just grey (or whatever was set). Now it is always
just displayed like regular new incoming MUC text.
Some users might want there nick to always stay white (etc) for easier
recognition.
Now we can do `/color own off` to not generate the color based on
xep-0392. The `me=` color (etc) from the theme will then be used.
Once we run this command `theme_load()` is called again.
And the theme looks totally wrong.
We encountered this at other times already and I think it's nothing
wrong with this new code here now but that there seems to be a missing
closing attr for the color when drawing.
Should be investigated seperately.
Fix https://github.com/profanity-im/profanity/issues/1288
`/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
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 the correction is sent. But the UI in Profanity itself is not
updated.
Also autocompletion for `/correct` with the last sent message is
missing.
`/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.
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
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 `/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
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
room is either argv[0] or allocated by GString. We have to free memory
in the 2nd case. Replace argv[0] with g_strdup(argv[0]) in order to
make unconditional g_free().
This should actually never happen because we have the mechanism that
checks the commands. But let's do it in case we break something in that
mechanism and to make clang happy.
Fixes clangs: 'Argument with 'nonnull' attribute passed null'
Implements feature requested at: https://github.com/profanity-im/profanity/issues/632
So instead of:
/time console set <format>
/time chat set <format>
/time muc set <format>
/time mucconfig set <format>
/time private set <format>
/time xml set <format>
As a short cut the user can do:
/time all set <format>
Excluding statusbar and lastactivity settings since they are not for main windows, but used slightly differently.
Some code was duplicated/similar.
The parts about using a chatwin while being started from another window
(recipient provided) and being a chatwin were the same.
Like this it should be easier to read and less code.
In case Python or C plugins are disabled install/load failed silently.
Notify the user that we can't load them because profanity was built
without support for plugins.
`/occupants char` now sets a character that is displayed before the nick
in MUCs. Similar like `/roster char` is displaying a char for the roster.
Regards #690
`/occupants header char` now sets a character that is displayed before
the role (moderator, visitor..) in a room. Similar to `/roster header
char` is displaying a char for the roster.
Regards https://github.com/boothj5/profanity/issues/690
Roster has a `/roster contact indent` option.
Now we have the same for occupants. So contacts in roster and in MUC can
have configurable indentation.
Regards https://github.com/boothj5/profanity/issues/690
There is 3 policy:
- manual: OMEMO session are only started manually
- automatic: OMEMO session are only started if they have been started
manually before
- always: OMEMO session are always started unless they have been ended
manually before
Closes#1040 and fixes#1052
The command "/plugins install <path_to_folder> should install all
plugins in the given folder. This commit removes the check if the path
points to a file (which is repeated in the section installing a plugin
from file) and makes the existing code installing multiple plugins accessible
Don't lower account name before calling accounts_get_account().
Only lower if there is no account with the given name and the name is
interpreted as a jid.
Updated unittests to test this behaviour.
Fixes#725
.
With this feature user can configure TLS policy for an account and
override it for a single login with /connect command.
Example:
/account set <jid> tls force
/connect <jid> tls trust
The example shows how to trust server's certificate only once.
Fixes#1021.
New tls policy "trust" added to /connect and /account. With the policy
TLS connection is established even with invalid certificate. Note, that
trust policy forces TLS connection and it fails when server doesn't
support TLS.
Examples:
/connect <jid> tls trust
/account <name> set tls trust
Add "legacy" tls policy to /account and /connect commands. When this
policy is specified the connection is connected with
XMPP_CONN_LEGACY_SSL flag. Notice, legacy SSL and STARTTLS are not
compatible and user has to know when exactly the new policy should be
used.
To enable it, run one of the next commands:
/connect <jid> tls legacy [server <host>]
/account <name> set tls legacy
Notice, there is no SRV record for legacy SSL. Therefore, you may need
"server" property to connect successfully. Refer to configuration
provided by your server.
