about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
...
| * xep-0308: correct incoming MUC PMsMichael Vetter2020-02-121-0/+14
| |
| * xep-0308: Display corrected incoming MUC messages correctlyMichael Vetter2020-02-124-5/+21
| |
| * xep-0308: Don't check whether receiving clients supports this featureMichael Vetter2020-02-121-16/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * xep-0308: enable corrections for outgoing encrypted messagesMichael Vetter2020-02-128-44/+55
| |
| * Distinguish between _win_print() and _win_printf()Michael Vetter2020-02-121-19/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _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.
| * Rename win_correct_incoming to win_correctMichael Vetter2020-02-121-4/+4
| | | | | | | | and make it static.
| * xep-0308: update the UI upon sending a corrected messageMichael Vetter2020-02-118-24/+37
| | | | | | | | | | So far we don't do this for encrypted messages. Still needs to be done. And MUC also needs to be done.
| * xep-0308: Implement `/correct` to correct the last send messageMichael Vetter2020-02-1013-11/+132
| | | | | | | | | | | | | | | | 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.
| * xep-0308: add cons_correction_setting stub to testsMichael Vetter2020-02-101-0/+1
| |
| * xep-0308: make correction.char themeableMichael Vetter2020-02-103-0/+10
| |
| * xep-0308: create setting to toggle lmcMichael Vetter2020-02-107-11/+27
| | | | | | | | and print settings if only `/correction` is run.
| * xep-0308: set correction char in configMichael Vetter2020-02-105-1/+58
| |
| * xep-0308: add `correction` autocompletionMichael Vetter2020-02-104-0/+48
| |
| * xep-0308: Initial support for incoming LMCMichael Vetter2020-02-105-7/+75
|/
* travis: Update icons switchMichael Vetter2020-02-081-2/+2
| | | | Use --enable-icons-and-clipboard instead of old --enable-icons
* Start next development cycleMichael Vetter2020-02-071-1/+1
|
* Release 0.8.1Michael Vetter2020-02-072-3/+3
|
* Update changelog for 0.8.1Michael Vetter2020-02-071-2/+15
|
* avatar: use unique id for stanza idMichael Vetter2020-02-073-7/+10
| | | | "retrieve1" should have been only for testing.
* Clear buffer upon /clearMichael Vetter2020-02-071-0/+2
| | | | | | | | 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.
* Set PREF_COLOR_NICK to false by defaultMichael Vetter2020-02-061-1/+1
|
* Merge pull request #1263 from paulfariello/fix/segfault-occupants-colorMichael Vetter2020-02-061-0/+2
|\ | | | | Add default pref for PREF_COLOR_NICK
| * Add default pref for PREF_COLOR_NICKPaul Fariello2020-02-051-0/+2
|/ | | | Fix a segfault if corresponding preference is not saved in config file.
* Add zipfiles to gitignoreMichael Vetter2020-02-031-0/+3
|
* Lift 50 issues ban :-)Michael Vetter2020-02-031-4/+0
|
* Fix years in CHANGELOGMichael Vetter2020-02-031-3/+3
|
* rosterwin: end correct colorsMichael Vetter2020-02-031-1/+1
| | | | | Actually presence_colour should be stopped there. Thanks to rumin-miller for finding this.
* Start next development cycleMichael Vetter2020-02-031-1/+1
|
* Release 0.8.0Michael Vetter2020-02-033-5/+5
|
* Add `/omemo char` autocompletionMichael Vetter2020-02-031-0/+1
| | | | Seems this got forgotten.
* Update CHANGELOGMichael Vetter2020-01-311-0/+5
|
* Merge pull request #1260 from paulfariello/fix/omemo-fingerprint-acMichael Vetter2020-01-3127-148/+178
|\ | | | | Fix OMEMO fingerprint autocompletion
| * Fix unittest buildPaul Fariello2020-01-311-14/+14
| |
| * Add context to autocomplete_with_func and use it for omemo trust commandPaul Fariello2020-01-3126-134/+164
|/ | | | Fix #1068
* fix: Initialize variable in stanza_get_oldest_delay()Michael Vetter2020-01-301-1/+1
|
* Update gitignoreMichael Vetter2020-01-301-0/+2
|
* Fix error in stanza_get_oldest_delay()Michael Vetter2020-01-301-3/+3
| | | | Introduced in bf2e09feee1697c570fcfb9e1e44a8ec991bd196.
* muc: save oldest timestampMichael Vetter2020-01-303-3/+38
| | | | | | | | | | | | | | | | | | 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 https://github.com/profanity-im/profanity/commit/61f66966ddfe8ebd8bae26dd7ff92d777004edda#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
* stanza: Refactor stanza_get_delay_from()Michael Vetter2020-01-301-26/+49
| | | | Have two helper functions one for XEP-0203 and one for XEP-0091.
* Change theme handlingMichael Vetter2020-01-296-17/+51
| | | | | | | | | | | | | | | | 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
* Add comments to preferences.cMichael Vetter2020-01-291-2/+2
|
* Refactor theme.cMichael Vetter2020-01-291-27/+44
| | | | | | Make _theme_list_dir() static. Sort _load_preferences() loadings accoding to type. Add comments.
* Add gruvbox to CHANGELOGMichael Vetter2020-01-281-1/+2
|
* Merge pull request #1259 from Misaflo/theme-gruvboxMichael Vetter2020-01-281-0/+82
|\ | | | | Add gruvbox theme
| * Add gruvbox themeFlorent Lévigne2020-01-281-0/+82
| | | | | | | | Inspired by the vim gruvbox color scheme.
* | Fix two typos in CHANGELOGMichael Vetter2020-01-281-2/+2
|/
* Add Changes header to CHANGELOGMichael Vetter2020-01-281-0/+2
|
* Add changelog draft for 0.8.0Michael Vetter2020-01-281-0/+99
|
* Revert "Save first delay tag as timestamp"Michael Vetter2020-01-281-9/+0
| | | | | | | | This reverts commit ef00b10c90aef8b75415fae558789d21bb975d75. According to reply by user in https://github.com/profanity-im/profanity/issues/1254#issuecomment-578389784 it didn't help.
* Save first delay tag as timestampMichael Vetter2020-01-241-0/+9
| | | | | | | | | | | | 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
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-27 09:33:24 +0000