On 11 November 2010 23:59, TJ Robotham wrote:
> Meh, I can't really think of a particularly compelling reason to put config.h
> back in, but from the perspective of someone who was using it, its removal
> feels strange and arbitrary and a bit like someone insisting that I get out of
> bed at some
On Thu, Nov 11, 2010 at 06:59:03PM -0500, TJ Robotham wrote:
> Meh, I can't really think of a particularly compelling reason to put config.h
> back in, but from the perspective of someone who was using it, its removal
> feels strange and arbitrary and a bit like someone insisting that I get out of
On Thu, Nov 11, 2010 at 10:31:44PM +, Connor Lane Smith wrote:
> Not in tip. My argument is, if you want to configure defaults just add
> an override dmenu script to your path:
>
> > #!/bin/sh
> > /usr/local/bin/dmenu -fn ... -bg ...
>
> Easier than recompiling imo, and means everyone on a mu
On 11 November 2010 21:54, TJ Robotham wrote:
> Uh ... dmenu does have a config.h file. If all of your dmenu scripts use the
> same colour and font overrides you can easily save yourself the trouble by
> changing the default colours and font - which is what I wound up doing over a
> year ago, prob
Because #ifdef is the epitome of portability. Everyone knows that.
On Nov 11, 2010 4:05 PM, "Josh Rickmar" wrote:
> On Thu, Nov 11, 2010 at 08:04:32PM +0100, Danilo Bargen wrote:
>> Hello all
>>
>> In case anyone is interested: I've added logging capabilities to
>> Slock. The patch is attached. It
On Thu, Nov 11, 2010 at 04:54:28PM -0500, TJ Robotham wrote:
> On Thu, Nov 11, 2010 at 02:40:54PM -0500, Peter John Hartman wrote:
> > I've made this request before, and always get yelled at, but it would be
> > nice if dmenu had a config.h file which allowed one to override the default
> > keybind
On Thu, Nov 11, 2010 at 02:40:54PM -0500, Peter John Hartman wrote:
> I've made this request before, and always get yelled at, but it would be
> nice if dmenu had a config.h file which allowed one to override the default
> keybindings, set a default color/font, and so on and so forth.
>
> Peter
On Thu, Nov 11, 2010 at 08:04:32PM +0100, Danilo Bargen wrote:
> Hello all
>
> In case anyone is interested: I've added logging capabilities to
> Slock. The patch is attached. It will enable logging of all locks,
> unlocks and failed unlock attempts to ~/.slock.log, if compiled with
> the ENABLE_L
On 11 November 2010 18:36, Michael Farnbach wrote:
> Would you say that dwm, being a much longer more persistent environment
> manager, benefits from the stability of being only one configuration for the
> duration of that session? Conversely, dmenu, is more instantaneous and has
> application tha
On Sun, Nov 7, 2010 at 10:50 PM, Moritz Wilhelmy wrote:
> Whatever you want, wchar_t is not the solution.
Amen.
Added it to the cat-v fortunes file:
http://fortunes.cat-v.org/cat-v/
uriel
On Tue, Nov 9, 2010 at 6:06 AM, Jens Staal wrote:
> There is an rc version in the svn repository though.
Out of principle I refuse to touch anything stored in a svn repository.
And really, the whole problem space is wrong, if you need an 'init
system' your system is already FUBAR.
If your init
On Thu, Nov 11, 2010 at 04:37:37PM +, Connor Lane Smith wrote:
> On 11 November 2010 16:00, Michael Farnbach wrote:
> > Hey, this brings up a question.
> > I've noticed that suckless's apps push as many configuration items into the
> > compile time as they can (just a high-level observation, I
Excerpts from Dmitry Maluka's message of Thu Nov 11 19:17:26 +0100 2010:
> C++ish declarations should be removed. Patch attached.
It's actually C99-ish declaration and thus valid.
Declaring loop variables before the loop is pointless.
Hello all
In case anyone is interested: I've added logging capabilities to
Slock. The patch is attached. It will enable logging of all locks,
unlocks and failed unlock attempts to ~/.slock.log, if compiled with
the ENABLE_LOGGING flag.
--Danilo
diff -up /tmp/slock-0.9/config.mk slock-0.9/config.m
On Thu, Nov 11, 2010 at 9:37 AM, Connor Lane Smith wrote:
> On 11 November 2010 16:00, Michael Farnbach
> wrote:
> > Hey, this brings up a question.
> > I've noticed that suckless's apps push as many configuration items into
> the
> > compile time as they can (just a high-level observation, I'm
C++ish declarations should be removed. Patch attached.
On Thu, Nov 11, 2010 at 11:41:58AM +, Connor Lane Smith wrote:
> Hey,
>
> On 11 November 2010 05:25, Dan Brown wrote:
> > Why is this patch of interest? I call it "filtermode" because it uses
> > dmenu to generate a list of matches, with
On 11 November 2010 16:00, Michael Farnbach wrote:
> Hey, this brings up a question.
> I've noticed that suckless's apps push as many configuration items into the
> compile time as they can (just a high-level observation, I'm not saying it
> is actually a rule of thumb.)
This is certainly true fo
Hey, this brings up a question.
I've noticed that suckless's apps push as many configuration items into the
compile time as they can (just a high-level observation, I'm not saying it
is actually a rule of thumb.)
So would the choice between a dmenu filter and a dmenu, well menu, be made
at compil
On 11 November 2010 14:59, markus schnalke wrote:
> In contrast to the filter mode, with caseless matching you would *see*
> that it behaves differently. And you see which item will get printed.
Fair point, though considering your vi example it is like hitting 'i'
and it telling you that it's doi
You're not actually considering pushing this into mainline dmenu, are you?
--
# Kurt H Maier
[2010-11-11 14:08] Connor Lane Smith
> On 11 November 2010 14:02, Connor Lane Smith wrote:
> > I do agree there should be some sort of indication like this, but I
> > don't think it's that easy. Right now all I can think of is changing
> > the prompt, like dwm does when its behaviour changes with
On 11 November 2010 14:02, Connor Lane Smith wrote:
> I do agree there should be some sort of indication like this, but I
> don't think it's that easy. Right now all I can think of is changing
> the prompt, like dwm does when its behaviour changes with the layout
> symbols.
I'd also like to point
On Thu, 11 Nov 2010 14:53:32 +0100
markus schnalke wrote:
> [2010-11-11 14:36] Dieter Plaetinck
> > On Thu, 11 Nov 2010 14:12:59 +0100
> > markus schnalke wrote:
> >
> > > Note that the user might not be able to know in which mode dmenu
> > > acts at run-time.
> >
> > why wouldn't he? if a d
On 11 November 2010 13:37, Petr Sabata wrote:
> It might also be useful to allow the user to change the mode while dmenu
> is running.
As Dieter said, I can't really see a use case for this. There are
commands which can only logically take a single input (eg, dmenu_run)
and giving users the optio
[2010-11-11 14:36] Dieter Plaetinck
> On Thu, 11 Nov 2010 14:12:59 +0100
> markus schnalke wrote:
>
> > Note that the user might not be able to know in which mode dmenu acts
> > at run-time.
>
> why wouldn't he? if a dmenu appears on a users' screen, it appears
> because the user configured/in
On Thu, Nov 11, 2010 at 02:12:59PM +0100, markus schnalke wrote:
> [2010-11-11 12:47] Dieter Plaetinck
> > On Thu, 11 Nov 2010 12:36:23 +0100
> > sta...@cs.tu-berlin.de wrote:
> >
> > > * Anselm R Garbe [2010-11-11 12:19]:
> > > > On 11 November 2010 06:25, Dan Brown wrote:
> > > > > As part of
On Thu, 11 Nov 2010 14:12:59 +0100
markus schnalke wrote:
> Note that the user might not be able to know in which mode dmenu acts
> at run-time.
why wouldn't he? if a dmenu appears on a users' screen, it appears
because the user configured/installed a script/keybinding/tool that
spawns the dmen
[2010-11-11 12:47] Dieter Plaetinck
> On Thu, 11 Nov 2010 12:36:23 +0100
> sta...@cs.tu-berlin.de wrote:
>
> > * Anselm R Garbe [2010-11-11 12:19]:
> > > On 11 November 2010 06:25, Dan Brown wrote:
> > > > As part of a project to create a simple and fast music player
> > > > interface, I patche
On 11 November 2010 11:47, Dieter Plaetinck wrote:
> you mean you want to choose between "return current result" vs "return
> all current matches" at run-time? What's a use case for that?
> I think this should be configured with a commandline argument, because
> the script that calls dmenu needs
On Thu, 11 Nov 2010 12:36:23 +0100
sta...@cs.tu-berlin.de wrote:
> * Anselm R Garbe [2010-11-11 12:19]:
> > On 11 November 2010 06:25, Dan Brown wrote:
> > > As part of a project to create a simple and fast music player
> > > interface, I patched dmenu to allow it to return all matching
> > > it
* Anselm R Garbe [2010-11-11 12:19]:
> On 11 November 2010 06:25, Dan Brown wrote:
> > As part of a project to create a simple and fast music player
> > interface, I patched dmenu to allow it to return all matching items
> > instead of just the one at the cursor. dmenu is the browsing
>
> This p
Hey,
On 11 November 2010 05:25, Dan Brown wrote:
> Why is this patch of interest? I call it "filtermode" because it uses
> dmenu to generate a list of matches, with interactivity similar to the
> trendy "instant" style of searching. For applications working with
> sets of items, this method could
Hi,
On 11 November 2010 06:25, Dan Brown wrote:
> As part of a project to create a simple and fast music player
> interface, I patched dmenu to allow it to return all matching items
> instead of just the one at the cursor. dmenu is the browsing
> interface; and there is another mode of operation
On Wed, 10 Nov 2010 21:25:09 -0800
Dan Brown wrote:
> Hello and thanks everyone.
>
> As part of a project to create a simple and fast music player
> interface, I patched dmenu to allow it to return all matching items
> instead of just the one at the cursor. dmenu is the browsing
> interface; and
34 matches
Mail list logo
