Tại sao Vim đặt chiều rộng văn bản tối đa là 79 thay vì 80?


13

Tôi hơi bối rối về một số giá trị mặc định trong Vim. Đặc biệt, cho gq{motion}, được nói rằng

[...]
If the 'textwidth' option is 0, the formatted line
length is the screen width (with a maximum width of
79).

Tôi nghĩ rằng nó nên có ý nghĩa hơn nếu nó sẽ đặt chiều rộng tối đa thành 80, thay vào đó.

Ai đó có thể khai sáng cho tôi về điều này? Tôi đoán tôi đang thiếu một cái gì đó.


1
Chà, 80có phải là một "tiêu chuẩn" khá độc đoán để bắt đầu với vậy nên tại sao không 79? Bây giờ, các dòng bọc 79trong một 80thiết bị đầu cuối rộng cột cung cấp thêm một chút chỗ ở bên phải và có thể cải thiện mức độ dễ đọc. github.com/vim/vim/blob/ đá
romainl

2
Có lẽ, trên 80thiết bị đầu cuối toàn cột, cột cuối cùng được dành cho biểu tượng gói? Tuy nhiên, nếu bạn có số dòng trên, thì chúng chắc chắn sẽ mất nhiều hơn chỉ một cột. Vì vậy, tôi vẫn còn hoang mang. Hơn nữa, từ mã bạn liên kết, 79giá trị tối đa nó có thể được sử dụng? Có lẽ tôi không hiểu những gì tôi đọc.
Vào

3
... Hoặc bạn chỉ có thể thiết lập textwidthvà được thực hiện với.
VanLaser

13
80 là số cột của thiết bị đầu cuối phần cứng cũ và sau đó là màn hình MS DOS (chế độ văn bản). tw=79thay tw=80vì vì hiển thị một dòng dài 80 ký tự trên thiết bị đầu cuối 80 cột sẽ in thêm một dòng mới.
Sato Katsura

7
Một dòng mới luôn được thêm vào. Nếu nó là ký tự thứ 81 trên thiết bị đầu cuối rộng 80 ký tự, bạn chỉ cần có một dòng đầy đủ theo sau là một ký tự trống.
Sato Katsura

Câu trả lời:


7

Tôi không có bất kỳ bằng chứng nào cho thấy đây là lý do 79 ban đầu được chọn, nhưng một lý do chính đáng để bỏ nó ở giá trị đó là bởi vì nếu bạn sử dụng 'list'với một giá trị được bao gồm eoltrong 'listchars'đó thì việc hiển thị danh sách sẽ gây ra 80 ký tự- dòng dài để bọc lên dòng tiếp theo trong một thiết bị đầu cuối rộng 80 ký tự.

Nếu dòng chỉ dài 79 ký tự, thì cột thứ 80 là miễn phí cho dòng cuối cùng listcharngồi.


Tôi đã không nhận được nó. Tôi nên sử dụng ở 'list'đâu? Nó phải làm gì đây?
Vào

@Atcold Đó là một tùy chọn khiến các ký tự thường không nhìn thấy (chẳng hạn như cuối dòng) được hiển thị trên màn hình. Xem :help 'list'hoặc chỉ thử chạy :set listđể xem nó trong hành động.
Giàu

:set listkhông làm gì nhiều Tôi đặt cược tôi không có eoltrong listchars. Tôi không chắc chắn đây là lý do đằng sau các 79nhân vật. Tôi tin rằng @ sato-katsura có câu trả lời tốt nhất trong bình luận.
Vào

eollà trong 'listchars'theo mặc định, nhưng tất nhiên nó có thể một cái gì đó trong cấu hình của bạn đã loại bỏ nó. Tôi đặc biệt nêu trong câu trả lời của mình rằng tôi không có lý do để tin rằng đây là lý do lịch sử mà 79 ban đầu được chọn. Bây giờ tôi chỉ đưa ra một lý do tại sao nó tiếp tục là một giá trị tốt để sử dụng.
Giàu

@ Trả lời. Dòng mới không được hiển thị theo mặc định, sẽ không có ý nghĩa khi dành một ký tự phụ cho điều đó.
Christian Brabandt

6

Điều quan trọng là phải nhận ra rằng "mặc định" này chỉ áp dụng cho gqgwlệnh và tự động định dạng như mô tả trong phần đó. Mặc định textwidthlà 0. Hơn nữa, :right:centermặc định là 80, không phải 79.

Vì lý do 79 được chọn, nó không thể là người nắm giữ trực tiếp từ vi kể từ khi gq , gwvà tính năng tự động định dạng không tồn tại trong vi. Điều này chủ yếu là suy đoán, nhưng tôi tin rằng mặc định 79 cho định dạng tự động đã được chọn để thống nhất với tính năng tự động đóng gói hiện có của vi. Điều này áp dụng cho gqgwlà một tác dụng phụ; người ta có thể mong đợi 80 sẽ được chọn khác.

Trong textwidth=0văn bản vi (và trong vim if ) bắt đầu tự động đóng gói ở độ rộng cửa sổ trừ đi wrapmargin. Tuy nhiên, nếu wrapmargin=0, không có gói tự động sẽ diễn ra. Điều này có nghĩa là nếu bạn đang sử dụng ADM-3A với giới hạn 80 ký tự, với wrapmargin=1, chiều rộng tối đa với tính năng tự động đóng gói là 79. Một nhược điểm của hành vi này là có một nơi để con trỏ sống trong khi chờ xem nhân vật tiếp theo sẽ là trước khi quyết định bọc. Tất nhiên, vi và vim có thể đặt con trỏ trên dòng tiếp theo (như được quan sát khi gõ một từ rất dài) nhưng để lại một cột phụ thì đẹp hơn một chút.

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.