Le 30/05/2018 à 09h00, Milan Crha a écrit : > On Wed, 2018-05-30 at 01:43 +0200, Garreau, Alexandre wrote: >> If you inspect the In-Reply-To headers you’ll see none of these is >> marked as an answer to another, yet References mark them because some >> of them do reference the other ones. > > Hi, > I highly doubt any regular user even knows anything about the > internals. They care of the result. And what you did has the result as > shown in the attachment. > > That's a very good habit to discuss one issue in one thread (or even > bug report), though I agree it's not always possible. While you think > the things are related, then the X-Mailer has nothing to do with Reply- > to-List (it just happened that you wrote both messages), still if I'm > not interested in the X-Mailer thread then when I collapse it (or mark > it to be ignored) I lost track of the other threads.
Wouldn’t it be more practical then not to nest inside other threads messages that *don’t* have an “In-Reply-To” header? > I also expect that you did put some effort to have the References > header filled in the other messages, which just shows that even you can > do that manually, regular users will not do it, unless they have tools > for it. I have a hook that looks for references to other messages (through Message-ID for instance) in the body and add them to “References”. The same way I can in my UI select several messages, then do “Reply” and this way reply to several messages, and get several Message-ID in “In-Reply-To” if I want. That stays pretty straightforward, and don’t require that much “extra” tools or commands. However I indeed never saw any user-agent correctly handling threads in that they won’t thread messages without “In-Reply-To” (sometimes they don’t even read it in any way and only use “References” to construct threads >< how random), or that have the ability to correctly represent a thread that’s not a tree but a graph (git has the ability to do that, I’d expect an user-agent to do the same, and I plan in the future to put MaGit code in my User-Agent to get that output). > Anyway, we diverged from the subject from my point of view, we just > discuss our habits and preferences, which obviously differ. Each has > its pros and cons, I'm not questioning that. Yet “it’s *your* opinion and everything can be good or bad and that doesn’t matter” is not really a constructive conclusion: I like to interpret standards not because of authority, but because they help building interoperability while preserving functionality. If there are different pro and cons we should find the simpler method to make the more easily people able to get all the pros they want and avoid all the cons they want, depending on their preferences and what’s technically possible, while preserving interoperability. > My personal past experience is that changing someone habits is pretty > hard (near to impossible), no matter what any document can suggest as > the best practice. Again, consider regular users, corporate > environments (top posting), incorrect quoting, Habits are not magically originating from the sky after having popped from nowhere, new habits can be analyzed and influenced by ergonomy, as well as old habits can be changed by a new environment (I don’t think going from GNOME 2 to GNOME 3 did preserve all “old habits” without changing anything, beside orienting people to MATE), and better: old habits *consequences* and implications can be changed by the underlying system habits build on and use. If the habit is “press the big button”, and from one precise meaning that was abuse that button begins to offer *the* simpler and most-of-time appropriated thing to do in this case, then usage become better, without changing habit. Software should adapt to habits, not the reverse, I agree. But what software do in this case should depend on interoperability and functionality, not on “preserving the old”, like an old habit would, because software isn’t habit and one change may result in non-proportional (potentially positive) outcome. > when people cannot distinguish between instant messaging and e-mail > (they try to use instant messaging habits in e-mails, huh) and so on. Beside synchronicity and presence, if quick enough with close-circuit enough I can see how mail might be used in a such way, especially as things may become quicker and software better, I don’t see this as a bad thing, only a new usage. And since currently mail is an old, interoperable and established standard, building new stuff on it, be it with adding extensions, seems to me a lot more powerful and natural than building anything on IRC bots or, how it nowadays has become sadly systematic, web browser. I still prefer exchanging one sentence per one mail per minute in a “conversation-like” view, than passing 3 hours trying to make XMPP work, waiting for my browser stop to freeze in front of Matrix, find an unambiguous way to specify threading/reply-to and formating in IRC, or using any centralized protocol. _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers