缓冲区

发布VIM缓冲区切换插件buf_it升级版

五迷三道 提交于 2020-03-01 10:14:26
VIM默认使用的过程中有一个重要的问题,就是打开多个文件的时候无法可视化看到打开的文件,并在这些文件中切换。MiniBufExplorer是一个常用的buffer切换插件,但是这个插件在Windows下使用的时候有许多问题,同时也太繁琐。buf_it [1] 则实现了轻量的buffer管理,但是buf_it同样在windows下有许多问题,而buf_it的退出机制也会出现只想关闭一个文件确关闭了整个vim的情况。 基于这两个问题,我修改了buf_it插件,这里共享出来,欢迎大家提意见。先给张图 修改: 1 windows下使用GVIM优化,方式多开一个空白缓冲区,windows下gvim右键配置见参考文献2 2 增加自定义退出方式 3 修改了部分快捷键,只是个人习惯,可无视之 安装: 直接扔到plugin目录就行,原作者没写doc,那我也不写啦。 配置: nnoremap <Leader>wq :w<CR><Esc>:call BufClose()<CR> nnoremap <Leader>q :call BufClose()<CR> nnoremap <Leader>w :w<CR> nnoremap <Leader>x :bd!<CR><Esc>:call BufClose()<CR> 使用: shift+h,l :左右切换tab <leader>be :BufEcho

C Primer Plus 第8章 字符输入/输出和输入确认 8.2 缓冲区

假如想象 提交于 2019-12-05 20:56:22
8.2 缓冲区 当您在一些系统上运行前面的程序时,您所输入的文本立即回显。也就是说,一个可能的运行示例如下所示: HHeelllloo,,tthheerree..II wwoouulldd[enter] lliikkee aa# 前面描述的行为是例外的。在大多数系统上,在您按下回车键之前什么都不会发生,正如在第一个例子中所示。 输入字符的立即回显是非缓冲(unbuffered)或直接(direct)输入的一个实例,它表示您所键入的字符对正在等待的程序立即变为可用。 相反,延迟回显是缓冲(buffered)输入的实例,这种情况下 您所键入的字符被收集并存储在一个被称为缓冲区(buffer)的临时存储区域中 。 按下回车键可使您所键入的字符 对程序变为可用 。 为什么需要缓冲区? 首先,将若干个字符作为一个块传输比逐个发送这些字符耗费时间少 。 其次,如果您输入有误,就可以使用您的键盘更正功能来修正错误 。当最终按下回车键时,您就可以发送正确的输入。 缓冲分为两种: 完全缓冲(fully buffered)I/O和行缓冲(line-buffered)I/O。 对完全缓冲来说,缓冲区满时被清空(内容被发送至其目的地)。这种类型的缓冲通常出现 在文件输入中。缓冲区的大小取决于系统,但512字节和4096字节是常见的值。对行缓冲I/O来说,遇到一个换行字符时将被清空缓冲区。

Slime 手册学习总结 (一)Emacs 快速切换不同缓冲区的设置技巧

别等时光非礼了梦想. 提交于 2019-12-04 23:56:39
Slime 手册学习总结 (一)Emacs 快速切换不同缓冲区的设置技巧 用 Emacs 环境进行 Common Lisp 编程,好的键盘操作技巧可以让你尽量少用鼠标,避免切换操作,有组于保持连续的思路。 今天介绍的技巧是如何设置快速切换不同缓冲区,一般的方法是用那个 C-x o 的命令,但是无法迅速指定你要的缓冲区,今天在学习 slime 用户手册时,发现这么一个使用 slime-selector 的设置技巧,试了一下非常好用,具体方法是在你的配置文件 .emacs 里增加这条语句: (global-set-key "\C-c s" 'slime-selector) z这条语句把 slimeselector 命令绑定到快捷键 "\C-c s" 同时按 CTRL 和 c 键,松开,再按 s 键,最下方的回显区会提示:Select : [候选字符] 输入候选字符中的任意一个就可以迅速切换到对应的缓冲区,候选字符对应的缓冲区如下: Select Methods: 4: Select in other window ?: Selector help buffer. c: SLIME connections buffer. d: *sldb* buffer for the current connection. e: most recently visited emacs-lisp

DirectByteBuffer更快吗?

对着背影说爱祢 提交于 2019-12-02 14:38:18
ByteBuffer.allocateDirect vs ByteBuffer.allocate 操作系统的IO机制 操作系统在内存区域上执行IO操作,这些内存区域是连续的字节。毫无疑问只有字节缓冲区才有资格参与IO操作的。同样操作系统会直接访问进程空间,包括JVM进程,传输数据。JVM内部,字节数组可能不是连续的,或者GC任意时刻会移动这些字节。Java内部数组是对象,对象内部数据存储的方式,是跟JVM实现相关的。 引入Direct Buffer 出于这个原因,引入了direct buffer。direct buffer就是为了和channel和本地IO例程交互。direct buffer的实现会尽量让channel直接使用,本地操作系统代码能够直接读写。 利弊 直接缓冲区通常是IO操作的最佳选择,是JVM能够使用的最高效的IO机制。non-direct缓冲区可以传递给channel,但通常会带来性能损耗。通常non-direct缓冲区不是本地IO操作的直接目标。如果让channel写non-direct ByteBuffer,channel会隐含的执行下列步骤: 创建临时的direct ByteBuffer 复制non-direct buffer中的内容到临时buffer 使用临时buffer执行IO操作 临时buffer不被引用,最终被垃圾收集

VIM使用系列:寄存器与复制粘贴缓冲区

♀尐吖头ヾ 提交于 2019-11-27 19:48:39
现在已经可以熟练使用VIM的大多数基本命令、功能来进行项目代码的开发了,但是在项目的开发过程中,依然会感觉到一些操作效率比较低,比如通过h/j/k/l来进行光标的大范围移动这类操作,显然VIM提供了更高效的命令操作方式。最近经常需要完成的工作就是需要在代码之间来回的复制、粘贴、搜索和替换,常用的d/y/x/p命令已经显得不够,于是学习了一下VIM的寄存器功能,使用寄存器的内容缓冲功能可以极大地提高大量复制粘贴工作的效率。 寄存器类型 VIM中有9中类型的寄存器,寄存器的主要功能就是缓存操作过程中删除、复制、搜索等的文本内容,通过 :help registers命令查看寄存器的详细帮助说明,这里对类型翻译如下: 未命名寄存器 "" —— vim使用的默认寄存器,文本来源命令:d/c/s/x/y 10个数字命名寄存器 "0 - "9 —— vim缓存yank和delete行操作命令产生的文本 1个非行删除内容缓存寄存器 "- —— vim缓存delete操作在非行上时产生的文本 26个字母命名寄存器 "a - "z / "A - "Z —— 完全由用户指定内容的寄存器 4个只读寄存器 ". "% "# ": 表达式寄存器 "= —— 使用VIM强大的表达式功能(从来没用过,一点不懂) GUI选择寄存器 "* "+ "~ —— vim缓存在GUI中选择的文本 黑洞寄存器 "_ ——