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

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