Re: select patch

Thanks for your response,

I sometimes have multiple browser windows open, and some programs like 
gimp spawn multiple windows with the same name,
when I have lots if windows open, this comes in handy as I do not have 
to remember the window number or cycle through all with next/previous.

 From what I understood, I can use somthing like strncmp(a,b,40) for the 
exact match and strncmp(a,b,strlen(a)) for the prefix match.
Will this work as expected?
strnlen() seems to be a GNU extension and I don't want to break 
compability with other libcs
In this case strlen(a) should be safe as it is used  in the parent 
function cmd_select() (a is the argument for the select function).
Merging the two blocks will be sensible of course once we agree on how 
to implement it.
Now I think there are three options how to implement my idea
The behavior is a bit odd, of course. But the default select does depend 
on the order too: It selects the first matching name.
     - Make a new function - I don't like this because it would increase 
redundancy (I would just copy the majority of the current cmd_select())
     - Make cmd-select() accept an additional bitmask or so, so that it 
could vary its behaviour,
       then bind ("select", "select-next", ...) to those - I don't know 
if this is possible, seems a bit hacky
     - Add a new ratpoison setting ("selectstyle") to control its behavior
The last is my favourite option because it seems like it will give more 
flexibility while (probably) not needing much SLOC.
For example it could be a bitmask like this:
     the first bit decides if we want to select the first(presumably the 
oldest) or last(youngest) window in the list
     the second one if it should cycle through the matching windows
     (etc)

Best Regards,
Johannes Altmanninger

On 06/18/2014 08:51 PM, Jeff Abrahamson wrote:
> Thanks for the contribution.  Your C isn't so bad.
>
> I have three small quibbles:
>
>   * Using raw strcmp() isn't a very good idea -- if one of the strings
>     is not null-terminated, you introduce a subtle bug.  Prefer
>     instead strncmp() and strnlen().  This requires defining some
>     reasonable upper limit on window names, of course.
>   * The two blocks are almost the same, the only difference is the
>     string compare.  It would be nice to merge them into one.
>   * My opinion only, but I don't actually like the behavior.  It makes
>     sense to me to skip the current window in the search, but it seems
>     odd to me to have behavior depend on the current numbered ordering
>     of windows.  At the very least, to my mind this should be an
>     option that is off by default (i.e., preserves current behavior)
>     or else a new function (select-next).
>
> Out of curiosity, why do you find it convenient to name multiple 
> things with the same name?
>
> Regards,
>
>
> Jeff Abrahamson
> +33 6 24 40 01 57   <-- brièvement indisponible le 4 juillet
> +44 7920 594 255  <-- will change 18 July
>
> http://jeff.purple.com/
> http://blog.purple.com/jeff/
>
>
> On 17 June 2014 17:41, Johannes Altmanninger <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     The default "select" command (disregarding window numbers) selects
>     the first exact match,
>     if there is none, the argument is matched against the beginning of
>     each window name,
>     again selecting the first match.
>     I have shortcuts to select my each of my windows by their name,
>     but sometimes i have more
>     than one window with the same name. I wrote a script to alternate
>     between them but I think
>     it is more appropriate as a native feature.
>     The attached patch adds a function to find a window by name, if
>     there is more than one returns
>     the match after the currently selected. The select command is
>     changed to use this function.
>
>     I am pretty new to C, so please let me know if I am doing
>     something horribly wrong.
>
>     Johannes Altmanninger
>
>     _______________________________________________
>     Ratpoison-devel mailing list
>     [email protected] <mailto:[email protected]>
>     https://lists.nongnu.org/mailman/listinfo/ratpoison-devel
>
>

_______________________________________________
Ratpoison-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/ratpoison-devel