Bạn sẽ cảm thấy thế nào nếu trình soạn thảo mã của bạn định dạng mã cho bạn khi bạn nhập, không có tab / dấu cách? [đóng cửa]


8

Như với hầu hết mọi thứ, tôi chắc chắn rằng khái niệm này đã được thử trước đây - Tôi chỉ bắt gặp các biên tập viên sử dụng cái mà tôi gọi là 'Định dạng ảo'. Nguyên tắc là có một lề trái nổi mô phỏng hiệu ứng của các ký tự không gian / tab đệm được chèn bởi nhà phát triển hoặc chính trình soạn thảo để định dạng mã. Trình chỉnh sửa liên tục phân tích mã (ngay cả khi nhận xét) khi bạn nhập và tính toán thụt lề yêu cầu dựa trên ngữ cảnh nơi mỗi nguồn cấp dữ liệu được tìm thấy

Tôi đang phát triển ý tưởng này hoạt động cụ thể với trình soạn thảo XML vì XML có một số vấn đề đặc biệt với định dạng ký tự và nó có xu hướng được lồng rất nhiều, tuy nhiên tôi tin rằng nhiều nguyên tắc vẫn giữ cho mã thông thường.

Bạn có kinh nghiệm mã hóa với một công cụ như vậy hoặc bạn có một cái nhìn về việc nó sẽ giúp hoặc cản trở? Nó sẽ gây ra vấn đề với các hệ thống kiểm soát phiên bản? (nó phát hiện và loại bỏ tất cả các ký tự đệm hiện có)

Trừ khi bạn đã thử nó, hành vi của một công cụ như vậy rất khó để mô tả, nó trông có vẻ thông thường cho đến khi bạn thực sự bắt đầu chỉnh sửa. Tôi đã đưa lên một video screencast cho thấy một nguyên mẫu hoạt động thể hiện việc chỉnh sửa XML, thay đổi thứ bậc của nó và thực hiện các thao tác kéo / thả và sao chép và dán, sau đó cách định dạng bị hỏng / cố định khi nhập các ký tự không hợp lệ.

Chỉnh sửa Tất cả các câu trả lời / nhận xét cho đến nay đều tiêu cực - vì vậy, để cố gắng khắc phục sự cân bằng, một số lợi ích của định dạng ảo phải suy nghĩ về:

  • Không còn tranh luận về các tiêu chuẩn định dạng, chỉ cần đặt nguồn cấp dữ liệu phù hợp với quy ước được chọn / bắt buộc của bạn
  • Khi không gian ở mức cao (trong sách / blog / tài liệu), bạn có thể bọc từ nhưng vẫn nhận được sự thụt lề hoàn hảo
  • Mỗi khối mã có thể có một 'tay cầm chuột' ngay lập tức liền kề với nơi nó bắt đầu, không bị ép vào cạnh màn hình - nhấp vào đây để chọn toàn bộ khối hoặc khối bên trong
  • Kéo, thả và quên - lần đầu tiên trở nên khả thi
  • Không có thời gian để định dạng lại mã người khác
  • Không có mã được định dạng không chính xác (theo nghĩa là không có - chỉ là kết xuất)
  • Sử dụng Backspace thay vì Ctrl + Backspace giữ ngón tay của bạn trên các phím hướng dẫn bàn phím
  • Kết xuất linh hoạt - điều chỉnh định dạng kết xuất phù hợp với môi trường của bạn, có ai đã thử đọc mã trên điện thoại di động / máy tính bảng màn hình nhỏ không?
  • Hãy xem xét rằng có ít hơn 25% ký tự có thể chỉnh sửa (trong XSLT mẫu), không có lợi ích hiệu quả?

Chỉnh sửa - Kết luận cho đến nay

  1. Các nhà phát triển đã thiết lập các công cụ và phương pháp làm việc khắc phục hiệu quả hầu hết các nhược điểm vốn có trong việc sử dụng các ký tự đệm được sử dụng để thụt lề.

  2. Có lo ngại rằng việc loại bỏ các ký tự định dạng sẽ gây ảnh hưởng xấu đến một số công cụ khác biệt.

  3. Các nhà phát triển muốn linh hoạt để 'tinh chỉnh' định dạng theo cách mà kết xuất tự động không thể xử lý.

  4. Việc loại bỏ các khoảng trắng / tab hàng đầu có nghĩa là một công cụ 'nhận biết mã' có khả năng định dạng mã là cần thiết để xem xét mã đó một cách hiệu quả - một trình soạn thảo văn bản đơn giản sẽ không hiển thị định dạng.

  5. Những người cảm thấy có thể có một số lợi ích giả định (đối với thụt ảo), có quan điểm rằng những nhược điểm vượt trội hơn những lợi ích tiềm năng đó - một cách thuyết phục .

Chỉnh sửa - Phán quyết

Nhận thức về những trở ngại và một số lợi ích (nếu có) là điều không khôn ngoan đối với tôi, với tư cách là nhà phát triển duy nhất, theo đuổi khái niệm chỉnh sửa không gian này cho các ngôn ngữ chung. Tuy nhiên, đối với XML / XSLT (vì cách xử lý khoảng trắng đặc biệt của nó), dường như có một số thỏa thuận về tiềm năng ít nhất.

Chỉnh sửa - Sản phẩm được giao

Mặc dù tình cảm tiêu cực thường thấy ở đây, tôi đã đi trước và chuyển biên tập viên. Tôi đã tạo ra một phiên bản miễn phí với hy vọng nó sẽ mang lại sự chỉ trích dưới dạng các vấn đề cụ thể hơn, dựa trên kinh nghiệm thực tế. Hơi khó chịu, cho đến nay không có khiếu nại nào (thực tế hầu như không có phản hồi nào xem xét khối lượng tải xuống). Tôi muốn nghĩ rằng điều này là do người dùng đã điều chỉnh ý tưởng tốt đến mức họ thấy đây là một 'vậy thì sao?' loại tính năng - nhưng không có cách nào để nói ...


Tôi nghĩ rằng một số biên tập viên Đề án thực hiện loại định dạng này một cách nhanh chóng, nhưng chèn (và xóa) không gian thực
Javier

@Javier Tôi phải thú nhận rằng tôi chưa bắt gặp Scheme - Tôi sẽ xem xét điều này, quan điểm của tôi là có một số ngôn ngữ mà định dạng quan trọng / nguy hiểm hơn các ngôn ngữ khác, vì vậy Scheme có thể là một trong những ngôn ngữ đó
pgfearo

Tôi đề nghị bạn nên xem Fireorms và cách nó chỉnh sửa cây HTML.
Lie Ryan

@Lie Ryan - Vâng, tôi thích trình soạn thảo cây, cho đến nay. Nhưng tôi vẫn cảm thấy như bạn đang điền vào một biểu mẫu thay vì văn bản tự do, tôi đoán đó là vì nó chỉ chỉnh sửa các thuộc tính, không phải các thành phần (trong chế độ này, theo như tôi có thể nói).
pgfearo

HTML không chính xác là một văn bản tự do để bắt đầu, nhưng tôi hiểu ý của bạn khi cảm thấy như điền vào biểu mẫu (thực tế đó là lý do tại sao tôi thích nó, các hạn chế khiến chúng tôi không thể vô tình giới thiệu các thẻ không được gắn / không khớp, thuộc tính không được trích dẫn, v.v; Tôi sẽ không sử dụng trình soạn thảo XML chuyên dụng nếu nó cho phép tôi viết XML không được định dạng tốt). Trong Fireorms, bạn có thể thêm nút mới bằng cách nhấp chuột phải> chỉnh sửa HTML, khá bất tiện nhưng đủ để chỉnh sửa nhỏ mà các nhà phát triển web cần. Trong một trình soạn thảo nghiêm túc hơn, có thể có nút / menu ngữ cảnh / phím tắt để chèn các nút.
Lie Ryan

Câu trả lời:


6

Vấn đề lớn nhất là làm thế nào các tệp sẽ xuất hiện với các công cụ khác, đặc biệt là các công cụ kiểm soát phiên bản. Kết thúc dòng có ý nghĩa đối với các công cụ này. Tôi sẽ không muốn thấy một màn hình hợp nhất nơi tôi có cả một lớp trong một dòng và thử và hợp nhất một phần của văn bản tại cột 347.


1
@Jeremy - để làm rõ, tất cả các nguồn cấp dữ liệu (nếu có) được giữ nguyên chỉ là các tab / khoảng trắng được loại bỏ. Tôi đã hy vọng các công cụ khác biệt có thể đối phó nếu những thứ này bị thiếu.
pgfearo

1
Một số công cụ kiểm soát phiên bản và khác biệt cung cấp tùy chọn bỏ qua sự khác biệt về khoảng trắng.
Thất vọngWithFormsDesigner

1
+1 - Tôi không thể thấy bất kỳ lợi ích nào cho việc này, tất cả những gì sẽ làm là làm rối tung kiểm soát phiên bản và các công cụ khác.

4
@pgfearo Vấn đề tôi gặp phải với một thứ như thế này là nó sẽ gần như tuyệt vời, nhưng <1% thay đổi tôi không muốn làm cho trình soạn thảo đi trước và thay đổi dù sao cũng sẽ điên rồ . Trình chỉnh sửa của bạn sẽ phải hoàn toàn có thể tùy chỉnh ở mức thứ n để đảm bảo rằng nó đáp ứng nhu cầu của mọi người.
Michael Todd

1
@pgfearo - Định dạng xml, vâng, đây chắc chắn là cách tiếp cận cần thực hiện, nhưng tôi nghĩ đó là cách mà hầu hết các biên tập viên định dạng xml.

4

Điều đó sẽ rất tuyệt. Emacs ít nhiều làm điều này, và chủ yếu là làm cho đúng. Bạn đã thử chế độ nXML của Emacs chưa? Làm thế nào bạn sẽ cải thiện về điều đó?

Bạn không thể xây dựng một trình soạn thảo mới cho đến khi bạn lấy mẫu những gì đã có sẵn.

Dù sao, thụt lề phải được lưu trong tệp đầu ra, vì vậy tệp có thể được xem bằng các công cụ khác. Tôi không có khả năng chấp nhận một trình soạn thảo mới trừ khi nó hỗ trợ tùy chỉnh thời gian chạy như Emacs.


Tại sao phải thụt lề, chúng ta nên áp đặt định dạng của mình lên người khác? Mọi người vẫn sử dụng các công cụ không có sẵn các trình cắm XML, có thể định dạng XML theo nhu cầu của họ (không phải của các tác giả)?
pgfearo

Trên Emacs. Tôi chỉ sử dụng Emacs đủ lâu để biết rằng tôi không có thời gian (sau đó) để học nó đúng cách để thực hiện công lý. Tôi nghi ngờ người dùng Emacs cũng sẽ khó lòng thử 'cách khác'. Tôi sẽ xem xét lại Emacs, nhưng tôi lo lắng về "hầu hết là đúng" - bạn có thể cải thiện điều đó.
pgfearo

@pgfearo được gọi làcat
thay thế

@mathepic hy vọng * nhà phát triển dòng lệnh nix có quyền truy cập vào xmlsh hoặc một cái gì đó tương tự?
pgfearo

@pgfearo Thành thật tôi chưa bao giờ nghe về điều đó và sẽ không bao giờ sử dụng vỏ phục vụ cho xml;)
thay thế

3

Tôi đã thấy ý tưởng này trước đây, nhưng tôi chưa bao giờ thấy nó thực sự hiệu quả. Hầu hết thời gian, khi tôi đã nhìn thấy ý tưởng đưa ra, nó bị bắn rơi bởi tất cả các nhà phát triển ngoài kia - hoặc khi nó đã được thực hiện, nó làm cho điều khiển phiên bản hầu như vô dụng như chỉ đơn thuần xem đang gấp sẽ thay đổi các tập tin và nhầm lẫn hơn nữa các công cụ khác. (Một ví dụ cho thấy điều này tệ đến mức nào là Studio Phát triển Witango .)

Tôi có thể nghĩ ra một số trở ngại mà biên tập viên của bạn sẽ phải vượt qua để có ích cho nhiều nhà phát triển:

  • Thay đổi tệp không được tạo tiếng ồn trong lệnh * nix diff -uw. (Không có khác biệt giả!)
  • Chỉnh sửa tệp (trước đây chưa được định dạng) không được phức tạp hóa việc hợp nhất trong các công cụ SCM.
  • Nó phải chơi độc đáo với các biên tập viên khác được sử dụng bởi nhóm dev.
  • Người dùng phải có thể tùy chỉnh định dạng theo nội dung trái tim của họ - một số người khá say mê về cách mã của họ xuất hiện.
  • Chỉnh sửa mã hiện tại không được thay đổi định dạng hiện có. Điều quan trọng là trình soạn thảo không đột nhiên định dạng lại toàn bộ tệp mà không có lý do rõ ràng và không thay đổi định dạng của một dòng cho các chỉnh sửa nhỏ đơn giản - điều đó sẽ gây nhầm lẫn cho các công cụ khác và chọc giận các thành viên khác trong nhóm.
  • Nó có lẽ không nên loại bỏ khoảng trắng dư thừa - nó có thể sẽ khiến ai đó bực mình. Tốt nhất không nên mạo hiểm.
  • Các dòng mới được thêm vào một tệp phải tuân theo các cài đặt của các mô hình hiện có hoặc phải tuân theo định dạng hiện có (trong +/- 3 dòng).
  • Trình chỉnh sửa phải có bảng cài đặt cho phép người dùng xác định chính sách định dạng mã của nhóm tách biệt với những gì trình soạn thảo thực sự hiển thị.

Không cần phải nói, rõ ràng là điều này sẽ yêu cầu một số lượng siêu dữ liệu về định dạng hiện có của tệp. Bạn có thể muốn tách nó ra khỏi các nguồn, nhưng việc giữ nó đồng bộ với kho lưu trữ luôn thay đổi có lẽ sẽ khá khó khăn.

Là người dùng Vim, tôi cũng phản đối rằng biên tập viên nên tôn trọng các mô hình của Vim, Emacs và các biên tập viên khác và giữ nguyên định dạng bị cấm của modeline, bất kể cuối cùng nó hiển thị gì.

Theo tôi, các yêu cầu đối với phần mềm như vậy làm cho nó không thể thực hiện được. Quá nhiều người dùng sẽ mong đợi quá nhiều về nó quá thường xuyên để làm cho một dự án như vậy thành công.


Vì vậy, có vẻ như chúng tôi bị mắc kẹt với giải pháp hiện tại của chúng tôi, không phải vì đó là giải pháp tốt nhất, mà vì quá khó để thay đổi. Đáng buồn thay, điều này đúng trong nhiều lĩnh vực CNTT đến mức nó sẽ thật ngu ngốc / kiêu ngạo đối với tôi khi cảm thấy tôi có thể tự khắc phục điều này. Vì tôi khá cố chấp nên tôi vẫn sẽ sử dụng khái niệm này được tích hợp như một công cụ tùy chọn trong một giải pháp máy tính để bàn lớn hơn nhiều trong đó xử lý / phân tích là mối quan tâm chính. Bằng cách đó, nhà phát triển có một sự lựa chọn.
pgfearo

@pgfearo: Không, tôi nghĩ chúng tôi "mắc kẹt" với tình hình hiện tại của mình, không phải vì nó tốt nhất, mà vì không có gì tốt hơn. Để chiến thắng ý tưởng của người dùng Vim và Emacs, bạn sẽ cần cung cấp một lợi ích đáng kể so với các công cụ hiệu quả mà họ sử dụng. Để chiến thắng mọi người khác, bạn sẽ chỉ cần cung cấp các tính năng mà người dùng Vim và Emacs đã được thưởng thức cho nhiều đối tượng hơn. Đợi đã, có lẽ giấy phép TextMate xứng đáng.
greyfade

@pgfearo: Quan điểm chung của tôi là tôi không nghĩ bạn sẽ đạt được thứ gì đó mà bất cứ ai cũng muốn sử dụng trên các công cụ hiện có của họ, ngoại trừ một tập hợp con rất nhỏ của công việc chúng tôi làm. Có một lợi ích rõ ràng cho các tin tặc XML và XSLT, vì cấu trúc chiếm 99% công việc, nhưng có ít lợi ích rõ ràng hơn đối với các ngôn ngữ có cấu trúc chặt chẽ hơn như C, Java, C #, Ruby, v.v. -cốt lõi.
greyfade

Có, điểm này về các công cụ / phương pháp hiệu quả hiện có là số 1 trong các kết luận được chỉnh sửa (tạm thời) cho câu hỏi. Từ những gì đã nói, tôi nghi ngờ tôi thậm chí nên cố gắng giành chiến thắng trước người dùng Vim / Emacs - nếu có hứng thú với điều này, nó sẽ đến từ nơi khác.
pgfearo

Chấp nhận câu trả lời này vì nó phá vỡ các vấn đề ngắn gọn và phù hợp với tâm lý chung của các câu trả lời / nhận xét khác. Không phải câu trả lời mà tôi hy vọng, nhưng nó đã giúp thuyết phục tôi, rằng - ít nhất là đối với các môi trường không phải là XML / XSLT - không có lý do gì để theo đuổi khái niệm này hơn nữa, không cần phải lãng phí thêm nỗ lực.
pgfearo

2

Giải pháp, sử dụng tệp cấu hình định dạng dựa trên văn bản (ví dụ: XML):

  • Có một định dạng cá nhân được cấu hình bởi nhà phát triển cá nhân.

    • Lưu trữ định dạng này tại địa phương.

    • Các tập tin được tải và chỉnh sửa với định dạng cục bộ.

    • Họ có thể tự do thay đổi phong cách định dạng của họ mà không phá vỡ bất cứ điều gì.

    • Tự động định dạng có thể được tắt để hiển thị và chỉnh sửa các tập tin thô.

  • Có một định dạng nhóm tối thiểu được cấu hình cho tiêu chuẩn nhóm.

    • Lưu trữ định dạng này trong kiểm soát phiên bản nhóm.

    • Các tệp được lưu với định dạng nhóm làm dự phòng cho các công cụ khác.

    • Diffs không gặp vấn đề về định dạng.

Thật nực cười khi lo lắng về tính kinh tế của việc lưu tệp mà không có khoảng trắng bên ngoài, vì vậy bạn thực sự không mất gì khi lưu các tệp với một số định dạng được xác định theo tiêu chuẩn nhóm. Trong trường hợp là nhà phát triển solo, bạn có thể cung cấp khả năng đã lưu định dạng (cho "nhóm" của một) định dạng được hiển thị.

Khi trình định dạng không đủ, bạn có hai tùy chọn khả thi:

  • Đưa ra một giao diện cho các trình định dạng tùy chỉnh.

    • Thực hiện đúng, đây là giải pháp tốt nhất.

    • Làm sai, đó là điều tồi tệ nhất.

  • Cho phép ghi đè thủ công định dạng tự động.

    • Khả năng sử dụng không bị ảnh hưởng khi xem xét Ctrl- (Enter | Tab | Space).

    • Bạn có thể lưu định dạng này ở đâu? Phải không


Điểm hữu ích. Tôi thích ý tưởng về việc chia sẻ tập tin cấu hình định dạng. Định dạng tự động đã có thể chuyển đổi trong nguyên mẫu - bởi vì nó cần thiết để cô lập khoảng trắng 'thực' khỏi các công cụ ảo. Chuyển đổi giữa các khung nhìn dĩ nhiên không làm thay đổi một ký tự. Quan điểm của tôi không phải là cung cấp tùy chọn trong công cụ để lưu 'với định dạng' mà thay vào đó là cung cấp 'bộ điều hợp' miễn phí, đa nền tảng và cũng có thể chạy như một dịch vụ web, chúng có thể sử dụng các tệp cấu hình định dạng XML rất giống nhau bạn đề nghị.
pgfearo

2

Tôi muốn thể đồng ý với mã đang được autoformatted nếu ngôn ngữ không được định dạng nhạy cảm ho Python ho .

Emacs định dạng Lisp thực sự tốt và nó được định dạng khi đang di chuyển Tôi sẽ rất vui. Tôi không thể tự động chèn parens hoặc các dấu phân cách khác: không có trình tự động nào tôi đã thử làm cho nó gần đúng với cách tôi nhập.


Có, tôi nghĩ F # cũng sử dụng định dạng trong cú pháp của nó. Tự động chèn các dấu phân cách là một vấn đề. Đối với XML, đây là hình thức thêm dấu ngoặc kép, v.v. Nó không hoàn hảo nhưng bù lại cho những người đánh máy cảm ứng có thể đi trước cuộc đua, vì vậy nó kiểm tra xem thứ gì đó đã gõ chưa được xếp hàng để tự động chèn dù sao đi nữa - tránh sự lặp lại. Nếu không tự động chèn, trình phân tích cú pháp sẽ đoán cách thụt lề - nó có thể trì hoãn một chút, nhưng sẽ có một số 'tiếng cười' bên lề khi trình phân tích cú pháp cố gắng hiểu ý định thực sự của mã được gõ.
pgfearo

@pgfearo: fortran, cobol, f #, haskell, python, make và một vài hệ thống khác được phân định khoảng trắng. IMO khá lố bịch, vì nó cản trở các công cụ tự động trong hoạt động của họ (và phân tích cú pháp của người dùng), nhưng, yannow, chúng tôi bị mắc kẹt với chúng.
Paul Nathan

2

Tôi thuộc ý tưởng trong khái niệm . Và trong khi bạn có thể thành công, tôi vẫn chưa tìm thấy một trình soạn thảo đủ làm mọi thứ tôi muốn nó làm về mặt định dạng. Dưới đây là một vài rào cản (IMO):

  • Ngôn ngữ kén chọn
  • Điều gì được lưu vào đầu ra? (Ở một mức độ nào đó, bạn sẽ phải lưu ít nhất một số vết lõm để nó có thể đọc được cho người khác mà không cần công cụ)
  • hoàn toàn phải chơi tốt với các sản phẩm kiểm soát nguồn / phiên bản hiện có đã có
  • Nó phải có khả năng tùy biến cao , đặc biệt đối với những người trong chúng tôi (bao gồm cả tôi) rất, rất, rất kén chọn về cách mã được định dạng và thụt lề (và dấu phẩy đó sẽ nằm trong danh sách, nhưng nếu danh sách đó thực sự dài, thì làm thế nào các dòng nên được phá vỡ, vv)
  • Nó phải thực sự hiểu ngôn ngữ. Điều này có nghĩa là nó phải tuân theo ngôn ngữ chính xác vì trình biên dịch sẽ hiểu nó. Tôi đã có quá nhiều trình soạn thảo với cú pháp màu bị sai cú pháp bởi vì có một số khía cạnh hấp dẫn của ngôn ngữ không thể xử lý đơn giản với RegExp. Cấp, bạn chỉ ra rằng bạn sẽ liên tục phân tích ngôn ngữ, nhưng ai sẽ nói rằng những gì bạn phân tích phù hợp với trình biên dịch tôi đang sử dụng? (Tin tôi đi, có rất nhiều tiêu chuẩn ngoài kia, và có rất nhiều hoạt động kinh doanh hài hước diễn ra ở hầu hết các ngôn ngữ, bao gồm cả mã có vẻ sai với trình phân tích cú pháp đơn giản, nhưng hoàn toàn chính xác với trình biên dịch.)
  • Nó phải nhanh thôi. Và đây là nơi cao su gặp đường - bạn không thể thực hiện một trình biên dịch đầy đủ chạy mã của tôi mỗi lần nhấn phím (đặc biệt là với một dự án lớn), trừ khi bạn có thể tối ưu hóa trình phân tích cú pháp của mình đến mức Nth. Nếu thậm chí có một gợi ý về sự chậm chạp trong trình chỉnh sửa, sẽ không có ai sử dụng nó. (Tôi là một ví dụ hoàn hảo về việc từ bỏ các biên tập viên chậm để ủng hộ những người nhanh hơn. Nếu điều đó chậm nhất, tôi sẽ ra ngoài.)

Bạn có thể tạo ra một cái gì đó đáp ứng hầu hết các tiêu chí hợp lý tốt? Có lẽ. Nhưng chúng tôi lập trình viên rất khó tính và kén chọn và không thích thay đổi và sẽ nhảy lên tàu ngay khi có dấu hiệu rắc rối đầu tiên. Ở đây bạn sẽ gặp rắc rối nếu đầu ra đánh dấu người khác vào nhóm nhà phát triển hoặc nếu nó không chơi tốt 100% với hệ thống phiên bản, hoặc nếu nó không định dạng chính xác mã của tôi hoặc nếu nó hiểu sai ngôn ngữ và hiểu sai mã của tôi hoặc nếu nó chậm một phần nghìn giây ngoài những gì tôi mong đợi. Bởi vì, tôi rất thích ý tưởng này, tôi sẽ chuyển đến các biên tập viên ưa thích của mình trong tích tắc.


Về quan điểm của bạn về hiệu suất: khả năng đáp ứng có thể so sánh với các công cụ hiện có. Vì định dạng không có tác dụng đối với văn bản mã, nên việc xử lý có thể được chạy trong nền và kết thúc theo ý muốn. Với XSLT, có một cách tiếp cận theo tầng, định dạng / tô màu được thực hiện trước khi xác thực hạt mịn và biên dịch cuối cùng. Vì tất cả điều này xảy ra trên một luồng nền và bị gián đoạn ngay lập tức trên tổ hợp phím tiếp theo, không có độ trễ hiệu suất rõ ràng. Chỉ văn bản hiển thị cần được làm mới ngay lập tức, văn bản còn lại được định dạng lại trong các cụm được chia nhỏ khi có tạm dừng.
pgfearo

Điều gì được lưu vào đầu ra? Không định dạng trực tiếp, vì điều này sẽ áp đặt một phong cách định dạng cho người khác. Ý tưởng (đáp lại các câu trả lời trước) là cung cấp các trình định dạng có thể cắm được, sử dụng tệp cấu hình chuẩn khai báo các quy tắc định dạng và đầu ra tương ứng, theo yêu cầu.
pgfearo

1

Có tồn tại một cách tiếp cận thậm chí triệt để hơn - một trình soạn thảo ngữ nghĩa thuần túy. Một IDE xử lý một mã thậm chí được thể hiện bên trong như một AST, không phải là một văn bản đơn giản. Xem MPS JetBrains chẳng hạn.


Hay đấy. Tôi chưa hoàn toàn hiểu cách tiếp cận MPS, nhưng thiết kế cho trình soạn thảo này sử dụng AST tương đương với ánh xạ tới các vị trí trong XML văn bản thuần túy. Vì vậy, bất cứ khi nào có sự tương tác của người dùng với văn bản thuần túy, biên tập viên sẽ biết ngay phần nào của 'AST' đang được chỉnh sửa. Điều này giúp nó xác định xem có cần phải sửa chữa hay không và cũng giúp bảo vệ các bộ phận của cây khỏi việc xóa vô tình, khi người dùng thực hiện thao tác xóa và nhấn ', chẳng hạn. Điều này cũng được sử dụng để trình bày dữ liệu về lựa chọn hiện tại trong thời gian thực. Tôi sẽ xem xét MPS hơn nữa.
pgfearo

0

Bây giờ tôi đã xuất bản trình soạn thảo XML được mô tả trong câu hỏi của mình, tôi đang ở vị trí tốt hơn (nhưng không lý tưởng) để cố gắng tự trả lời điều này - vì vậy tôi sẽ:

Sau hơn 500 lượt tải xuống trong vòng chưa đầy 2 tuần, phản ứng đối với khái niệm mới mang tính đột phá này trong định dạng mã động đã ...

KHÔNG

Không phàn nàn, không khen ngợi. Giải thích (hy vọng) của tôi về điều này là mọi người chỉ muốn và mong đợi một biên tập viên cảm thấy bình thường và không làm rối mã của họ. Người dùng sẽ hầu như không nhận thấy rằng định dạng của họ là hoàn toàn ảo và bằng chứng cho thấy họ thậm chí còn quan tâm ít hơn.

Sẽ là một sai lầm mặc dù đọc quá nhiều vào phản ứng không phản ứng này, công cụ này là miễn phí và thật không may, điều này có nghĩa là ít nhất một số người dùng sẽ ít có khuynh hướng chỉ trích. Nếu họ không thích nó, họ có thể đã loại bỏ nó và sử dụng thứ khác.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.