Emacs là gì?

MỘT máy ảo hoặc thông dịch viên cho emacs ngôn ngữ lập trình lisp ... đại loại. Ngôn ngữ lập trình lisp emacs (elisp) là mục đích chung, nhưng có hỗ trợ hạng nhất cho trình soạn thảo văn bản thực sự chạy nó. Các kiểu nguyên thủy tập trung vào chỉnh sửa văn bản, tuy nhiên bạn có thể viết bất cứ thứ gì bạn muốn với hiệu suất tốt (gần đây nhờ biên soạn jit ) bởi vì nó là hậu duệ ngọng của MACLISP và một anh chị em của nói ngọng thông thường . Tuy nhiên lisp emacs không có tiêu chuẩn và đặc điểm kỹ thuật tương đương với cách triển khai phổ biến nhất, đó là GNU Emacs.

Tại sao emacs?

Với cụm từ "Emacs là một hệ thống hoạt động" có nghĩa là bạn có thể sử dụng nó để làm bất cứ điều gì bạn sử dụng máy tính. Nó không phải là một hệ thống hoạt động theo nghĩa đen vì hạt nhân, (thường là linux) vẫn chịu trách nhiệm về phần cứng.^[1] Tuy nhiên, nó có thể dễ dàng được gọi là môi trường máy tính để bàn vì nó cung cấp một môi trường để làm việc. Nó cung cấp cho bạn khả năng viết mã tương tác nhanh để giao diện với bất kỳ ứng dụng nào, nó có thể bẩn như các tập lệnh shell hoặc được nghĩ ra để cung cấp các API ổn định. Trong thực tế, nhiều chức năng của emacs được cung cấp bởi các gói.^[2] Các trình soạn thảo khác có thể mở rộng được như emac không? Không, tại sao? Bởi vì các trình soạn thảo khác sử dụng mô hình người dùng khác, mô hình mà người dùng phải bị hạn chế vì nó được coi là "khách" của môi trường đang chạy cung cấp "dịch vụ" cho người dùng. Đây không phải là trường hợp của emacs, nơi mà môi trường và người dùng trở thành một và giống nhau. Trong emacs, bạn có quyền truy cập vào mọi thứ và có thể sửa đổi hầu hết mọi thứ thông qua cùng một phương tiện mà những thứ đó đã được tạo ra, hay còn gọi là elisp.

Nó có đáng không?

Lợi ích tích lũy, đó là đầu tư, và giống như bất kỳ khoản đầu tư nào, bạn nên mong đợi lợi nhuận tương ứng với số tiền bạn bỏ vào, do đó bạn phải dành một chút thời gian để học và thực hành cách sử dụng nó.

Danh sách mong muốn GNU emacs của tôi

Emacs là một hệ thống hoạt động rất tốt, nhưng là một trình soạn thảo văn bản tồi.

...Hoặc một cái gì đó dọc theo các đường dây. Việc triển khai GNU Emacs, giống như emacs, có nguồn gốc từ những năm tám mươi và nhiều phần cốt lõi của nó cho thấy tuổi của chúng ...

• Sự khác biệt giữa giao diện đồ họa và giao diện đầu cuối. Vì emacs đã cũ nên nó bắt đầu như một ứng dụng để chạy bên trong một thiết bị đầu cuối nhưng với sự ra đời của giao diện đồ họa vào những năm chín mươi, nó bắt đầu thu thập các chức năng hướng tới dựa trên cửa sổ tương tác và khoảng năm 2000 hỗ trợ cho X11 giao thức đã được giới thiệu. Khi nhiều năm trôi qua, tính hữu dụng của phiên bản đầu cuối có thể giảm và cùng với đó, bạn cần quan tâm đến việc duy trì nó, bởi vì việc các emac hoạt động khác nhau tùy thuộc vào đồ họa / thiết bị đầu cuối là một gánh nặng và một chip phức tạp. Tôi muốn xem một bản tóm tắt của GUI emacs trên một cái gì đó như sixelgiao thức, sao cho giao diện đồ họa và giao diện đầu cuối có thể đạt được mức độ chia sẻ mã sâu hơn. Điều này sẽ yêu cầu emacs đảo ngược giả định "thiết bị đầu cuối đầu tiên, thứ hai đồ họa" (mà tại thời điểm viết bài, tôi nghĩ vẫn giữ nguyên).^[3]

• Mã không đồng bộ trong elisp không dễ dàng hoặc có thể xảy ra trong một số trường hợp. Emacs hỗ trợ các chủ đề năng suất điều đó có thể tạm dừng và cung cấp lại quyền kiểm soát cho bộ lập lịch chính, đây là cách triển khai hợp tác đa nhiệm . Emac có cần hỗ trợ hiện đại cho các nguyên thủy không đồng bộ không? Thực tế là emacs chủ yếu bị giới hạn trong một lõi có nghĩa là mã khá tối ưu hóa và bản thân emacs cũng có thể chạy khá nhanh trên các thiết bị nhỏ hơn. Tôi nghĩ rằng emacs, là một giao diện tương tác, chỉ hỗ trợ một giao diện đồ họa không đồng bộ . Trong trường hợp này, phạm vi và ngữ cảnh cho mã không đồng bộ sẽ chỉ được giới hạn trong giao diện người dùng. Đây là thiết kế được sử dụng trong các trình soạn thảo dựa trên điện tử khác như VSCode , nơi giao diện người dùng chạy trong quy trình riêng biệt của chính nó. Tôi đặc biệt muốn kinh nghiệm đánh máy để không bao giờ bị gián đoạn và tôi ổn khi đánh dấu cú pháp bị trì hoãn, hoàn thành hoặc các công cụ phụ trợ khác cho thời gian thực mềm độ trễ đầu vào.

• Vì trong emacs mà bạn phải có quyền truy cập vào mọi điều , cách emacs nói X11 khá tham lam vì emacs gần như triển khai lại một máy chủ X11 đầy đủ bên trong chính nó. Điều này đã gây ra một số rắc rối trong lịch sử^[4] vì hầu hết các lần emac được sử dụng như một cửa sổ bên trong một X11 khác, và không phải là một Máy chủ X11 . Máy chủ hiển thị, xử lý các phiên đồ họa. Một môi trường hiển thị khác sẽ như thế nào? Tôi tưởng tượng thứ gì đó bắt đầu từ cấp thấp hơn và trông giống một công cụ trò chơi hơn, có thể dựa trên SDL . Trên đầu ra video trực tiếp cơ sở, có thể truy cập được từ elisp (được biên dịch nguyên bản) hoặc API C (hoặc gỉ) ổn định. Hệ thống cửa sổ emacs sẽ được triển khai trên phần phụ trợ "pixel cruncher" và không còn dựa vào bộ công cụ đồ họa bên ngoài như lucid hoặc GTK và đạt được mức độ cao hơn của thuyết bất khả tri nền tảng. Điều đó cũng có nghĩa là hiệu suất đáng tin cậy hơn trên các hệ thống, bởi vì khi màn hình được xử lý bởi bộ công cụ đồ họa bên ngoài, hiệu suất của bộ công cụ đồ họa bên ngoài có thể trở nên không thể đoán trước, và ví dụ như những thứ như sinh ra một khung mới kết thúc trên windows chậm hơn trên linux; khi các chức năng này được sử dụng thường xuyên, chẳng hạn như các ứng viên hoàn thành hiển thị, sự khác biệt trở nên rõ ràng.^[5]

• Có một nền tảng hiển thị hiện đại hơn sẽ không chỉ cho phép hiệu suất tốt hơn mà còn cho phép truy cập vào các công cụ hình ảnh nâng cao hơn, như chuyển tiếp thích hợp, bóng đổ, làm mờ và một hệ thống tốt hơn cho các lớp, vì emacs hiện đang triển khai chúng với lớp phủ quy mô nào kém. Nói chung, sẽ rất tuyệt nếu có toàn bộ sức mạnh của CSS3 và hơn thế nữa, sẵn sàng sử dụng và cải thiện các giao diện emacs hiện tại có phần hơi khác nhau.^[6]

• Làm việc trên một số đặc điểm kỹ thuật cho elisp. Các nhà bảo trì emac hiện tại quan tâm đến khả năng chạy emac trên các nền tảng khác nhau (kiến trúc cpu). Nếu phần lớn cốt lõi được viết lại bằng chính elisp^[7], thứ duy nhất còn lại trong nội bộ trở thành trình thông dịch elisp. Với một thỏa thuận về một số dạng đặc tả elisp, việc chuyển toàn bộ các emac sang một thời gian chạy khác sẽ trở nên khả thi, vì vấn đề tương đương với việc "chỉ" triển khai một trình thông dịch elisp.

• Một nền tảng tài trợ emacs? Trong này reddit bài nó được đề cập đến việc khó có thể "chỉ cấp vốn" cho mọi người làm việc và phải là những nhà phát triển quan tâm đến việc làm việc trên các tính năng cụ thể phải yêu cầu tài trợ. Tuy nhiên, điều này không xem xét thực tế là không có nhiều người thành thạo về nội bộ của emacs. Một cách hiệu quả, việc chờ đợi các nhà phát triển có được kiến ​​thức để triển khai các tính năng cụ thể có thể mất 20 năm (và còn tiếp tục tăng); những gì sẽ tăng tốc độ mọi thứ sẽ là đầu tiên trả tiền cho mọi người để tìm hiểu (và viết tài liệu!) về nội bộ emacs để nhiều người hơn có thể làm quen với nó và từ từ chuyển sự phát triển của emacs khỏi nhà thờ và chợ mô hình phát triển sang một mô hình toàn diện hơn.

• Danh sách mong muốn các gói:

  • Ngồi trên cây tất cả mọi thứ! Đánh dấu cú pháp Emacs dựa trên các biểu thức chính quy, không chậm (hầu hết các trường hợp) nhưng có thể gây ra một số rào cản về hiệu suất mà nó khá mong muốn tránh được hoàn toàn. Nhưng treeitter không chỉ giúp làm nổi bật cú pháp, nó còn cung cấp một biểu diễn phân cấp của nội dung đệm, điều này cũng có lợi cho các gói khác:

    • smartparens, paredit, lispyville, v.v.: Đây là gói cung cấp api tính năng nhất để áp dụng các thao tác văn bản dựa trên các đối tượng văn bản, như slurping, nhưng chúng rất chậm (đặc biệt là smartparens). Đổ lại api trên đầu cây trồng trông rất hấp dẫn.

    • Polymode: là một chế độ phụ để trộn các chế độ chính khác nhau trong cùng một bộ đệm. Nó áp dụng tính năng thu hẹp vùng thông qua các biểu thức chính quy, sử dụng treeitter ở đây sẽ giúp tăng tốc mọi thứ.

    • Orgmode: sau khi ngữ pháp cho tree sitter đã được viết, orgmode có thể nhận được tốc độ đáng kể vì rất nhiều logic chế độ tổ chức và việc thực thi dựa trên nội dung bộ đệm phải thường xuyên được phân tích cú pháp (thuộc tính, khối mã, tiêu đề, đầu ra)

  • Thêm vào cường điệu tới chế độ tổ chức: gói này triển khai siêu liên kết trên toàn cầu, trong khi các siêu liên kết mã tổ chức chỉ hoạt động giữa các bộ đệm của chế độ tổ chức. Ngoài ra, chế độ tổ chức dựa trên chế độ phác thảo, có thể được hưởng lợi từ chế độ kline được cung cấp bởi hyperbole, thực hiện các nút không va chạm.

  • Circhat: một từ kết hợp giữa Circe.el và weechat.el . Circe triển khai giao diện người dùng rất tốt cho bộ đệm trò chuyện, trong khi weechat.el cung cấp hỗ trợ giao tiếp với giao thức chuyển tiếp weechat , nhưng có giao diện người dùng kém và lỗi. Sử dụng weechat để xử lý thông tin liên lạc trò chuyện giúp giảm thiểu việc phải xử lý tất cả các kết nối IRC và giám sát tất cả các bộ đệm, điều này có thể làm chậm emacs đi khá nhiều. Hơn nữa, weechat có hỗ trợ plugin cho ma trận, vì vậy bạn cũng nhận được hỗ trợ ma trận trực tiếp bên trong emacs.

  • Tramp: tramp là gói emacs xử lý các kết nối từ xa, nhưng rất chậm. Đây không nhất thiết là tất cả lỗi theo dõi, bởi vì các gói khác không bao giờ kiểm tra xem phiên hiện tại là cục bộ hay từ xa và áp dụng những thứ như hoạt động nặng của hệ thống tệp trên các điểm cuối từ xa. Nhưng tramp cũng thiếu hỗ trợ không đồng bộ, đây là một trạng thái rất đáng buồn đối với một thứ mà hầu hết gửi lệnh cho các quy trình bên ngoài xử lý các giao thức được yêu cầu (ssh, sftp, docker ...). Trải nghiệm VSCode với loại bỏ máy chủ tốt hơn nhiều và emacs cần phải nâng cấp trò chơi của nó :)