值得投入时间学习使用 Emacs 吗?

发布于 2024-07-04 01:44:33 字数 340 浏览 5 评论 0原文

首先:我不想想要发动宗教战争。

从我记事起,我就一直在使用 vi,而有几次我尝试使用 Emacs 时,我都迷失了方向,很快就迷失了方向放弃了。 然而,很多人发现 Emacs 非常强大。 它的可编程性有点传奇。 我主要从事 Solaris+Java 开发,我想问一个简单的问题:如果我花时间熟悉 Emacs,我的工作效率会提高吗? 它相对于 Vim 提供的功能是否会在合理的时间范围内通过生产力的提高得到回报?

重复:我不想要“我的编辑比你的更好”的答案。 我只想知道是否值得投入时间。 我的工作效率真的会提高吗?

Right up front: I do not want to start a religious war.

I've used vi for as long as I can remember, and the few times I've tried to pick up Emacs I've been so lost that I've quickly given up. Lots of people find Emacs very powerful, however. Its programmability is somewhat legendary. I'm primarily doing Solaris+Java development, and I'd like to ask a simple question: will my productivity increase if I invest time in getting my head around Emacs? Is the functionality that it offers over Vim going to be paid back in productivity increases in a reasonable timeframe?

Repeat: I don't want a "my editor is better than yours" answer. I just want a yes or no answer as to whether it's worth investing the time or not. Will my productivity really increase?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(29

盛装女皇 2024-07-11 01:44:34

在之前的回答中,Aristotle Pagaltzis 写道:“Vim 在小方面表现出色......您可以在正常的编辑过程中轻松地在 Vim 中完成需要您在 Emacs 中编写脚本的操作。”

在专门使用 vi 十多年后,我转向了 Emacs,最初我会同意这样的说法:“在正常的编辑过程中,您可以在 Vim 中轻松完成需要您在 Emacs 中编写脚本的操作。” 但后来我发现,通过使用 Emacs 的宏功能和大量的重复次数,我可以轻松地让 Emacs 完成 vi 所做的几乎所有事情,甚至更多。

Emacs 的宏功能涉及三个命令:

C-x (       start remembering keystrokes
C-x )       stop remembering keystrokes
C-x e       replay the remembered keystrokes

例如,在 vi 中,如果我想查找 HTML 文件中的所有 标签
并添加一个 target 属性,我可能会执行如下操作:

:g/^<a/s/>/ target="_blank">/

这个示例并不完美,因为它假设所有 标签本身都在一行上。 但它足以说明如何在两个不同的编辑器中完成相同的任务。

为了在 emacs 中轻松实现相同的效果,我是这样做的:

1.  C-x (
2.  M-C-s <a\>
3.  C-b
4.  C-s >
5.  C-b
6.   target="_blank"
7.  C-x )
8.  C-u 10000 C-x e

下面是上面每个击键的作用的描述:

1.  start remembering keystrokes
2.  regex search for <a.  Note that the "\>" after the "a" is not HTML.  It's emacs regex notation for end-of-word.
3.  back up one character - as a side-effect this gets you out of search mode
4.  search for the next ">"
5.  back up over the ">"
6.  enter space as an attribute-delimiter followed by the target="_blank" attribute
7.  stop remembering keystrokes
8.  replay the remembered keystrokes 10,000 times or until the search fails

看起来很复杂,但实际上很容易输入。 您可以使用这种方法做很多 vi 无法做的事情,而无需陷入 Lisp 代码。

In an earlier answer, Aristotle Pagaltzis wrote: "Vim excels in the small ... You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs."

I switched to Emacs after over a decade of exclusively using vi, and initially I would have agreed with the claim, "You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs." But then I discovered that by using Emacs' macro capability and a large repeat count, I could easily make Emacs do pretty much everything that vi had made easy, and a great deal more.

Emacs' macro functionality involves three commands:

C-x (       start remembering keystrokes
C-x )       stop remembering keystrokes
C-x e       replay the remembered keystrokes

For example, in vi if I wanted to find all <a> tags in an HTML file
and add a target attribute, I might do something like the following:

:g/^<a/s/>/ target="_blank">/

This example is not perfect, since it assumes that all <a> tags are on a line by themselves. But it's good enough for illustrating how one accomplishes the equivalent task in two different editors.

To achieve the same effect easily in emacs, here's what I do:

1.  C-x (
2.  M-C-s <a\>
3.  C-b
4.  C-s >
5.  C-b
6.   target="_blank"
7.  C-x )
8.  C-u 10000 C-x e

Here's a description of what each keystroke above does:

1.  start remembering keystrokes
2.  regex search for <a.  Note that the "\>" after the "a" is not HTML.  It's emacs regex notation for end-of-word.
3.  back up one character - as a side-effect this gets you out of search mode
4.  search for the next ">"
5.  back up over the ">"
6.  enter space as an attribute-delimiter followed by the target="_blank" attribute
7.  stop remembering keystrokes
8.  replay the remembered keystrokes 10,000 times or until the search fails

It looks complicated, but it's actually very easy to type. And you can use this approach to do lots of things that vi can't do, without ever dropping down to Lisp code.

不必在意 2024-07-11 01:44:34

免责声明:我无知。 我使用 emacs 大约有 4 年了,使用 vim 大约有 6 个月了,如果算上我尝试学习但又讨厌它的次数的话,可能更像是 15 个月了。 (写作模式与移动模式的区别每次都杀了我。所以如果它不能杀了你,那么我的观点可能完全毫无价值。)也就是说,我认为我的观点实际上与我见过的其他 26 个观点有有趣的不同就在这里,所以我要说出来。
:免责声明

我的观点:

  • Emacs 更适合打字,尤其是大型打字“我正在编写一个新功能,需要一段时间才能尝试看看是否它运行”。
  • Vim 更适合编辑,尤其是快速编辑。

当我需要同时理解和破解 8 个文件时,Emacs 作为具有多缓冲区的平铺窗口管理器的属性(缓冲区与文件有 1.2:1 对应关系,它们通常是相同的东西,但不一定) regexp - 搜索(和替换)令人难以置信。

如果我因为 shell 中的 git diff 而不喜欢某些小东西(我不经常使用 emacs 的 VC 功能,尽管当我使用它们时我很喜欢它们),我会用 vim 打开它并比我按 Alt-TAB 还快,快点离开吧。

事实上,Emacs 的编辑命令在打字时更容易使用,这使得打字速度比在 Vim 中快得多。 Ctrl+aESC ^ i很多,并且您不会有“我想要a吗”的认知负担ioO...”,上帝,我讨厌思考这些。 对于所有其他移动命令也是如此。

我在 Emacs 中打字速度越来越快。 这意味着诸如 Org 模式之类的东西(我将其用于所有内容:TODO 列表、错误跟踪、注释、长电子邮件、文档。 ..)(对我来说)在 Emacs 中比在 Vim 中更有意义。

而且,Elisp 令人难以置信,尽管它很糟糕。 它完全弥补了 Emacs 损坏的正则表达式:您可以在任何地方使用 emacs 的全部功能,包括在多文件正则表达式替换中。 在文本片段中。

Disclaimer: I'm ignorant. I've been an emacs user for about 4 years, and vim user for about 6 months, maybe more like 15 if you count all the times I've tried to learn it and hated it. (The writing vs moving mode distinction kills me. Every time. So if it doesn't kill you then my opinion might be completely worthless.) That said, I think my opinion is actually interestingly different from the 26 others that I've seen on here, so I'm going to voice it.
:Disclamer

My opinion:

  • Emacs is better for typing, especially large-scale "I'm writing a new feature and it will be a while before I even try to see if it runs".
  • Vim is better for editing, especially quick edits.

When I need to understand and hack in 8 files simultaneously, Emacs' properties as a tiling window manager with multi-buffer (buffers have a 1.2:1 correspondence to files, they're often the same thing, but aren't necessarily) regexp-search (and replace) are incredible.

If I don't like some small thing because of git diff in the shell (I don't use emacs' VC features very often, although when I do I love them) I open it with vim and get the hell out faster than I could hit Alt-TAB.

The fact that Emacs' editing commands are more readily available while typing make typing much faster than it is in Vim. Ctrl+a is much faster than ESC ^ i, and you don't have the cognitive load of "do I want a or i or o or O..." which, god, I hate thinking about. And same for all the other movement commands commands.

I type faster, much faster, in Emacs. That means things like Org Mode (which I use for everything: TODO lists, bug tracking, notes, long emails, documentation...) make more sense (to me) in Emacs than they would in Vim.

And, Elisp is incredible, even though it sucks. It totally makes up for Emacs' broken regular expressions: you can use the full power of emacs everywhere, including in a multi-file regexp-replacement. And in text snippets.

世界等同你 2024-07-11 01:44:34

如果您担心双手健康,请选择 Vim。

我过去曾遭受过一次 RSI 的困扰,我发现罪魁祸首之一是“和弦”,即同时按住多个键。 Emacs 广泛使用和弦,而 VIM 使用快速连续链接的单字母命令。 这会给您的手带来更少的压力,因为肌肉不必扭曲和扭曲即可在编辑器中执行命令。 RSI 造成的伤害可能会破坏您的工作效率,因此在计算时请务必考虑到这一点。

If you are concerned about the health of your hands choose Vim.

I suffered from a bout of RSI in the past, and I found one of the main culprits was "chording" i.e. holding down many keys at the same time. Emacs uses chording extensively whilst VIM uses single letter commands chained in quick succession. This puts much less strain on your hands as the muscles don't have to twist and contort to perform commands in the editor. Injury due to RSI can ruin your productivity so in your calculations be sure to account for this.

时光与爱终年不遇 2024-07-11 01:44:34

我实在看不出有什么理由要换。 我已经使用 vi 很长时间了,并且用起来很舒服; 大约每六个月我就会安装 emacs 来尝试一下,然后很快就切换回来。 是的,我非常喜欢 vi 的一些东西,但我从未坚持使用它的主要原因是,当我已经知道一个非常有能力的编辑器时,投入时间来完全学习另一个编辑器是不值得的。
我想起了这个相当过时的研究。

在我看来,SLIME如果您已经精通 vi,这可能是切换到 emacs 的唯一原因。

I really see no reason to switch. I've used vi for a long time and am quite comfortable with it; about every six months I would install emacs to give it a go, then quickly just switch back. Yes there were things I much preferred about vi, but the main reason I never stuck with it is because the time investment to fully learn another editor when I already know an extremely capable one isn't worth it.
I'm reminded of this rather dated study.

In my opinion, SLIME is about the only reason to switch to emacs if you're already proficient with vi.

迟月 2024-07-11 01:44:34

不,

我已经使用 emacs 多年了,我是 VIM 的转换者,我非常喜欢它。

但是,拥有一个更好的可编程编辑器所带来的任何生产力提升都将因掌握 emacs 的窍门而需要花费大量的精力而完全消失。 它被设计为控制台编辑器,其界面的想法不是你的。

即使您完全掌握了它,您额外的生产力也将主要体现在您可以编写额外的 emacs lisp 中。

谁在乎? 太有趣了,口齿不清就是狗! 如果你想“把事情做好”,那就忘掉编程吧。 你总是可以雇佣程序员来“做”“事情”。

出于生产力原因,我建议学习 emacs 的唯一情况是,如果您是 lisp/scheme/clojure 程序员。 它创造了一个非常好的 lisp 环境,每次你想做任何事情时,它都会为你节省几秒钟的时间,很快就会累积成真正的收获。 如果你已经使用过真正的 lisp,那么 elisp(它与 lisp 的关系就像 excel 宏与 ALGOL 的关系一样)看起来就不那么陌生了。

如果您确实尝试一下,请在虚拟控制台上使用它,感觉更像是安排编辑器的合理方式。 只有当有意义时才尝试在窗口系统下使用它,窗口系统会与之对抗。

No

I've been using emacs for years, I'm a convert from VIM, and I love it to bits.

But any productivity gains from having a better, programmable editor will be totally wiped out by the enormous amount of head-fucking that it takes to get the hang of emacs. It was designed as a console editor, and its idea of interface is not yours.

And even when you've got it completely, your extra productivity will mainly be expressed in the extra emacs lisp you can write.

Who cares? It's great fun, and lisp is the dogs! If you want to 'get things done', then forget about programming. You can always hire programmers to 'do' 'things'.

The only circumstance under which I'd recommend learning emacs for productivity reasons is if you're a lisp/scheme/clojure programmer. It makes such a good lisp environment that then the few seconds it will save you every time you want to do anything will quickly add up to a real gain. And elisp (which stands in relation to lisp as excel macros stand to ALGOL) will seem much less alien if you already use a real lisp.

If you do give it a try, use it on a virtual console where it feels more like a sane way to arrange an editor. Only when that makes sense try to use it under a window system, which will fight with it.

柏林苍穹下 2024-07-11 01:44:33

[免责声明:就我个人而言,我更喜欢 Vim。 免责声明 免责声明:请继续阅读。]

Vim 擅长小处:通过将运动和动作分开的概念并提供复杂重复的设施,您只需按几个简短的按键序列即可执行令人难以置信的强大编辑操作。 在正常的编辑过程中,您可以在 Vim 中轻松执行需要您在 Emacs 中编写脚本的操作。 此外,您使用的大部分功能都是开箱即用的,因此即使您有大量的 .vimrc 自定义,您也有可能能够高效地使用任何 Vim安装。

Emacs 在大方面表现出色:通过将其所有 UI 概念直接映射到 Elisp 中的基本构造和概念,可以非常轻松地全局引入针对特定类型文件或环境的功能,使 Emacs 类似于基于文本且更加结构化Excel 的可编程形式。 这假设您将花费大量时间根据个人需求和偏好定制环境。 当然,Emacs 确实尽力让您可以轻松地在一个环境中完成您可能想做的所有事情。

最终,两者都不优越。 它们提供不同的风格,根据您的喜好,其中一种会更适合您的个人需求和思维方式。 当然,了解两者(以及更多编辑)总是有帮助的。 但这种或那种方式并不会让你的工作效率明显提高。

[Disclaimer: personally, I prefer Vim. Disclaimer disclaimer: read on.]

Vim excels in the small: by making motion and action separate concepts and providing facilities for complex repeats, you can perform incredibly powerful editing operations in just a short sequence of keystrokes. You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs. Also, most of the power you use comes out of the box, so even if you have extensive .vimrc customisations, chances are you will be able to work productively with any Vim installation.

Emacs excels in the large: by mapping all of its UI concepts directly to basic constructs and concepts in Elisp, it becomes very easy to globally introduce features for specific kinds of files or circumstances, making Emacs something like a text-based and much more structuredly programmable form of Excel. This presumes that you are going to spend a lot of time customising your environment for personal needs and preferences. Of course, Emacs does do its best to make it easy to stay inside that one environment for everything and anything you may want to do.

Ultimately, neither is superior. They offer different styles, and depending on your proclivities, one or the other will suit your personal needs and way of thinking better. It is always helpful to know both (plus more editors), of course. But you aren’t going to be appreciably more productive this way or that.

德意的啸 2024-07-11 01:44:33

根据您的编码方式,您可能会看到工作效率的提高。 作为背景,我也是一名长期的 vim 用户,但我大约 2 年前学习了 emacs,现在可以互换使用它们。

促使我真正学习 emacs 的是它的有用功能,可以一次打开大量文件,并在它们之间轻松切换。 我正在介绍一个添加并涉及大量类的功能。 (这是 C++,所以每个类通常有两个文件。)由于我仍在巩固界面,因此当我意识到需要更改另一个文件时,我通常会在更新一个文件的过程中。

使用 gvim,最简单的方法是为每个文件打开一个新窗口,但这开始变得笨拙。 不过,使用 Emacs,在同一窗口中打开新文件(Ctrl-x、Ctrl-f)非常简单。 一旦 Emacs 打开了一个文件,就可以很容易地在打开的缓冲区之间来回切换(Ctrl-x、Ctrl-b)。

更进一步,一个 emacs 会话可能会打开许多​​窗口,因此除了垂直分割窗口之外,我还可以决定在不中断文件工作的情况下打开它旁边的另一个窗口,让我有效地并行工作 -侧,同时仍然保持每个窗口的默认 80 字符宽度。

我仍然发现 vim 中的一些操作更容易(例如块选择模式、简单宏记录、差异模式),而 Emacs 中的操作更简单(行对齐、文件/缓冲区管理、窗口/屏幕管理)。 因此,我发现自己在两者之间交替使用(有时同时使用两者),具体取决于我预期的编辑任务。

如果您仍然不确定,我建议您尝试一下。 通读 Emacs 教程,然后用一个早上或一天的时间来编写代码,严重依赖帮助。 如果您仍然不喜欢所看到的内容,请继续使用 vim。 无论编辑器带来什么,您对该工具的熟悉程度和知识将是迄今为止影响您工作效率的最重要因素。

Depending on how you code, you may see a productivity increase. For background, I'm also a long-time vim user, but I learned emacs about 2 years ago, and now use them interchangeably.

What drove me to the point of actually learning emacs was its useful ability to have a large number of files open at once, and to easily switch between them. I was in the middle of introducing a feature that added and touched a large number of classes. (This was C++, so there were typically two files per class.) Since I was still firming up the interface, I would typically be in the middle of updating one file when I would realize that I needed to change another.

With gvim, it was easiest to open a new window for each file, which was starting to get unwieldy. With Emacs, though, it was simple to open a new file in the same window (Ctrl-x, Ctrl-f). Once Emacs has a file open, it's very easy to switch back and forth between the open buffers (Ctrl-x, Ctrl-b).

Taking that one step further, a single emacs session may open many windows, so in addition to splitting the window vertically, I could decide, without interrupting work on a file, to open another next to it, letting me effectively work side-by-side while still keeping each window at the default 80-character width.

There are still some things that I find easier in vim (e.g. block-select mode, simple macro recording, diff mode), and things that are easier in Emacs (line alignment, file/buffer management, window/screen management). Therefore, I find myself alternating between the two (and sometimes using both simultaneously), depending the editing task I anticipate.

If you're still unsure, I'd suggest trying it out. Run through the Emacs tutorial and then use it to write code for a morning or a day, leaning heavily on the help. If you still don't like what you see, stay with vim. Regardless of what the editor brings to the table, your familiarity and knowledge of the tool will by far be the most important factor in your productivity.

↘人皮目录ツ 2024-07-11 01:44:33

vi 是一把菜刀。

vim 是一把非常漂亮、锋利、平衡的厨师刀。

Emacs 是一把光剑。

大多数时候,我的工作需要我切蔬菜。 有时,我必须对抗一整支机器人军队。

我使用 Emacs 已有 20 年了。 我现在正在 Emacs 中输入一个名为 "It's All Text"< 的小部件/a> 让我可以在 Firefox 的文本框中输入和输出文本。 我在 Emacs 中运行得非常快。 如果没有它,我的工作效率就会大大降低。

这是很有争议的,但我也认为学习 Emacs 可以教会你大量关于编程的知识。

vi is a kitchen knife.

vim is a really nice, sharp, balanced chef's knife.

Emacs is a light saber.

Most of the time, my job requires me to chop vegetables. Occasionally, I have to take on an entire army of robots.

I've been using Emacs for 20 years. I'm typing in Emacs right now with a widget called "It's All Text" that lets me suck text in and out of text boxes in Firefox. I can go really fast in Emacs. I am significantly less productive without it.

This is highly debateable, but I also think that learning Emacs can teach you a surprising amount about programming.

萌︼了一个春 2024-07-11 01:44:33

与 vi 相比,我更喜欢 emacs,但我对两者都很满意。

您可以在 emacs 中执行一些操作,使其比 vi 更强大,但并非所有操作都与编程相关。 (你可以在 vi 中发送电子邮件或阅读新闻吗?不,但谁在乎呢?)如果你熟悉 lisp(我不熟悉),你也许可以编写附加组件、模式和其他东西来让你的生活更美好更容易,但这很可能是语法着色和大括号匹配之类的养眼之事。

我现在就停止胡言乱语了。 使用 emacs 会提高您的工作效率吗? 否。

更新:请参阅下面我的评论。 自从我发布这篇文章以来,我发现使用 emacs 比使用 vi 更高效。

I prefer emacs to vi, but I'm comfortable in both.

There are some things that you can do in emacs that make it more powerful than vi, but not all of them are even programming-related. (Can you send email or read news from within vi? No, but who cares?) If you're comfortable with lisp (I'm not), you might be able to write add-ons and modes and stuff to make your life easier, but that's just likely to be syntax colouring and brace matching and eye candy like that.

I will stop rambling now. Will your productivity increase using emacs? No.

Update: See my comment below. Since I posted this, I have come across ways that using emacs has made me more productive than using vi.

别闹i 2024-07-11 01:44:33

我不想要一场圣战,但请用是/否的答案回答一个高度主观的问题。

是的,由于功能强大,您可能会看到生产力的提高。

不,您不会看到生产力的提高,因为 emacs 中使用的模式和隐喻可能与您的大脑不一致。

I don't want a holy war, but please answer a highly subjective question with a yes/no answer.

Yes, you may see a productivity increase because of the powerful functionality.

No, you will not see a productivity increase because the patterns and metaphors used in emacs may not align with you brain.

誰認得朕 2024-07-11 01:44:33

您的问题的简短答案是“是”。 下面有更多详细信息。

从大约 1980 年到 1991 年,我几乎只使用 vi。我唯一一次不使用 vi 是当我处理 Unix 的最小安装时,它太小而无法包含 vi,所以我不得不回到 ed,这是原始 vi 构建于其之上的编辑功能的最小子集。

大约从 1985 年开始,我工作过的其他程序员就不断地称赞 emacs。 但每次我尝试学习它时,我都不会走得太远。 我会花一个小时浏览 emacs turorial (Ch t),最后我所知道的就是如何插入和修改文本以及如何在屏幕上移动。 我使用 vi 可以做的事情比我在那一小时内使用 emacs 学到的要多得多,所以我无法进行切换。 三个月后,我会抽出时间再花一个小时,最终我会浏览同样的材料。 Emacs 有一个大写“L”的学习曲线。 直到我正在做一份其他人都使用 emacs 的合同时,我最终决定需要一次花一个多小时来学习它。 在花了一天多的时间除了完成教程和附带的文档之外什么也没做之后,我终于达到了可以用 emacs 做一些 vi 做不到的事情的地步。 从那时起,我就再也不想回去了。 我仍然可以在睡觉时输入 vi 命令,但我可以使用 emacs 做更多的事情。

请注意,我正在比较 emacs 和 vi,而不是 vim。 我从来没有了解过 vim 为 vi 添加的扩展,很可能其中很多功能都是从 emacs 复制的。 如果是这样,并且您已经精通 vim,那么 emacs 对您来说可能没有那么多优势。

我在 emacs 中一直依赖的东西包括:

  1. 当您使用 emacs 时,所有内容都被视为文本。 这意味着您可以使用几乎相同的命令来操作任何缓冲区中的任何数据。 如果缓冲区处于某些标准命令不可用的模式,您可以将文本复制到在基本模式下运行的另一个缓冲区并在那里使用标准命令。

  2. Emacs 提供了可在字符单元终端上显示的多“窗口”环境。 在位图图形和真实窗口出现之前,emacs 的编写是为了仅使用 ascii 字符和光标定位来模拟类似窗口的行为。 您可能会想,“那是古老的历史。为什么今天还有人关心它呢?” 我仍然每天使用该功能。 我使用一家允许我进行 SSH 访问的网络托管公司。 这样我就可以通过 Internet 登录 Linux 主机并运行 shell 命令。 虽然这非常强大,但更强大的是能够使用 emacs 将我的终端模拟器划分为“窗口”,在其中几个“窗口”中运行 shell,在其他窗口中编辑文件,以及在其他“窗口”中查看和编辑目录。窗口”。

    实际上,当我在上一段中说“窗口”时,我真正的意思是“缓冲区”。 Emacs 的 Windows 字符单元模拟是一种划分屏幕空间的方法。 emacs 缓冲区与当前可能显示或可能不显示的内容(文件、bash shell、目录、与文件无关的任意文本等)相关联。 要查看缓冲区中的内容,您可以选择一个窗口并告诉它您想要查看哪个缓冲区。 因此,您可以处理的事情远远多于屏幕上可显示的空间。 它大致类似于您在现代位图图形 GUI 中图标化/取消图标化窗口时所做的操作。

  3. 我已经提到过,您可以在 emacs 缓冲区内运行 shell。 您可以根据需要让任意多个缓冲区运行 shell。 您可以在 shell 缓冲区和文本文件之间来回复制和粘贴文本,或者使用与复制文本或比较两个不同文本之间的文本完全相同的击键序列来比较 shell 缓冲区和文本文件之间的部分文本。文本文件。 实际上,这对于大多数类型的缓冲区都是如此,而不仅仅是 shell 缓冲区和与文件关联的缓冲区。

  4. 当你使用 emacs 命令打开一个文件,但你选择的实际上是一个目录时,缓冲区会以 dired(目录编辑器)模式运行。 在此模式下,单击一次按键即可打开光标当前指向的任何内容,无论是文件还是子目录。 Dired 模式下的缓冲区是一个文件管理器 - 一个面向字符单元终端的类似于 Mac 或 Windows 资源管理器上的 Finder。

  5. 我几乎经常使用的 emacs 功能之一是“compare-windows”。 与 Eclipse 内置的命令行“diff”或 GUI 比较工具相比,我更喜欢它。 Diff 或 Eclipse 会比较整个文件,并显示哪些行不同。 但是,当两条不同的线看起来非常相似时会发生什么? 考虑以下因素:

    这条线和另一条线有什么区别?

    这条线和另一条线有什么区别?

    您需要多长时间才能发现差异? (提示:ASCII 和 Unicode 撇号看起来非常相似。)

    与 diff 和 Eclipse 不同,它们仅显示不同的行,emacs 的“compare-windows”功能是交互式的。 将光标放置在两个并排窗口中每个窗口内容相同的位置。 运行“compare-windows”,每个窗口中的光标将移动到第一个不同的字符。 将其中一个窗口中的光标重新定位到与另一个窗口相同的位置,然后重新运行“compare-windows”以查找下一个差异。 这使得比较文件的子部分变得容易。

    我经常使用“compare-windows”的另一件事是比较校验和。 许多软件项目在页面上分发应用程序的 tarball,其中还包含 tarball 的 MD5 哈希值。 那么,如何将分发页面上的 MD5 哈希值与从下载文件计算出的 MD5 哈希值进行比较。 Emacs 使这变得微不足道。

    首先将 MD5 哈希值从网页复制到新的 emacs 缓冲区中。 然后,下载 .tar.gz 文件后,运行:

    md5sum 下载文件.tar.gz

    在 shell 缓冲区中。 当这两个缓冲区显示在并排的 emacs 窗口中时,将光标定位在每个窗口中校验和的开头并运行“compare-windows”。 如果它们相同,每个窗口中的光标将位于每个校验和的末尾。

  6. 在上一点中,我给出了在以下行上运行“compare-windows”的示例:

    这条线和另一条线有什么区别?

    这条线和另一条线有什么区别?

    “compare-windows”将使光标定位在每行的撇号上。 所以,现在您知道哪些字符不同了。 但他们是什么角色呢? 输入两个按键命令 CTRL-x =,emacs 将显示该字符、其八进制、十进制和十六进制的 ASCII 值、距文件开头的字符偏移量以及距行首的字符偏移量。 由于 ASCII 是 7 位编码,因此所有 ASCII 字符的高位都被关闭。 一旦您看到第一个撇号的值为 0x27,第二个撇号为 0x92,很明显第一个撇号在 ASCII 字符集中,而第二个撇号则不是。

  7. Emacs 是最早的 IDE 之一,也许是第一个。 它具有针对特定语言的模式。 我发现它们可以很方便地在我的代码上施加一致的缩进,以使其更具可读性。 还有用于编译和调试代码的内置功能。 我不太使用编译功能,因为当我为 C 等编译语言编写代码时,我习惯在 shell 提示符下执行此操作。 对于 C 和 C++ 来说,调试功能非常好。 它将 gdb 与编辑器集成在一起,您可以获得与 Eclipse 中现在的调试功能几乎相同的功能,但不会像现代基于 GUI 的 IDE 那样浪费屏幕空间。 从理论上讲,调试器集成应该很容易使其适用于几乎任何其他语言,但我还没有检查它现在可以与哪些其他语言一起使用。

  8. Emacs 允许您通过告诉它何时开始记住您正在输入的内容以及何时停止来创建宏。 这对于您经常执行的任务来说非常强大。

  9. 如果您了解 Lisp,Emacs 可以无限扩展。 但即使我从未学过 Emacs Lisp,我仍然发现 Emacs 是我用过的最强大的工具之一。

  10. Emacs 键绑定。 我将是第一个承认 Emacs 键绑定很糟糕的人。 但它比我使用过的任何其他工具都强大得多,因此我愿意忍受键绑定。

  11. 多年前,Emacs 的作者 Richard Stallman(也是 GPL 的创始人、GNU 项目的创始人和 FSF 的创始人)以一种幽默的方式讽刺了那些将 vi 与 emacs 视为圣战的人。 他发明了 Emacs 教会的角色“Saint IGNUcius”。 以此为幌子,Stallman 评论道:“有时人们会问我,在 Emacs 教会中使用其他文本编辑器 vi 是否是一种罪过。嗯,确实,vi vi vi 是野兽编辑器,但使用的是免费版本vi 不是罪孽,而是一种忏悔。” (参见http://stallman.org/saint.html。还有一张他的可爱照片,但是因为我是 StackOverflow 的新手,所以它不允许我发布多个 URL。所以请转到同一个域,但获取文件 saintignucius.jpg)

The short answer to your question is, "YES". More detail below.

I used vi almost exclusively from about 1980 to 1991. The only time I didn't use vi was when I was dealing with a minimal install of Unix that was too small to include vi, so I had to drop back to ed which is the minimal subset of editing functionality that the original vi was built on top of.

From about 1985 on, other programmers where I worked were constantly singing the praises of emacs. But every time I'd try to learn it I wouldn't get very far. I'd spend an hour going through the emacs turorial (C-h t) and by the end of it all I'd know would be how to insert and modify text and move around the screen. I could do so much more with vi than what I'd learned in that hour with emacs that I couldn't make the switch. Three months later I'd find time to spend another hour and I'd end up going through the same material. Emacs has a Learning Curve with a capital "L". It wasn't until I was doing a contract where everybody else used emacs that I eventually decided I needed to devote more than an hour at a time to learning it. After spending a little over a day doing nothing but working through the tutorial and the included documentation, I finally got to the point where I could do things with emacs that I couldn't with vi. From then on, I've never wanted to go back. I can still type vi commands in my sleep, but I can do so much more with emacs.

Understand that I'm comparing emacs and vi, not vim. I've never learned the extensions that vim has added to vi, and it's likely that many of them are features copied from emacs. If so, and if you're already proficient with vim, emacs may not hold as many advantages for you.

Among the things I depend on all the time in emacs are:

  1. When you use emacs, everything's treated as text. This means that you can manipulate any data in any buffer with pretty much the same commands. And in cases where a buffer's in a mode where some of the standard commands are unavailable, you can copy text to another buffer running in fundamental mode and use the standard commands there.

  2. Emacs provides a multi-"window" environment displayable in on a character-cell terminal. In the days before bitmapped graphics and real windows, emacs was written to simulate window-like behavior using nothing but ascii characters and cursor positioning. You're probably thinking, "That's ancient history. Why should anyone care about that today?" I still use that capability every day. I use a webhosting company that allows me SSH access. So I can log into a Linux host across the Internet and run shell commands. While that's pretty powerful, it's far more powerful to be able to divide my terminal emulator up into "windows" using emacs, run shells in several of those "windows", edit files in other windows, and view and edit directories in still other "windows".

    Actually, when I said "window" in the previous paragraph, I really meant "buffer". Emacs' character cell emulation of windows is a way of dividing up the screen real-estate. An emacs buffer is associated with content (a file, a bash shell, a directory, arbitrary text not associated with a file, etc.) which may or may not currently be displayed. To view what's in a buffer, you pick a window and tell it what buffer you want to see. So you can be working on way more things than you have space on the screen to display. It's roughly analogous to what you do in a modern bitmapped-graphics GUI when you iconify/de-iconify a window.

  3. I've already alluded to the fact that you can run a shell inside an emacs buffer. You can have as many buffers running shells as you like. You can copy and paste text back and forth between a shell buffer and a text file, or compare a portion of text between a shell buffer and a text file using the exact same keystroke sequences you would use to copy text or compare text between two different text files. Actually, this is true for most types of buffers, not just shell buffers and buffers associated with files.

  4. When you use emacs' command to open a file, but what you've selected is actually a directory, the buffer runs in dired (directory editor) mode. In this mode, a single keystroke will open whatever the cursor's currently pointing at, be it a file or subdirectory. A buffer in dired mode is a file manager - a character-cell terminal oriented analog to Finder on the Mac or Windows Explorer.

  5. One of the emacs functions I use almost constantly is "compare-windows". I greatly prefer this to command-line "diff" or GUI comparison tools like what's built in to Eclipse. Diff or Eclipse compare entire files, and show you which lines differ. But what happens when you have two different lines that look very similar? Consider the following:

    What's the difference between this line and the other?

    What’s the difference between this line and the other?

    How long would it take you spot the difference? (Hint: ASCII and Unicode apostrophe look pretty much alike.)

    Unlike diff and Eclipse, which just show the lines that differ, emacs' "compare-windows" function is interactive. You position the cursor in each of two side-by-side windows at a point where the window contents are the same. Run "compare-windows", and the cursor in each window will move to the first character that differs. Reposition the cursor in one of the windows to the point where it's the same as the other window, and rerun "compare-windows" to find the next difference. This makes it easy to compare subportions of files.

    Another thing I regularly use "compare-windows" for is comparing checksums. Many software projects distribute a tarball of the application on a page that also includes an MD5 hash of the tarball. So, how do you compare the MD5 hash on the distribution page with the MD5 hash computed from the downloaded file. Emacs makes this trivial.

    First copy the MD5 hash from the webpage into a new emacs buffer. Then, after downloading the .tar.gz file, run:

    md5sum downloadedfile.tar.gz

    in a shell buffer. With those two buffers displayed in side-by-side emacs windows, position the cursor in each window at the beginning of the checksum and run "compare-windows". If they're the same, the cursor in each window will be positioned at the end of each checksum.

  6. In the previous point, I gave the example of running "compare-windows" on the lines:

    What's the difference between this line and the other?

    What’s the difference between this line and the other?

    "compare-windows" will leave the cursor positioned on the apostrophe in each line. So, now you know which characters differ. But what characters are they? Type the two keystroke command CTRL-x =, and emacs will display the character, its ascii value in octal, decimal, and hex, the character offset from the beginning of the file, and the character offset from the beginning of the line. Since ASCII is a 7-bit encoding, all ASCII characters have their high-order bit turned off. Once you see that the value of the first apostrophe is 0x27 and the second one is 0x92, it's obvious that the first one is in the ASCII character set and the second one is not.

  7. Emacs was one of the first IDEs, perhaps the very first one. It has modes for specific languages. I find them handy for imposing consistent indentation on my code to make it more readable. There's also built-in functionality for compiling and debugging code. I don't use the compiling functionality that much because when I was writing for a compiled language like C, I was used to doing that at a shell prompt. The debugging functionality was very nice for C and C++. It integrated gdb with the editor in such a way that you got pretty much the same functionality as the debugging capabilities now in Eclipse, but didn't waste screen real-estate the way modern GUI-based IDEs do. Theoretically the debugger integration should be easy to make it apply to virtually any other language, but I haven't checked to see what other languages it works with nowadays.

  8. Emacs allows you to create macros by telling it when to start remembering what you're typing and when to stop. This is extremely powerful for tasks you frequently do.

  9. Emacs is infinitely extensible if you know Lisp. But even though I've never learned Emacs Lisp, I still find Emacs one of the most powerful tools I've ever used.

  10. Emacs key-bindings. I'll be the first one to admit that Emacs key-bindings suck. But it's so much more powerful than anything else I've used, that I'm willing to put up with the key-bindings.

  11. In a humorous vein, years ago Emacs' author Richard Stallman (also originator of the GPL, founder of the GNU project and founder of FSF) lampooned those who treat vi vs. emacs as a holy war. He invented the character "Saint IGNUcius" of the Church of Emacs. In that guise, Stallman commented, "Sometimes people ask me whether it is a sin in the Church of Emacs to use the other text editor vi. Well, it's true that vi vi vi is the editor of the beast, but using a free version of vi is not a sin, it's a penance." (See http://stallman.org/saint.html. There's also a cute photo of him, but since I'm new to StackOverflow, it won't let me post more than one URL. So go to the same domain, but fetch the file saintignucius.jpg)

抠脚大汉 2024-07-11 01:44:33

我使用 Vim 已经有 10 年了,直到 2 年前才开始深入研究 Emacs。 对于我的生产力曲线如何随着时间的推移而变化,我有着相当清晰的记忆。

我的观点都是有条件的,YMMV取决于你的优势和经验。

如果您使用 Unix 和命令行足够长的时间,并且熟悉 Ca、Ce、Cn、Cp、Ck、Cy 等在 shell 上的功能,那么很快就会过渡到使用这些相同的绑定(默认值)在 Emacs 中。 我最近发现 XCode 也使用这些绑定。

如果您对始终运行的编辑器感到满意,管理缓冲区(就像您对浏览器选项卡一样)并因此生活在应用程序中(就像您在浏览器中使用 Web2.0 应用程序一样),那么 Emacs 可能会立即显示出生产力的提高。

如果您通常在许多相关文件的项目中工作,那么这种持久性在维护该缓冲区的上下文方面会带来一些额外的好处。 每个缓冲区都与其打开的文件相关,以便您可以方便地使用该项目的各种生产力提升工具(例如 grep-find、eshell、run-python 和 slime)。 这与文本完成、yasnippets 等相结合,开始看起来像 IDE 的一小部分,尽管它们是临时的并且根据您的配置进行了高度个性化。 这与 ECB 等更文明的类似 Emacs IDE 的服务不同。

我的工作效率最初受到了影响,因为我在第一周左右不断地输入“jjjkkk”Esc-Esc-Esc-Esc。 接下来的一周,我开始小心翼翼地使用正确的导航键。 然后我发现了配置文件...老实说,如果我有 Emacs Starter Kit 从一开始,我会说我的生产力在第三到第四周慢慢恢复到同等水平,但我确实陷入了配置文件的困境。 不过,我的一位同事刚刚从 vim 过渡到 emacs,他刚刚拿到了入门工具包,并且正在上路。 第一周,他看起来很舒服,并享受着所有令人惊讶的好处(这种感觉可能会持续十年)。

最后,如果您犯了错误,您将立即从循环终止/猛拉环和撤消环中获得生产力(和信心)。 我个人也很喜欢特定区域的撤销。

我的简短回答是,是的,花 3-4 周的时间来学习 Emacs 是值得的,这对生产力的影响正在逐渐减少。 即使您决定更喜欢使用简化的 Unix 实用程序组合而不是 Emacs 进行开发,您也将从中获得广泛适用于编辑器之外的教育。

I used Vim for 10 years leading up to delving into Emacs 2 years ago. I have a reasonably fresh recollection of just how my productivity curve modified over time.

My points are all conditional, YMMV depending on your strengths and experience.

If you have used Unix and the command line long enough that you are familiar with C-a, C-e, C-n, C-p, C-k, C-y, etc as they function on the shell, it will not take long to transition to using those same bindings (the defaults) in Emacs. I recently discovered that XCode uses these bindings as well.

If you are comfortable with an always running editor, tending buffers (like you would browser tabs) and thus living in the application (like you would with Web2.0 apps in the browser), Emacs will likely show immediate productivity enhancements.

If you generally work in projects of many related files, this persistence pays some added benefits in maintaining context to that buffer. Each buffer is contexted at its open file allowing for convenient use of various productivity boosting tools for your that project (like grep-find, eshell, run-python and slime). This coupled with text completion, yasnippets, etc start to look a tiny fraction like an IDE although ad-hoc and heavily individualized by your configuration. This is apart from more civilized Emacs IDE-like services like ECB.

My productivity took a hit initially as I typed "jjjkkk" constantly Esc-Esc-Esc-Esc for the first week or so. The following week I cautiously started using the right navigation keys. Then I discovered the configuration file... Honestly, if I had had Emacs Starter Kit from the start, I would have said my productivity slowly worked back to parity over the 3rd-4th week but I did go down the config file rabbit hole. A co-worker of mine, though, has just transitioned from vim to emacs and he just grabbed the Starter Kit and he is on his way. First week in and he seems comfortable and enjoying all the surprise benefits (that sensation will probably last a decade).

Finally, if you make mistakes you will immediately gain productivity (and confidence) from the circular kill/yank-ring and undo-ring. I am also personally a fan of region specific undos.

My short answer is Yes it is worth taking 3-4 weeks of a diminishing productivity-hit to learn Emacs. Even if you decide you prefer a streamlined unix utility combo over Emacs for development you will derive from it an education widely applicable beyond the editor.

随风而去 2024-07-11 01:44:33

Emacs 文档是一座森林。 当我意识到 Vim 的文档是多么有组织性,以及许多功能是多么令人共鸣时,我从 Emacs 转向了 Vim。 我不知道 Emacs 专家的道路是什么,但我会警告你,学习做任何有用的事情都需要很长时间,并且不会让你在 nethack 方面变得更好。 坚持使用 Vim。

Textmate 是适用于 Mac 的更好的 Emacs,但在 Solaris 上这对您没有帮助。 Eclipse 很酷,并且有很多插件。

Emacs documentation is a forest. I came from Emacs to Vim when I realized how organized Vim's documentation is, and how chordable many of the features are. I don't know what lies down the path of an Emacs expert, but I will warn you that learning to do anything useful in it takes a long time, and won't make you any better at nethack. Stick with Vim.

Textmate is a better Emacs for Macs, though that won't help you with Solaris. Eclipse is kind of cool, and has a lot of plugins.

人生百味 2024-07-11 01:44:33

如果您愿意学习并自定义 Emacs 以满足您的需求,Emacs 将提高工作效率。 大多数人都不是。 为了提高您的工作效率,您必须使用该工具进行不仅仅是简单的编辑 - 大多数人永远不会超越简单的编辑。

这是一个快速测试:您是否自定义了窗口管理器以使您的环境更加高效(根据您的需求量身定制)? 如果“否”,那么您可能不会通过学习 emacs 获得投资回报。

话虽这么说,如果您正在开发 Java,Eclipse 是标准答案,所以您的问题毫无意义。

Emacs will provide a productivity gain if you're willing to learn and customize it to fit your needs. Most people are not. To increase your productivity you must use the tool for more than simple editing - most people never progress past simple editing.

Here's a quick test: have you customized your window manager to make your environment more efficient (tailored to fit your needs)? If 'no' then likely you will not get the ROI by learning emacs.

That being said, if you're developing Java, Eclipse is the standard answer, so your question is pretty moot.

爱给你人给你 2024-07-11 01:44:33

我曾两次尝试学习 Emacs。 它不适合我的大脑工作方式,所以我不使用它。

Emacs(或 vim)并不比 vim(或 Emacs)好太多。 两者都有很多选项可供添加,使他们能够做出令人惊奇的事情。 我毫不怀疑,任何你能在 Emacs 中完成的事情,你也可以在 Vim 中完成,只是不标准。

尝试一下 Emacs。 看看是否更适合。 这是一个不会输的局面。

Twice I've tried to learn Emacs. It just doesn't fit how my brain works, and so I don't use it.

Emacs (or vim) is not significantly better than vim (or Emacs). Both have many options to add to them that allow them to do amazing things. I have no doubt that anything you can get done in Emacs you can also get done in Vim, just not standard.

Try Emacs. See if it fits better. It's a no-lose situation.

一抹微笑 2024-07-11 01:44:33

我对我的 Vim 非常满意,但是当我听说 org-mode 后,我就开始了学习 Emacs。
org-mode 可能是学习 Emacs 的重要原因之一。

I was very happy with my Vim, but once I heard of org-mode, I started learning Emacs.
org-mode could be one strong reason to learn Emacs.

浪漫人生路 2024-07-11 01:44:33

我喜欢 emacs 并且每天都使用它。

也就是说,我不认为学习它的成本可以通过未来生产力的提高来弥补。

如果您正在编写 Java 程序,那么您需要一个好的 IDE。 Emacs 朝着成为一体的目标迈出了一大步,但让我们面对现实吧,IDEA 等人轻而易举地击败了它。 (emacs 可能启发了很多这样的 IDE,但那是另一个故事了)。

I love emacs and use it every day.

That said, I don't think the cost of learning it will be recouped by productivity gains down the road.

If you're programming Java, you need a good IDE. Emacs goes a fair way towards being one, but let's face it, IDEA et al beat it hands down. (emacs probably inspired a lot of those IDEs, but that's another story).

倾城°AllureLove 2024-07-11 01:44:33

我同意 Alan Storm 的观点:“因为 Emacs 中使用的模式和隐喻可能与你的大脑不一致”

这是一个非常重要的因素。 不同的大脑对不同的界面有不同的适应能力。

我非常喜欢 Emacs 的一些主要且易于使用的功能,我将其视为生产力增强器:
1.“yank-pop”工具 - 每个剪切/复制都会保存到堆栈中,以便您以后可以选择要粘贴的内容(不知道 vi / Vim 是否有此功能,但大多数 Java IDE 没有)
2. Ctrl 键导航映射 - 这使您无需移开双手即可使用箭头键来导航文件。 (其他编辑器中的键绑定当然有帮助)
3. 几乎在所有平台上都可用(当然 vi/Vim 也是如此) - 无论是基于 GUI 还是基于文本(Java IDE 也可在大多数平台上使用,但仅在 GUI 模式下可用,并且体积大得多,需要单独安装而 Emacs 通常更广泛使用 - BSD / *nix / Linux / Mac 系统
4. 我更喜欢我的编辑器在我需要之前不要打扰 - Emacs 简洁的显示迫使我在打字之前思考。
5. Emacs 中的基本导航键是普遍可用的 - 在我的 Mac OS 上,我可以在终端、mac 邮件等中使用这些键。

最终,如果 Emacs 的理念吸引您,您将在额外的努力来学习它。 它会奖励你。

I agree with Alan Storm: "because the patterns and metaphors used in Emacs may not align with you brain"

This is a very important factor. Different brains adapt differently to different interfaces.

Some of the main - and easily available - features I really love Emacs for, and I count as productivity enhancers:
1. "yank-pop" facility - every cut/copy is saved into a stack so you can later choose which to paste (don't know if vi / Vim has this but most Java IDEs don't)
2. the Ctrl-key navigation mapping - this allows you to navigate your file without moving your hands off to use the arrow keys. (key-binding in other editors helps of course)
3. available on almost every platform (true of vi/Vim too of course) - whether GUI- or text-based (Java IDEs are available on most platforms too but only in GUI mode, and are significantly larger and need to be installed separately whereas Emacs is generally more widely available - BSD / *nix / Linux / Mac systems
4. I prefer my editor to stay out of the way until I need it - Emacs' spartan display forces me to think before I type.
5. The basic navigation keys in Emacs are kind of universally available - on my Mac OS, I can use these keys in terminal, mac mail, etc.

Ultimately, if Emacs' philosophy appeals to you, you will put in the extra effort to learn it. And it will reward you.

情话已封尘 2024-07-11 01:44:33

由于 vi/Vim 和 Emacs 在可以做什么或不能做什么方面非常接近,因此这两个编辑器的生产力来自于使用它们的经验。

在我看来,作为一名程序员,一旦开始使用 Emacs,你很快就会对它有一个大致的了解。 别人只能说这么多,你自己去尝试一下就知道了。

至于我,我两者都用。 这就像在战争中携带多种武器一样,在正确的情况下使用正确的武器。 ;)

Since vi/Vim and Emacs are pretty close in terms of what they can or cannot do, productivity with these two editors comes from experience in using it.

In my opinion, being a programmer it won't take you long to get the general idea about Emacs once you start using it. Others can only say so much, you got to try it out for yourself to know it.

As for me, I use both. It's like taking more than one weapon to a war, use the right one in the right circumstances. ;)

缺⑴份安定 2024-07-11 01:44:33

我喜欢Emacs,你可以根据你的需要来扩展它——在我看来,任何你能自己扩展的系统都是值得奖励的。

I like Emacs, you can extend it by your needs- in my eyes, any system which you can extend by yourself is award-worthy.

飘逸的'云 2024-07-11 01:44:33

我的工作效率真的会提高吗?

在最初的几天/几周,绝对不是。

当您每次想要编辑某些内容时都不必通读教程之后 - 当然..

Emacs 比 vim 更“强大”,它的脚本引擎更加灵活,并且有更多的脚本、模式等围绕 emacs 构建。

也就是说,事实恰恰相反.. 如果你花同样多的时间来提高你对 vim 的了解,你的工作效率也会一样高..

也许效率不高 - 我想说 vim 的编辑速度更快文件,emacs 更擅长做其他事情(同样,我个人会说像 flymake-mode 这样的事情,VCS 绑定比 vim 等价物使用起来更快)

Will my productivity really increase?

For the first few days/weeks, absolutely not.

After you stop having to read through the tutorial every time you want to edit something - sure..

Emacs is more "powerful" than vim, it's scripting engine is far more flexible, and there are far more scripts, modes and the likes built around emacs.

That said, the opposite is true.. If you spent the same amount of time improving your knowledge of vim, you'd could be just as productive..

Maybe not productive in the same way - I'd say vim is quicker for editing files, emacs is better at doing everything else (again, I would personally say things like flymake-mode, VCS bindings are such are quicker to use than the vim equivalent)

初熏 2024-07-11 01:44:33

学习 Emacs 的一个很好的理由是其他程序也使用 Emacs 键绑定。 例如,您可以在 bash 提示符下使用 Emacs 键绑定,或者使用 GNU readline 进行任何其他操作。 学习 Emacs 中的基本动作、单词/行删除以及撤消/重做和弦是很好的,这样您就可以在其他程序中使用它们。 即使您不再使用 Emacs,您的工作效率也会提高这些其他工具。

我了解 Vim 和 Emacs,Vim 更适合我的大脑和习惯。 但其他人对 Emacs 也有同样的看法。 除非你尝试,否则你永远不会知道自己的情况。 不需要花很长时间就能把 Emacs 学好,看看你是否会喜欢它。

One good reason to learn Emacs is because other programs use Emacs keybindings too. You can use Emacs keybindings at a bash prompt, for example, or anything else using GNU readline. It's good to learn the basic movement and word/line deletion and undo/redo chords in Emacs so that you can use them in other programs. Your productivity will increase in those other tools even if you never use Emacs again.

I know Vim and Emacs, and Vim fits my brain and my habits better. But other people claim the same about Emacs. You never know for yourself unless you try. It doesn't take that long to learn Emacs well enough to see whether you're going to like it.

岁月静好 2024-07-11 01:44:33

一般来说,emacs 比 vi 更强大。 你可以在 emacs 中做更多的事情。

Generally, emacs is more powerful than vi. You could do a lot more things in emacs.

眼眸 2024-07-11 01:44:33

如果您决定花时间对文本编辑器进行编程,您的工作效率将会提高。 在这两个编辑器中,emacs 提供了更好的框架或不断的定制。 如果您不对文本编辑器进行编程,则只需使用舒适的即可。

You're productivity will increase if you decide to put the time in to program your text editor. Of the two editors, emacs presents a better framework or constant customization. If you don't program your text editor, just stay with what is comfortable.

給妳壹絲溫柔 2024-07-11 01:44:33

你打字的速度有多快? 如果您喜欢狩猎和啄食,那么 emacs 不适合您。 如果你的速度很快,那么就不必一直抓着鼠标了。

How fast do you type? If you hunt and peck, then emacs is not for you. If your fast tho, it can help not having to grab your mouse all the time.

山色无中 2024-07-11 01:44:33

同样,不寻求宗教战争(但如果你觉得必须的话,请继续投票给我),为什么你觉得 vi 的唯一选择是 emacs? 是您开发的操作系统,还是只是您探索的选项?

Java 开发环境如今享有一些最好的 IDE(免费和付费),即使在代码编辑和重构支持方面不是最好的。IntelliJ IDEA 甚至还有一个 vi 插件,可以帮助您感觉更自在,例如(不确定 Eclipse 是否有类似的功能)。 虽然改变工具确实意味着一个学习曲线,但如果飞跃足够大,那么花在这上面的时间可能是值得的。

Along the same line of not looking for a religious war (but go ahead and downvote me if you feel you must), why do you feel that the only option to vi is emacs? Is it the OS you develop on, or just the options you explored?

The Java development landscape enjoys some of the best IDEs these days (both free and paid for), if not the best when it comes to code editing and refactoring support.IntelliJ IDEA even has a vi plugin that can help you feel more at home, for instance (not sure if something similar is available for Eclipse). While changing tools does imply a learning curve, the time spent doing it might be worth it if the leap is big enough.

汐鸠 2024-07-11 01:44:33

不(而且我都用过)。

No (and I've used both).

滥情稳全场 2024-07-11 01:44:33

vim 和 emacs,它们是最有能力的编辑器,并且已经存在很长一段时间了。
如果您非常了解其中一个,我怀疑您会在此过程中获得那么多...

但是,研究一下可用的插件始终是一个好主意
几个新插件可以为生产力带来奇迹。

/约翰

vim and emacs, they are THE most capable editors and have been for quite some time.
If you know one really well, I doubt that you will gain that much in the process...

However, it is always a good idea to look into what plugin that are available since
a couple of new plugins can do wonders for the productivity.

/Johan

落日海湾 2024-07-11 01:44:33

我想进一步研究 emacs,但我就是不能长时间使用它; 我的手很痛。 我做错了什么可怕的事情吗?

I want to look into emacs further, but I just can't use it for long stretches of time; it hurts my hands. Am I doing something horribly wrong?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文