Hi list,
attached patch (against 1528:b4f5309d6253) allows to name the tags for
each monitor. You can name your tags for as many monitors as you like.
If you still have more monitors, it uses the last defined as a fallback
for these.
Also included is a slight modification of Evan Gates' nametag pa
Hi there,
I wanted a menu that would allow me to select entries both from the
uzbl history and from google suggest 'as you type' (like in firefox).
While dmenu allows selecting entries in a static list (like uzbl
history) easily, modifying this list and providing hints to google
suggest did not se
On Fri, 26 Nov 2010 14:38:10 +0100
Christophe-Marie Duquesne wrote:
> Hi there,
>
> I wanted a menu that would allow me to select entries both from the
> uzbl history and from google suggest 'as you type' (like in firefox).
> While dmenu allows selecting entries in a static list (like uzbl
> his
Hey,
On 26 November 2010 14:04, Dieter Plaetinck wrote:
> I would prefer if it works like this:
> - when you invoke dmenu, it immediately appears, and user can start
> typing input. as soon as dmenu is started, it starts reading stdin,
> however fast or slow it goes until EOF.
> - anytime anythin
Connor Lane Smith writes:
> Hey,
>
> On 26 November 2010 14:04, Dieter Plaetinck wrote:
>> I would prefer if it works like this:
>> - when you invoke dmenu, it immediately appears, and user can start
>> typing input. as soon as dmenu is started, it starts reading stdin,
>> however fast or slow i
On 26 November 2010 15:43, Connor Lane Smith wrote:
> On 26 November 2010 14:04, Dieter Plaetinck wrote:
>> I would prefer if it works like this:
>> - when you invoke dmenu, it immediately appears, and user can start
>> typing input. as soon as dmenu is started, it starts reading stdin,
>> howeve
On 26 November 2010 15:27, Anselm R Garbe wrote:
> Well the question is if the bottleneck is the input writer or dmenu
> reading the input. The problems I remember from the past where all
> related to the input writer (for example dmenu_path taking some time
> to create it's output) but not dmenu
On Fri, Nov 26, 2010 at 3:04 PM, Dieter Plaetinck wrote:
> the delay caused by dmenu waiting for stdin input to be complete
> is noticeable.
Actually, while performance also matters, the thread thing is not
primarily a matter of fast processing. It is just that if you wait for
the input to finish
On 26 November 2010 15:30, Connor Lane Smith wrote:
> That's fair. We could do some testing to see whether dmenu reading a
> *lot* of data from a pipe is noticeably slow, or whether it's just
> dmenu_path's sorting (which obviously we can't do anything about).
That said, if the source of the pipe
On 26 November 2010 16:30, Connor Lane Smith wrote:
> On 26 November 2010 15:27, Anselm R Garbe wrote:
>> Well the question is if the bottleneck is the input writer or dmenu
>> reading the input. The problems I remember from the past where all
>> related to the input writer (for example dmenu_pat
On 26 November 2010 15:33, Christophe-Marie Duquesne
wrote:
> > The threaded input is neat, and I am perfectly willing to
> > add it into dmenu proper. Though I expect others will not share that
> > willingness.
>
> It isn't. I experimented a crash when messing with it, so expect to find bugs.
I
On Fri, Nov 26, 2010 at 4:36 PM, Anselm R Garbe wrote:
> With vanilla dmenu
>
> seq 10 | dmenu
>
> works instantaneously for me. I see some 2s lack if I increase to seq
> 100 | dmenu though.
> But is 1M items a usual scenario? I kind of doubt that and the 2s
> penalty doesn't sound too bad
On 26 November 2010 16:33, Christophe-Marie Duquesne
wrote:
> On Fri, Nov 26, 2010 at 3:04 PM, Dieter Plaetinck wrote:
>> the delay caused by dmenu waiting for stdin input to be complete
>> is noticeable.
>
> Actually, while performance also matters, the thread thing is not
> primarily a matter o
On 26 November 2010 16:43, Anselm R Garbe wrote:
> On 26 November 2010 16:33, Christophe-Marie Duquesne
> wrote:
>> On Fri, Nov 26, 2010 at 3:04 PM, Dieter Plaetinck
>> wrote:
>>> the delay caused by dmenu waiting for stdin input to be complete
>>> is noticeable.
>>
>> Actually, while performan
On Fri, Nov 26, 2010 at 04:42:36PM +0100, Christophe-Marie Duquesne wrote:
> On Fri, Nov 26, 2010 at 4:36 PM, Anselm R Garbe wrote:
> > With vanilla dmenu
> >
> > seq 10 | dmenu
> >
> > works instantaneously for me. I see some 2s lack if I increase to seq
> > 100 | dmenu though.
> > But is
Hello,
This patch seems to fix (at least for me) garbled multibyte titles.
--
Regards,
Michał Kazior.
tabbed-0.3-fix-multibyte-titles.diff
Description: Binary data
On Fri, 26 Nov 2010 16:33:51 +0100
Christophe-Marie Duquesne wrote:
> On Fri, Nov 26, 2010 at 3:04 PM, Dieter Plaetinck
> wrote:
> > the delay caused by dmenu waiting for stdin input to be complete
> > is noticeable.
>
> Actually, while performance also matters, the thread thing is not
> primar
Here's a quick fix to pass the opt_cmd to $SHELL -c, which fixes a
bug where you couldn't call -e with a command with spaces (arguments
to that command).
I earlier tried to pass the command directly to execvp() by using
strsep to set args, but the code turned out to be far too complex
(I think).
d
Josh and I were discussing this over IRC. Here's an alternative patch I
came up with. It relies on the shell that executes st to parse the
arguments, so you can't run a command like st -e "touch arst", you have
to run st -e touch arst. This also means you can't have any st arguments
after the -e be
19 matches
Mail list logo
