Biến môi trường cho đường dẫn thời gian chạy cá nhân? (~ / .vim trên * nix, ~ / vimfiles trên win32)

9

Tôi đang cố gắng di chuyển .viminfotệp của mình vào .vim/thư mục để đồng bộ hóa sạch hơn trên nhiều máy. (Tôi đã .vimlưu trữ trên Dropbox và sau đó tạo liên kết tượng trưng cho nó từ thư mục chính của tôi.)

Vì vậy, sáng nay, tôi đã tìm thấy câu trả lời này về cách làm điều đó. Tuyệt quá! Thật không may, tôi sử dụng Windows tại nơi làm việc và Mac ở nhà, ~/.vimđôi khi thực sự như vậy ~/vimfiles. Kết quả là, một giải pháp một dòng

set viminfo+=n~/.vim/viminfo

bây giờ đã trở thành một giải pháp 5 dòng

if has('unix')
  set viminfo+=n~/.vim/viminfo
elseif has('win32')
  set viminfo+=n~/vimfiles/viminfo
endif

mà chỉ cảm thấy vụng về với tôi

Có một số loại biến môi trường mặc định mà tôi có thể sử dụng để truy cập vào đường dẫn thời gian chạy cụ thể của người dùng, à la $VIMRUNTIMEhay $MYVIMRC? Hay đây là thứ tôi phải nhảy xung quanh?

vimrc

— Ryan Lue
nguồn

8

Điều này sẽ hoạt động và là bất khả tri của nền tảng / plugin: fnamemodify(expand("$MYVIMRC"), ":p:h")

— poppyschmo
nguồn

Bạn là người thiên tài.

— Ryan Lue

5

Giả sử bạn không thay đổi nó, mục đầu tiên trong &runtimepathlà thư mục thời gian chạy của bạn theo mặc định:

$HOME/.vim        on unix-like systems
$HOME\vimfiles    on windows

Bạn có thể sử dụng giá trị đó để cho Vim biết nơi đặt viminfotệp của bạn với lớp lót không biết nền tảng này:

let &viminfo .= ',n' . split(&rtp, ',')[0] . '/viminfo'

Tài nguyên:

:h :let-option
:h split()
:h runtimepath

— romainl
nguồn

Đáng buồn là điều này không đúng. &runtimepathđược thao tác bởi các trình quản lý plugin, hoàn toàn không có lý do gì để bắt đầu bằng $HOME/.vimhoặc với nó $HOME\vimfiles.

— lcd047

@ lcd047, ở trạng thái mặc định, &runtimepathluôn bắt đầu với thư mục thời gian chạy cấp người dùng mặc định cho nền tảng hiện tại. Bây giờ, rõ ràng người dùng có thể bán thịt 'rtp'ngoài sự công nhận của mình nhưng mầm bệnh AFAIK, vundle, plug, VAM và neobundle đều để lại ~/.vim(hoặc tương tự) ngay từ đầu.

— romainl

Chỉ với cấu hình mặc định. Trong một thời gian dài, tôi đã sử dụng một cái gì đó như thế này : pathogen#infect("$VIM/local/bundle/{}"), để cho phép tôi (1) có sẵn các gói cho tất cả người dùng, (2) tách chúng khỏi thời gian chạy chính của Vim và (3) cho phép tôi tự động nâng cấp chúng. ~/.vimkết thúc ở giữa bó với thiết lập đó.

— lcd047

@ lcd047, tôi đã thay đổi từ ngữ của câu đầu tiên theo cuộc trò chuyện của chúng tôi.

— romainl

Đã làm điều đó cho tôi, và đánh tôi là giải pháp tao nhã nhất, cho thiết lập của tôi. Cảm ơn!!

— Ryan Lue

2

Lỗi đầu tiên tôi thấy hết lần này đến lần khác liên quan đến Windows là luôn cố gắng giải quyết vấn đề bằng cách sử dụng $HOME, đừng.

Việc sử dụng $HOMEcuối cùng sẽ gây ra vấn đề, đặc biệt nếu bạn sử dụng bất kỳ môi trường nào giống Unix (Cygwin, git bash, v.v.). Đừng sử dụng nó trong các tập lệnh, đừng đặt nó làm biến môi trường. Trên thực tế, cài đặt $HOMEsẽ khiến Cygwin ngừng hoạt động chính xác và git bash cũng làm tương tự. Bạn càng chơi với $HOMEnhững con bọ càng tệ, và truy tìm chúng càng khó hơn. Chỉ không sử dụng nó.

Windows xây dựng $HOMEnhanh chóng và đằng sau hậu trường %HOMEDRIVE%%HOMEPATH%. Chỉ cần sử dụng cái này bên trong _vimrchoặc vimrc(không có dấu chấm):

set viminfo+=n%HOMEDRIVE%/%HOMEPATH%/vimfiles/viminfo

Điều này sẽ giải quyết vấn đề. Nếu bạn thay đổi vimfilesđể .vimđiều chỉnh cho phù hợp.

— người dùng1640896
nguồn

0

Những gì tôi đã làm là đổi tên thư mục viminfo của Windows thành .vim (hoặc sao chép nội dung của trình định dạng vào sau và sau đó xóa cái trước) và sau đó liên kết chúng với mklink /d viminfo .vim. (Lưu ý rằng mklink lấy các đối số của nó theo thứ tự ngược lại từ lệnh ln của Unix.)

— Edward
nguồn