在多年未更新之后，微软出人意料的透露它将在 Windows 10 下次重大更新中为记事本程序引入多项新功能。
记事本一直是 Windows 系统最基本的工具，但也一直非常简陋，功能单一，为此市面上就出现了各种增强的文本编辑工具，而在最新放出的 Windows 10 Build 17713 内测版中，记事本迎来了 N 年来的第一次大规模升级，颇有焕然一新的感觉。
记事本的新功能包括：
1.默认启用状态栏，能显示行数和列数
2.缩放文本，按住 ctrl 键，就可以使用鼠标滑轮放大或缩小文本
3.查找/替换功能全面升级，增加全文循环查找/替换选项(wrap-around)、可记忆查找/替换关键字和选项状态下次自动恢复、选中文字后打开查找/替换对话框会自动填入
其他改进
提升底层性能，改进打开大文件的速度
支持 Unix 和 Mac 换行符，默认使用 Windows 换行符，但能正确显示 Linux 和 Mac 文本内容，该功能微软在今年五月就已经提供给测试者
用户将可以用 ctrl+backspace 来删除记事本里的前一个单词
提供右键选项用 Bing 搜索记事本中的单词
方向键可以正确反选文字并移动光标
可正确显示超过屏幕大小的行
等到今年秋天发布的 Windows 10 Redstone 5 正式版，也就是 Windows 10 2018年10月更新版，记事本将以全新的姿态展现在大家面前！
精彩评论
引用来自“Eriloan”的评论
一个记事本都能成大新闻，有意思。引用来自“Fenying”的评论
完了完了，连notepad都要出bug了引用来自“久永”的评论
非常正确！我们要的不是功能强大，
我们要的是 可靠、安全、有基本功能
还有就是为什么要用记事本的最重要原因：
速度快！
对于记事本来说，启动速度改慢了，一切升级都失去了意义！
引用来自“乌龟壳”的评论
记事本打开大文件慢成狗，这个启动速度没啥意义大文件本来就不是它原来一开始的设计目标，后来勉强支持，本来就是个被饱受诟病的bug，这个谁不知道？
说它快，当然是指它程序启动速度最快了。
需要杠这个吗？
引用来自“Fenying”的评论
完了完了，连notepad都要出bug了我们要的不是功能强大，
我们要的是 可靠、安全、有基本功能
还有就是为什么要用记事本的最重要原因：
速度快！
对于记事本来说，启动速度改慢了，一切升级都失去了意义！
最新评论（51）
再一次证明了联通就是不如移动.
代码编辑交给Sublime、VS Code以及更加集成化的IDE。
引用来自“久永”的评论
@乌龟壳 汗！这样做你们也敢干！你们技术总监不干你们？这个是矢量图的计算问题，和svg无关吧？我不知道你在什么环境下用，我是在 wpf 里面用的类似功能。wpf的图像底层是非托管底层是DX的，就算这样，处理起来依然效率不是很高。还好我要处理的量不多，而且官方库提供了现成的 api ，总算勉强够用。我觉得，如果你是用 svg 相关库处理的，那是肯定慢的。
这种东西最好有个底层的库来运算，最好是用GPU计算的。
否则大量运算的画，肯定慢。
最好找找 DX、 GPU 计算的相关库有没有什么现成的API。
没有底层API实现的话，考虑绕过去吧。
引用来自“乌龟壳”的评论
gpu bezier 八竿子打不着，gpu只认三角形。这个问题不熟悉算啦，我再找别人去问问。引用来自“久永”的评论
看来逆还停留在 gpu=显卡 的认识上，难怪会搞成这样，你还年轻啊，小伙子。引用来自“乌龟壳”的评论
对于认为“凡是图形计算都能用GPU”这种认识的外行来说，他们以为凡是和图形挂钩的东西都适合 GPU 去做。这种认识就像算三角形的面积，本来几个乘法就解决的事情，非要用 GPU 渲染后，计算最终像素值，求近似解。美其名曰 GPU 加速。
引用来自“久永”的评论
按这个说法，不能按图形计算计算需求（指没法转换成对应等效渲染计算的计算需求——补充下，怕），那就没法没法用GPU计算了？行，我们搞GPU计算的是外行。
我错了，你赢了。
反正我们的聊天记录大家都能看到，孰是孰非，大家自有公论。
装睡的人是叫不醒的。
我们的讨论到此为止吧，我不会再回你了。
就算扯上 GPU，你也得把算法搞清楚才能在 GPU 实现吧？
你可能不知道我说的裁剪是矢量-矢量的，你提的那些跟 GPU 有关的库都是渲染的东西。GPU 有关的库大部分都是矢量-标量的，而且那些库的裁剪因为 GPU 可以在标量层面（片元着色器）裁剪，所以一般不做太复杂的裁剪计算——因为他们只要最终的标量（图像）正确即可。
说你外行是因为你根本不清楚里面的细节。当然你不清楚就不清楚没啥，毕竟是我提的问题，也是我研究的领域，你不清楚有啥？我也不清楚浏览器开发，但我不觉得这算啥事，术业有专攻而已。
问题是你从一开始就给我定性“杠精”，到后面画风全变了，弄得我说每句话都像跟你杠一样。你不是装睡，只是自视甚高。
引用来自“久永”的评论
@乌龟壳 汗！这样做你们也敢干！你们技术总监不干你们？这个是矢量图的计算问题，和svg无关吧？我不知道你在什么环境下用，我是在 wpf 里面用的类似功能。wpf的图像底层是非托管底层是DX的，就算这样，处理起来依然效率不是很高。还好我要处理的量不多，而且官方库提供了现成的 api ，总算勉强够用。我觉得，如果你是用 svg 相关库处理的，那是肯定慢的。
这种东西最好有个底层的库来运算，最好是用GPU计算的。
否则大量运算的画，肯定慢。
最好找找 DX、 GPU 计算的相关库有没有什么现成的API。
没有底层API实现的话，考虑绕过去吧。
引用来自“乌龟壳”的评论
gpu bezier 八竿子打不着，gpu只认三角形。这个问题不熟悉算啦，我再找别人去问问。引用来自“久永”的评论
看来逆还停留在 gpu=显卡 的认识上，难怪会搞成这样，你还年轻啊，小伙子。引用来自“乌龟壳”的评论
对于认为“凡是图形计算都能用GPU”这种认识的外行来说，他们以为凡是和图形挂钩的东西都适合 GPU 去做。这种认识就像算三角形的面积，本来几个乘法就解决的事情，非要用 GPU 渲染后，计算最终像素值，求近似解。美其名曰 GPU 加速。
行，我们搞GPU计算的是外行。
我错了，你赢了。
反正我们的聊天记录大家都能看到，孰是孰非，大家自有公论。
装睡的人是叫不醒的。
我们的讨论到此为止吧，我不会再回你了。
引用来自“久永”的评论
@乌龟壳 汗！这样做你们也敢干！你们技术总监不干你们？这个是矢量图的计算问题，和svg无关吧？我不知道你在什么环境下用，我是在 wpf 里面用的类似功能。wpf的图像底层是非托管底层是DX的，就算这样，处理起来依然效率不是很高。还好我要处理的量不多，而且官方库提供了现成的 api ，总算勉强够用。我觉得，如果你是用 svg 相关库处理的，那是肯定慢的。
这种东西最好有个底层的库来运算，最好是用GPU计算的。
否则大量运算的画，肯定慢。
最好找找 DX、 GPU 计算的相关库有没有什么现成的API。
没有底层API实现的话，考虑绕过去吧。
引用来自“乌龟壳”的评论
gpu bezier 八竿子打不着，gpu只认三角形。这个问题不熟悉算啦，我再找别人去问问。引用来自“久永”的评论
看来逆还停留在 gpu=显卡 的认识上，难怪会搞成这样，你还年轻啊，小伙子。这种认识就像算三角形的面积，本来几个乘法就解决的事情，非要用 GPU 渲染后，计算最终像素值，求近似解。美其名曰 GPU 加速。
引用来自“久永”的评论
@乌龟壳 汗！这样做你们也敢干！你们技术总监不干你们？这个是矢量图的计算问题，和svg无关吧？我不知道你在什么环境下用，我是在 wpf 里面用的类似功能。wpf的图像底层是非托管底层是DX的，就算这样，处理起来依然效率不是很高。还好我要处理的量不多，而且官方库提供了现成的 api ，总算勉强够用。我觉得，如果你是用 svg 相关库处理的，那是肯定慢的。
这种东西最好有个底层的库来运算，最好是用GPU计算的。
否则大量运算的画，肯定慢。
最好找找 DX、 GPU 计算的相关库有没有什么现成的API。
没有底层API实现的话，考虑绕过去吧。
引用来自“乌龟壳”的评论
gpu bezier 八竿子打不着，gpu只认三角形。这个问题不熟悉算啦，我再找别人去问问。引用来自“久永”的评论
@乌龟壳 汗！这样做你们也敢干！你们技术总监不干你们？这个是矢量图的计算问题，和svg无关吧？我不知道你在什么环境下用，我是在 wpf 里面用的类似功能。wpf的图像底层是非托管底层是DX的，就算这样，处理起来依然效率不是很高。还好我要处理的量不多，而且官方库提供了现成的 api ，总算勉强够用。我觉得，如果你是用 svg 相关库处理的，那是肯定慢的。
这种东西最好有个底层的库来运算，最好是用GPU计算的。
否则大量运算的画，肯定慢。
最好找找 DX、 GPU 计算的相关库有没有什么现成的API。
没有底层API实现的话，考虑绕过去吧。
我觉得，如果你是用 svg 相关库处理的，那是肯定慢的。
这种东西最好有个底层的库来运算，最好是用GPU计算的。
否则大量运算的画，肯定慢。
最好找找 DX、 GPU 计算的相关库有没有什么现成的API。
没有底层API实现的话，考虑绕过去吧。