~e-v

~e-v/edgar-vincent-public-inbox

Last active 4 months ago
View more

Recent activity

Re: Why is vivendi dark and operandi bright - and not the other way around? 15 days ago

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.

Re: beframe: in Consult integration, return '(other-buffer)' first? 2 months ago

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

Re: beframe: in Consult integration, return '(other-buffer)' first? 5 months ago

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:

beframe: in Consult integration, return '(other-buffer)' first? 5 months ago

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.

Re: Quels outils pour l'édition / exploration de code? 5 months ago

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

Re: [PATCH] Fix (cond ...) in `logos-narrow-dwim' 5 months ago

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

Re: [PATCH] Fix (cond ...) in `logos-narrow-dwim' 5 months ago

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.

[PATCH] Fix (cond ...) in `logos-narrow-dwim' 5 months ago

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

Re: Jolies polices pour org etc. 5 months ago

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.
>>>> 

Re: Jolies polices pour org etc. 5 months ago

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).
>>