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

Abierto
  • ¿Algo no está bien?
#4,269 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
backend, cli

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Go
Estrellas
29.8k
Forks
1.4k
Merge medio
1 d 12 h
PR fusionados (30 d)
2

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de micro-editor/micro

Todos los issues de micro-editor/micro

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.