Should micro set $PWD in CdCmd()/cd?

Đang mở
  • Có gì không ổn?
#4,269 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 3 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
backend, cli

Hướng nghiên cứu

Start with CdCmd() in internal/action/command.go around the os.Getwd() call cited in the issue, then check how buffer paths are updated and look for tests covering cd and working directory behavior. Confirm how PWD should be managed on Unix and how other platforms should behave; done means cd preserves logical paths as intended without breaking buffer paths or cross platform behavior.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

feature
Description

Hi, lovely micro maintainers! Thank you all for maintaining a nice and, so far, AI-free, editor shell. Hope you don't mind a feature request.

Could CdCmd()/cd please set and manage the PWD environment variable so that it appears to work with logical paths on Unix platforms? It would seem less surprising, since >open stores the logical path in buffers' AbsPath fields. Setting this var permutes how subsequent calls to os.Getwd() work, and therefore how tabs display, into something that's arguably nicer for the user when symbolic links are involved.

By "logical path", I mean the path as specified on the command line, or to >cd, >open, etc. in an editor session. On Unix, this can contain unresolved symlinks. Let's call the opposite the "real path", after the Unix realpath command which resolves all symlinks (cf. Go's filepath.EvalSymlinks()).

Backstory

I've recently been making an autocd plugin that automatically >cds you around if you're working on multiple projects, in the way I was using vim-rooter and similar personal code in neovim. One of the design choices for this plugin is that I want to work pretty much exclusively with logical paths - i.e. using the paths I choose, before symlinks are resolved. I'm a heavy user of GNU stow on Unix platforms, and some of my projects are hidden behind its managed symlinks.

It's easy to process buffer paths without resolving symlinks in Micro because its buffers' AbsPath fields store the logical paths. However, the automated >cd commands appeared to be resolving symlinks unnecessarily. It turns out that's just the way the underlying Go funcs work, and Micro's CdCmd() uses os.Getwd()'s stock behaviour to rejiggle the relative Path fields on buffers. OK.

Knowing that, I was able to get the desired behaviour by setting the PWD environment variable just before calling bp:CdCmd(). This is documented Golang behaviour for its os.Getwd().

On Unix platforms, if the environment variable PWD provides an absolute name, and it is a name of the current directory, it is returned.

Suggestion: manage PWD in micro

Anyway, at the end of that long ramble, I'm left wondering why micro-editor doesn't manage this variable itself on Unix platforms, like bash and other shells do, so that all Getwd()/pwd commands produce logical paths. I think it would be less surprising to users, since buffer paths (and therefore default tab display strings) are stored as, and display using, logical paths.

Maybe the PWD setting should go just before CdCmd() calls os.Getwd(), so that the value of wd is a logical path? If that was done, the re-jiggling of the Paths would work relative to what the user probably perceives as their working directory.

I'm of course working with the plugin I wrote, and so far I haven't observed any weird behaviour by doing this in the plugin.

Environment
  • Version: 2.0.15
  • OS: Debian testing
  • Terminal: alacritty
Ngôn ngữ chính
Go
Star
29.8k
Fork
1.4k
Merge trung bình
1 ngày 12 giờ
Pull request đã merge (30 ngày)
2

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của micro-editor/micro

Tất cả issue của micro-editor/micro

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.