Prior to Python 3.8, you will get error message:

  TypeError: 'dict_keys' object is not reversible

Increased memory usage for this list instantiation should be minimal
and worth it to support older Python.  Tested with Python 3.6 on EL7.
---
 wee_most.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wee_most.py b/wee_most.py
index b5140ec..d46b87e 100644
--- a/wee_most.py
+++ b/wee_most.py
@@ -1073,7 +1073,7 @@ class ChannelBase:
             line = weechat.hdata_pointer(weechat.hdata_get("line"), line, "prev_line")
             line_data = weechat.hdata_pointer(weechat.hdata_get("line"), line, "data")
 
-        for file_id in reversed(post.files.keys()):
+        for file_id in reversed(list(post.files.keys())):
             tags = get_line_data_tags(line_data)
             tags.append("file_id_{}".format(file_id))
             weechat.hdata_update(weechat.hdata_get("line_data"), line_data, {"tags_array": ",".join(tags)})
-- 
2.40.1

Without this, I had to use /debug tags to find the tag
`post_id_3y8x6qot7pn63qa4ku5p9bjj6w` and then manually
`/mattermost reply 3y8x6qot7pn63qa4ku5p9bjj6w` which was rather awkward
to say the least :)

Now I have `/alias reply /mattermost reply $*` and can `/reply 3y8 great!`

---
 wee_most.py | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/wee_most.py b/wee_most.py
index d46b87e..9c84131 100644
--- a/wee_most.py
+++ b/wee_most.py
@@ -510,6 +510,7 @@ def command_reply(args, buffer):
 
     server = get_server_from_buffer(buffer)
     channel = server.get_channel_from_buffer(buffer)
+    post_id = channel.find_thread(post_id)
     post = channel.posts.get(post_id, None)
 
     if not post:
@@ -536,6 +537,8 @@ def command_react(args, buffer):
     emoji_name = emoji_name.strip(":")
 
     server = get_server_from_buffer(buffer)
+    channel = server.get_channel_from_buffer(buffer)
+    post_id = channel.find_thread(post_id)
 
     run_post_reaction(emoji_name, post_id, server, "singularity_cb", buffer)
 
@@ -551,6 +554,8 @@ def command_unreact(args, buffer):
     emoji_name = emoji_name.strip(":")
 
     server = get_server_from_buffer(buffer)
+    channel = server.get_channel_from_buffer(buffer)
+    post_id = channel.find_thread(post_id)
 
     run_delete_reaction(emoji_name, post_id, server, "singularity_cb", buffer)
 
@@ -1108,6 +1113,17 @@ class ChannelBase:
 
         return "\n".join(lines)
 
+    def find_thread(self, post_id_prefix):
+        newest = None
+        for i, post in self.posts.items():
+            if i.startswith(post_id_prefix):
+                if newest is None or post.created_at > newest.created_at:
+                    newest = post
+        if newest is None:
+            return post_id_prefix
+        else:
+            return newest.id
+
     def remove_post(self, post_id):
         del self.posts[post_id]
 
-- 
2.40.1

I just thought this should be configurable.  The chance of a short-id
collision is pretty large with just 3 characters, but since the previous
patch which does prefix matching will prefer the newest matching thread
it doesn't cause much problems in practice.  also that code does not care
if you give it 1 or 26 characters to match against.  Personally I prefer
to display 4 characters, but I think 2 will work reasonably well, too.

---
 wee_most.py | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/wee_most.py b/wee_most.py
index 9c84131..1a7762d 100644
--- a/wee_most.py
+++ b/wee_most.py
@@ -158,6 +158,10 @@ class Config:
             self.sections["look"], "thread_prefix_suffix", "string",
             "String displayed after the thread prefix, if empty uses value from weechat.look.prefix_suffix",
             "", 0, 0, None, None, 1, "", "", "", "", "", ""), "type": "string" }
+        self.options["look.thread_prefix_length"] = { "pointer": weechat.config_new_option(self.file,
+            self.sections["look"], "thread_prefix_length", "integer",
+            "How many characters to include from thread prefix",
+            "", 2, 26, "3", None, 0, "", "", "", "", "", ""), "type": "integer" }
         self.options["look.thread_prefix_user_color"] = { "pointer": weechat.config_new_option(self.file,
             self.sections["look"], "thread_prefix_user_color", "boolean",
             "Use root post user color for the thread prefix",
@@ -1103,7 +1107,8 @@ class ChannelBase:
         suffix_color = config.get_value("color", "thread_prefix_suffix") or weechat.config_string(weechat.config_get("weechat.color.chat_prefix_suffix"))
         suffix = colorize(suffix_string, suffix_color)
 
-        prefix = prefix_format.format(post_id[:3])
+        prefix_length = config.get_value("look", "thread_prefix_length")
+        prefix = prefix_format.format(post_id[:prefix_length])
         prefix_empty = "{} {} ".format(" " * len(prefix), suffix)
         prefix = colorize(prefix, prefix_color)
         prefix_full = "{} {} ".format(prefix, suffix)
-- 
2.40.1

The root id was only displayed by update(), called when a post got
a reply.  This meant it is not visible for easy replies until someone
else has made the post into a thread.  The default behaviour is unchanged.

The option name was chosen to match "weechat.look.read_marker_always_show"

---
 wee_most.py | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/wee_most.py b/wee_most.py
index 1a7762d..763263f 100644
--- a/wee_most.py
+++ b/wee_most.py
@@ -162,6 +162,10 @@ class Config:
             self.sections["look"], "thread_prefix_length", "integer",
             "How many characters to include from thread prefix",
             "", 2, 26, "3", None, 0, "", "", "", "", "", ""), "type": "integer" }
+        self.options["look.thread_prefix_always_show"] = { "pointer": weechat.config_new_option(self.file,
+            self.sections["look"], "thread_prefix_always_show", "boolean",
+            "Show thread id for all posts, also those with no replies yet",
+            "", 0, 0, "off", "off", 0, "", "", "", "", "", ""), "type": "boolean" }
         self.options["look.thread_prefix_user_color"] = { "pointer": weechat.config_new_option(self.file,
             self.sections["look"], "thread_prefix_user_color", "boolean",
             "Use root post user color for the thread prefix",
@@ -1159,6 +1163,8 @@ class ChannelBase:
             message = self._prefix_thread_message(message, post.root_id, root=False)
         elif post.thread_root:
             message = self._prefix_thread_message(message, post.id, root=True)
+        elif config.get_value("look", "thread_prefix_always_show"):
+            message = self._prefix_thread_message(message, post.id, root=False)
 
         lines = message.split("\n")
 
@@ -1218,6 +1224,8 @@ class ChannelBase:
         message = post.render_message() + post.render_reactions()
         if post.root_id:
             message = self._prefix_thread_message(message, post.root_id, root=False)
+        elif config.get_value("look", "thread_prefix_always_show"):
+            message = self._prefix_thread_message(message, post.id, root=False)
 
         date = int(post.created_at / 1000)
 
-- 
2.40.1

Thank you, I've applied it this first part.

> Without this, I had to use /debug tags to find the tag
> `post_id_3y8x6qot7pn63qa4ku5p9bjj6w` and then manually
> `/mattermost reply 3y8x6qot7pn63qa4ku5p9bjj6w` which was rather awkward
> to say the least :)

There are already some convenient helpers so that you don't have to type 
the post id manually. But I admit it's a bit hidden as I didn't find the 
time to document it more than "check running /key list cursor"

You can go to the weechat cursor mode in the chat part, scroll to the 
line you want to reply to and then press "t" (for thread). This will 
directly fill your prompt with "/mattermost reply 
3y8x6qot7pn63qa4ku5p9bjj6w " so that you just have to type the reply.

This "t" is the default keybinding but you can customize it and also 
make it happen from a mouse click if you prefer.

They are other really useful keybindings in there and it's a powerful 
mechanism to automate some actions. For example, I have this keybinding 
to react with a :wave: on a message very quickly via a single key press 
while going through the history:
"/input delete_line; /input insert /mattermost react; 
hsignal:mattermost_cursor_insert_post_id; /input insert :wave:; /input 
return"

I am for now reluctant to apply the rest of the patches. I understand 
that they offer another way to reply/react/... without using the cursor 
mode. But I'm not sure this method is easier and faster to use in 
practice with the need to type the hash.

There are some little concerns about the hash collision issue and the 
efficiency issue of having to loop through all the post items to find 
the matching one, but in practice I think those won't be a problem 
indeed.

I would personally be more annoyed about the visual display. There would 
need to be an ugly hash displayed on each line which takes quite some 
space and also make it very difficult to actually see the real threads 
among them.

Please have a look at the cursor mode but if after trying you still 
really prefer your way, I'll be ok to merge them.

On Thu, 2023-06-29 at 17:56 +0200, Damien Tardy-Panis wrote:
> > Without this, I had to use /debug tags to find the tag
> > `post_id_3y8x6qot7pn63qa4ku5p9bjj6w` and then manually
> > `/mattermost reply 3y8x6qot7pn63qa4ku5p9bjj6w` which was rather
> > awkward
> > to say the least :)
> 
> There are already some convenient helpers so that you don't have to
> type 
> the post id manually. But I admit it's a bit hidden as I didn't find
> the 
> time to document it more than "check running /key list cursor"
> 
> You can go to the weechat cursor mode in the chat part, scroll to the
> line you want to reply to and then press "t" (for thread). This will 
> directly fill your prompt with "/mattermost reply 
> 3y8x6qot7pn63qa4ku5p9bjj6w " so that you just have to type the reply.
> 
> This "t" is the default keybinding but you can customize it and also 
> make it happen from a mouse click if you prefer.

wow, I didn't know about the cursor mode.  that's a bit hidden in
Weechat's own documentation, too.  there's not even a default key
binding to enter it, I see.  I bound it to meta-g now, it works fine.

I had however patched wee_most.py to get rid of wee_most from the
channel/buffer name of every Mattermost buffer:

  wee_most.look.buffer_name_prefix: Prefix to use for all wee_most
buffer names [default: "wee_most."]                                   

and that makes the context binding more tricky.  I guess that can be
solved by documenting the need for adding new key bindings if the
buffer_name_prefix is changed.  I'll have to look at this more closely
before submitting the patch.

> They are other really useful keybindings in there and it's a powerful
> mechanism to automate some actions. For example, I have this
> keybinding 
> to react with a :wave: on a message very quickly via a single key
> press 
> while going through the history:
> "/input delete_line; /input insert /mattermost react; 
> hsignal:mattermost_cursor_insert_post_id; /input insert :wave:;
> /input 
> return"
> 

very neat!  I think I can use some of the same key macro technique to
reply to same thread as the previous message I sent?

/key bind meta-j /input history_previous;/input
move_beginning_of_line;/input move_next_word;/input
move_next_word;/input move_next_word;/input move_next_char;/input
delete_end_of_line

not very elegant, though.  it would be better/more reliable to make a
new signal to insert the last replied-to id, I think.

> I am for now reluctant to apply the rest of the patches. I understand
> that they offer another way to reply/react/... without using the
> cursor 
> mode. But I'm not sure this method is easier and faster to use in 
> practice with the need to type the hash.
> 
> There are some little concerns about the hash collision issue and the
> efficiency issue of having to loop through all the post items to find
> the matching one, but in practice I think those won't be a problem 
> indeed.
> 
> I would personally be more annoyed about the visual display. There
> would 
> need to be an ugly hash displayed on each line which takes quite some
> space and also make it very difficult to actually see the real
> threads 
> among them.
> 
> Please have a look at the cursor mode but if after trying you still 
> really prefer your way, I'll be ok to merge them.

I think this patch (2/4) is still useful, but I agree the other parts
can be dropped.  especially patch 4 did turn out to clutter the display
too much and I stopped using it after a couple of days.

-- 
venleg helsing,
Kjetil T.

> I had however patched wee_most.py to get rid of wee_most from the
> channel/buffer name of every Mattermost buffer:
>
>   wee_most.look.buffer_name_prefix: Prefix to use for all wee_most
> buffer names [default: "wee_most."]                                   
>
> and that makes the context binding more tricky.  I guess that can be
> solved by documenting the need for adding new key bindings if the
> buffer_name_prefix is changed.  I'll have to look at this more closely
> before submitting the patch.

This "wee_most" prefix to buffer names is something meant for the 
internal implementation, not something for the users to be aware of.

If it's just a matter of not wanting to have it displayed in the UI, you 
should look again at your config. There are different possible values to 
use for the buffers name (short_name, name, full_name) and so it's 
easily doable to have it hidden.

> I think this patch (2/4) is still useful, but I agree the other parts
> can be dropped.  especially patch 4 did turn out to clutter the display
> too much and I stopped using it after a couple of days.

I can see the value of it indeed so I've just merged it. Thanks!