telegram_1241768779
@telegram_1241768779:nichi.co
90 messages · Page 1 of 1
telegram_1241768779
可能是为了这个吧
telegram_1241768779
那个似乎是调整对比度以后颜色深浅有变化
telegram_1241768779
不大吧，以后单独开发了而已
telegram_1241768779
但是既然fork自SDDM也无所谓，反正不会更坏的
telegram_1241768779
貌似一堆和Plasma集成的功能还是TBD
telegram_1241768779
那个是SDDM的fork吧
telegram_1241768779
对
telegram_1241768779
把分辨率弄低了问题就解决了
telegram_1241768779
然后内核自己把色彩输出信息减少以降低带宽，导致颜色有问题
telegram_1241768779
草
telegram_1241768779
发现应该是HDMI接口的带宽不够
telegram_1241768779
但是这个应该可以直接修改LC_TIME？
telegram_1241768779
主要是时间格式
telegram_1241768779
感觉对这个用途用有点怪怪的
telegram_1241768779
今天滚的时候多个pacnew用diff看见了
telegram_1241768779
结果不怎么下载都忘了，这下舒服了
telegram_1241768779
* 今天重新看配置的时候才发现我两年前就弄好了用mpv边看边播种子...
telegram_1241768779
今天重新开配置的时候才发现我两年前就弄好了用mpv边看边播种子...
telegram_1241768779
* 只有切成a卡的集显可以用上杜比视界
telegram_1241768779
虽然downmix也是能听，但是感觉可能有个什么妙妙函数做这个效果比较好
telegram_1241768779
感觉影音体验这块缺一个虚拟环绕声的解决方案
telegram_1241768779
不然不支持杜比视界也没啥，资源太少了，我测试的那个还是我自己拍的
telegram_1241768779
显示白底红字的时候效果非常古怪
telegram_1241768779
就是 KDE 的 HDR 显示 SDR 的时候，在我这可以明显看到偏色
telegram_1241768779
* 现在发现好像gpu-next是没法通过vulkan硬解杜比视界，但是一般的HDR视频可以
telegram_1241768779
* 切成a卡的集显反倒可以用上杜比视界
telegram_1241768779
* 现在发现好像gpu-next似乎是没通过vulkan硬解杜比视界，但是一般的HDR视频可以
telegram_1241768779
切成a卡的集显反倒可以
telegram_1241768779
现在发现好像gpu-next似乎是没通过vulkan硬解杜比视界
telegram_1241768779
我这n卡用mpv看HDR视频，之前原以为是有什么参数弄错了
telegram_1241768779
即便是同时作数组和哈希表，luals都是支持的
telegram_1241768779
* 你写的时候觉得它是个类，类型注解就写它是个类；你只是用元表，那就别写
telegram_1241768779
你写的时候它是个类，类型注解就写它是个类；你只是用元表，那就别写
telegram_1241768779
你这个是什么理解…
telegram_1241768779
luacats基本是应用最广的，新的LSP server都是兼容的
telegram_1241768779
这个是类型注解实现的
telegram_1241768779
我常写的也是LuaJIT
telegram_1241768779
连范型都有
telegram_1241768779
那怎么没法搞
telegram_1241768779
还有js也是有tsserver做了支持
telegram_1241768779
但是LSP server都有几个
telegram_1241768779
Lua：jb从来没正眼瞧过我
telegram_1241768779
这又没有关系
telegram_1241768779
rust-analyzer也做得很全，之前听说rust有让rust-anakyzer和rustc共享一个前端的做法，如果做了的话，和ts就是一个情况
telegram_1241768779
像TypeScript这种，它自己项目一起ship一个tsserver就把编辑器支持做了，jb基本没啥可以额外加成的
telegram_1241768779
所以说jb啥的优点就是那样吧
telegram_1241768779
确实
telegram_1241768779
还不如我自己搜索字符串改，关键他们搜索也是卡半天
telegram_1241768779
对的，我之前试用WebStorm也有类似的情况
telegram_1241768779
就是IntelliJ可以支持到SpringBoot的级别，检测到每个路由和控制器，这种功能才是超出LSP范围的
telegram_1241768779
实际上jdtls也有很多针对Java的重构，因为这个项目来自Eclipse
telegram_1241768779
都不是LSP的问题
telegram_1241768779
其它编辑器没这个功夫挨个适配语言
telegram_1241768779
好处是扩展作者有什么想加的功能直接魔改同样是自己管的client的部分就行了
telegram_1241768779
vscode那个是每个扩展自己带了一套client的实现，然后这套client实现再对接vscode的API
telegram_1241768779
要说限制就是改变它现在已有的规定很麻烦
telegram_1241768779
极限到了vscode只要想，再往里面塞就是了
telegram_1241768779
这个协议基本是以vscode为中心的，vscode要啥它就通过这个协议写server该怎样给它传东西
telegram_1241768779
主要的问题是少有人为免费工具做支持到这个地步
telegram_1241768779
rust-analyzer就有很多
telegram_1241768779
严格来说这个不是LSP的问题这个是server的问题
telegram_1241768779
连kate都支持LSP了
telegram_1241768779
话说LS P确实是很省事的东西，基本上就是要server解决一切，client显示就可以了
telegram_1241768779
* 而且比如安卓开发指定的就是用的android studio
telegram_1241768779
而且比如安卓开发制定的就是用的android studio
telegram_1241768779
讨论的不是一个问题
telegram_1241768779
你说的是现在了…
telegram_1241768779
以前大厂喜欢把SDK打包一套分发出去
telegram_1241768779
回望过去这个变迁，就是IDE和编辑器的概念变得模糊的过程
telegram_1241768779
那你说的是另一个角度
telegram_1241768779
但是visual studio不能没有msbuild呀
telegram_1241768779
它自己打包在一起，而且是按一个许可证分发的吧
telegram_1241768779
* 就不再有真正意义上的IDE和编辑器的区分
telegram_1241768779
就不再有真正意义上的IDE
telegram_1241768779
要不然现在构建系统和调试器都是拆开的
telegram_1241768779
IDE这种定义只对以前微软着重弄visual studio有效了
telegram_1241768779
有LSP的很多，DAP不太多
telegram_1241768779
而且有些自带功能，不知包不包括所有调试功能，是用捆绑的插件实现的
telegram_1241768779
它自己也只是用的gcc
telegram_1241768779
总被看作IDE的IntelliJ是一个例子
telegram_1241768779
比如gcc
telegram_1241768779
* DAP本身就是能支持的，只要工具实现了这个协议，是直接和编辑器交流的
telegram_1241768779
DAP本身就是能支持的，只有工具实现了这个协议，是直接和编辑器交流的
telegram_1241768779
其实未必有插件
telegram_1241768779
怎么说呢这个
telegram_1241768779
我倾向于这是一个过时的区分方式
telegram_1241768779
主要是流行的公认为IDE的产品带构建系统的也不算多数
telegram_1241768779
现在很难说这个差别在哪了
telegram_1241768779
这也太老了
telegram_1241768779
要终端也得放张nvim的图好吧
Page 1 / 1