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

オープン
  • 何か問題がありますか？
#4,269 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go
領域
backend, cli

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
Go
スター
29.8k
フォーク
1.4k
平均マージ
1日 12時間
マージ済み PR（30日）
2

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

micro-editor/micro のほかの issue

micro-editor/micro の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。