|
|
|---|---|
|
|
20年前的易语言玩过一下，现在不知道是啥样了。 如果你说的是像它一样把变量声明放到一个表格里，写代码变成填空题，暂时怕是支持不了。目前也没有这种打算。 倒是支持一下类似scratch那种代码积木的编辑方式，我的TODO列表里是有这个计划的。 但这也只是给非常基础的入门开发者玩的玩具而已，干不了什么大事。 代码反向生成流程图，代码结构之类的功能。 clangd其实是支持的，未来我也有打算支持这个功能。目前没有想好如果设计交互形式。这个功能只是看上去很美，但没啥普遍应用场景。 clangd能分析得出来的简单结构 ，自己一眼就能看透；而太复杂的结构，它分析出来还是很复杂，还不如看代码来得直接。 总之是有点鸡肋。 |
|
|
明白了，我说的引用dll可能表达的不准确，实际上是引用com类型库，也就是引用tlb文件。你这个编辑器和我想象的不太一样。 |
|
|
关于COM的使用有很多解决方案: 1. 最原始的办法就是通过COM的接口头文件，直接使用非双分派的对象接口。 这是最原始，最高效，最直接也是最简单的方式。这种方式是所有编译器都可以支持的。基本上就相当于调用一个纯虚的接口类。 2. 稍微间接一点的是通过IDL文件，其实这与方法1是类似的。只是要通过接口描述文件(IDL)先生成标准的C/C++头文件，再引用。 IDL的中间层次为不同种类的语言使用COM接口带来了很大的便利。 3. 通过双分派接口调用。这种方案只针对实现了双分派接口的COM组件。 它是通过IDispatch获取接口定义，再把打包后的参数发送给COM对象，由它自己进行调用的分派。 由于它是动态调用的，所以性能会差很多。但很适合动态类型的语言以及远程调用。 当然C/C++里也可以用，只是会比较繁琐。 4. 直接通过TLB引用。这只有微软自家的编译器通过#import扩展才能做到。 TLB其实也就是把IDL里的东西二进制化了，甚至可以与PE合并。 它带来的好处就是COM库的发布变得简单了，只用一个dll文件就能发布所有相关内容。也为动态调用非双分派的COM接口带来的便利。 MSVC的实现方式其实无非是在引用它时，动态的为它生成所需的头文件并自动引用而已。 这大概就是你所说的引用TLB了吧？ 其实这些与EDX本身没有太大的关系。 方案1,2,3用任何一个C/C++编译器都可以直接做到。 方案4只有用MSVC才能直接做到。 其它家编译器不能直接支持TLB，需要通过三方工具生成头文件或是用户自己动态根据TLB创建对象并调用。 在使用方案1,2时，基本上等同于使用C++的抽象类，EDX里会有相应的语法提示。 而使用方案3时，由于调用方式不同，C/C++中不可能直接实现对COM接口方法进行相关的提示。除非再加个包装类。而且C/C++中很少直接调用IDispatch，倒是实现IDispatch的很多。 方案4只有MSVC支持，语法提示也只有VS才做了。在EDX里目前是不支持的。 |
|
|
32位版本已收到..正在学习试用..感谢老大支持!1 
|
|
|
|
|
|
之前在虚拟机里测试的时候发现有这个问题，被补全列表抢了焦点。因为感觉win7没多少人用了，就没去管它。现在已经修正了。等版本更新应该就好了
最后于 2021-12-12 21:52
被无心红叶编辑
，原因：
|
|
|
|
|
|
|
|
|
感谢各位的支持，我又来更新功能了 本周实现了一个简单的文件比较功能，可以用来查看GIT提交记录的变化。 在提交记录界面，双击修改的文件即可弹出文件比较界面。 为了省事，直接翻出以前写的LD算法比较的文件差异，性能不怎么样，比较超过1万行的文件会有点慢。留作以后优化。 目前也只支持文本文件的比较。也还不支持差异合并，冲突解决等功能，以后再慢慢实现。
补充： 刚才稍微优化了一下文本比较的算法实现，改进了一下CPU缓存，寄存器分配之类的东西。 在x64系统上，性能提升了近一倍。不改算法的话，也就只能先这样了。
最后于 2021-12-18 02:54
被无心红叶编辑
，原因：
|
|
|
大佬厉害了，期待更新
|
|
|
本周定期更新没有新功能在UI上有特别显著的变化，变化主要集中在功能调整和优化上。 变更如下： 为构建任务分配Job。中断构建时同步关闭所有后续子进程，以避免子进程继续占用资源。 优化UI性能、显示效果（调整窗口尺寸，DPI切换有显著性能提示，减少了一半的无效刷新） 改进文件比较界面（优化UI，支持光标同步，展示文件格式信息） 版本历史面板中，工作目录变更改为异步加载，减轻UI卡顿 巨型版本库依旧有严重性能问题，关闭应用时等待异常操作可能会卡很久 未来考虑不依赖libgit2进行变更比较，改由手工实现可中断的异步版本比较 文本渲染改回性能较低的系统API，以支持特殊字符的显示 修正WinDBG字符串指针表达式计算失效的问题 修正LSP下，clangd占用文件对象，导致文件无法操作的问题 修正文件比较算法死循环 更新Zstd到v1.5.1
|
|
|
|
|
|
发个2022年第一版。最近忙些乱七八糟的事，没有做太多东西。 变更如下： 支持在工程页面比较文件/目录变更(快捷键Ctrl+D) 支持从文件比较对话框定位到文本编辑器相应位置(快捷键F4) 支持Intel oneAPI 2022版本工具链 支持以文本/二进制模式打开指定文件 优化浮动类视图HIDPI兼容性 优化工程关闭时UI刷新问题 优化未知编码格式文件加载性能(性能提升约120%) 优化浮动提示对话框定位逻辑 优化C/C++补全项匹配算法 改进子任务管理逻辑 所有子任务都通过job管理，并在job关闭时强制关闭所有子任务。 避免edx异常中止后，子任务在后台挂起的问题。 修正文本编辑器撤销操作时可能出现非法字符的问题 更新xxHash到0.8.1
|
|
|
|
|
|
dalao
|
|
|
|
|
|
|
|
|
|
|
|
计划中是有支持MarkDown的。但可能要花比较长的一段时间。 因为在最初设计这个编辑器的时候，为了能流畅支持单行1M字符以及10M行内容的大型文本放弃了自动换行这个功能。 这个功能带来的性能开销对于超长行和超大文本来说是不可接受的 而自动换行对于MarkDown来说却是必须的。 目前市面主流的编辑器都在这方面有或多或少的问题。比如： VSCode对自动换行支持得很好。但处理超长行(最大长度默认限制为10K)及大型文本的性能很差。 SCIntilla(非常多开源编辑器都依赖于它)打开大型文本性能很好，但超长行性能比较差，自动换行的性能就更不行了（最新版本感觉比老版本性能还差）。 VIM打开大型文本文件的性能不错，但处理超长行和自动换行的性能都不太行。如果在文本模式下，不经常改变窗口宽度，自动换行的性能到影响不太大。 EmEditor用几十倍的性能开销来解决大型文本的编辑问题，是仅有的能比较正常操作几百MB的大型文本文件的软件。但扫描文件真的有点慢。 JetBrain很鸡贼，弄了个特殊的只读模式应付大型文本。超长行和自动换行的性能也不怎么样(但因为它界面性能很差，不能同步刷新，这个问题反而影响变小了) 其它如ECLIPSE，VisualStudio之类的，你敢用它打开有超长行的或比较大的文本文件，它就敢死给你看。 支持MarkDown的计划已经筹划了数年之久，目前还在验证新的文本渲染器。 希望能以较小的性能代价把自动换行和多光标(目前仅支持列选择模式)编辑功能给支持了。 以下为开发中的效果，全新的文本渲染器，千里之行才迈出了第一步：
|
|
|
|
|
|
新的文本渲染器一时半会儿是写不好了，搞得人晕头转向。先写了个Markdown分析器来放松一下心情。 基本的语法高亮是有了，预览还没实现，以后打算做所见即所得的Markdown编辑。 不过市面上的Markdown编辑器都是浏览器搞的，纯C++写的怕是独此一家吧？
|
|
|
最近忙些乱七八糟的事，没搞啥东西，更新如下： 2022-02-27: 调整搜索对话框，去除标题栏 优化TreeGrid组件，修正编辑相关BUG 实现GIT Upstream配置界面 修正GDB调试崩溃的BUG 修正WSL调试相关问题 修正GIT提交时可能丢失内容的BUG WinDBG支持std::filesystem::path/std::filesystem::directory_entry美化 2022-02-15: GIT支持修改最后一次提交 添加GIT配置界面 Markdown的代码块支持自动缩进 修正GDB在栈帧为空时会卡住2秒的BUG
|
|
|
|
|
|
|
|
|
工程向导有规划，但暂时还没有安排具体的开发时间。 目前有以下几种简单的办法解决你的问题： 1.单文件编译，调试。 你只要在c/c++源文件文件头添加一行注释 // toolset: xxxx 其中xxxx为你的电脑上可用的工具集，按 alt+. 会有自动的补全。 2. 半自动创建cmake工程 新建一个空目录，然后用edx打开这个目录。通过工程面板新建一个名为CMakeLists.txt的文本文件，然后会自动生成基本的cmake工程文件模板。这时你只要再这个目录时添加你自己的.cpp/.c文件即可。 |
