[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RP] libhistory-support.
From: |
Jeremie Courreges-Anglas |
Subject: |
Re: [RP] libhistory-support. |
Date: |
Mon, 07 Aug 2017 20:13:46 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (berkeley-unix) |
On Sun, Jul 30 2017, Martin Hertz <address@hidden> wrote:
> After thinking about it, then as ratpoison has implemented internal history
> support itself, then maybe enabling libhistory support and adding to
> resource-usage, wouldn't be the best solution, and I only also wanted a
> single option from said lib, which was the search-in-history completion
> function(e.g. 'ch<arrow-up>' becomes 'chromium', or 'sou<arrow-up>' becomes
> 'source .ratpoisonrc' etc, which in libhistory is enabled with a preceding
> exclamation-mark), which possibly could be implemented anyway additionally
> later on, in the internal history support if deemed appropriate.
Being able to search in the ratpoison history using C-r, etc looks like
a nice feature, maybe it could be implemented in a simple fashion.
> Btw, i'm sorry I cannot contribute myself (yet), as a noob in C
> programming, but im doing what I can to learn it currently :)
As someone that uses C almost every day, I can only support that
effort. :)
> Unrelated, sorry, but I previously read about adding mouse-focus to frames,
> though not by default... I have no say in this obviously, but I would hope
> it would then be as an external compile option and external file, like
> sloppy.c, and not going into main-code. Personally I find this highly
> strange, that there's a demand for such and think it's highly
> misplaced,
I personnally don't care at all about mouse-focus suport. And fact that
you care about a feature doesn't mean that I - or anyone - *has* to
implement it. This is free software, you're not a client.
> but of course as said, none of my business, and I respect the maintainers
> decision on this obviously.
As I already said on this list, mouse-focus support is likely to be
accepted if someone actually takes the time to discuss and implement it,
from scratch or using the work done by folks like Jeff Abrahamson.
> A final unrelated note, is that I would love if xft got disabled by default
> - it more than doubles memory usage and imho doesn't seem to fit into a
> small fast keyboard-centric wm, but that's just my humble opinion. though
> i've seen plenty state the same around the web - of course the only ones
> deserving a vote on this, is the actual maintainer and coding-contributors,
> I of course understand and respect.
I'm unlikely to disable Xft support by default given that non-Xft looks
ugly even to me, and most people have tons of ram and high-resolution
screens. If you build ratpoison yourself you can disable it, or ask
your distro to disable it by default.
> Thanks for keeping ratpoison alive everyone, it's very much appreciated!
Sure. :)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
signature.asc
Description: PGP signature