解决 sublime 的 日常误操作

对于快捷键不熟悉的同学，当你把sublime的菜单栏隐藏起来的时候，你会发现能够提示你快捷键操作的菜单栏本身已经消失的无影无踪了。

接下来就是sublime 变成 简版notepad进行开发的过程，你会发现原来看起来并没有卵用的菜单栏，它在你心中的地位还是蛮大的。

那么既然已经脑洞开了一次，那么接下来就只好不断尝试修复这个问题。想到用 ctrl+shift+p打开命令面板，发现不知道命令。既然有这个想法了，

那么就是尝试找命令的了。这次很简单发现，有人已经贴出了百度，并且把方法写成了百度经验，我可以想象这位老兄当时去看官方文档的时候的心情。

所以  当你 手贱隐藏sublime 菜单栏的时候，请记住这样恢复。

1 ctrl+shift+p     打开命令面板
2
3 View:Toggle Menu

为sublime的机智暗暗喝彩~

时间： 2024-10-13 14:13:28

解决 sublime 的 日常误操作的相关文章

请列出你在从事IT生涯中,最难以忘怀的一次误操作

IT系统最怕什么,我觉得就两点: 1.不可靠的软硬件. 2.误操作. 第一点就不用解释了,第二点是该文的内容,主要摘选自ITPUB的精华贴——[精华] 请列出你在从事DBA生涯中,最难以忘怀的一次误操作 中摘录各位网友的经验和教训,常看看以警惕自己. #2 一次一个session占用内存很大,这个session id比较大,所以以为是用户进程,kill, 则库立刻down了,查日志后,才知道是一个后台进程,但详细是哪个进程,现在忘记了. 好的是库起来了,这个故障,我一直牢记于心. 现在做任何操作

MySQL 误操作后数据恢复（update,delete忘加where条件）

在数据库日常维护中,开发人员是最让人头痛的,很多时候都会由于SQL语句写的有问题导致服务器出问题,导致资源耗尽.最危险的操作就是在做DML操作的时候忘加where条件,导致全表更新,这是作为运维或者DBA的我们改如何处理呢?下面我分别针对update和delete操作忘加where条件导致全表更新的处理方法. 一. update 忘加where条件误操作恢复数据(binglog格式必须是ROW) 1.创建测试用的数据表 mysql> create table t1 ( -> id int un

SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

问题: 经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题. 遇到这种情况,一般都是没有做备份,不然也不会来发问了.首先要冷静,否则会有更大的灾难.直到你放弃. 解决方法: 对于这类问题,主要是找回误操作之前的数据,在2008之前,有个很出名的工具Log Exploer,听说还挺好用的,这个网上大把教程,这里就不多说了.但是唯一遗憾的是,不支持2008及更高版本,这

一次误操作引起的linux系统网络故障

1.故障描述 接到用户报障,生产某系统无法访问.同事接到报障后立即排查,经测试,系统确实无法访问,并且无法ping通服务器. 2.故障处理 由于客户端无法ping通服务器,需要进入机房查看.经查看,服务器硬件无报警,系统无重启.登录系统使用ifconfig命令查看,IP丢失(eth0不存在),紧接打开网卡配置目录/etc/sysconfig/network-scripts,发现网卡文件ifcfg-eth0丢失,只存在之前备份的ifcfg-eth0.bak文件和ifcfg-peth0文件.根据先抢

MySQL 误操作后如何快速恢复数据~！~！~

基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了.误操作后,能快速回滚数据是非常重要的. 传统解法 用全量备份重搭实例,再利用增量binlog备份,恢复到误操作之前的状态.然后跳过误操作的SQL,再继续应用binlog.此法费时费力,不值得再推荐. 利用binlog2sql快速闪回 首先,确认你的MySQL server开启了binlog,设置了

【转】SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

4号,公司的生产数据表被全部删除,目前没有找到原因,由于刚接触SQL不久,所以短时间内不会还原,也不敢动被原服务器,于是就将原服务器停掉,拷贝出里面的PPD数据库文件,留作备份:近几天在自己的电脑上尝试修复,一直没有成功,细读了一下<SQL2005技术内幕——存储引擎>了解到删除列.删除表这些操作不会直接对每一行数据进行操作,而是直接改变他们的物理指向地址的ID,专业术语我也不是很清楚,我的理解是这样的,有时间再弄清楚,不过这足以让我明白被删除的表还是存在mdf文件中,其改变的便宜地址记录在日

rm-rf 误操作的恢复过程

很多DBA一定对rm -rf深恶痛绝吧,没准哪天自己一个犯迷糊就把数据库给消灭了,然后,就没有然后了--那万一--真的发生了这样的不幸,是否真的就无药可救了吗?未必,还是有解决方法的,也许某天当你不幸遇到,就可以用来救自己了.这里做恢复操作的前提是没有可用的rman备份,或者数据库冷备份等,也就是说,没有任何备份. 一.登陆SQLPLUS,并启动数据库 [[email protected] ~]$ sqlplus / as sysdba SQL*Plus: Release 10.2.0.1.0

Git误操作 git reset强制回滚 恢复commit方法

参考: 找回Git中丢失的Commit Git误操作 git reset强制回滚 恢复commit方法 使用Git时,常有误操作,在Commit之后又执行了git reset --hard HEAD强制回滚本地记录以及文件到服务器版本,导致本地做的修改全部恢复到Git当前分支的服务器版本,同时Commmit记录也消失了. 此时解决方法是通过git reflog来查看先前记录并恢复: git reflog会记录所有HEAD的历史,也就是说当你做 reset,checkout等操作的时候,这些操作会

binlog-rollback.pl 在线恢复update 和delete不加条件误操作sql

一.binlog-rollback.pl工具介绍 是perl开发的脚本工具,此工具主要是生成反向的DML sql语句: #基于row模式的binlog,生成DML(insert/update/delete)的rollback语句 #通过mysqlbinlog -v 解析binlog生成可读的sql文件 #提取需要处理的有效sql #"### "开头的行.如果输入的start-position位于某个event group中间,则会导致"无法识别event"错误 #将