在 list 子命令中使用 search 子命令

[zzhaolei]

目前在 list 中只能搜索语言，回车后是复制了vmr search go的搜索命令。

但是在 list 中回车会给人一个很大的期望，就是回车能搜索版本，这存在了一些干扰。

希望在 list 中选定语言后，回车可以直接搜索。（备用方案是：回车后直接在下一个命令行上写入vmr search go的内容，不需要用户再粘帖）

[moqsien]

list->search确实可以有。后面考虑做。

search->use以及local->use不做，因为use有很多flag，还是交给用户粘贴编辑，这样更灵活。

[zzhaolei]

那可以 search 后选择版本，直接回车就输入vmr search go@version，只是输入，不确定，这样用户也可以直接编辑，单独粘帖会比较麻烦

[eryajf]

这里我想补充一个点，就是list的时候，有没有可能，增加一个类似收藏的功能，毕竟，每个人在使用的时候，不会用到这么多，有时候list之后，要往下滑很久，比如我只使用或者关心go,node,jdk这几个，那是否有可能收藏一下，默认只展示收藏的几个

[moqsien]

这里我想补充一个点，就是list的时候，有没有可能，增加一个类似收藏的功能，毕竟，每个人在使用的时候，不会用到这么多，有时候list之后，要往下滑很久，比如我只使用或者关心go,node,jdk这几个，那是否有可能收藏一下，默认只展示收藏的几个

可以考虑加上历史记录，凡是在历史记录中的排在前面，剩下的按字母顺序排就行了。

[eryajf]

这里我想补充一个点，就是list的时候，有没有可能，增加一个类似收藏的功能，毕竟，每个人在使用的时候，不会用到这么多，有时候list之后，要往下滑很久，比如我只使用或者关心go,node,jdk这几个，那是否有可能收藏一下，默认只展示收藏的几个

可以考虑加上历史记录，凡是在历史记录中的排在前面，剩下的按字母顺序排就行了。

可以有

[moqsien]

这里我想补充一个点，就是list的时候，有没有可能，增加一个类似收藏的功能，毕竟，每个人在使用的时候，不会用到这么多，有时候list之后，要往下滑很久，比如我只使用或者关心go,node,jdk这几个，那是否有可能收藏一下，默认只展示收藏的几个

可以考虑加上历史记录，凡是在历史记录中的排在前面，剩下的按字母顺序排就行了。

可以有

最近发现个有趣的事情，有竞品一边疯狂黑vmr，攻击vmr的贡献者，一边偷偷地把vmr的SDK版本仓库复制到自己那边使用。注意，还不是fork过去使用，是悄悄地复制过去，看情况应该是用python脚本自动抓过去的，似乎很忌讳提及，也没有加入竞品的官方组织项目之下，但无疑是竞品的贡献者之一。

稍作一个解释：之前的确有某竞品的贡献者跑过来提issue，重点在于他不理解vmr这边的设计逻辑和思路，找不到重点，给人的感觉就是来指挥vmr变成竞品的，这样就不可避免地有各种理念上的冲突。但都限于vmr自身的issues中。vmr贡献者们至今也没拿这些到处去宣扬过。一直认为，你可以有比较，可以有不同观点，可以认为什么不好，什么好，那是自由。关于个人对客观事物的不同的主观认识，没必要上纲上线到某个人如何如何，这类行为才是极不负责任的。

这说明vmr还是挺成功的啊，至少竞品还挺重视咱的，哈哈。

话说，vmr还真没直接拿过竞品的任何代码或者其他什么，功能上可能会有重叠和借鉴，但无一例外都是自己实现的。vmr的想法也不是抄袭任何人，而是脱胎自比竞品更早的自己的项目gvc。vmr的SDK版本管理的功能，基本上分离自gvc，gvc可做得比竞品早多了，只是出于某些原因，没火起来。

哈哈哈，没想到竞争竟然如此的激烈啊。

我们还是不要学这些不好的了。正经的比较可以有，借鉴学习别人好的地方可以有，但不要到处搞无中生有的黑，更不要对任何人进行人身攻击啥的。相信绝大部分人还是比较客观公正的。一起学习成长，奥利给，哈哈哈～～～

[zzhaolei]

加上搜索怎么样？历史记录和收藏都会涉及到状态的记录，增加搜索功能可以直接进行搜索。

实时进行搜索，比如输入 g，自动过滤搜索 g 开头的所有 plugin

[moqsien]

加上搜索怎么样？历史记录和收藏都会涉及到状态的记录，增加搜索功能可以直接进行搜索。

实时进行搜索，比如输入 g，自动过滤搜索 g 开头的所有 plugin

可以考虑，不过还没有试过bubbletea的table如何实现模糊搜索。这样的话，TUI部分要自己从新实现一下。

[eryajf]

这里我想补充一个点，就是list的时候，有没有可能，增加一个类似收藏的功能，毕竟，每个人在使用的时候，不会用到这么多，有时候list之后，要往下滑很久，比如我只使用或者关心go,node,jdk这几个，那是否有可能收藏一下，默认只展示收藏的几个

可以考虑加上历史记录，凡是在历史记录中的排在前面，剩下的按字母顺序排就行了。

可以有

最近发现个有趣的事情，有竞品一边疯狂黑vmr，攻击vmr的贡献者，一边偷偷地把vmr的SDK版本仓库复制到自己那边使用。注意，还不是fork过去使用，是悄悄地复制过去，看情况应该是用python脚本自动抓过去的，似乎很忌讳提及，也没有加入竞品的官方组织项目之下，但无疑是竞品的贡献者之一。

稍作一个解释：之前的确有某竞品的贡献者跑过来提issue，重点在于他不理解vmr这边的设计逻辑和思路，找不到重点，给人的感觉就是来指挥vmr变成竞品的，这样就不可避免地有各种理念上的冲突。但都限于vmr自身的issues中。vmr贡献者们至今也没拿这些到处去宣扬过。一直认为，你可以有比较，可以有不同观点，可以认为什么不好，什么好，那是自由。关于个人对客观事物的不同的主观认识，没必要上纲上线到某个人如何如何，这类行为才是极不负责任的。

这说明vmr还是挺成功的啊，至少竞品还挺重视咱的，哈哈。

话说，vmr还真没直接拿过竞品的任何代码或者其他什么，功能上可能会有重叠和借鉴，但无一例外都是自己实现的。vmr的想法也不是抄袭任何人，而是脱胎自比竞品更早的自己的项目gvc。vmr的SDK版本管理的功能，基本上分离自gvc，gvc可做得比竞品早多了，只是出于某些原因，没火起来。

哈哈哈，没想到竞争竟然如此的激烈啊。

我们还是不要学这些不好的了。正经的比较可以有，借鉴学习别人好的地方可以有，但不要到处搞无中生有的黑，更不要对任何人进行人身攻击啥的。相信绝大部分人还是比较客观公正的。一起学习成长，奥利给，哈哈哈～～～

这种无视掉就好了。 不过话说回来，我觉得有一点我也想提点个人的看法，那就是文档里介绍演示的，GIF给我的感觉不是很好，比如一般来说，我可能想看看 vmr search go 会是什么意思什么效果，但GIF就要等着到这条命令，而且还可能一闪而过。所以希望这里在GIF之外，还是从头到尾演示一个比如go的整体交互流程，会给人更直观易读的感觉。 前几天我了解到了cobra能自动生成doc说明文档，可以考虑是否使用这个组件来生成详细的说明文档。

[moqsien]

这里我想补充一个点，就是list的时候，有没有可能，增加一个类似收藏的功能，毕竟，每个人在使用的时候，不会用到这么多，有时候list之后，要往下滑很久，比如我只使用或者关心go,node,jdk这几个，那是否有可能收藏一下，默认只展示收藏的几个

可以考虑加上历史记录，凡是在历史记录中的排在前面，剩下的按字母顺序排就行了。

可以有

最近发现个有趣的事情，有竞品一边疯狂黑vmr，攻击vmr的贡献者，一边偷偷地把vmr的SDK版本仓库复制到自己那边使用。注意，还不是fork过去使用，是悄悄地复制过去，看情况应该是用python脚本自动抓过去的，似乎很忌讳提及，也没有加入竞品的官方组织项目之下，但无疑是竞品的贡献者之一。 稍作一个解释：之前的确有某竞品的贡献者跑过来提issue，重点在于他不理解vmr这边的设计逻辑和思路，找不到重点，给人的感觉就是来指挥vmr变成竞品的，这样就不可避免地有各种理念上的冲突。但都限于vmr自身的issues中。vmr贡献者们至今也没拿这些到处去宣扬过。一直认为，你可以有比较，可以有不同观点，可以认为什么不好，什么好，那是自由。关于个人对客观事物的不同的主观认识，没必要上纲上线到某个人如何如何，这类行为才是极不负责任的。 这说明vmr还是挺成功的啊，至少竞品还挺重视咱的，哈哈。 话说，vmr还真没直接拿过竞品的任何代码或者其他什么，功能上可能会有重叠和借鉴，但无一例外都是自己实现的。vmr的想法也不是抄袭任何人，而是脱胎自比竞品更早的自己的项目gvc。vmr的SDK版本管理的功能，基本上分离自gvc，gvc可做得比竞品早多了，只是出于某些原因，没火起来。 哈哈哈，没想到竞争竟然如此的激烈啊。 我们还是不要学这些不好的了。正经的比较可以有，借鉴学习别人好的地方可以有，但不要到处搞无中生有的黑，更不要对任何人进行人身攻击啥的。相信绝大部分人还是比较客观公正的。一起学习成长，奥利给，哈哈哈～～～

这种无视掉就好了。 不过话说回来，我觉得有一点我也想提点个人的看法，那就是文档里介绍演示的，GIF给我的感觉不是很好，比如一般来说，我可能想看看 vmr search go 会是什么意思什么效果，但GIF就要等着到这条命令，而且还可能一闪而过。所以希望这里在GIF之外，还是从头到尾演示一个比如go的整体交互流程，会给人更直观易读的感觉。 前几天我了解到了cobra能自动生成doc说明文档，可以考虑是否使用这个组件来生成详细的说明文档。

可以将不同子命令的GIF动图做到文档里面。我之前就想过了，感觉还有点麻烦，要想一想怎样展示比较好。一直没时间做。

做终端录屏的GIF动图，可以用vmr安装asciinema，这也是gvcgo社区下面的一个好用的工具，支持终端录屏为asciinema格式，可以编辑，例如加速、裁剪等，也可以转换为GIF动图。

[moqsien]

还有个一直都存在的问题，就是对于Windows用户，go编译的exe经常会误报病毒，然后安装失败。对于一些小白用户，这可能就把他们阻挡在门外了。甚至有小白会认为vmr是恶意软件。这确实造成了不小的影响。开源项目，用爱发电，又不可能花那么多钱去购买证书啥的。

我最近也一直都是用UPX压缩之后手动发布的，但似乎不起作用。

go语言官方的解释：https://go.dev/doc/faq#virus

对此，各位有什么好的想法没？

我看到有人说，引入CGO可以大概率降低被windows误报病毒的可能。也有一些跨平台编译CGO的方案，但还没具体测试。

[moqsien]

这里我想补充一个点，就是list的时候，有没有可能，增加一个类似收藏的功能，毕竟，每个人在使用的时候，不会用到这么多，有时候list之后，要往下滑很久，比如我只使用或者关心go,node,jdk这几个，那是否有可能收藏一下，默认只展示收藏的几个

可以考虑加上历史记录，凡是在历史记录中的排在前面，剩下的按字母顺序排就行了。

可以有

最近发现个有趣的事情，有竞品一边疯狂黑vmr，攻击vmr的贡献者，一边偷偷地把vmr的SDK版本仓库复制到自己那边使用。注意，还不是fork过去使用，是悄悄地复制过去，看情况应该是用python脚本自动抓过去的，似乎很忌讳提及，也没有加入竞品的官方组织项目之下，但无疑是竞品的贡献者之一。 稍作一个解释：之前的确有某竞品的贡献者跑过来提issue，重点在于他不理解vmr这边的设计逻辑和思路，找不到重点，给人的感觉就是来指挥vmr变成竞品的，这样就不可避免地有各种理念上的冲突。但都限于vmr自身的issues中。vmr贡献者们至今也没拿这些到处去宣扬过。一直认为，你可以有比较，可以有不同观点，可以认为什么不好，什么好，那是自由。关于个人对客观事物的不同的主观认识，没必要上纲上线到某个人如何如何，这类行为才是极不负责任的。 这说明vmr还是挺成功的啊，至少竞品还挺重视咱的，哈哈。 话说，vmr还真没直接拿过竞品的任何代码或者其他什么，功能上可能会有重叠和借鉴，但无一例外都是自己实现的。vmr的想法也不是抄袭任何人，而是脱胎自比竞品更早的自己的项目gvc。vmr的SDK版本管理的功能，基本上分离自gvc，gvc可做得比竞品早多了，只是出于某些原因，没火起来。 哈哈哈，没想到竞争竟然如此的激烈啊。 我们还是不要学这些不好的了。正经的比较可以有，借鉴学习别人好的地方可以有，但不要到处搞无中生有的黑，更不要对任何人进行人身攻击啥的。相信绝大部分人还是比较客观公正的。一起学习成长，奥利给，哈哈哈～～～

这种无视掉就好了。 不过话说回来，我觉得有一点我也想提点个人的看法，那就是文档里介绍演示的，GIF给我的感觉不是很好，比如一般来说，我可能想看看 vmr search go 会是什么意思什么效果，但GIF就要等着到这条命令，而且还可能一闪而过。所以希望这里在GIF之外，还是从头到尾演示一个比如go的整体交互流程，会给人更直观易读的感觉。 前几天我了解到了cobra能自动生成doc说明文档，可以考虑是否使用这个组件来生成详细的说明文档。

VMR已开启讨论功能，这些设计上面有关的问题，已经放到讨论区了。 各位有什么好想法，可以移步discussions。

https://github.com/gvcgo/version-manager/discussions

[moqsien]

这里我想补充一个点，就是list的时候，有没有可能，增加一个类似收藏的功能，毕竟，每个人在使用的时候，不会用到这么多，有时候list之后，要往下滑很久，比如我只使用或者关心go,node,jdk这几个，那是否有可能收藏一下，默认只展示收藏的几个

可以考虑加上历史记录，凡是在历史记录中的排在前面，剩下的按字母顺序排就行了。

可以有

最近发现个有趣的事情，有竞品一边疯狂黑vmr，攻击vmr的贡献者，一边偷偷地把vmr的SDK版本仓库复制到自己那边使用。注意，还不是fork过去使用，是悄悄地复制过去，看情况应该是用python脚本自动抓过去的，似乎很忌讳提及，也没有加入竞品的官方组织项目之下，但无疑是竞品的贡献者之一。 稍作一个解释：之前的确有某竞品的贡献者跑过来提issue，重点在于他不理解vmr这边的设计逻辑和思路，找不到重点，给人的感觉就是来指挥vmr变成竞品的，这样就不可避免地有各种理念上的冲突。但都限于vmr自身的issues中。vmr贡献者们至今也没拿这些到处去宣扬过。一直认为，你可以有比较，可以有不同观点，可以认为什么不好，什么好，那是自由。关于个人对客观事物的不同的主观认识，没必要上纲上线到某个人如何如何，这类行为才是极不负责任的。 这说明vmr还是挺成功的啊，至少竞品还挺重视咱的，哈哈。 话说，vmr还真没直接拿过竞品的任何代码或者其他什么，功能上可能会有重叠和借鉴，但无一例外都是自己实现的。vmr的想法也不是抄袭任何人，而是脱胎自比竞品更早的自己的项目gvc。vmr的SDK版本管理的功能，基本上分离自gvc，gvc可做得比竞品早多了，只是出于某些原因，没火起来。 哈哈哈，没想到竞争竟然如此的激烈啊。 我们还是不要学这些不好的了。正经的比较可以有，借鉴学习别人好的地方可以有，但不要到处搞无中生有的黑，更不要对任何人进行人身攻击啥的。相信绝大部分人还是比较客观公正的。一起学习成长，奥利给，哈哈哈～～～

这种无视掉就好了。 不过话说回来，我觉得有一点我也想提点个人的看法，那就是文档里介绍演示的，GIF给我的感觉不是很好，比如一般来说，我可能想看看 vmr search go 会是什么意思什么效果，但GIF就要等着到这条命令，而且还可能一闪而过。所以希望这里在GIF之外，还是从头到尾演示一个比如go的整体交互流程，会给人更直观易读的感觉。 前几天我了解到了cobra能自动生成doc说明文档，可以考虑是否使用这个组件来生成详细的说明文档。

demo改了一下，直接演示search子命令和use子命令。 这样应该可以了。