openSUSE Tumbleweed – Review of the week 2021/12

Dear Tumbleweed users and hackers,

This has been a week in which we focused a little bit less on Staging, as it was SUSE HackWeek. ‘Less’ does not mean we ignored it of course. We still managed to release 4 snapshots (0318, 0319, 0320, and 0321) during this week.

The changes delivered this week included:

  • transactional-updates 3.2.2
  • KDE Plasma 5.21.3
  • Perl 5.32.1
  • GTK+ 3.24.27
  • SQLite 3.35.2: fixes an issue in combination with Tracker timing out

The future, near or far, will bring those updates:

  • SELinux 3.2
  • GNOME 40
  • MicroOS Desktop – GNOME-based
  • Python 3.9 modules: besides python36-FOO and python38-FOO, we are testing to also shop python39-FOO modules; we already have the interpreter after all. Python 3.8 will remain the default for now.
  • UsrMerge is gaining some traction again, thanks to Ludwig for pushing for it
  • GCC 11 as the default compiler

packagesの説明文書を訳しつつ、使えるものを探してみました(O編)

前回は B でしたが今回は O です。

パッケージ名 okteta
バージョン okteta-0.26.5-1.3.x86_64
動作 ◎
詳細
okteta は KDE のバイナリエディタです。単にバイナリデータの編集だけではなく、文字コード変換やファイル中の文字の統計、ブール演算処理などもできます。
起動すると以下のような画面になります。

左側にファイルの内容を表示、右側に処理機能といようになっています。処理機能は色々選ぶことができ、選ぶと1つのウィンドウが表示されます。複数表示することもできます。
たとえば、文字コードを変更する場合は、まず変更したい部分を左側のウィンドウで選択し、変更先として、To: を選び、文字コードを指定して、 Convert をクリックすることで変更ができます。

また、バイト単位のバイナリ演算をすると、たとえば各バイトの最上位に1を立てる(ハイビット ON)ということもできます。ただ、フォント設定がうまくないのか、1バイトかな文字は表示されませんでした。

バイナリ編集は、左側の画面で、テキストエディタと同じように、なぞってコピーや削除を選べば編集できます。データを追加するときには、メニューで、挿入を選べば、文字のパターンやランダムデータなどで入力できます。

okteta はいくつかの処理がプリセットされていて、適合する処理があればかなり便利に使えそうです。ただ、文字コードの変換対象に UTF-8 が無いので、文字コードの変換に使うには、あまり希望に添わないかもしれません。

Mar 26th, 2021

Let's build Software Libre APM together

Alright, you learned about ActiveSupport::Notifications, InfluxDB, Grafana and influxdb-rails in the two previous posts. Let's dive a bit deeper and look how we built the dashboards for you. So we can study, change and improve them together.

“Individually we are one drop; but together we are an ocean.” – Ryunosoke Satoro

Welcome to your Ruby on Rails Application Monitoring 101.

This post is the last part of a three part series about monitoring your Ruby on Rails app with influxdb-rails. Make sure to check them all out!

The Ying and Yang of measurements

Basically there are two types of measurements we do. How often something happened and how long something took. Both types are most often complementary, interconnected and interdependent. On the performance dashboard we count for instance how many requests your application is serving.

A Grafana Panel plotting requests per minute

We also look at the time your application spends on doing that.

A Grafana Panel plotting requests per minute

At some point the number of requests will have an influence on the time spend (oversaturation). If one of your actions is using too many resources it will have influence on the number of requests you are able to serve (overutilization). Ying and Yang.

The minions of measurements

Looking at the graphs above you see some helpers at work you should know about.

Time

First and foremost: Time Windows. The requests are counted per minute and we look at measurements in the last hour. Time windows help to lower information density and make your measurements a bit more digestible. Look at the same measurements per second for the last 12 hours. 60 times 24 higher information density. Not so easy to interpret anymore...

A Grafana Panel plotting requests per second

Statistics

The same way time windows will make it easier for you to understand your data, some descriptive statistics will help you too. For instance calculating the maximum time 99% of requests in the last minute took. Like we did above. I won't bore you to death with the math behind this, if you're into this checkout wikipedia or something. Just remember, it makes data digestible for you. Look at the same performance data without applying statistics.

A Grafana Panel plotting requests per second

Grouping

The third helper that makes data understandable for you is grouping data. Like ActiveJobs per minute grouped by queue. That grouping might make more clear to you why the number of jobs so high. Or grouping requests per minute by HTTP Status might reveal how much stuff goes wrong.

A Grafana Panel plotting requests per second

A different form of grouping is to visualize all measurements connected to a specific event, like a single request. Or all the measurements a specific controller action has fired in the last hour.

A Grafana Panel plotting requests per second

Rankings

Another thing we do on the dashboard is ranking (groups of) events by time, slow to fast. So you know where you might want to concentrate your efforts to improve performance.

A Grafana Panel plotting requests per second

Apply your knowledge, let's collaborate on Rails APM/AHM

Maybe I inspired some ideas for new features in the 101 above? I'm also sure there are many people out in the Rails community that have way more knowledge and ideas about statistics, measurements and all the tools involved than Chris and me. Let's work together, patches to the collection of dashboards (and the Ruby code) are more than welcome!

Why build, not buy?

But Henne, you say, there is already Sentry, New Relic, Datadog, Skylight and tons of other services that do this. Why build another one? Why reinvent the wheel?

Because Software Libre is an deeply evolutionary process. Software Libre, just like Evolution, experiments all the time. Many experiments find their niche to exist. Some even go global.

A tire graveyard

Coronavirus: BW CG Illustration by Yuri Samoilov

Like Linux, the largest install base of ALL operating systems on this planet. Wordpress powering an unbelievable 30% of the top 10 million websites. Mediawiki running the 5th most popular site globally. But also, more than 98% of all projects on GitHub are not seeing any development beyond the first year they were created. Just like 99% of all species that ever lived on Earth are estimated to be extinct.

We need to experiment and collaborate together. Evolution is what we do baby! 🤓 Can't run, copy, distribute, study, change and improve the software SaaS providers run. We can't scratch our itch, can't break it, learn how it works and make it better together, that's why. Let's do this!

Mar 25th, 2021

Album Art – Plasmoides de KDE (174)

Nuevo plasmoide para la lista de esos pequeños programas que decorar, informan o aumentan las funcionalidades de nuestro escritorio Plasma de la Comunidad KDE. En esta ocasión se trata de Album Art, un simple widget que nos muestra la carátula de la canción que estemos reproduciendo y con el que llegamos a 174 plasmoides presentados en el blog.

Album Art – Plasmoides de KDE (174)

Aunque es más habitual tener un controlador multimedia para controlar la reproducción de música como MediaBar, Mediacontroller Plus o Media Controller Compact, habrá gente que solo le interese que aparezca solo una imagen de la canción que está escuchando.

Y eso es justamente lo que nos ofrece Album Art, un plasmoide de quank123wip que muestra la imagen de la portada (o cualquier otra variante) en nuestro escritorio.

Album Art - Plasmoides de KDE (174)

Y como siempre digo, si os gusta el plasmoide podéis “pagarlo” de muchas formas en la nueva página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day 2017 de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

¿Qué son los plasmoides?

Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.

En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.

El cliente de correo para Android K9mail busca financiación

K9mail es un cliente de correo electrónico para sistemas Android que realiza su tarea de una forma eficiente y eficaz y además es software libre

Desde hace años el cliente de correo electrónico que utilizo en mi dispositivo Android es K9mail. Por ser eficaz, por ser eficiente y por ser software libre.

Ya escribí un artículo sobre este cliente de correo electrónico:

Ahora vuelvo a dedicarle un artículo para dar a conocer que el desarrollador de este software está pidiendo financiación para poder seguir con el proyecto de una manera más dedicada a desarrollarlo.

El desarrollador de K9mail, comunicaba en su blog oficial, que quien quisiera podía contribuir con el proyecto donando dinero. Eso le permitiría dedicarle más esfuerzo y recursos a desarrollar y mejorar su cliente de correo.

Sí, puedes descargar y utilizar este software de manera gratuita, así que ¿por qué ibas a pagar por su uso? Bueno, yo lo he hecho, porque desde hace años está instalado en mi dispositivo y me permite gestionar mis correos electrónicos de manera eficaz.

Me gusta la aplicación y estoy muy contento de utilizarla, así que decido pagar al desarrollador para que siga dedicándole su tiempo y esfuerzo. Pago por software gratuito, siempre que sea libre y en este caso muy contento de hacerlo.

Así que si llega al objetivo de 1000 € a la semana en donaciones eso le permitirá poder dedicarle más tiempo, integrar nuevas funcionalidades, actualizar el software y corregir errores. Y comer, pagar facturas y darse algún capricho…

Pero además del dinero, también por supuesto puedes colaborar con código, traduciendo, ayudando a resolver dudas en el foro…

Yo ya he hecho mi aporte, puedes utilizar Liberapay para donar demanera recurrente o una donación puntual. ¿Te animas tu también?

Enlaces de interés

Super Resolution Video Enhancing with AMD GPU

I’ve had a somewhat recent AMD Radeon RX 560 graphics card in my Mini-ITX PC for over a year already, and one long term interest I have would be to be able to enhance old videos. Thanks to Hackweek I could look at this as one of the things that I’ve waited to have time for. In recent years there have been approaches to use eg neural networks to do super resolution handling of photos and also videos, so that there would be more actual details and shapes than what would be possible via normal image manipulation. The only feasible way of doing those is by using GPUs, but unfortunately the way those are utilized is a bit of a mess, most of all because proprietary one vendor only CUDA is the most used one.

On the open source side, there is OpenCL in Mesa by default and Vulkan Compute, and there’s AMD’s separate open source ROCm that offers a very big platform for computing but also among else OpenCL 2.x support and a source level CUDA to portable code (including AMD support) translator called HIP. I won’t go into HIP, but I’m happy there’s at least the idea of portable code being thrown around. OpenCL standardization has been failing a bit, with the newest 3.0 trying to fix why the industry didn’t adopt 2.x properly and OpenCL 1.2 being the actual (but a bit lacking) baseline. I think the same happened a bit with OpenGL 1.x -> 2.x -> 3.x a long time ago by the way… Regardless if the portable code is OpenCL or Vulkan Compute, the open standards are now making good progress forward.

I first looked at ROCm’s SLE15SP2 installation guide - interestingly, it also installed on Tumbleweed if ignoring one dependency problem of openmp-extras. However, on my Tumbleweed machine I do not have Radeon so this was just install test. I was however surprised that even the kernel module compiled against TW’s 5.11 kernel - and if it would have not, there’s the possibility of using upstream kernel’s module instead.

Over at the Radeon machine side, I installed ROCm without problems. Regardless of that SDK, many real world applications for video enhancing are still CUDA specific so would at minimum require porting to portable code with HIP. These include projects like DAIN, DeOldify etc. However, there are also projects using OpenCL and Vulkan Compute - I’ll take video2x as an example here that supports multiple backends, some of which support OpenCL (like waifu2x-converter-cpp) or Vulkan (like realsr-ncnn-vulkan). I gave the latter a try on my Radeon as it won the CVPR NTIRE 2020 challenge on super-resolution.

I searched my video collection far enough back in time so that I could find some 720p videos, and selected one which has a crowd and details in distance. I selected 4x scaling even though that was probably a time costly mistake as even downscaling that 5120x2880 video probably wouldn’t be any better than 2x scaling to 2560x1440 and eg downscaling that to 1920x1080. I set up the realsr-ncnn-vulkan and ffmpeg paths to my compiled versions, gave the 720p video as input and fired way!

And waited. For 3.5 hours :) Noting that I should probably buy an actual highend AMD GPU, but OTOH my PC case is smallish and on the other hand the market is unbearable due to crypto mining. The end result was fairly good, even if not mind blowing. There are certainly features it handles very well, and it seems to clean up noise a bit as well while improving contrast a bit. It was clearly something that would not be possible by traditional image manipulation alone. Especially the moving video seems like higher resolution in general. Maybe the samples I’ve seen from some other projects out there have been better, then OTOH my video was a bit noisy with movement blur included so not as high quality as would be eg a static photo or a video clip tailored to show off an algorithm.

For showing the results, I upscaled a frame from the original 1280x720 clip to the 4x 5120x2880 resolution in GIMP, and then cropped a few pieces of both it and the matching frame in the enhanced clip. I downscaled them actually then to 1440p equivalent crop. Finally, I also upscaled the original frame to FullHD and downscaled the enhanced one to FullHD as well, to be more in line what could be one actual desired realistic end result - 720p to 1080p conversion while increasing detail.

The “1440p equivalent” comparison shots standard upscale vs realsr-ncnn-vulkan.

crop1 original crop1 enhanced

crop2 original crop2 enhanced

The FullHD scaling comparison - open both as full screen in new window and compare.

original scaled to FullHD enhanced scaled to FullHD

Measure twice, cut once: App Performance Monitoring with influxdb-rails

Now that we learned how truly magnificent ActiveSupport::Notifications is in the previous post, let's explore a RubyGem Chris, others and me have built around this: influxdb-rails. Together with even more awesome Software Libre, it will help you to deep dive into your Ruby on Rails application performance.

This post ist part two of a three part series about monitoring your Ruby on Rails app with influxdb-rails. Make sure to check them all out!

Application Performance Monitoring (APM)

I'm not sure we have to discuss this at all anymore, but here is why I think I need application performance monitoring for my Ruby on Rail apps: I'm an expert in using the software I hack. Hence I always travel the happy path, cleverly and unconsciously avoid the pitfalls, use it with forethought of the underlying architecture. Because of that, I usually think my app is fast: perceived performance.

It's not what you look at that matters, it's what you see. – Henry David Thoreau

That is why I need someone to correct that bias for me, in black and white.

Free Software APM

The good folks at Rails bring the instrumentation framework. InfluxData deliver a time series database. Grafana Labs make a dashboard builder. All we need to do, as so often, is to plug Software Libre together: SUCCE$$!

InfluxDB + Grafana == 🧨

I assume your Rails development environment is already running on 127.0.0.0:300. Getting InfluxDB and Grafana is a matter of pulling containers these days. You can use this simple docker-compose configuration for running them locally.

# docker-compose.yml
version: "3.7"
services:
  influx:
    image: influxdb:1.7
    environment:
      - INFLUXDB_DB=rails
      - INFLUXDB_USER=root
      - INFLUXDB_USER_PASSWORD=root
      - INFLUXDB_READ_USER=grafana
      - INFLUXDB_READ_USER_PASSWORD=grafana
    volumes:
      - influxdata:/var/lib/influxdb
    ports:
      - 8086:8086
  grafana:
    image: grafana/grafana:7.4.5
    ports:
      - 4000:3000
    depends_on:
      - influx
    volumes:
      - grafanadata:/var/lib/grafana
volumes:
  influxdata:
  grafanadata:

A courageous docker-compose up will boot things and you can access Grafana at http://127.0.0.1:4000 (user: admin / password: admin). To read data from the InfluxDB container in Grafana, leave the /datasources InfluxDB defaults alone and configure:

URL: http://influx:8086
Database: rails
User: grafana
Password: grafana

influxdb-rails: 🪢 things together

The influxdb-rails RubyGem is the missing glue code for making your app report metrics into the InfluxDB. Plug it into your Rails app by adding it to your bundle.

bundle add influxdb-rails
bundle exec rails generate influxdb

The next time you boot your Rails dev-env it will start to measure the performance of your app. Now comes the interesting part, interpreting this data with Grafana.

Understanding Ruby on Rails Performance

Every time you use your dev-env, influxdb-rails will write a plethora of performance data into InfluxDB. Let's look at one of the measurements so you get an idea of what's going on. You remember the ActiveSupport::Notification called process_action.action_controller from the previous post? Rails sends this message every time an action in your controller has finished. It includes performance data for this action.

You should know this from somewhere: development.log! It contains the same information.

Started GET "/things" for 127.0.0.1 at 2021-03-25 15:20:14 +0100
...
Completed 200 OK in 5ms (Views: 4.1ms | ActiveRecord: 0.1ms | Allocations: 3514)

ThingsController#index took 5ms to finish overall, 4.1ms of those 5 in rendering, 0.1ms in querying the database. You find the same data for every request you make in your InfluxDB. Head over to http://127.0.0.1:4000/explore and let Grafana plot it for you.

A Grafana Panel plot

Only want to see how your views are performing? Change the field from controller to view. Magic 🪄 But this is only one out of many different ways to look at this measurement. All of the panels below use this one measurement and the data it brings to visualize controller actions.

Many different Grafana panel plots

And this is only one measurement, influxdb-rails reports around a dozen. Now I could send you off your way to learn about ALL. THE. SOFTWARE. involved, but that would be mean wouldn't it?

Ruby on Rails Dashboards

We, the Free Software community, are in this together! We collaborate on Ruby on Rails. We work together to make InfluxDB better. We cooperate to improve Grafana. Why not do the same for the dashboards to visualize Rails performance data? Let's collaborate! That is why we have build a couple of dashboards you can import. Just copy and paste the URLs into your Grafana.

Play a little, I will tell you about all the nitty gritty details in the last post of this series: Let's build Software Libre APM together

Yakuake | Drop-down Terminal Emulator on openSUSE

I was recently asked why I haven’t mentioned anything about Yakuake on CubicleNate.com so I decided to take the time and cover some of its features, what I did to modify it a smidge and why I use it. For starters, I don’t think the terminal is a “power user” function. I truly believe it … Continue reading Yakuake | Drop-down Terminal Emulator on openSUSE

KDE Blog cumple 13 años

Este año he estado más atento, y es que las vacaciones de fallas me han venido estupendo para centrarme un poco en el blog y prestarle la atención que se merecía. Y es que hoy 24 de marzo de 2021 KDE Blog cumple 13 años de publicación constante (la promesa de un artículo al día no se ha incumplido nunca) y sigue siendo mi forma de pagar a la Comunidad todo lo que me ha dado.

KDE Blog cumple 13 años

KDE Blog cumple 13 años

Todo se remonta a hace más de 10 años cuando decidí que una parte de mi vida la iba a dedicar a ayudar a los demás en su migración hacía el Software Libre y a reportar cómo solucionaba los problemas del día a día.

¿Y cómo pensé hacerlo? Dado que no sabía programar y que me venía muy grande el diseño o la traducción, decidí que haría lo mejor que sabía hacer: enseñar.

Y como en aquella época estaban de moda las bitácoras personales, decidí escribir un blog donde explicaría mis vicisitudes en este nuevo sistema de sistemas operativos GNU/Linux que llevaba un escritorio libre conocido por aquel entonces como KDE.

Lo he dicho muchas veces, cuando empecé no sabía casi nada, de hecho pienso que fui muy atrevido ya que en mi cabeza no existían conceptos bien formados de Comunidad, kernel, beta, Release Candidate, escritorio vs distribución, etc, de tal forma los errores que cometí fueron apoteósicos, … pero nadie murió por ello y me sirvió para ir creciendo y aprendiendo.

Como todos lo años, y este año especialmente, quiero agradecer el capote que me ofreció maslinux (aka Pedro) cuando cometí un desliz sin mala intenciones y se me echó encima toda una comunidad de usuarios de una web potente de la época. Muchas gracias Pedro.

Y, como es habitual, me gusta recordar la declaración de intenciones de KDE Blog:

[24 de marzo de 2008]
«Hola a todos y todas: Hoy se inaugura KDE Blog un nuevo blog en el inmenso e infinito mundo de los blogs. El objetivo de este blog es múltiple: ayudar a los principiantes en el mundo Linux, informar sobre el mundo KDE, (el entorno de escritorio bajo Linux) y fomentar el uso del Software Libre.»

Aspecto en los primeros días del blog.

A pesar de la doce años pasados, la idea principal sigue válida aunque los artículos van cambiando de temática porque cada vez es más difícil hacer entradas explicando cómo hacer las cosas o solucionar problemas, lo cual es positivo, y cada vez más voy dedicando el blog a eventos y podcast.

Y es que cada vez más gente utiliza GNU/Linux y el Software Libre cada vez tiene una alta calidad (está a la altura y supera al privativo en muchos aspectos) aunque sigo opinando que el gran salto solo se dará cuando los dispositivos que compre la gente ofrezcan GNU/Linux por defecto.

Mientras tanto, el KDE Blog blog seguirá siendo mi granito de arena en la promoción del Software Libre y de la Comunidad KDE.

Los años siguen siendo complicados pero se mantienen las entradas diarias

KDE Blog cumple 13 años

Esto se repite año a año ya que igual que el 2020 mis obligaciones familiares, académicas y laborales me dejan poco tiempos para poder dedicarlo al blog. No obstante, este año me he organizado mejor y apenas tengo problemas para poder escribir… en mis tiempos vacacionales suelo redactar lagunas entradas que me alivian en épocas más estresantes.

De esta forma, sigo publicando de forma diaria sin demasiadas dificultades ya que el entorno no deja de ofrecerme decenas de eventos, colaboraciones, podcast y servicios, los cuales debo admitir que parece que han aumentado en estos tiempos pandémicos.

En cuento a mis actividades fuera del blog quisiera destacar que:

A lo largo de estos 13 años he ido publicando entradas conmemorativas que podéis seguir en la siguiente etiqueta, en las cuales se resumen muy bien los sentimientos y la historia del blog, y como este año no tengo tiempo y apenas han cambiado os invito a leer para no repetirlo.

Renovación de votos

Los votos no cambian, al parecer he llegado a un momento de estabilidad, y mi compromisos con la Comunidad KDE se mantienen:

  • KDE Blog sigue teniendo cuerda para muchos años,
  • Sigo estando ilusionado con el proyecto KDE y en su difusión.
  • Sigo abierto a todo tipo de colaboraciones (¿quieres ayudar a publicar en el blog? ¿Encargarte de la parte social? ¿Mejorar las entradas? Mándame un correo [bortega@kde_espana.org] y hablamos)
  • Y para finalizar decir que me siento orgulloso de pertenecer a un movimiento cuyo objetivo es compartir su conocimiento en pro de una evolución más rápida de la humanidad, que se concreta en pertenecer a una Asociación de Software Libre como KDE España.

Así que:

¡Muchísimas gracias a todos por seguirme!

Los registros numerados en #Vim

Veamos los registros numerados que dispone el editor Vim y cómo poder usar esta gran herramienta al editar

El editor Vim dispone de 10 tipos de registros que almacenan ciertos textos en una u otras circunstancias.

  1. El registro sin nombre ("").
  2. Los registros numerados ("0-9).
  3. El registro de pequeñas eliminaciones ("-).
  4. Los registros nominales ("a-z).
  5. El registro de solo lectura (":, ".,y "%).
  6. El registro de archivo alternativo ("#).
  7. El registro de expresiones ("=).
  8. Los registros de selección ("* y "+).
  9. El registro de agujero negro ("_).
  10. El registro del último patrón de búsqueda ("/).

En este artículo vamos a fijarnos en los registros numerados que dispone el editor Vim. Vamos a conocerlos y saber cómo utilizarlos mientras editamos con Vim.

Este artículo es una nueva entrega del curso “improVIMsado” que desde hace meses vengo publicando en mi blog sobre el editor Vim y que puedes seguir en estos enlaces:

Los registros numerados almacenan ciertos textos que copiamos o borramos. Vamos a ver cómo funcionan. Cabe diferenciar en los registros numerados el registro 0 y los registros del 1 al 9.

Podemos consultar los textos almacenados en los registros numerados (entre otros registros que dispone Vim y que si os apetece veremos en otras ocasiones) ejecutando el comando:

:reg

Primero vamos a repasar los registros numerados. Y después veremos cómo podemos usarlos.

El registro numerado 0

El registro 0 almacena el último texto copiado, ya sea un único caracter (yl), una palabra (yiw), línea (yy), etc. El texto nuevo copiado sustituirá al anterior, pero mientras no copiemos otro texto, nuestro texto copiado estará disponible en este registro.

Los registros numerados del 1 al 9

Cuando borramos una línea (dd) o cuando cambiamos una línea (cc) ese texto queda almacenado en los registros numerados del 1 al 9. Y los distintos textos se almacenan como si fueran una pila.

Es decir, el primer texto se almacena en el registro 1, cuando borramos otra línea, el texto del registro 1 pasa al 2 y el nuevo texto se almacena en el registro 1. Y así de manera consecutiva hasta el registro 9.

Cómo utilizar los registros numerados.

Ya hemos visto qué se almacena en cada registro numerado. El 0 sería el registro de copia, y del 1 al 9 las líneas borradas y cambiadas que se van almacenando progresivamente.

Esos textos almacenados los podemos utilizar para pegarlos tantas veces como deseemos.

Para pegar esos textos, cualquiera de ellos del 0 al 9, estando en el modo normal de Vim podemos ejecutar:

"xp

Donde las comillas dobles se refieren al registro, la x la sustituiremos por el número de registro que queremos pegar y la p la acción. Si usamos la p pega el texto después del cursor. Si usamos la P antes del cursor.

Por ejemplo, si queremos pegar el contenido del registro 2, sería:

"2p

Una curiosidad, si después de ejecutar esa acción usamos el comando del punto, Vim en la repetición del comando incrementará el registro utilizado.

Es decir en el ejemplo anterior que hemos pegado el registro 2, si ahora repetimos la acción usando el punto, Vim pegará el registro 3, si lo repetimos pegará el registro 4, etc…

Pero también podemos utilizar los registros estando en el modo insertar, en vez de usar las comillas dobles, deberemos hacerlo con la combinación de teclas Ctrl-r n. Donde n sería el número de registro que queremos pegar.


Espero que esta explicación haya sido aclaratoria del modo de utilizar los registros y os sea útil a la hora de mejorar vuestra experiencia usando el edito Vim.

¿Conocías esta funcionalidad? ¿Os ha resultado útil? ¿Queréis que escriba sobre los otros registros? Usad los comentarios para dar vuestra opinión.