Sửa CTRL- * trong vim dưới màn hình GNU


10

Khi chạy vim dưới màn hình GNU, tôi thấy rằng sự kết hợp CTRLvới các phím mũi tên và phím PG * không hoạt động như mong đợi.

Tôi đang sử dụng vim-gnomegói Ubuntu 10.10 .

Trên một máy khác, cũng chạy Ubuntu, điều này đã hoạt động mà không gặp vấn đề gì; tiếc là bây giờ tôi không có sẵn cấu hình đó.

Có một câu hỏi liên quan ở đây: Làm cách nào để sửa mũi tên Ctrl + trong Vim?

Tuy nhiên, giải pháp được đề xuất là sắp xếp lại các phím bấm của vim để làm việc với trình giả lập thiết bị đầu cuối, trong trường hợp đó là PuTTY. Tôi không nhớ đã làm bất cứ điều gì tương tự, và nghi ngờ rằng có một tùy chọn cấu hình màn hình sẽ giải quyết vấn đề này.

Ngoài ra còn có một chủ đề trong danh sách gửi thư màn hình gnu cho thấy rằng chạy vim qua $ TERM=xterm vimlà một sửa chữa hoặc giải pháp thích hợp. Điều này không hiệu quả, nhưng tôi hơi lo ngại rằng có thể có tác dụng phụ. Nó cũng không đủ quen thuộc để trở thành giải pháp tôi thiết lập trên máy khác (nếu cần một giải pháp).


+1 - Tôi đã gặp vấn đề tương tự và - như bạn đề xuất - thêm term xtermvào ~/.screenrctệp của tôi đã sửa nó cho tôi. Cảm ơn một lần nữa!
Justin Ethier

Câu trả lời:


4

Như đã nêu trong bản cập nhật của mình, việc thêm term xtermvào ~/.screenrctệp dường như sẽ khắc phục vấn đề này.


Vâng .. vâng, nhưng tôi đang đưa ra một số lời giải thích về lý do tại sao screenkhông chỉ truyền bá $TERMbiến môi trường thay vì ghi đè lên nó "screen". Có lẽ có một số trường hợp quan trọng là phải có $TERM == screen.
trực giác

3
@intuited: Lý do Các bộ màn hình TERM=screenlà các ứng dụng chạy bên trong đang giao tiếp bên trong Thiết bị đầu cuối màn hình: các chuỗi điều khiển mà chúng gửi và nhận là của Màn hình, không phải của bất kỳ thiết bị đầu cuối nào được hiển thị. Vì bạn có thể tách phiên Screen và gắn lại nó vào một loại thiết bị đầu cuối khác, nên lớp cảm ứng này là cần thiết.
Gilles 'SO- ngừng trở nên xấu xa'

@Gilles: Cảm ơn, tôi đã nghi ngờ điều gì đó như thế. Những loại vấn đề có thể phát sinh từ việc đặt lại nó xterm?
trực giác

1
Không nhiều, vì xterm và màn hình hầu hết tương thích. Nhưng mỗi cái có một vài khả năng mà cái kia không có, và nếu bạn nói dối với các ứng dụng, chúng có thể sử dụng một khả năng không thực sự hoạt động. So sánh đầu ra của infocmp screeninfocmp xterm, và các chuỗi thoát màn hình với các chuỗi thoát xterm . Tôi không có một sự cố để cung cấp; hầu hết các ứng dụng sẽ không phiền, nhưng một số ít có thể hành xử khó chịu.
Gilles 'SO- ngừng trở nên xấu xa'

2

Có một số cách khác để đặt thiết bị đầu cuối hoạt động trong các quy trình đang chạy:

  • Trong một phiên bản màn hình đang chạy, nhấn ^A- :và ban hành lệnh term xtermsẽ khiến các màn hình mới được mở trong trường hợp đó bắt đầu với $TERMbiến môi trường của chúng được đặt thành xterm; điều này sẽ lần lượt truyền đến các vimtrường hợp được gọi . Các phiên bản vim này sẽ hiển thị hành vi phù hợp đối với các tổ hợp CTRL; Tôi chưa phát hiện ra bất kỳ tác dụng phụ nào của chiến lược này. Lệnh này không ảnh hưởng đến các màn hình hiện có. Lệnh này tất nhiên có thể được sử dụng trong một ~/.screenrctệp, vì vậy có thể phương thức này đã được sử dụng trên máy khác.

  • Trong một phiên bản vim đang chạy, lệnh set term=xtermsẽ làm cho các tổ hợp CTRL hoạt động trong trường hợp vim đó. Điều này có tác dụng phụ của ngắt kết nối clipboard X (tức là @*@+) vì những lý do mà tôi chưa hiểu. Thật thú vị, hiệu ứng phụ clipboard cũng xảy ra khi lệnh :set term=screenđược thực thi trong một ví dụ vim bắt đầu bằng $TERM=xterm.


Câu trả lời này được lấy từ các bản cập nhật của OP. Tất cả những gì tôi làm là định dạng lại và điều chỉnh lại một chút.
phunehehe

2

Vấn đề cơ bản là ánh xạ được thực hiện bởi screengiữa thiết bị đầu cuối thực tế (được xác định bởi TERMbiến môi trường bên ngoài screen) và mô phỏng bên trong screenlà không đầy đủ.

Nếu bạn tình cờ kiểm tra nó (sử dụng vttest hoặc tack ), bạn có thể nhận thấy thiếu sót cho

  • màu sắc
  • chìa khóa đặc biệt

Cố gắng sửa chữa những vấn đề này bằng cách thiết lập termtrong .screenrccó nhược điểm mà nó chỉ hoạt động cho một cho thực tế-thiết bị đầu cuối, và không phải là di động để triển khai thiết bị đầu cuối khác. Các tài liệu ghi chú

Việc sử dụng lệnh hạn không được khuyến khích cho mục đích không mặc định.

Có một giải pháp khác (với một nhược điểm khác), sử dụng tính năng này từ screen tài liệu :

Khi màn hình cố gắng tự tìm ra một tên thiết bị đầu cuối, đầu tiên nó sẽ tìm một mục có tên là màn hình. hạn , trong đó hạn là nội dung của $TERMbiến của bạn . Nếu không có mục nào như vậy tồn tại, màn hình sẽ thử screen(hoặc screen-w, nếu thiết bị đầu cuối rộng (132 cols trở lên)). Nếu thậm chí mục này không thể được tìm thấy, vt100được sử dụng như là một thay thế.

ncurses cung cấp một số mô tả thiết bị đầu cuối thay thế hữu ích cho trường hợp này, ví dụ: screen.xterm-new , để sửa chữa các vấn đề trong ánh xạ màn hình. Trong thực tế, tôi sử dụng TERM=xterm-newvà khi chạy màn hình, có được một ánh xạ có thể sử dụng các phím chức năng.

Tham khảo lại termcài đặt của màn hình , trong thử nghiệm, bạn có thể nhận thấy rằng vẫn còn vấn đề với ánh xạ, được giải quyết trong các lựa chọn thay thế này. Nếu có thể có được một mô tả thiết bị đầu cuối chính xác bằng cách sử dụng term, những lựa chọn thay thế này sẽ là bí danh đơn giản screen. Họ không phải.

ncurses không cung cấp screen.xterm(sic) vì:

  • TERM=xtermđược sử dụng rộng rãi cho các trình giả lập thiết bị đầu cuối khác với xterm; việc thêm ánh xạ này sẽ chỉ làm nặng thêm tình huống đó (xem ví dụ Tại sao không sử dụng TATE được đặt thành "xterm"? trong Câu hỏi thường gặp của ncurses)
  • tên thay thế screen.xtermít có khả năng được cài đặt trên các hệ thống từ xa (xem bình luận thay đổi từ tháng 6 năm 2015 trong cơ sở dữ liệu đầu cuối).

Tuy nhiên, về tổng thể, sử dụng tên thay thế là một cải tiến so với việc sử dụng termtrong của bạn .screenrc: nó giải quyết được nhiều vấn đề hơn so với việc tạo ra. Điều ngược lại là đúng với các termthiết lập.

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.