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,
  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
  38. ta No idea what the roadmap about that is.
  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](
  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
  77. ta
  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_ < >: #9585: < Bug report 18.02.19 16:43 h >
  118. bot Philipp Hörist closed an issue in _gajim_ < >: #9585: < Bug report 18.02.19 16:43 h >
  119. bot villeneuve modified an issue in _gajim_ < >: #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_ < >: #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.
  128. an
  129. bot Роман Николенко created an issue in _gajim_ < >: #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_ < >:
  133. bot Philipp Hörist pushed 1 commit to branch _refs/heads/nbxmpp_0.6_ of _python-nbxmpp_ < >: *07f9b818* < > 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_ < >: *bcceae50* < > Add Annotations (XEP-0145) module *30876f0e* < > IQ: Add getQueryChild()
  145. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim-plugins_ < >: *ee21ca8a* < > [omemo] Update manifest.ini & CHANGELOG
  146. bot Philipp Hörist closed an issue in _gajim-plugins_ < >: #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_ < >:
  149. hannibal asterix can upload a wheel package of nbxmpp to pypi