00dbc1ba7c attempted to fix
https://github.com/profanity-im/profanity/issues/1449.
Here we revert the part about initializing is_omemo in chatwin_new()
since this is done in win_create_chat() already.
The actual mistake was the wrong cast of the muc window which is fixed
by the same commit. The mistake was introduced in in 3370418d71.
While being at it we also remove the is_ox initialization since this is
handled in win_create_chat()/win_create_muc() too.
`profanity mangen` will create for each command (`/account`, `/roster`)
an own manpage (`profanity-account.1`, `profanity-roster.1`)
See https://github.com/profanity-im/profanity/issues/1444
Needs some polishing formatting wise.
Regards https://github.com/profanity-im/profanity/issues/1435
So far we didn't print the error if it contained `<error
type="cancel">`. It appears that the code always thought this is a
service-not-available (so one is either blocked or the account doesn't
exist) and printed `Recipient not found`.
But there can be other errors as well. Like in above mentioned issue
`not-allowed`.
Let's just print the text.
In case of the cancel type we still remove the jid from the chat
sessions. I'm not entirely sure whether this needs to be done in other
cases too.
Using g_date_time_new_now_utc instead of g_date_time_new_now_local
Using g_date_time_format(timestamp, "%FT%TZ") instead of "%FT%T%:::z"
Edit:
DebXWoody created this patch because ejabberd returned an error with the
old date format.
When a bookmark is created with '/bookmark add' command,
ext_gajim_minimize remains uninitialised in new bookmark object and
is read further in _send_bookmarks().
Initialise the field with 0.
Fixes#1432.
Commit f12161f fixes memory leak, but introduces use-after-free issue.
Allocate new memory for win_name with g_strdup() since it is freed with
g_free() later.
This partly reverts d3a387a0ec.
For proanity 0.9.x we still wanted to support older glib versions so
that we can be packaged for various linux distros.
Now with 0.10 we want to move on.
Replace our own stanza_get_child_by_name_and_ns() with the upstreamed
xmpp_stanza_get_child_by_name_and_ns() provided by the new
libstrophe/libmesode 0.10.0.
This allows profanity to work without segfaulting from NULL
pointer dereferences when used with NetBSD libcurses.
Basic functionality was tested, there may be more NULL pointer
issues hiding.
- Add NetBSD as a recognized platform without -ldl.
- Allow building with NetBSD libcurses instead of ncurses.
- Portability to NetBSD sh - use POSIX '=' instead of '=='.
archive_is is <stanza-id> or <result id=""> and should identify one
message stable and uniquely.
See XEP-0359: Unique and Stable Stanza IDs.
We need this for example for this situation:
* we go online with Profanity
* we fetch all messages since yesterday
* we add them to the db
* we go offline
* we go online with Profanity
* we fetch all messages since yesterday
* we only want to add the new ones
So far we don't ask MAM "give me all since last 'id'" but since a
certain date.
In case no archive_id will be set, it will be `(null)` and thus should
be inserted anyways because it won't find a value with (null) in that
row.
Because when adding we use `message->stanzaid ? message->stanzaid : "",`
so it will be empty in such a case.
Regards MAM: https://github.com/profanity-im/profanity/issues/660
Regards Stable IDs: https://github.com/profanity-im/profanity/issues/1207
We use malloc() to allcoate memory for the arguments.
But later on in cmd_funcs.c we use g_strfreev() to free it.
Let's use g_malloc() to allocate instead.
Second change is to use g_malloc() and g_free() for a gchar.
Autocomplete only completed on|off.
Now:
`/lastactivity get` -> get server uptime
`/lastactivity get <jid>` -> get user lastactivity
`/lastactivity set on` -> enable for self
`/lastactivity set off` -> disable for self
Fix https://github.com/profanity-im/profanity/issues/1411
`parse_args()` and `parse_args_with_freetext()` shared a lot of common
code.
Let's have a helper function `_parse_args_helper()` for that. The
`with_freetext` parameter will make it behave like
`parse_args_with_freetext()`.
In preparation for https://github.com/profanity-im/profanity/issues/1404
This commit partly reverts
8f37afcd37
Which was using a wrong approach to achieve this.
It changed parse_args() to have a -1 for infinite parameters.
But actually parse_args_with_freetext() should have been used exactly
for this behaviour.
Discovered when checking for
https://github.com/profanity-im/profanity/issues/1404
Discovering Public Keys via PEP
* 4.3 Discovering Public Keys of a User
* 4.4 Requesting Public Keys
* Import Public Keys into GnuPG's local keyring.
Issue: #1331
If we receive a message we get:
<< room message: eagle@conference.anoxinon.me (win 2)
Same for private chats and regular chats.
And several other kinds of notifications.
If we only receive notifications from a chat window it would be nice to
also clear the hilight on the console window since we already catched up
by reading the actual message in the chat window.
Probably not the best description :-) I hope you get it..
Regards https://github.com/profanity-im/profanity/issues/1399
src/pgp/gpg.c:p_ox_gpg_readkey
Used to read a public key from a file. The function will return the fingerprint
of the file and the base64 encoded key.
src/xmpp/ox.[hc]
ox_announce_public_key(const char* const filename) can be called from the /ox
announce <filename> command. The key within the file will be pushed on PEP and
the Metadata node will be set.
Issue: #1331
Plain chat messages not working for non-carbon + no OTR support.
On master we did some clean-up. The problem is at https://github.com/profanity-im/profanity/blob/0.9.patch/src/event/server_events.c#L625 (0.9.0). The implementation looks like:
- HAVE_LIBOTR is set - _sv_ev_incoming_otr
- HAVE_LIBOTR is not set - _sv_ev_incoming_plain
I think the `_sv_ev_incoming_otr` can handle otr and plain, because I didn't find a `_sv_ev_incoming_plain` if `HAVE_LIBOTR` is set.
On master for 0.10.0 the implementation is much better:
https://github.com/profanity-im/profanity/blob/master/src/event/server_events.c#L623
But, we just call `_sv_ev_incoming_otr` independent of `HAVE_LIBOTR`.
Unfortunately, `_sv_ev_incoming_otr` is doing nothing if `HAVE_LIBOTR` is not set:
https://github.com/profanity-im/profanity/blob/master/src/event/server_events.c#L538
I did some more clean-up at sv_ev_incoming_message and changed the implementation of `_sv_ev_incoming_otr`.
```
static void
_sv_ev_incoming_otr(ProfChatWin *chatwin, gboolean new_win, ProfMessage *message)
{
// OTR or plain
plain
}
```
The caller do not take care of `HAVE_LIBOTR`, call `_sv_ev_incoming_plain` if you are sure it's a plain message or call `_sv_ev_incoming_otr`. `_sv_ev_incoming_otr` can be used for otr / plain or for plain only.
In 0.9.x we fixed an issue, because OMEMO devices should be defined in "item"
with id "current". This should work, but it won't work if there is no "current".
If there is no "current" we will just use the first item.
Issue #1384
Messages from Conversations contains:
<request xmlns='urn:xmpp:receipts'/>
And would not be displayed in Profanity as it never reached
_handle_chat(..).
So far:
```
/executable urlsave html "test %u" results in url.save.cmd[html]=test %u
/executable urlsave * "test %u" results in nothing.
```
Probably due to limitation in .ini file format.
Additionally to ec7e635e75.
In the earlier commit I just setted the test value ignoring the real
format.
Now we correctly transform:
```
[logging]
urlopen.cmd=xdg-open
```
into:
```
[executables]
url.open.cmd=false;xdg-open %u;
```
c56d530b67 by peetah moves:
urlopen.cmd from the 'logging' to a new 'executables' section in profrc
avatar.cmd from the 'logging' to a new 'executables' section in profrc
We need to adapt this so that users don't have to set the setting again
themselves.
The display of commands associated with specific file
types and protocols will need to be implemented later,
but this requires to use private data of the GKeyFile
structure, which can be a maintainability issue on the
long term.
Signed-off-by: Pierre Mazière <pierre.maziere@gmx.com>
/urlopen is replaced by /url with the following sub commands:
/url open <url>
/url save <url> [<path>]
Signed-off-by: Pierre Mazière <pierre.maziere@gmx.com>
Where GKeyFile usually use the pref[locale] format to define
locale specific translated data, it is here hijacked to be used
as pref[option] in order to specialize a preference according
to an option:
open.url.cmd[pdf] = pdf-viewer
open.url.cmd[jpg] = image-viewer
Signed-off-by: Pierre Mazière <pierre.maziere@gmx.com>
strncpy(3) is not so safe function and can lead to mistakes. For
example, strncpy(dest, "Profanity", 10); is redundant and leads to
problems when someone changes the source string.
Different example is when 3rd argument equals to length of the
destination buffer. strncpy(3) doesn't terminate string with '\0' when
it truncates. Therefore, the destination string becomes corrupted.
Zeroize storage for 'nid', so the last byte remains '\0' in case of
truncate.
Since d92c576aa5
we rely on g_spawn_sync().
Which doesn't do variable/glob expansion.
For our use of call_external() in opening and URL or avatar this is
fine.
For getting the password we want to be able to use ~ for our files.
Let's use a shell here.
Fix https://github.com/profanity-im/profanity/issues/1364
98c38dc6d6
sets C99 as standard.
strdup() is not part of C99.
For now set `-D_POSIX_C_SOURCE=200809L` macro to have strdup() in C99.
Using `gnu99` instead would be another option.
We should take more care to use glib functions whenever possible.
Regards https://github.com/profanity-im/profanity/issues/1357
Found this when looking to fix bug https://github.com/profanity-im/profanity/issues/1357
Not sure if it is related.
man 3 getenv sais:
```
As typically implemented, getenv() returns a pointer to a string within
the environment list. The caller must take care not to modify this
string, since that would change the environment of the process.
```
Some systems don't provide recent libstrophe releases. When older
version of libstrophe is detected, don't build legacy auth support.
To simplify this patch, report about unsupported legacy auth and
keep commands option as is.
Profanity requests the device list and keys for contacts, also when the user
hasn't generated the OMEMO key. If the user has no OMEMO key, there is no need
to request OMEMO information.
Issue: #1332
Memleak was reinroduced in d92c576aa5
It was already fixed in ac5ce105ac
But the rebase peetahs rebase ontop of master took the wrong changes.
I decided to pull anyways and fix since reviewing/giving feedback
without GH probably takes longer.
Fix https://github.com/profanity-im/profanity/issues/1280
p_contact_set_presence() is triggered in
(roster_process_pending_presence) to set the presence to online
after the roster is displayed.
This happened to me _every time_ with one certain account on my server.
But not even once with other accounts on my server.
I don't understand why that is the case, but AFAIK the code should be
like it is in this PR anyways.
roster_process_pending_presence() was added there in
973a05d15a to fix
https://github.com/profanity-im/profanity/issues/1050
NOTE: as per XEP-0060 §12.20, it is RECOMMENDED for the publisher to specify an
ItemID of "current" to ensure that the publication of a new item will overwrite
the existing item.
https://xmpp.org/extensions/xep-0384.html#devices
Issue: 1329
There is code to redraw the ui, because the user may enter a passphase for the
private key. There was also a ui_init, which shouldn't be called, because it
will set the status to the initial state, which is 'offline' and 'no tls'.
Issue: #1327
A autoping is to make sure that there is still a connection between server and
client. If the application receives incoming stanza, the connection is fine.
There is no need to wait for response, if there are other incomings.
Issue: #1333 and #1315
With d1d0ad8d1a we set a timestamp to now
for all messages upon receival. Even if the original message didn't
contain any timestamp. So we can use the timestamp of retrieval for
logging and displaying and don't get them at each of those location
where they might differ.
This means that timestamp will never be NULL.
I don't see why we would want to check for the chat state only if
timestamp isn't there.
Probably because in XEP-0085 there is not timestamp defined.
So if it thats stanza it's not there and we can parse quicker, but there
is nothing forbidden it to be there.
Related to https://github.com/profanity-im/profanity/issues/1339
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
1f8b1eb740 made it possible to have utf8 chars as correction chars. So since then prefs_get_correction_char() doesn't return a regular char but a char*.
Seems like there was an oversight that we need to use %s then.
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.
Profanity request the OMEMO Device List for all members, also if the MUC is
anonymouse. If the user is Admin / Owner, the device list will be requtest.
Issue #1315
glib functions can allocate a GError object that must be freed with
g_error_free(). Otherwise a memory leak happens.
There are similar unfixed places in omemo, check:
grep "&error" src/omemo/omemo.c
Fixes#1304.
MUCPMs and regular chat messages get printed with the same code.
But we don't save MUC PMs in the sqldb, because another jid could use
the same nick the next time.
And if we would take the log out we would need a different routine,
checking for resourcepart too.
Fix https://github.com/profanity-im/profanity/issues/1312
Only when we start the conversation.
Not yet when we get messaged and a new window is opened.
Need to have sorting of messages in the window buffer then, I guess.
Also MAM IQ should only be send one time in such a case.
If MAM is enabled history from sql backend will not be shown.
`mam` in profrc enables experimental MAM.
Can change soon again. Don't rely on stuff in this stage ;)
Later we will have several options.
Getting everything since last timestamp (if none everything at all).
Getting everything since today + configure time (1 week).
Should also have a reload all command like conversations once you
cleared the history.
All MAM messages should be written into sql db.
And then probably displayed from there so that regular history works
too.
MAM messages don't have a type nor a from.
If we detect a message without type let's log it and exit without
continuing to try to parse it.
Otherwise we go into _handle_chat() and crash on the no from.
The function creates a form to find such strings as software, os, etc.
It remembers the strings allocated by form_create() and use them below
in caps_create(). The issue is that the form is destroyed before and as
result the strings are freed too.
As solution, allocate own copy of strings.
Otherwise we print the freshly received message to the window twice.
Once when receiving (and immediately printing), then logging it, and
then again when we print the last 10 log entries.
Fix https://github.com/profanity-im/profanity/issues/1305
Use g_date_time_format() instead of g_date_time_format_iso8601() to only
rely on glib 2.56.0 which is the latest version in Debian Buster
(current stable).
We also only use basic sqlite functions so 3.27.0 should be fine there
(also the one in Debian buster).
Thanks to @DebXWoody.
We now dont get the log files from the text files via chat_log_get_previous() anymore.
We use the sql backend via log_database_get_previous_chat().
So far it just has the same behaviour like chat_log_get_previous(),
except that in _chatwin_history() we don't pass the sender to
win_print_history() which should be fixed in a commit soon.
And log_database_get_previous_chat() can later easily be expanded to fix
https://github.com/profanity-im/profanity/issues/205.
Maybe if we only use `/connect` we dont have ProfAccount. In that case
we won't log anything. Only if a account is used we log.
If this is the case or the init of the db didn't work we still want
profanity to run but wont log anything to the db.
Timestamps are only set if a message is delayed.
If none is set let's set it upon recaival so we don't have to set it
when it gets displayed.
This means we will also have it for logs etc in the ProfMessage.
I plan to save all messages in an SQLite db.
For retrieving information it's nicer than having it in a text file.
We will have more info in there and easier to parse it.
This will also be good for later MAM
(https://github.com/profanity-im/profanity/issues/660).
Regular text files will still be an option for users so that they can
easily grep them and do whatever they like.
Internally Profanity will only use the SQLite db.
xmpp_stanza_add_child() takes own reference to the child stanza.
Therefore we have to release our reference or the child is lost
and not freed otherwise.
The memory leak happens when a presence is received for a MUC room. The
JID is not present in the roster, so updating its status is ignored. We
have to free resource in this case, because it has no owner and is lost
otherwise.
==25736== 47 (32 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 1,625 of 3,399
==25736== at 0x4A330FF: malloc (vg_replace_malloc.c:309)
==25736== by 0x13A962: resource_new (resource.c:47)
==25736== by 0x145501: _available_handler (presence.c:665)
==25736== by 0x145501: _presence_handler (presence.c:399)
==25736== by 0x145501: _presence_handler (presence.c:358)
==25736== by 0x80D5F34: handler_fire_stanza (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x80D2B49: _handle_stream_stanza (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x80E15CE: _end_element (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x843EE9B: doContent (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x843F94B: contentProcessor (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x8441E77: XML_ParseBuffer (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x80D586B: xmpp_run_once (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x13E07E: connection_check_events (connection.c:119)
==25736== by 0x13869C: prof_run (profanity.c:129)
Fixes#1279.
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
Most clients have them enabled by default already for a smoother modern XMPP experience.
Enable by default: allowing message corrections, sending of read
receipts, enabling carbons, typing/chat states.
If users input strange stuff and we can't create a jid from it even the
setting is set to 'user' we still should fallback to the regular
identifer.
For example with `/msg @name%matrix.domain.org@matrix.org hi`.
win_println_incoming_muc_msg() always used the current time. Now let's
use whatever is sent int he message struct (from the delay stanza or
the current time that we set now once the message is received).
No playing with the time upon display anymore.
I suspect this was just a copy paste error.
`_win_create_simple_layout()` is called in other creation functions like
`win_create_config()` or `win_create_private()`.
I suspect when `win_create_muc()` was created it was just copied. But in
this function we actually set the layout ourself later.
So calling the function isn't needed.
Regards https://github.com/profanity-im/profanity/issues/1279
We use the same incoming function as for regular incoming text here. But
don't want to filter out our own messages since we didn't print them
during sending.
Follow up to 8ee2cdadc8
`/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
* 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)
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.
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.
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.
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.
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
