From Edgar Vincent to ~protesilaos/modus-themes
Hello everyone, On 21/11/2023 11:18, Protesilaos Stavrou wrote: > Hello Mekeor, > > There is no specific reason. Of course, we can always come up with some > fancy story behind this choice, but I don't have one right now. > > Have a nice day, > Prot > I assumed that the naming implied that one worked (the generic, mechanical *zoè*) during the day and lived (a full, qualified, vital *bios*) during the night.
From Edgar Vincent to ~protesilaos/general-issues
On 15/09/2023 14:07, Protesilaos Stavrou wrote: > Hello Edgar, > > I remember we discussed this before, but forgot what the outcome was. I > did not have regular access to the Internet in the meantime and so I am > still out of sync. If you can summarise the issue, it will be easier. > > All the best, > Prot > Certainly. My suggestion was related to the default order of beframe buffers in the context of its integration with Consult as described in the
From Edgar Vincent to ~protesilaos/general-issues
Tony Zorman <soliditsallgood@mailbox.org> writes: > Hi, Hello Tony, > maybe I'm misreading this, but to me it sounds like Edgar is exactly > talking about the functionality that was implemented in that patch. At > least, the commit mimics what `consult–buffer-sort-visibility' does for > consult, which seems to produce the desired behaviour. > > @Edgar: maybe you missed it in the manual (or use an older version of > beframe), but `beframe-buffer-names' can take a sorting function, like > this:
From Edgar Vincent to ~protesilaos/general-issues
Hi Prot, I am using beframe with the consult-buffer integration that you mention in the manual. I noticed that, when using it, the first buffer in the list is the current buffer, which contradicts the behaviour of `beframe-switch-buffer', which itself mimics `switch-to-buffer''s behaviour by placing the buffer returned by `other-buffer' at the top of the list. I suggest that the default behaviour look like this instead: ┌──── │ (defun beframe-buffer-sort-other (buffers) │ "Sort BUFFERS by placing the most recently selected buffer first. │ │ Return a sequence that first lists the result of `other-buffer', then the other │ buffers.
From Edgar Vincent to ~bzg/emacsfr
Bonjour Sébastien, Peut-être ai-je mal compris ta question, mais `imenu', intégré à Emacs, ferait-il l'affaire ? Il ne « plie » pas le code, mais en affiche la structure dans un nouveau tampon. Il y a également `ts-fold', qui, comme son nom l'indique, permet, lui, de « plier » le code et qui se base sur tree-sitter (plutôt que sur des expressions régulières, comme le fait `imenu'). Edgar
From Edgar Vincent to ~protesilaos/logos
Thanks, Prot! 21 Jun 2023 21:05:11 Protesilaos Stavrou <info@protesilaos.com>: >> From: Edgar Vincent <e-v@posteo.net> >> Date: Wed, 21 Jun 2023 14:57:01 +0000 >> >> Hi Prot, > > Hello Edgar, > >> I just discovered logos and, as usual, it looks like exactly what I am looking for. >> I noticed that `logos-narrow-dwim' wouldn't widen buffers when called a second time. I >> believe that this is caused by a malformed (cond …) condition. You'll find a patch which fixes the
From Edgar Vincent to ~protesilaos/logos
Edgar Vincent <e-v@posteo.net> writes: > Hi Prot, > > I just discovered logos and, as usual, it looks like exactly what I am looking for. > I noticed that `logos-narrow-dwim' wouldn't widen buffers when called a second time. I > believe that this is caused by a malformed (cond …) condition. You'll find a patch which fixes the > issue attached to this email. > > In the patch, I took the liberty to replace (null) with (not), which I think is more idiomatic > in conditions. > > I hope the work on the hut is leaving you time to breath; consider my support to be > somehow attached to this email too.
From Edgar Vincent to ~protesilaos/logos
Hi Prot, I just discovered logos and, as usual, it looks like exactly what I am looking for. I noticed that `logos-narrow-dwim' wouldn't widen buffers when called a second time. I believe that this is caused by a malformed (cond …) condition. You'll find a patch which fixes the issue attached to this email. In the patch, I took the liberty to replace (null) with (not), which I think is more idiomatic in conditions. I hope the work on the hut is leaving you time to breath; consider my support to be somehow attached to this email too. Edgar
From Edgar Vincent to ~bzg/emacsfr
"l@tlo" <lists@traduction-libre.org> writes: >> On Jun 7, 2023, at 19:22, Edgar Vincent <e-v@posteo.net> wrote: >> >> Lucien Cartier-Tilet <lucien@phundrak.com> writes: >> […] >>> "l@tlo" <lists@traduction-libre.org> writes: >>> >>>> Bonjour, >>>> >>>> Je suis dans la dernière ligne droite pour écrire mes 100+ pages de >>>> mémoire de master, et je fatigue un peu avec la police monospace par >>>> défaut pour org. >>>>
From Edgar Vincent to ~bzg/emacsfr
Lucien Cartier-Tilet <lucien@phundrak.com> writes: […] > "l@tlo" <lists@traduction-libre.org> writes: > >> Bonjour, >> >> Je suis dans la dernière ligne droite pour écrire mes 100+ pages de >> mémoire de master, et je fatigue un peu avec la police monospace par >> défaut pour org. >> >> J'aimerais bien avoir une police pas monospace (comment on dit ça ?) >> pour le texte normal, et une police monospace pour les tables (parce >> que c'est pénible d'avoir les champs décalés). >>