I don't know if you are offended but you sound a bit like it and there
is no need, this thread is not a criticism of your work. The default
changed, it makes the code better but it doesn't seem as usable... so
what? It happens to everyone. And I don't think it's bikeshedding, the
layout is a fairly big chunk of text to be adding to choose-windows by
default and people do use it a lot.

If it makes things significantly simpler to have one define, I think I
would consider trimming bits from list-windows and force people to add
them back with -F rather than adding them to choose-windows. But I don't
know, like you pointed out the other day we have a contract with users
and breaking everyone's scripts is not something to do just to save a
couple of LOC. 100 is a different matter :-).

But for now I'll apply your diff and if it is a bit wart on your next
change then we can think again?


On Sun, May 27, 2012 at 11:27:56PM +0100, Thomas Adam wrote:
> Hi,
> 
> On Sun, May 27, 2012 at 10:45:00PM +0100, Nicholas Marriott wrote:
> > I don't mind having DEFAULT_CHOOSE_* and DEFAULT_LIST_* separately, I
> > don't much like having the layout there, but it has to be in
> > list-windows output.
> 
> Well we've already set a precedent for adding information when assigning
> DEFAULT_* macros to format templates -- see cmd_list_windows.c where we
> prepend the #{session_name} when being passed "-a".  This realistically
> can't live in a #define without it being a pointless one.
> 
> I'll reiterate though that there's really only one conclusion this can come
> to; that the defaults are NOT the be-all-and-end-all, and that despite the
> benefits of allowing customisations with -F, if people don't want to do
> this, well that's a shame.  But I do not want to embark on a shed-painting
> exercise.  Shock horror, the defaults aren't quite the same as before.  You
> can't _really_ complain given the added bonus of being able to change them.
> 
> Given that I want to see the back of *one* of the {choose,list}-* commands
> anyway, and amalgamate the two to one command, I would rather we didn't
> separate out the functionality between DEFAULT_CHOOSE or DEFAULT_LIST as
> that just adds an annoying burden of overhead -- one we can easily avoid.
> 
> So see the following.  Enjoy.
> 
> diff --git a/trunk/cmd-list-windows.c b/trunk/cmd-list-windows.c
> index 5f4326a..a816a01 100644
> --- a/trunk/cmd-list-windows.c
> +++ b/trunk/cmd-list-windows.c
> @@ -84,7 +84,9 @@ cmd_list_windows_session(
>       if (template == NULL) {
>               switch (type) {
>               case 0:
> -                     template = DEFAULT_WINDOW_TEMPLATE;
> +                     template = DEFAULT_WINDOW_TEMPLATE \
> +                             " [layout #{window_layout}] #{window_id}" \
> +                             " #{?window_active, (active),}";
>                       break;
>               case 1:
>                       template = "#{session_name}:" DEFAULT_WINDOW_TEMPLATE;
> diff --git a/trunk/tmux.h b/trunk/tmux.h
> index 76c3033..7053658 100644
> --- a/trunk/tmux.h
> +++ b/trunk/tmux.h
> @@ -113,9 +113,7 @@ extern char   **environ;
>  #define DEFAULT_WINDOW_TEMPLATE                                      \
>       "#{window_index}: #{window_name}#{window_flags} "       \
>       "(#{window_panes} panes) "                              \
> -     "[#{window_width}x#{window_height}] "                   \
> -     "[layout #{window_layout}] #{window_id}"                \
> -     "#{?window_active, (active),}"
> +     "[#{window_width}x#{window_height}]"
>  #define DEFAULT_PANE_INFO_TEMPLATE                           \
>       "#{session_name}:#{window_index}.#{pane_index}"
>  
> 
> -- Thomas Adam
> 
> -- 
> "Deep in my heart I wish I was wrong.  But deep in my heart I know I am
> not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users

Reply via email to