# Gajim - 2019-02-18

1. Maranda lovetox, ok it works now
2. ta fm, syntax highlighting plugin works like charm on Windows, 1.1.2 snapshot.
3. fm ta, nice thx for testing
4. ta want some feedback? ;-)
5. fm sure
6. ta i think the defaul language should not be set, but be monospace without highlighting. and the nickname is monospaced as well. The codeblock should be in a new line leaving the rest of the Chatlog in normal text.
7. ta last one is probably some hacky stuff in the background.
8. fm it should, yes. and it does for me....? Have some example?
9. fm about having no default language: good point - should be up to the user. I will have a look at it.
10. fm maybe I can offer a 'None' Language at top of the (very long....) list
11. ta because it "breaks" what verbatim/monospace/codeblocks is intended for.
12. fm syntax highlighting is an addition to the message styling xep the plugin provides (the xep only specifies pre-formatted monospaced text)....
13. fm or do you mean something else that breaks something?
14. fm can you provide some code block, that "spreads" outside of the back-ticked block?
15. ta for being compliant with the xep i ment not setting a default language.
16. ta The styling bug i need to reproduce. Of course, now everything is fine.
17. fm as always when hunting bugs :D
18. fm sure, for xep compliance (and having the same user experience as with other clients), setting the default to monospace is a good thing.
19. fm I also wanted to add a section to the readme clearifying the relation of the plugin to the relevant xep sections
20. fm its XEP-0393 btw, https://xmpp.org/extensions/xep-0393.html
21. fm ta, are you still interested in having a way to enable the plugin with the current 1.1.2 gajim release (not snapshot)?
22. ta well, i don't need it to much. snapshot is fine.
23. ta I broke packagemanagement for this test already. that will be okay, with the next release.
24. fm ok, code would be ready though
25. fm s/woud/should/
26. ta can it then magically appear in the 1.1.2 plugininstaller for exisiting 1.1.2 installations?
27. fm yes, but you will have to provide a pygments installation or a clone of the pygments repo yourself. Don't know if it is worth it ;)
28. fm will have to test the code on an actual windows first anyway ;)
29. ta i take this snapshot for now. I consider gajim more like a rolling release, with the frequency of bugfixes ;-)
30. fm alright :)
31. fm to the others here: if you for some reason can't use the snapshot, ping me, I can provide the "fix" for the current Gajim release
32. ta unfortunately gajim does not honor xep 393 exactly. *is bold* ´is monospaced´ _is underlined_ ~is not striked through~
33. ta unfortunately gajim does not honor xep 393 exactly. *is bold* is monospaced _is underlined_ ~is not striked through~
34. fm true. I am missing quotations.... But iirc, gajim does not claim to support it ;)
35. fm true. I am missing quotations.... But iirc, gajim does not claim to support it (fully) ;)
36. ta yeah quotations are more important than ~ ~ or "correct" _ _
37. fm also, combined styling does not work (with my plugin): *monospace and bold*, not sure if It is worth investing time here. With syntax highlighting, the outter formatting will be killed anyway
39. fm yeah, maybe this will be part of the coming ui changes. If not, it should be not too hard to contribute this feature ;)
40. ta about honoring nesting: it would be nice to not break xep 393. If bold/strike/whatever is applied around a inline monospace all bold keywords stay bold and others are bolted. If that conflicts with readability, its the users fault or intention.
41. fm hm... I would have to override whatever the formatter does in terms of bold/strike/whatever then
42. fm should be possible
43. ta but that is really something, if xep 393 should be complied.
44. debacle ta, there are some things, I would like to change in XEP-0393:
45. debacle 1. to me use of underscore would be more intuitive for underlining
46. debacle 2. for italic, maybe slashes would be better (/italic/)
47. ta debacle, absolutely right. But for now it exists like this. No ending "tag" for multiline preformatted text is also not nice, i think
48. debacle 3. there is one formatting, I need very often and is not in XEP-0393: [Link](https://gajim.org/)
49. ta so you wand complete markdown. Thats probably not the scop of 393 until now.
50. debacle so far, 393 is experimental. changes can be proposed to the author
51. debacle ta, not complete markdown, no tables, no lists
52. ta but more markdown than now. As i understood, there is no right markdown anyway.
53. fm would be happy to see lists added, too
54. ta lists i would like, actually. They are simple. Tables are to much for the scope of an messenger.
55. ta lists i would like, actually. They are simple. Tables are to much for the scope of a messenger.
56. ta lets take over that xep ;-)
57. fm furthermore, tables are a pain to write in a messanger... and hard to dispaly nicely in a mobile environment with small screens
58. ta actually i like also experimental xeps implemented consistently.
59. oli xep 393 sucks anyway
60. debacle oli, do you like 394 more?
61. ta i like the symetry of the numbers.
62. debacle does not believe in the decimal system anyway
63. oli debacle: yes
64. debacle 0393 work better with non-supporting clients, i.e. they show *something*, while 0394 falls back to plain text
65. oli and don't want stupid characters surrounding my text
66. oli and don't want stupid characters surrounding text
67. debacle it's a long tradition in western scripture
68. debacle we have quotation marks, we have ¿questions?, ¡and so on!
69. fm oli, you know you can disable this (in gajim)
70. debacle we have "quotation" marks, we have ¿questions?, ¡and so on!
71. oli but then it's better to show the characters only instead of characters and formating in three different styles
72. debacle s/scripture/script/ sorry
73. oli like in conversations
74. debacle but that's a matter of the client or the client configuration
75. fm oli: search for "show_ascii_formatting_chars in the ACE ;)
76. oli but it is what happens. i have to compile my own conversations apk, just to get rid of it
78. ta didnt know ?!( and their counterparts also do inline monospacing...
79. fm ta, thx, this looks buggy.... maybe because the edit took over (look at the timestamps)
80. ta oli, surounding characters are no must according to xep 393
81. fm ta, they are not supposed to, i guess it is an issue with the message edits
82. oli i always hated markdown. one of the worst wiki markups. and i'm against hard coding that shit
83. oli and every parser will be slightly different
84. debacle oli, I'm not a huge fan of markdown neither and the problems are huge
85. ta fm, ok the words between got monospaced as well...
86. ta oli, what are you not against?
87. oli and then there will be xyz-flavored variants, because there is no consens for changing the xep
88. debacle e.g. many things that work in Diaspora do not work (or half-work) in Movim
89. debacle but I don't see a good solution to formatting other than 0393
90. debacle XHTML has been deprecated for security reasons, 0394 is strange
91. oli xep 394 is not good?
92. ta debacle, i think 393 is fine too, could be improved a little, maybe extended a little. It works renderd and in plaintext, so thats fine.
93. fm ta, my guess would be, that the edited message and my message somewhat interfere... i will try to debug it late
94. fm r
95. debacle ta, I agree. It's not a _good_ solution, but it's a _pragmatic_ solution.
96. debacle (unfortunately, _this_ is italic in 0393, not underlined as it should)
97. ta thats what i meant with improvement is possible.
98. oli debacle: yeah, thats what i dislike the most
99. oli is it whatsapp style?
100. debacle oli, I never used WA, no idea
101. ta 394 looks okay too, but is not KISS, i think. And normal clients don't see andything. While 393's approach gives visible feedback to clients not implementing it at all.
102. debacle thinks about a \latex{syntax} \begin{xep}XEP\end{xep}...
103. ta citing a message with 394 in it could be a PITA
104. ta debacle, latex was discussed lately. probably a security issue because of possible code execution on the other clients machine.
105. debacle 0394 is probably harder to implement than 0393
106. debacle ta, I was joking
107. debacle there is a LaTeX plugin for Gajim, but I would not allow it on my machine
108. ta that was the conclusion after disussing the plugin
109. ta interprets jokes badly online
110. ta we need more xeps! o/
111. debacle oli, I share your dislike for all the very "simple" markdowns, rests, asciidocs, etc. because non of them has a nice and regular syntax.
112. debacle They are all ad-hoc markups. Esp. I dislike, that they don't distinguish begin and end tags.
113. debacle Does *` start or end a bold text? Well, depends whether it's odd or even count. Ugly!
114. debacle But in practice it works and at least people using Github or Gitlab or Diaspora etc. are somehow used to it.
115. ta debacle, +1
116. ta begin and end text would complicate things for "normal" users. We are not normal.
117. bot villeneuve created an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9585 >: #9585: < Bug report 18.02.19 16:43 h >
118. bot Philipp Hörist closed an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9585 >: #9585: < Bug report 18.02.19 16:43 h >
119. bot villeneuve modified an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9585 >: #9585: < Bug report 18.02.19 16:43 h >
120. fm ta, I think I know what caused the bug with too much monospace in the morning....
121. fm just from looking at the code, but it totally makes sense -.-
122. ta Does it have an easy explanation?
123. fm well. yeah. me so stupid ^^
124. fm There are two places, where I am taking the end of the textbuffer that represents the chat window. a corrected message is placed "somewhere" in the buffer, i.e. it is not the last message, so taking the end of the buffer contains all following messages, too
125. fm most stupid part: the fix is already in the code, I simply did not use it -.-
126. bot Jan-Philipp Litza created an issue in _gajim-plugins_ < https://dev.gajim.org/gajim/gajim-plugins/issues/390 >: #390: < [omemo] Allow <markable> tag to be sent >
127. an lovetox, since you mentioned the icons regarding scaling I have noticed that the editorial icon in chat is especially large.
129. bot Роман Николенко created an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9586 >: #9586: < Crash >
130. ta fm: well, nice to see, that testing helps. Feels more rewarding here, than in my day job.
131. ta an: it's normal sized here, lineheight.
132. bot Philipp Hörist pushed 2 commits to branch _refs/heads/master_ of _gajim-plugins_ < https://dev.gajim.org/gajim/gajim-plugins >: https://conference.gajim.org:5281/pastebin/3ff82dfa-af0b-4c46-bc9c-37473eac9a26
133. bot Philipp Hörist pushed 1 commit to branch _refs/heads/nbxmpp_0.6_ of _python-nbxmpp_ < https://dev.gajim.org/gajim/python-nbxmpp >: *07f9b818* < https://dev.gajim.org/gajim/python-nbxmpp/commit/07f9b8188e09ba38359068ec29610bbae05ecade > Update ChangeLog
134. an suddenly the history from before I restarted gajim is gone from this conference. It is still saved in the history manager but why not in the chat? I think it kept the history in chat the past couple of times I restarted gajim.
135. an does gajim not support editing of the last message or how would I accomplish that? just wanted to test if the icon is overly large still.
136. lovetox an last messages are only loaded from the database in single chat
137. lovetox and message correction with CTRL + arrow up
138. an does gajim not support editing of the last message or how would I accomplish that? just wanted to test if the icon is overly large still.
139. an thanks!
140. an I just restored the GDK_SCALE variable from last time to see if it would affect the editorial icon but had no effect.
141. fm ta: thanks for testing and your feedback 🙂
142. fm I'll open an mr tomorrow morning
143. fm Also added a "monospace only" mode, as you proposed :)
144. bot Philipp Hörist pushed 2 commits to branch _refs/heads/master_ of _python-nbxmpp_ < https://dev.gajim.org/gajim/python-nbxmpp >: *bcceae50* < https://dev.gajim.org/gajim/python-nbxmpp/commit/bcceae507b9e2b6c0413ce913675af546005d23f > Add Annotations (XEP-0145) module *30876f0e* < https://dev.gajim.org/gajim/python-nbxmpp/commit/30876f0e6b45d480cfc95dcb464e68d99702aac8 > IQ: Add getQueryChild()
145. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim-plugins_ < https://dev.gajim.org/gajim/gajim-plugins >: *ee21ca8a* < https://dev.gajim.org/gajim/gajim-plugins/commit/ee21ca8ad5e585abd7177ace86341d7efc7837b2 > [omemo] Update manifest.ini & CHANGELOG
146. bot Philipp Hörist closed an issue in _gajim-plugins_ < https://dev.gajim.org/gajim/gajim-plugins/issues/389 >: #389: < Omemo crash after latest refactor >
147. nico thank you lovetox 🙂
148. bot Philipp Hörist pushed 3 commits to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: https://conference.gajim.org:5281/pastebin/308505fc-540d-46d7-b25c-4f482a790557
149. hannibal asterix can upload a wheel package of nbxmpp to pypi