feat(log): 日志继续时，会回复上一条记录

[oissevalt]

根据用户反馈，log on 时骰子将会回复日志最后记录的消息，以便用户定位跑团进度。

[Xiangze-Li]

我保留意见，这个功能如果使用插件实现是否更好？

用插件实现的困难是，由于拿不到日志数据，必须同时 hook log off(甚至 end) 和 log on 两条指令，在插件里单独维护一个最后消息表。

另一方面，我同意这个功能应当是可选的。

[Xiangze-Li]

一个想法，把这个功能单独做一个子指令 log whereis [log name]

[oissevalt]

插件需要注册 OnCommandReceived 的钩子函数，并非不可以；不过依然需要实现 LogGetLastLine。同时，OnCommandReceived 会在日志开启后被调用，相当于每次都会在日志中记录定位消息。

如果改成子命令的话，我感觉用户大概不会注意到这个功能……实在不行就在 WebUI 再加个开关？

[fy0]

我认为功能上没有问题，最多就是加个开关，但是建议默认开启

[Xiangze-Li]

全局开关反而意义不大，因为这个功能影响的是终端用户，而不是骰主。

[JustAnotherID]

对展示最后一条记录的实用性有疑虑，会不会结果是只展示了类似「今天就到这里了」之类的无用信息？考虑这种情况的话我反对默认开启功能。 一个想法是增加类似 log tail <name> <num> 的命令展示最后多条记录。 此外如果要增加开关的话，同意 johnson 佬的意见，应当支持群维度的开关，而不是全局开关。

[Xiangze-Li]

对展示最后一条记录的实用性有疑虑，会不会结果是只展示了类似「今天就到这里了」之类的无用信息？ 一个想法是增加类似 log tail <name> <num> 的命令展示最后多条记录。

一定是无用信息（上一条 log off 指令），但是有这样一条回复就可以追溯到原始消息，就比较够了

tail 指令也会无法滤去无用信息，可能要很大的数量才能展示真正剧情

[JustAnotherID]

tail 指令也会无法滤去无用信息，可能要很大的数量才能展示真正剧情

我认为如果有 tail 的话，kp/dm 可以在末尾按自己需要用几条消息简单概括一下本次的剧情，支持数量的 tail 能帮助灵活展示这些概括，操作起来也并不麻烦。

至少仅展示最后一条我认为是没有什么价值的。

[Xiangze-Li]

tail 指令也会无法滤去无用信息，可能要很大的数量才能展示真正剧情

我认为如果有 tail 的话，kp/dm 可以在末尾按自己需要用几条消息简单概括一下本次的剧情，支持数量的 tail 能帮助灵活展示这些概括，操作起来也并不麻烦。

至少仅展示最后一条我认为是没有什么价值的。

如果是依赖gm总结的话，一个单独的log where指令反而更灵活：gm可以在他方便的任何时候定位到原处去写前情提要，而不是必须在off前写好

[JustAnotherID]

如果是依赖gm总结的话，一个单独的log where指令反而更灵活：gm可以在他方便的任何时候定位到原处去写前情提要，而不是必须在off前写好

我的想法是这样，可以手动总结也可以不总结，在没有刻意总结的情况下 tail 指令也能帮助展示一些内容。

log where 的问题在于，各个平台是否能良好地支持，如果中间的消息过多能否准确定位？

[oissevalt]

我还是觉得一个新的指令不会有人去用，而且我赞同 John 的观点，回复上一个 log off，让用户能定位到之前的消息就够了

要是 KP 和 PL 健忘到看到聊天记录都不知道发生了什么，这个团大概也可以重开了

Edit：要不我们去用户群问问，用户想要怎么设计

[fy0]

去问问吧，我觉得回复最后一条跑团信息，或者带上上次最后几句话，都可以接受

[oissevalt]

顺带重构了 cmdLog.Solve，烦请检查一下逻辑是否一致

[oissevalt]

直接进行了一个 rebase 然后 force push，希望 commit 记录不要变太乱

[fy0]

看起来当前行为是如标题所述的获取最后一条并回复的方案。 这几天QQ群的讨论所说，超过200条的情况下此方案无法正常定位，我对实用性感到有些疑虑。另外非qq平台也需要验证。 要不然还是给出最后几句录的话吧

关于重构部分，private统一了是好的。但是几个变量的修改导致了大范围的diff变化，其实不是很建议。 现在只能看出所有指令都需要重新测试，但是以当前PR的功能性来说影响范围不至于此。 改的话建议过测后进行修改。