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
61f66966dd (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
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
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()`.
`/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.
prekey is defined as `<xs:attribute name="prekey" type="xs:boolean"/>`
which allows both `true` and `1` as truthy values.
Not checking for `1` breaks omemo encryption when interacting with
clients which set prekey="1", example: psi+ 1.4.983
Regards https://github.com/profanity-im/profanity/issues/1247
So far `/occupants char *`, `/roster contact char *`, `/roster room char #`,
`/roster header char -`, `/occupants header char -` was saved and
loaded from the preferences.
But was overwritten when the theme was loaded. If the theme didn't set
these values the value was just cleared. Despite that it might have been
set in the users preferences.
Funny enough the themes don't operate generally like this.
For example `otr.char` is not cleared.
This is again due to our borked theme/prefs concept
(https://github.com/profanity-im/profanity/issues/1077).
For now let's just use the one set from the preferences if it's set. The
theme will however overwrite it if it is set there.
Fix https://github.com/profanity-im/profanity/issues/1244
So far we removed the avatar feature only after a succesful retrive in
avatar_request_item_by_id() before we are going to retrieve the actual
image.
We should remove it at every `/avatar barejid` call too so in case one
retrieval was unsucessful that we can call it again.
So far it seems like there is no other way to trigger getting the nodes
except announcing that we support the avatar feature.
So far we printed one after the last received message, which doesn't
make much sense of course.
Now only print one if there is not already one present.
This is because the actual command that parses itself (cmd_logging) returns false if it didn't get the expected parameters.
Handing the printing however is done by another function. This function is added to the Command struct as setting_function.
So if this is set, and the actual command returns false. We should just call the setting_function and not print the error message.
Fix https://github.com/profanity-im/profanity/issues/1237
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
* add theme_hash_attrs()
* when printing a user message check PREF_COLOR_NICK to decide whether
to colorize it or not
ideally we should hash the jid instead of the nick but this is already
a first step.
* add the HSL values of each of the 256 terminal colors
* add color_pair_cache_hash_str()
* move common code to _color_pair_cache_get() helper func
after hashing a string to a color, return the closest matching
terminal color using euclidian distance of the HSL diff vector (this
method was found empirically and seems to work well enough...)
From @xaizek s comment on issue #1235:
```
If the move would cause the window to be off the screen, it is an error and the window
is not moved.
Resize on the other hand doesn't fail like this according to its documentation. So new size needs to be applied first.
```
Big thanks to @xaizek for taking a look at our code and helping us!!
Regards https://github.com/profanity-im/profanity/issues/1235
This is encountered when biboumi is used.
Example: `/join #debian-next%irc.oftc.net@biboumi.lebihan.pl`
It seems then time can be null.
g_date_time_format() will not work in this case although time_pref will
not be "off". So let's not call g_date_time_format() in this case. But
treat it like time is set to off.
However message reflection will not work properly with biboumi.
Probably we dont get origin-id.
Fix https://github.com/profanity-im/profanity/issues/1230
https://github.com/profanity-im/profanity/issues/1190 had another issue:
Sometimes servers send multiple </delay> and we just checked the first
one we got and only used it if the 'from' attribute was fitting.
However it could be that we actually wanted the second </delay> element
and there the 'from' would have been right.
So we need to loop through them until we get the one with the fitting
'from'.
Fix https://github.com/profanity-im/profanity/issues/1190
Gajim sends \u200E and \u200F for RTL.
It is planned that Gajim stops doing this and uses some GTK feature to
get the same result.
However users expressed the whish that we filter out such characters in
incoming messages before displaying them to make Profanity more robust.
I'm still not sure whether I like the solution because it means a lot of
allocating/deallocating upon every new message.
Fix https://github.com/profanity-im/profanity/issues/1220
The problem is that in _handle_groupchat() we look for
STANZA_NS_STABLE_ID which will result in origin-id or stanza-id.
It seems like prosody servers send origin-id first, so this worked in
all my tests. But actually we cannot be sure of the order.
So far we stopped after the first element was found.
I only found xmpp_stanza_get_child_by_ns() and
xmpp_stanza_get_child_by_name() in libstrophe. But we need a combination
of both.
So I created stanza_get_child_by_name_and_ns() for Profanity. I need to
remember to upstream this to libstrophe later (if they really don't have
such a function).
Fix https://github.com/profanity-im/profanity/issues/1223
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
Regards https://github.com/profanity-im/profanity/issues/200
This doesn't work yet. And I have no idea why.
Weird behaviour:
- start profanity
- type 'ASDF'
- ctrl+arrow down
-> text vanishes (like intended)
- arrow up
-> nothing happens (intended is that the last history item [ASDF]
appears)
- type 'ABC'
- press enter
- arrow up
-> ABC appears
- enter
- type 'UUU'
- ctrl+arrow down
- type 'ZZZ'
- enter
- arrow up
- ZZZ appears
- arrow up
- UUU appears
So in the latter case we added to history and deleted from the input
line and then immediately entered new text and pressed enter, to add
this to the history too.
When we do this the not sent text succesfully was stored in history.
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
XEP-0184: Message Delivery Receipts, *requires* the id attribute.
Generally this is not the case.
For this reason the id was only present in the DeliveryReceipt struct
since it was only used for XEP-0184.
For https://github.com/profanity-im/profanity/issues/660 XEP-0313 MAM
and https://github.com/profanity-im/profanity/issues/805 XEP-0308 Last Message Correction
we will also need the id.
So in preparation for further work let's move the id to the general
ProfBuffEntry.
We will need to adapt code so that we actually always write the ID if we
receive one.
