Vim / Emacs cung cấp những lợi ích cụ thể nào về năng suất so với trình soạn thảo văn bản GUI?

Điều này không có nghĩa là troll hay flamebait hay bất cứ thứ gì tương tự. Tôi đã sử dụng Vim làm trình chỉnh sửa giao diện điều khiển mà tôi lựa chọn trong vài tháng nay (để chỉnh sửa các tệp cấu hình trong khi ở trong thiết bị đầu cuối của tôi), nhưng tôi không nghĩ rằng mình có thể chịu đựng được công việc viết ứng dụng web bình thường hàng ngày của mình , mà tôi thực hiện với trình soạn thảo văn bản GUI (cái này không quan trọng).

Tôi cảm thấy như trình soạn thảo văn bản GUI của tôi có thể làm mọi thứ tôi cần cho công việc của mình. Nó có một tìm kiếm / thay thế tốt với lịch sử tự động hoàn thành cho cả hai. Nó có đánh dấu cú pháp, đánh số dòng, giao diện theo thẻ, dễ dàng sao chép và dán, v.v. Điều duy nhất mà trình soạn thảo hiện tại của tôi còn thiếu là đối sánh biểu thức chính quy, nhưng có rất nhiều trình soạn thảo văn bản GUI sẽ thực hiện tìm kiếm / thay thế regex.

Với những gì tôi vừa nói, Vim (hoặc thậm chí Emacs) có những lợi thế năng suất nào so với trình soạn thảo văn bản GUI ngoài thực tế là nó được cài đặt trên mọi máy tính. Tôi muốn các tác vụ cụ thể tốt hơn / nhanh hơn trên Vim / Emacs hoặc không thể thực hiện được với các trình soạn thảo văn bản GUI hiện có.

Đối với Vim:

• Vim có khả năng tích hợp tốt hơn với các công cụ khác (lệnh shell, script, trình biên dịch, hệ thống kiểm soát phiên bản, thẻ ctags, v.v.) so với hầu hết các trình soạn thảo. Ngay cả một cái gì đó đơn giản như :.!, chuyển đầu ra của lệnh vào bộ đệm, là điều bạn sẽ không tìm thấy trong hầu hết các trình soạn thảo GUI.

• Giao diện tab không đẹp bằng giao diện "cửa sổ" mà Vim / Emacs cung cấp cho bạn. Bạn có thể xem hai hoặc nhiều tệp cùng một lúc. Bạn càng có thể nhìn thấy nhiều trên màn hình, bạn càng giải phóng tâm trí của mình để suy nghĩ về vấn đề của mình hơn là thực hiện việc ghi chép các tên biến và chữ ký hàm.

• Đừng đánh giá thấp sức mạnh của biểu thức chính quy Vim. Có rất nhiều tiện ích mở rộng dành riêng cho Vim để khớp với một cột cụ thể, một dấu, vị trí con trỏ, các lớp ký tự nhất định (từ khóa, số nhận dạng), v.v.

• Tích hợp diffvà grep(độc lập với nền tảng nên bạn không cần tải xuống và tìm hiểu một công cụ mới mỗi khi thay đổi máy tính).

• Chế độ khối trực quan (để chỉnh sửa cột) là thứ mà nhiều biên tập viên thiếu, nhưng tôi không thể sống thiếu. Tôi đã gây sốc và kinh ngạc cho mọi người tại nơi làm việc chỉ bằng cách sử dụng này, thực hiện một số chỉnh sửa trong một vài lần nhấn phím mà nếu không ai đó sẽ dành mười phút để làm thủ công.

• Nhiều thanh ghi sao chép / dán. Khi bạn chỉ có một, bạn sẽ phải trải qua những thay đổi kỳ lạ để tránh làm tắc khay nhớ tạm. Bạn không cần phải làm vậy.

• Hệ thống hoàn tác / làm lại của Vim là vô địch. Nhập nội dung nào đó, hoàn tác, nhập nội dung khác và bạn vẫn có thể lấy lại nội dung đầu tiên đã nhập vì Vim sử dụng cây hoàn tác thay vì ngăn xếp. Trong hầu hết các chương trình khác, lịch sử của điều đầu tiên bạn nhập sẽ bị mất trong trường hợp này.

• Di chuyển xung quanh, sao chép, dán và xóa văn bản cực kỳ nhanh trong Vim. Các lệnh rất đơn giản, một lần nhấn phím và có thể kết hợp. Cộng tất cả các lần bạn thực hiện đánh dấu chuột cẩn thận, tốn công sức và Ctrl-X, sau đó thay thế tất cả chúng bằng a da((xóa một tập hợp các parens phù hợp và mọi thứ trong đó). Nó tiết kiệm thời gian hơn bạn nghĩ

• Những điều nhỏ nhặt, như *tìm kiếm từ dưới con trỏ, .lặp lại một lệnh, hoặc %chuyển giữa dấu ngoặc đơn mở và đóng. Có quá nhiều trong số này để liệt kê.

• Ngôn ngữ kịch bản tích hợp và khả năng ánh xạ phím và macro mạnh mẽ để trình chỉnh sửa có thể được mở rộng theo bất kỳ cách nào bạn cần. Rất nhiều tập lệnh đã được viết và có thể tải xuống.

Nếu bạn quan sát đủ kỹ, bạn sẽ thấy rằng ngay cả những tính năng mà các trình soạn thảo khác cũng có, Vim thường làm tốt hơn. Tất cả các trình soạn thảo đều có đánh dấu cú pháp, nhưng Vim có một tệp cú pháp cho hầu hết mọi định dạng tệp, thường có nhiều tùy chọn cấu hình và việc viết của riêng bạn rất đơn giản. Rất nhiều trình chỉnh sửa xử lý các mã hóa tệp khác nhau OK, nhưng Vim cung cấp cho bạn những cách rất cụ thể và dễ hiểu để thiết lập các mã hóa tệp và chuyển đổi giữa chúng. Điều đầu tiên khiến tôi ấn tượng về Vim là cách nó xử lý hoàn hảo các tùy chọn thụt lề tab / khoảng trắng và ngắt dòng Unix / DOS so với các trình soạn thảo khác mà tôi gặp vấn đề vào thời điểm đó.

Nhiều điểm trong số này áp dụng tốt cho Emacs (theo những cách khác nhau nhưng thường là mạnh như nhau).

(vim là chất độc của tôi; tôi chắc chắn rằng emacs mang lại lợi ích tương tự)

Lợi ích lớn nhất: không cần chạm vào chuột.

Đối với tôi, điều thú vị nhất là chuyển tới (hoặc ngay trước đó) một chữ cái cụ thể hoặc tổ hợp các chữ cái, hoặc quay lại, bằng một vài lần nhấn phím. Nhảy về phía trước theo cùng một điều kiện hai lần hoặc mười lần, chỉ đơn giản là việc đặt tiền tố cho nó bằng một số.

Nếu bạn phải lặp lại một chỉnh sửa, bạn chuyển tiếp đến vị trí đó (2-3 lần nhấn phím), sau đó nhấn "." để lặp lại lần chỉnh sửa cuối cùng. Nhảy tới (hoặc lùi) dễ dàng hơn - một lần nhấn phím - nếu đó là cùng một điều kiện tìm kiếm.

Về cơ bản, với thời gian thực hiện nhỏ, bạn có thể học mười hoặc hai mươi phím tắt, nghĩa là bạn không cần phải di chuyển bàn tay để lấy chuột. Điều đó mang lại cho bạn số lượng chuyển động / lệnh chỉnh sửa nhiều gấp ba hoặc bốn lần so với những gì bạn làm nếu bạn phải tiếp tục lấy chuột.

Sau một vài ngày, bạn sẽ thấy mình trở nên khó chịu mỗi khi bạn phải lấy chuột (hoặc nhấn <Down>15 lần), khi bạn đang trong trình chỉnh sửa GUI.

Tôi luôn tự hỏi tại sao ít người lại quan tâm đến Vim. Xem video hành động của người dùng Vim power:

https://www.youtube.com/watch?v=FcpQ7koECgk

Nếu biên tập viên hiện tại của bạn có thể làm những gì anh ta đang làm, thì không cần phải chuyển đổi! :)

Ngoài ra, hãy đọc http://www.viemu.com/a-why-vi-vim.html này

Sau khi xem video và đọc bài báo đó, tôi không còn lựa chọn nào khác ngoài việc bắt đầu học VIM. Đã gần một năm kể từ khi tôi chuyển sang VIM và tôi không thể tưởng tượng được việc sử dụng bất cứ thứ gì khác.

Tôi nghĩ rằng một trong những sức mạnh thực sự của một trình soạn thảo văn bản chuyên dụng là chỉnh sửa macro. Việc lặp lại là điều khó khăn đối với rất nhiều lập trình viên và việc viết các macro thích hợp có thể rất thú vị. Nếu bạn không thực hiện mọi thứ thông qua bàn phím, việc tạo macro sẽ yêu cầu thêm một bộ lệnh thay vì tận dụng những lệnh bạn đang sử dụng.

Tôi không đủ năng lực với các keybindings, nhưng nhìn chung tôi thích Emacs hơn. Lý do khiến các trình chỉnh sửa này có những tín đồ nhiệt thành như vậy là vì mô hình chỉnh sửa mà họ cung cấp mạnh hơn các hệ thống mới hơn, đó là lý do tại sao việc cung cấp "vi keybindings" hoặc "emacs keybindings" là không đủ, ngay cả khi bạn không sử dụng bất kỳ tính năng mở rộng nào hoặc các tùy chỉnh cho emacs hoặc vi.

Tôi sẽ chỉ nói về mô hình của Emacs vì tôi hiểu rõ nhất về nó. Mô hình phổ biến để soạn thảo văn bản ngày nay liên quan đến một bộ đệm văn bản, trong đó văn bản có thể được chèn, xóa, chọn và cắt / sao chép / dán vào khay nhớ tạm của hệ thống.

Tất nhiên, bộ đệm Emacs có thể hỗ trợ các hoạt động này. Cùng với việc theo dõi vị trí con trỏ cho từng cửa sổ mà chúng hiển thị trong đó, chúng cũng theo dõi các "dấu" được thực hiện trong chúng. Văn bản giữa "điểm" (vị trí con trỏ) và "dấu" được gọi là "vùng", và tương ứng với lựa chọn trong các trình soạn thảo chính thống.

Sự khác biệt là Emacs theo dõi một số vị trí cuối cùng mà dấu được đặt trong vòng đánh dấu và bạn có thể quay lại chúng bằng một lần nhấn phím (hoặc hai, tùy thuộc vào cấu hình của bạn). Tôi thấy điều này cực kỳ hữu ích, đặc biệt là vì rất nhiều lệnh Emacs thay đổi vị trí của bạn trong bộ đệm đã đặt dấu tại vị trí cũ của bạn. Một ví dụ là khi tôi đang chỉnh sửa mô-đun Python và cần thêm câu lệnh nhập vào đầu tệp. Tổ hợp phím để đi đến đầu bộ đệm (Alt- <) đặt dấu. Tôi thêm câu lệnh nhập. Tôi nhấn Ctrl-u Ctrl-Space và tôi đã quay lại nơi bắt đầu. Tôi có thể tiếp tục làm điều này để quay trở lại các vị trí cũ. (Có lẽ tôi cần chọn một số văn bản trong khi thêm câu lệnh nhập đó.)

Sự khác biệt khác (và nổi tiếng hơn) của Emacs là vòng giết. Hầu hết các tổ hợp phím để xóa văn bản khỏi bộ đệm lưu văn bản vào vòng ngắt, sau đó có thể được gọi lại bằng lệnh "yank" (Ctrl-y). Tính năng cần thiết là các lệnh yank tiếp theo lấy ra văn bản bị giết cũ hơn. Vì vậy, bạn có thể hủy một số phần văn bản liên tiếp, sau đó truy xuất chúng theo thứ tự. Bạn cũng có thể chuyển qua vòng tiêu diệt bằng Alt-y sau khi giật, xóa văn bản đã truy xuất và chèn mục nhập tiếp theo vào vòng.

Emacs có những tính năng này vào năm 1978. Hệ thống chính khác duy nhất áp dụng chúng ở bất kỳ mức độ nào là NeXTStep (và hiện được Cocoa kế thừa). Các công cụ khác cung cấp nhiều tính năng hơn cho các tác vụ cụ thể, có thể được mở rộng bằng các ngôn ngữ dễ sử dụng hơn Emacs Lisp và có giao diện trực quan đẹp hơn ... nhưng Emacs vẫn tốt hơn trong việc chỉnh sửa văn bản. Đó là lý do tại sao, một khi bạn biết cách sử dụng nó, rất khó để bỏ thuốc lá.

Đây không chính xác là một nhiệm vụ cụ thể, nhưng đối với những người thậm chí có thể đang bị RSI, việc bàn tay của bạn không bao giờ rời khỏi bàn phím trong vim gần như là vô giá. Tôi thực sự kết thúc bằng tay trái trên con chuột của mình tại nơi làm việc vì nó cho phép tôi di chuyển tay ít hơn để chạm vào con chuột (bàn phím của tôi ở nhà không có bàn phím số, vì vậy tôi có thể giữ nó ở bên phải).

Một lợi ích nhỏ khác là IIRC, vi ban đầu được thiết kế để tăng tốc độ chỉnh sửa tệp qua một kết nối từ xa cực kỳ chậm. Được cho là điều đó gần như không xảy ra ngày nay, nhưng nếu bạn có kết nối chậm, chúc bạn may mắn khi chạy trình soạn thảo văn bản gui và nó có khả năng phản hồi.

Đối với tôi, những thứ năng suất lớn là

• Tôi có thể làm khá nhiều thứ từ bàn phím.
• Macro mạnh mẽ.
• Trong 20 năm sử dụng 9 hệ điều hành của tôi, các ràng buộc bàn phím cơ bản không thay đổi. Tôi có thể nhảy vào bất kỳ hệ thống nào và đã biết cách của mình xung quanh trình soạn thảo.
• Khá nhiều tính năng bạn có thể muốn trong trình soạn thảo văn bản đã được thêm vào.

Một điều mà tôi thực sự thích về vim là lệnh "lặp lại". Về cơ bản, bằng cách nhấn .trong chế độ lệnh, nó lặp lại hành động cuối cùng của bạn. Đây chỉ là một ví dụ về các tính năng thực sự thú vị mà "trình soạn thảo văn bản của lập trình viên" có mà GUI thường không có.

Theo kinh nghiệm của tôi, năng suất chính đạt được mà vim và emacs (bản thân tôi là một người có vim, nhưng emacs chắc chắn tương tự) cung cấp là:

• Bạn có thể có những tính năng mà IDE hiện đại cung cấp (như chu kỳ một phím nhấn chỉnh sửa-build ương và tài liệu nội tuyến và hoàn tab và không có điều gì) nhưng bạn không phải . Năng suất đạt được? Bạn chỉ thấy nhiều như bạn muốn xem. Theo kinh nghiệm của tôi, IDE không giúp mọi người làm việc hiệu quả hơn, cũng bởi vì chúng hiển thị quá nhiều thông tin (tất cả các loại trình duyệt). "Thêm chút sức mạnh, khi bạn cần - nhưng không sớm hơn" là một IMHO tăng năng suất.

• Các trình biên tập rất phổ biến đối với các lập trình viên, có nghĩa là có sẵn một kho tập lệnh, sách và nhóm người dùng khổng lồ.

• Theo kinh nghiệm của tôi (tôi chỉ có thể nói về vim ở đây) người dùng vim trung bình là một kỹ sư phần mềm khá giỏi. Tôi không biết tại sao lại như vậy (hoặc có thể tôi chỉ may mắn), nhưng có lẽ những người đã gặp rào cản trong việc làm quen với một công cụ 'cũ' như emacs hoặc vim có sự cống hiến phù hợp (và liên hệ với những người khác như vậy ). Có thể đó là tác động gián tiếp của những người biên tập này, nhưng đi chơi với những người có vim (hoặc emac) khác trên IRC hóa ra khá thú vị, vì những người đó cũng khá quan tâm đến tất cả các loại vấn đề về kỹ thuật phần mềm (hoặc khoa học máy tính) . Các biên tập viên này dường như thu hút một loại tính cách nhất định. :-)

"Năng suất đạt được" mà tôi nhận được khi sử dụng một bản sao emacs nhẹ cho các chương trình nhỏ là nó khởi động như tia sét được bôi mỡ. Tôi thường có thể thực hiện một chương trình kiểm tra nhanh trong C # trước khi Visual Studio tải xong giải pháp "hộp cát".

Tất nhiên, tôi có thể để Visual Studio mở (hoặc một VS khác đang mở nếu tôi đang làm việc trong đó vào thời điểm đó) nhưng sau đó nó sẽ bị hoán đổi nếu tôi để nó không hoạt động trong một thời gian, v.v.

Đối với bất kỳ thứ gì có kích thước đáng kể - hoặc nếu tôi không biết API mà tôi đang sử dụng khá tốt - thì IDE là con đường phía trước, IMO.

Tôi sử dụng gvim cho windows, vì vậy về mặt kỹ thuật nó là một trình soạn thảo văn bản GUI, nhưng nó là vim ..

Để cải thiện năng suất, tôi thấy:

1. Tôi không bao giờ phải sử dụng chuột, do đó tôi nhanh hơn.
2. tìm kiếm, thay thế, sao chép / dán, v.v. đều nhanh hơn với liên kết phím vim và di chuyển chuột (khi đường cong học tập đã được kiểm tra)
3. Như đã đề cập trong các bình luận trước, RSI đang giảm đáng kể. Cổ tay của tôi đã cảm ơn tôi kể từ khi tôi chuyển đến vim.
4. nó nhẹ và nhanh

Bạn biết đấy, đối với vi tôi nghĩ rằng nó đi xuống để có chế độ chèn và lệnh. Mặc dù nó có vẻ là một sự trở lại thời kỳ khi bạn không thể phụ thuộc vào con trỏ hoặc các phím đặc biệt, nhưng điều đó thực sự có nghĩa là nhiều lệnh chuyển động mạnh và tạo văn bản là một số lần nhấn phím tối thiểu. Mã hóa hiệu quả không phải là nhập văn bản hàng loạt (mặc định trong các trình chỉnh sửa "hiện đại") mà là một loạt văn bản hàng loạt, theo sau là các chỉnh sửa nhỏ đáng kể và thời gian duyệt thậm chí lớn hơn.

Điều này xuất hiện hàng đầu đối với cá nhân tôi khi sử dụng vi qua mạng khuôn viên có độ trễ cao. Bạn có thể dễ dàng nhận được 10 hoặc 15 ký tự trước câu trả lời. Với vi, tôi có thể thoải mái dự đoán nơi các lệnh đó sẽ rời khỏi tôi và có thể làm việc ở tốc độ gần như bình thường. Chuyên môn xoắn ốc này là một lợi ích liên tục trong điều kiện bình thường - ít trí óc thị giác hơn dành riêng cho việc liên tục phản hồi đồ họa.

Các trình tăng tốc tìm kiếm từ thông dụng * và # rất tuyệt vời để lướt qua mã. Và% để kết hợp dấu ngoặc đơn là cực kỳ hữu ích. Chắc chắn, hầu như không nhiều so với ctl-] nhưng một nửa số lần nhấn phím sẽ tăng lên.

Cá nhân tôi sử dụng winvi để bổ sung một số thứ lớn mà tôi chắc rằng vim cũng có. Việc nhanh chóng chuyển sang chế độ hex sẽ giải quyết rất nhiều vấn đề văn bản "chuyện quái gì đang xảy ra". Và việc xử lý hoàn toàn linh hoạt các kết thúc dòng là một ơn trời đã trở thành một tính năng được mong đợi cho một trình soạn thảo văn bản. Cuối cùng, nó có thể mở bất kỳ tệp nào bất kể nội dung là gì. Điều này tương đương với một kỹ năng hack ưu tú của đơn hàng đầu tiên.

Trong Unix, bạn có thể nhanh chóng nắm bắt đầu ra chương trình hoặc thậm chí lọc các phần của tệp của bạn thông qua các lệnh bên ngoài. Một chức năng cực kỳ mạnh mẽ nhưng tôi nghĩ là chưa được sử dụng hết.

Tôi sử dụng Vim khá thường xuyên. Nó không thay thế UltraEdit đối với tôi. Vì rất nhiều mặt tích cực đã được liệt kê, tôi đoán tôi sẽ đi ngược lại vấn đề và liệt kê một số điểm khó chịu với Vim.

• Xử lý FTP yếu. Tôi "sắp xếp" rất nhiều trang web, và không thể dễ dàng duyệt và chỉnh sửa tệp trên máy chủ FTP từ xa là một thiếu sót lớn đối với tôi. NWRead là không đủ tốt.
• Sự kỳ lạ của bảng điều khiển được thừa hưởng từ các vấn đề chung về thiết bị đầu cuối dường như đang ảnh hưởng đến Linux. Tôi thường sử dụng PuTTY để kết nối với hộp Linux của mình (chạy Ubuntu) và vì một số lý do, các phím mũi tên ánh xạ tới A / B / C / D trong chế độ chèn (và toàn bộ vấn đề hỗ trợ màu). Trong gVim, ctrl-tab có thể được ánh xạ thành "bn" dễ dàng, nhưng không phải trong chế độ console, rất nhiều vấn đề như vậy.
• Các tùy chọn tìm kiếm / thay thế rất yếu, giao diện khôn ngoan. Việc phải gõ toàn bộ vào một dòng duy nhất là không đủ. Tôi cảm thấy cuộc đối thoại phức tạp hơn nhiều nói rằng UltraEdit cuối cùng mang lại cho tôi nhiều sức mạnh hơn, ngay cả khi hỗ trợ biểu thức chính quy thực tế có thể yếu hơn nhiều.
• Phụ thuộc quá nhiều vào bố cục bàn phím của Hoa Kỳ. Rất nhiều phím được sử dụng cho các chức năng chính, chẳng hạn như `, không được in trên bố cục bàn phím tiếng Đan Mạch của tôi (và được đặt một cách khó hiểu, giống với $ và nhiều phím khác). Làm cho nó khá khó sử dụng một số chức năng.

Remote Desktop chỉ hiển thị nhanh ứng dụng Windows gốc. Chúng tôi đã cố gắng sử dụng Eclipse để phát triển dưới unix. Và bạn biết những gì? Nó thậm chí còn không thể.

Lý do thứ hai là chúng tôi có thể mở rộng Vims và Emac của mình để thực hiện tất cả các tác vụ cụ thể của dự án từ duyệt DB theo cách đặc biệt để làm nổi bật và tự động hoàn thành ngôn ngữ meta sở hữu của chúng tôi.

Tôi muốn nói một trong những lợi thế lớn là khả năng mở rộng của trình soạn thảo vim. Nếu tôi muốn thứ gì đó hoạt động với CVS, tôi có thể sử dụng plugin CVSMenu và thêm nó vào trình soạn thảo của mình để có được chức năng đó.

Tương tự với tô sáng cú pháp, hành vi với các tệp cụ thể, v.v. Tất cả những thứ có thể được điều chỉnh theo vim.

Không chắc liệu bạn có thể làm điều đó dễ dàng như trong trình chỉnh sửa loại GUI hay không.

Ghi và Phát lại trong VIM là tuyệt vời không thể đánh bại, mà bạn rất khó tìm thấy trong các công cụ dựa trên GUI.

Ngoài ra tự động tăng / giảm cung cấp cho nó khả năng tạo dữ liệu mà không cần viết chương trình cho nó.

Tôi đã là một người dùng Emacs chán nản trong nhiều năm. Nhưng không bao giờ thực sự nhận được vào nó. Sau đó, tôi bắt đầu học Clojure (Lisp đầu tiên của tôi) và khám phá ra ParEdit.

Và điều đó đã thổi bay tâm trí tôi.

(Xem tại đây để biết một số ví dụ: https://www.youtube.com/watch?v=D6h5dFyyUX0 )

Lisp + ParEdit là trải nghiệm chỉnh sửa tuyệt vời nhất mà tôi từng có. Chẳng có gì đến gần. Lisp không còn là một ngôn ngữ khó viết, buộc tôi phải lo lắng về việc cân bằng nhiều dấu ngoặc đơn ngớ ngẩn khó chịu. Với ParEdit, cấu trúc Lisp nhất quán trở thành một phần thưởng lớn để làm việc, vì các phép biến đổi cây giống nhau - slurping, barfing, splitting và join - hoạt động ở mọi nơi, trong các cấu trúc điều khiển và cấu trúc dữ liệu. Và ParEdit ngăn tôi mắc những sai lầm ngớ ngẩn. Hầu như không thể mắc lỗi cú pháp.

Và không giống như Eclipse, đây không phải là một số kiểm tra thời gian thực tốn công sức mà luôn chạy ở chế độ nền, đốt cháy bộ xử lý của tôi. Nó không tốn kém gì ... ParEdit chỉ đơn giản thực hiện thay đổi cấu trúc chính xác khi tôi yêu cầu.

(Nói chung Emacs nhanh hết mức cần thiết. Không giống như Eclipse giống như gõ vào keo.)

Điều tiếp theo tôi phát hiện ra là Yasnippet ( http://emacswiki.org/emacs/Yasnippet ). Một lần nữa, tôi đã không sử dụng bất cứ thứ gì như thế này trước đây. Không chỉ đơn giản là một macro để thêm bảng soạn sẵn, mà là một biểu mẫu động, có thể điều hướng.

Niềm vui cuối cùng là nhận ra rằng nếu tôi muốn tự mở rộng điều này, để có nhiều công cụ năng suất cấp cao hơn, tôi có sức mạnh của chính Lisp để làm việc.

(Nền tảng của tôi là một vài năm với Visual Studio và các IDE khác, sau đó là 15 năm với Vim và 6 tháng gần đây nhất với Emacs.)

Tuổi thọ - Vim / Emacs là FOSS , và đã tồn tại trong nhiều thập kỷ. Việc sử dụng chúng sẽ không giảm, cũng như các tính năng của chúng sẽ không bị hỏng / biến mất / thay đổi nhiều, vì vậy bạn có thể dựa vào việc xây dựng toàn bộ lõi hộp công cụ nghề nghiệp của mình xung quanh việc thành thạo chỉ một trình soạn thảo.

Truy cập từ xa / phổ biến trong các thiết bị đầu cuối - Mặc dù cả hai đều có hệ thống tốt để chỉnh sửa tệp từ xa, bạn cũng có thể cài đặt chúng trên bất kỳ hệ thống nào bạn từng đăng nhập.

Phát triển theo hướng REPL - Cả hai đều có chế độ "SLIME" ở nhiều dạng khác nhau tích hợp bất kỳ loại REPL nào bạn đang làm việc. Ví dụ: tôi chưa bao giờ gặp phải sự phát triển lặp đi lặp lại mạnh mẽ như được cung cấp bởi CIDER .

Linting - Bất kỳ ngôn ngữ nào bạn đang sử dụng đều có một số công cụ linting , cho dù được tích hợp sẵn trong trình biên dịch hay một công cụ bên ngoài. Các ứng dụng này tích hợp liền mạch với Emacs / Vim, hiển thị các phiếu mã hóa của bạn trong thời gian gần như thực.

Ngữ pháp của các lệnh dễ ghi nhớ - Mặc dù cả hai đều mất một thời gian để học, nhưng các trình soạn thảo này có các hệ thống nổi tiếng thông minh để truy cập - và thậm chí ghi nhớ - hàng nghìn lệnh với một vài lần nhấn phím và tổ hợp phím. Những thứ này hoàn toàn có thể loại bỏ mọi nhu cầu sử dụng chuột nếu bạn có khuynh hướng như vậy.

Hệ thống trợ giúp tích hợp - Tài liệu ngoại tuyến của nhiều ngôn ngữ và API của chúng thường được tìm thấy được tích hợp sẵn trong các trình chỉnh sửa này và có thể truy cập theo những cách đơn giản tương tự đối với hệ thống trợ giúp toàn diện và rộng lớn mà chúng có. Tính năng tự động hoàn thành đã được thêm vào cho hầu hết các ngôn ngữ phổ biến. Ngoài ra, có rất nhiều trợ giúp thảo luận về hầu như bất kỳ chủ đề trợ giúp nào.

Điều hướng - thẻ, lượt thích, dấu, cửa sổ, tab, nhảy vim-rails và nhiều tính năng tích hợp khác.

Quản lý gói / kho lưu trữ - Emacs có một số (elpa, melpa, marmalade) và Vim cũng tốt (vundle, mầm bệnh, v.v. ). Tôi không biết bất kỳ cộng đồng nào xung quanh IDE cung cấp bất kỳ thứ gì có thể so sánh được với những IDE này. Tôi thấy hơn 5.000 gói với package-list-packages.

Ngoài việc chỉ chỉnh sửa - Emacs còn tiến xa nhất ở đây với khả năng đọc tin tức, duyệt web, quản lý email, chỉnh sửa bảng tính, tạo bản trình bày và sắp xếp mọi thứ.

Tích hợp mọi thứ khác - trình gỡ lỗi, đồng bộ trình duyệt, biên dịch, trình bao, chạy thử nghiệm.

Có thể tùy chỉnh vô hạn - Elisp là một ngôn ngữ rất mạnh để mở rộng / sửa đổi Emacs. VimL là tương đương của Vim. Có những cuốn sách được viết trên cả hai. Điều chỉnh các chủ đề và hành vi màu sắc theo ý thích của bạn!

Một ưu điểm mà tất cả các trình soạn thảo dựa trên giao diện điều khiển đều có so với các trình biên tập GUI là chúng có thể được chạy trong một bộ ghép kênh đầu cuối như màn hình hoặc tmux . Tại sao điều này tốt?

• Chuyển từ bảng điều khiển ghép kênh đầu cuối này sang bảng điều khiển khác nhanh hơn là chuyển từ bảng điều khiển GUI này sang bảng điều khiển GUI khác bằng chuột hoặc thậm chí sử dụng tab thay thế. Điều này là do bảng điều khiển có thể được đặt tên và chuyển sang bằng cách nhập một vài ký tự của tên.
• Nếu các phiên soạn thảo của bạn nằm trong bảng điều khiển của bộ ghép kênh đầu cuối, bạn có thể truy cập chúng từ bất kỳ máy nào. Nếu tôi cần làm một số công việc ở nhà, tôi có thể ssh vào hộp của mình, gắn bộ ghép kênh đầu cuối đã chạy vào phiên ssh của tôi và ở ngay nơi tôi đã dừng lại khi rời công việc.

Vì vim / emacs thường được sử dụng bởi các lập trình viên và là người dùng C # từ năm 2003, từ pov thiên vị này, thật công bằng khi thực hiện điều này nếu không so sánh không công bằng (Một cái khác có thể là VS C ++ với Visual Assist X và C ++ trong vim / emacs):

Đối với C # và Visual Studio:

1. Tôi vừa đếm số lần nhấn phím cho dòng này:

       public List<string> Names = new List<string>();
   //  3      3    3      1111111111111            211   =3+3+3+8+5+2+1+1 = 26 keys strokes + 3 uses of Shift while typing the line above in VS C# 2013 vs 47 key strokes for non-IntelliSense IDE's
   //                              (IntelliSense offers the List<string> because that's what you're likely after here but you can type something else if you want)
   // https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction explains on how this is impl. for C#. In C++ I've heard of 3rd party VS plugin that improves or replaces the VS C++ auto-complete

2. Tôi đã đọc về tính năng emacs để nhảy mã. Tôi không nghĩ rằng nó có tính năng chính xác như vậy. Nó có một tính năng tương tự mặc dù. Đây là nhược điểm của VS. Có rất nhiều tính năng nhỏ nhưng theo thời gian chúng ngừng hoạt động. Lần cuối tôi kiểm tra tính năng nhảy không hoạt động nhưng đó là vài năm trước. VS đã giới thiệu một tính năng nhảy đồ họa mới mà tôi đang sử dụng thay thế. Nó yêu cầu chuột hoặc cảm ứng.

3. Đây là nơi mà emacs / vi giành chiến thắng. Nếu bạn phải nhảy xung quanh nhiều mã, các tính năng VS cho điều này không tồn tại hoặc chưa được kiểm tra đủ.

Vấn đề với điều hướng GUI dựa trên chuột là

a) Cũng giống như ngồi ở vị trí rất tĩnh có thể không tốt, nếu vậy, chuột chũi có xu hướng làm cho các ngón tay của bạn ở vị trí tĩnh. Đau cổ tay của tôi đã biến mất khi đổi sang bi xoay. Lần đầu tiên tôi đã thử chuột dọc nhưng nó không làm được gì cho sự cố.

b) Bàn phím lý tưởng của tôi sẽ có 2 hàng phím chức năng, không có phím bấm, vì vậy tôi có thể đặt bi lăn gần hơn, giúp khoảng cách nhảy dễ chịu hơn.

Tuy nhiên, cuối cùng, nếu bạn muốn nhảy giữa một vài địa điểm cụ thể, rõ ràng "vòng đánh dấu" hiệu quả hơn. VS có một cái gì đó dọc theo những dòng đó ... lần cuối tôi sử dụng nó, nó chỉ hoạt động không đáng tin cậy ...

c) và có thể có rất nhiều tính năng nhỏ bị hỏng với mỗi bản phát hành, vì vậy đây là nhược điểm của VS.

Giải pháp cho vấn đề "mã nguồn đóng" này: Viết toàn bộ VS trong C # và sau đó cho phép sửa đổi / chỉnh sửa mã đã biên dịch (trong thời gian chạy, lưu các thay đổi dưới dạng bản vá được tải tùy chọn vào lần bắt đầu tiếp theo) mà không cần giải phóng nguồn. Điều này có thể được thực hiện bằng cách để trình dịch ngược xuất ra mã như khi đi vào. 180 độ so với cách các trình biên dịch gốc hoạt động. Sau đó nhị phân trở thành mã nguồn và tệp thực thi thay vào đó là mớ hỗn độn của tệp .cs và tệp .exe, v.v. Tồn tại các công cụ của bên thứ 3 hầu như có thể làm được điều này, vì vậy "sửa đổi" exe của C # là khá tầm thường nhưng tôi đề xuất sử dụng điều này để kết luận hợp lý: bao gồm các nhận xét chẵn trong .exe và .dll. Các tệp vẫn sẽ rất nhỏ so với các ứng dụng C / C ++ đã biên dịch. Tối ưu hóa? Bạn cũng có thể bao gồm mã được tối ưu hóa trước. Khi người sửa đổi sửa đổi exe trong khi ứng dụng đang chạy, "AST" không được sửa đổi và tệp nhị phân được tối ưu hóa đi kèm sẽ được cắm lại. Ý tưởng tương tự như trong trình biên dịch C # nhưng được thực hiện xa hơn. Bước tiếp theo: Viết toàn bộ hệ điều hành bằng ngôn ngữ này, để ngay cả khi Windows là nguồn đóng, nó có thể được sửa đổi một cách đáng kể vì mã nguồn đi kèm với mọi nhị phân. Không cần thiết lập môi trường, biên dịch, liên kết. Chỉ cần sửa đổi hệ điều hành trong khi nó đang chạy. Tương tự gần gũi: Nếu bạn viết trình duyệt web trong Common Lisp, bạn có thể chỉnh sửa trình duyệt web mà không cần dừng nó và xây dựng các trang web bằng ngôn ngữ giống như trình duyệt. nó có thể được sửa đổi một cách nhẹ nhàng vì mã nguồn đi kèm với mọi hệ nhị phân. Không cần thiết lập môi trường, biên dịch, liên kết. Chỉ cần sửa đổi hệ điều hành trong khi nó đang chạy. Tương tự gần gũi: Nếu bạn viết trình duyệt web trong Common Lisp, bạn có thể chỉnh sửa trình duyệt web mà không cần dừng nó và xây dựng các trang web bằng ngôn ngữ giống như trình duyệt. nó có thể được sửa đổi một cách nhẹ nhàng vì mã nguồn đi kèm với mọi hệ nhị phân. Không cần thiết lập môi trường, biên dịch, liên kết. Chỉ cần sửa đổi hệ điều hành trong khi nó đang chạy. Tương tự gần gũi: Nếu bạn viết trình duyệt web trong Common Lisp, bạn có thể chỉnh sửa trình duyệt web mà không cần dừng nó và xây dựng các trang web bằng ngôn ngữ giống như trình duyệt.