Re: select patch

Oh, Johannes, you also asked about string comparison functions.  I don't
know a reason.  Maybe Jeremie has an opinion?
Code cleanup is usually a good thing, though.


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 25 June 2014 22:51, Jeff Abrahamson <[email protected]> wrote:

> It looks very good, thanks!
> Want to update the docs?  ;-)
> Disclaimer:  I haven't tested this myself.
>
> +Jérémie, since I think he may be the only one with commit privileges.
>
>
> 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 24 June 2014 14:22, Johannes Altmanninger <[email protected]>
> wrote:
>
>> Thanks for your help! There is a whole lot to learn for me..
>> I corrected most issues you pointed out, this keeps getting better ;)
>> I changed the default behavior to prefer unselected windows, the option
>> to change it is still there. Most users would probably not care too much
>> about this I guess.
>> Now there is a function called get_compare_string_function() which is
>> used in select_name(). It takes the match_type bitmask and the address of
>> compare_length.
>> I am not sure how I would implement a function that does not take the
>> match type as argument.
>> I noticed that there are 8 occurrences of str_comp(), is there a reason
>> why this is not replaced by `!strncasecmp()`?
>>
>>
>> On 06/23/2014 04:30 PM, Jeff Abrahamson wrote:
>> > Funny how documentation is always the trailing bit. ;-)
>> > This is looking very nice.  Thanks for all your work on this!
>> > A couple (easy) comments:
>> > Just delete the stuff you're deleting, don't comment it out. Git
>> remembers what was there before, and it just makes your diffs longer.  I
>> know it's useful while you're developing.
>> > I'm acutely aware that I'm the guy who called for the optional behavior
>> -- but the more I think about it, the more I think the default should be
>> the behavior you propose.  It is a very good idea.
>> > On that subject, the name "SELECT_SIMPLE" seems prejudiced by the old
>> behavior and otherwise devoid of meaning.  What do you think of
>> SELECT_OK_SELECTED ?
>> > When you define MAX_WINDOW_NAME_LENGTH, I think the value is arbitrary,
>> just long enough to distinguish between valid and invalid strings in
>> reasonable time.  Perhaps include a comment to that effect so that future
>> readers don't pause to wonder on the significance of that number.
>> > Personal tick:  Functions are most readable below ten or so lines.  By
>> the time I can't see the whole function in my editor, I have more trouble
>> understanding as I read.  In that light, and without remarking on other
>> examples of such, perhaps find_window_name() could easily be broken into a
>> helper function or two (with local linkage), such as a
>> >
>> >     compare_window_name_function window_name_matcher(size_t&
>> compare_length).
>> >
>> > 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/
>>
>>
>

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