{{<admonitiontype=dangertitle="ARTÍCULO SIN TERMINAR"open=true>}}
Este artículo **NO ESTÁ TERMINADO**, pero yo creo que ya es útil. En cuanto termine la migración de la configuración a Elpaca añadiré un enlace a la misma. Puedes mandarme sugerencias si te apetece.
{{</admonition>}}
Vamos a ver como configurar Emacs (lo estoy probando en versiones 29, 30 y 31) con el gestor de paquetes Elpaca. Dejo un enlace al repo en Codeberg donde tengo mi configuración de Emacs con Elpaca (que sigue cambiando continuamente) al final de esta entrada del blog.
Vamos a ver como configurar Emacs (lo estoy probando en versiones 29, 30 y 31) con el gestor de paquetes Elpaca.
## Gestión de paquetes en Emacs
### Gestión de paquetes en Emacs
#### package.el
### package.el
[_package.el_](https://www.emacswiki.org/emacs/InstallingPackages) es el gestor de paquetes por defecto en Emacs. Los paquetes de _package.el_ son ficheros comprimidos estructurados de manera que se puedan descomprimir en el directorio de paquetes de tu Emacs simplificando la instalación.
@ -33,13 +28,13 @@ _package.el_ funciona perfectamente y es la alternativa adecuada si quieres una
- Quieres instalar versiones específicas de los paquetes
- Quieres desarrollar tus propios paquetes, o quieres contribuir al desarrollo de algún paquete o quieres simplemente trastear con el código de paquetes instalados
#### use-package
### use-package
[_use-package_](https://github.com/jwiegley/use-package) **no es un gestor de paquetes**, es una macro que facilita muchísimo la especificación de paquetes a instalar desde los ficheros de configuración de Emacs. _use-package_ no se encarga de instalar los paquetes, sólo nos da una sintáxis muy potente y sencilla para declarar los paquetes a instalar y sus configuraciones. La instalación propiamente dicha siempre la hará el gestor de paquetes que utilices.
La mayoría (sino todos) los gestores de paquetes para Emacs son compatibles con _use-package_. De hecho este paquete es tan útil y popular que ya viene incluido como _built-in_ desde la versión 29 de Emacs.
Merece mucho la pena leerse con atención toda la documentación de _use-package_ en [esta web](https://jwiegley.github.io/use-package/keywords/) hay una explicación detallada de cada palabra clave.
Merece mucho la pena leerse con atención [toda la documentación de _use-package_](https://github.com/jwiegley/use-package) y a mayores en [esta web](https://jwiegley.github.io/use-package/keywords/) hay una explicación detallada de cada palabra clave.
Una característica curiosa (al menos para mi) de _use-package_ es que podemos invocarlo con una _feature_ de Emacs, y no solo con un paquete. Es bastante habitual invocarlo con la _feature_`emacs`, veamos un ejemplo:
@ -84,7 +79,7 @@ Tampoco es difícil crear una _feature_ al vuelo, aquí configuramos las fuentes
Hay otras formas de conseguir lo mismo en el fichero de configuración, pero se hace así unas veces para disponer de todas las facilidades que nos da `use-package` (por ejemplo sintáxis simplificada para asociar atajos de teclado, _hooks_, etc.), y otras simplemente por mantener toda la configuración organizada en bloques de `use-package` con una sintáxis coherente en todo el fichero.
#### Alternativas a _package.el_ (_straight.el_)
### Alternativas a _package.el_ (_straight.el_)
Tenemos muchas alternativas al gestor de paquetes por defecto de Emacs. Hay una excelente comparativa de gestores de paquetes en la [documentación de `straight.el`](https://github.com/radian-software/straight.el?tab=readme-ov-file#comparison-to-other-package-managers)
@ -95,9 +90,9 @@ La pega que le veo a _straight_ es que no da ninguna facilidad al usuario para e
La razón inicial para probar _elpaca_ fue precisamente que facilita de varias maneras explorar los paquetes disponibles. Es mucho más interactivo que _straight_. Y si a eso añadimos que es significativamente más rápido, tiene todas las papeletas para ser el sucesor de _straight_ en el futuro.
### Elpaca
## Elpaca
#### ¿Qué tiene de especial Elpaca?
### ¿Qué tiene de especial Elpaca?
Como comentaba _elpaca.el_ es el descendiente directo de _straight.el_ y varios desarrolladores del segundo forman parte del equipo de desarrollo de _elpaca.el_.
@ -111,7 +106,7 @@ Elpaca tiene las siguientes características:
Al haber desarrolladores comunes en `straight.el` y `elpaca`, hay ciertas similitudes entre ambos gestores de paquetes, así que pasar de _straight_ a _elpaca_ es incluso más fácil. Pero ojo, tampoco es un drama pasar de _package_ a _elpaca_ si ya estás usando _use-package_.
#### Instalación
### Instalación
Para instalar `elpaca.el` es imprescindible:
@ -130,12 +125,12 @@ La instalación de `elpaca` de forma análoga a la de `straight` se hace mediant
2. Y añadimos a nuestro fichero `init.el` el código _bootstrap_ de `elpaca`, en el momento de escribir esto sería la versión 0.8. Este código es mejor que lo copies del [github de `elpaca`](https://github.com/progfolio/elpaca) para que esté actualizado:
@ -331,7 +326,7 @@ Con esas condiciones mi fichero `init.el` tiene los siguientes contenidos:
;;; init.el ends here
```
#### Funcionamiento asíncrono de elpaca
### Funcionamiento asíncrono de elpaca
Sea cual sea el modo en que instales `elpaca.el` (me refiero a las dos formas que he descrito arriba, con y sin _no-littering_); hay que fijarse que `elpaca` instala los paquetes de forma asíncrona. Esta es una característica distintiva de `elpaca` y hace que cambien algunas cosas:
@ -387,7 +382,21 @@ Comandos disponibles dentro de `elpaca-manager`:
#### Problemas encontrados
### Problemas encontrados
- Como ya hemos comentado hay que tener cuidado con cargar anticipadamente todos los paquetes que Emacs necesite para cargar la configuración sin errores. Yo al final opté por mover la carga de paquetes necesarios al fichero `init.el` antes de la llamada a `(elpaca-wait)` en la linea 131 del listado de `init.el`. Estos paquetes son tres:
- `org`
- `no-littering`
- `delight`
- He tenido problemas con Emacs 29 y Emacs 30 por que _elpaca_ no podía determinar la variable `elpaca-core-date` así que la he definido yo en mi fichero `init.el` para que coincida con la fecha de la release de Emacs, ya sea la versión 29.4 o la 30.1 (ver linea 35 del listado arriba)
- Me he encontrado las siguientes dependencias:
- Tanto `magit` como `casual` necesitan tener instalada la última versión de `trasient`
- `magit` necesita tener instalado el paquete `llama`
Para resolver las dependencias además de añadir las correspondientes secciónes `use-package` para instalar `transient` y `llama`, necesitamos especificar la clausula `:after` en las secciones `use-package` de `casual` y `magit`
## Mi configuración actual con `elpaca`
Mi configuración para Emacs 30.1 (que es la versión que estoy usando normalmente) está disponible en [este repo en Codeberg](https://codeberg.org/salvari/emacs30_elpaca_public)
- Como ya hemos comentado hay que tener cuidado con cargar anticipadamente todos los paquetes que Emacs necesite para cargar la configuración sin errores. Yo al final opté por mover la carga de paquetes necesarios al fichero `init.el` antes de la llamada a `(elpaca-wait)` en la linea 131 del listado de `init.el`.
- He tenido problemas con Emacs 29 por que _elpaca_ no podía determinar la variable `elpaca-core-date` así que la he definido yo en mi fichero `init.el` para que coincida con la fecha de la release de Emacs 29 (ver linea 35 del listado arriba)
No está terminada, estoy cambiando mi antigua configuración con `straight.el` y algo anticuada a esta nueva configuración donde pretendo incluir `treesitter` y `corfu` De momento, todas las semanas hago algún avance.
title: "Emacs: Compilar Emacs en Linux Mint Vanessa"
date: 2023-07-26T11:24:41+0200
draft:
summary: "Apuntes para compilar Emacs 28 y Emacs 29 en Linux Mint Vanessa. Debería funcionar sin muchos cambios para cualquier versión de Emacs en cualquier linux de la familia Debian"
draft: false
summary: "Apuntes para compilar Emacs 28, Emacs 29 y Emacs 30 en Linux Mint Vanessa. Debería funcionar sin muchos cambios para cualquier versión de Emacs en cualquier linux de la familia Debian"
categories:
- pildoras
tags:
@ -199,7 +199,7 @@ $ ls -lha /usr/share/applications/*emacs*
Tendremos que crear nuevas versiones de esos ficheros que apunten al Emacs recién instalado (o editar los existentes), por poner un ejemplo este es el fichero `emacs-28.2.desktop` resultado de modificar el `emacs28.desktop`:
```ini
```toml
[Desktop Entry]
Name=Emacs-28.2
GenericName=Text Editor
@ -216,12 +216,33 @@ StartupWMClass=Emacs
Hay que ver el resto de ficheros desktop y comprobar si necesitan modificaciones para funcionar sin problemas.
## ACTUALIZACIÓN: Compilando emacs 30 en Linux Mint Xia (equivale a Ubuntu 24.04 Noble)
Podemos hacer `git tag --list` para ver todas las versiones disponibles, y con `git checkout` nos cambiamos a la versión que nos interese para compilarla.
Tanto si hemos clonado una rama específica como todo el repo para actualizar las fuentes basta con `git pull`
Tanto si hemos clonado una rama específica como todo el repo para
summary: "Reconfiguramos el prompt de zsh para mostrar la versión de Python en los entornos virtuales"
categories:
- pildoras
tags:
- zshell
---
## Configurar el prompt de zsh
Queremos modificar el prompt para que además de mostrar el entorno virtual de python (cuando haya uno activo) muestre también la versión de Python que usa ese `venv`
Para añadir la info de git a mi prompt de zsh ya estoy usando el paquete [zsh git prompt](https://github.com/olivierverdier/zsh-git-prompt)
## Deshabilitar el prompt generado por pyenv
En primer lugar, como tenemos instalado `pyenv` necesitamos inhibir el comportamiento por defecto de `pyenv` que muestra el nombre del entorno virtual en el prompt. Para ello, en el fichero `~/.zshrc` añadimos las siguientes lineas **antes** de la activación de `pyenv`:
```bash
# disable prompt modification by pyenv
# I'm using virtualenv plugin for prompt customization
export PYENV_VIRTUALENV_DISABLE_PROMPT=1
```
## Generamos una función que nos devuelva el venv y la versión de python.
Podemos instalar el plugin de zsh: `virtualenv` que sirve justamente para instalar una función que devuelve el virtualenv para usarlo en el prompt, pero como de todas formas la tenemos que cambiar pongo aquí el texto completo de la función, ya modificada para añadir la versión de Python:
# disables prompt mangling in virtual_env/bin/activate
export VIRTUAL_ENV_DISABLE_PROMPT=1
```
## Editamos el prompt en nuestro tema de zsh favorito
Yo estoy usando el tema `gnzh`, pero viene a ser lo mismo en cualquier tema. En mi fichero del tema el prompt queda configurado con las siguientes lineas:
Sergio Alvariño