有生之年系列:微软将对 Windows 的记事本进行大更新

局长
 局长
发布于 2018年07月14日
收藏 8

在多年未更新之后,微软出人意料的透露它将在 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月更新版,记事本将以全新的姿态展现在大家面前!

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:有生之年系列:微软将对 Windows 的记事本进行大更新
加载中

精彩评论

全体人员
全体人员
完了完了,连notepad都要出bug了
mymbrooks
mymbrooks
直接集成 Notepad++ 不就完事了 :smiley:
久永
久永

引用来自“Eriloan”的评论

一个记事本都能成大新闻,有意思。
当然了,任何文物的发掘变动当然都是新闻啦!
久永
久永

引用来自“Fenying”的评论

完了完了,连notepad都要出bug了

引用来自“久永”的评论

非常正确!
我们要的不是功能强大,
我们要的是 可靠、安全、有基本功能
还有就是为什么要用记事本的最重要原因:


速度快!


对于记事本来说,启动速度改慢了,一切升级都失去了意义!

引用来自“乌龟壳”的评论

记事本打开大文件慢成狗,这个启动速度没啥意义
又来杠?
大文件本来就不是它原来一开始的设计目标,后来勉强支持,本来就是个被饱受诟病的bug,这个谁不知道?
说它快,当然是指它程序启动速度最快了。
需要杠这个吗?
久永
久永

引用来自“Fenying”的评论

完了完了,连notepad都要出bug了
非常正确!
我们要的不是功能强大,
我们要的是 可靠、安全、有基本功能
还有就是为什么要用记事本的最重要原因:


速度快!


对于记事本来说,启动速度改慢了,一切升级都失去了意义!

最新评论(51

x
xzvbc
找马甲包上架开发者,想赚外快的来,IOS、安卓平台都有,有意者联系qq:1072454343
kernel64
kernel64
打开记事本,输入'联通' 保存起来,再打开....

再一次证明了联通就是不如移动.
Jay_M_Hu
Jay_M_Hu
简化一个VSCode当记事本就可以了(或者用Sublime?)。
W
WavinFlag
对我来说,支持\n行尾和多字符集多编码选择是最低要求。所以我用一个无插件的Notepad++代替原生记事本。
代码编辑交给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计算的是外行。
我错了,你赢了。
反正我们的聊天记录大家都能看到,孰是孰非,大家自有公论。
装睡的人是叫不醒的。
我们的讨论到此为止吧,我不会再回你了。
我问的裁剪 bezier 算法大概就是解高次方程,只有几步的事,非要扯上 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计算了?
行,我们搞GPU计算的是外行。
我错了,你赢了。
反正我们的聊天记录大家都能看到,孰是孰非,大家自有公论。
装睡的人是叫不醒的。
我们的讨论到此为止吧,我不会再回你了。
乌龟壳
乌龟壳

引用来自“久永”的评论

@乌龟壳 汗!这样做你们也敢干!你们技术总监不干你们?这个是矢量图的计算问题,和svg无关吧?我不知道你在什么环境下用,我是在 wpf 里面用的类似功能。wpf的图像底层是非托管底层是DX的,就算这样,处理起来依然效率不是很高。还好我要处理的量不多,而且官方库提供了现成的 api ,总算勉强够用。
我觉得,如果你是用 svg 相关库处理的,那是肯定慢的。
这种东西最好有个底层的库来运算,最好是用GPU计算的。
否则大量运算的画,肯定慢。
最好找找 DX、 GPU 计算的相关库有没有什么现成的API。
没有底层API实现的话,考虑绕过去吧。

引用来自“乌龟壳”的评论

gpu bezier 八竿子打不着,gpu只认三角形。这个问题不熟悉算啦,我再找别人去问问。

引用来自“久永”的评论

看来逆还停留在 gpu=显卡 的认识上,难怪会搞成这样,你还年轻啊,小伙子。
对于认为“凡是图形计算都能用GPU”这种认识的外行来说,他们以为凡是和图形挂钩的东西都适合 GPU 去做。
这种认识就像算三角形的面积,本来几个乘法就解决的事情,非要用 GPU 渲染后,计算最终像素值,求近似解。美其名曰 GPU 加速。
久永
久永

引用来自“久永”的评论

@乌龟壳 汗!这样做你们也敢干!你们技术总监不干你们?这个是矢量图的计算问题,和svg无关吧?我不知道你在什么环境下用,我是在 wpf 里面用的类似功能。wpf的图像底层是非托管底层是DX的,就算这样,处理起来依然效率不是很高。还好我要处理的量不多,而且官方库提供了现成的 api ,总算勉强够用。
我觉得,如果你是用 svg 相关库处理的,那是肯定慢的。
这种东西最好有个底层的库来运算,最好是用GPU计算的。
否则大量运算的画,肯定慢。
最好找找 DX、 GPU 计算的相关库有没有什么现成的API。
没有底层API实现的话,考虑绕过去吧。

引用来自“乌龟壳”的评论

gpu bezier 八竿子打不着,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实现的话,考虑绕过去吧。
返回顶部
顶部