I've attached a new patch for the logging.
> - Don't add new calls to status_replace please. Use format API directly > instead. The new patch does this. > - These option names aren't great. How about automatic-log and > automatic-log-format (or automatic-log-file)? Yeah, I didn't care for them either. I've used your suggestions. > - The hunk in cmd_set_option_exec is ridiculously nested and way over > the 80 column line length. If you use a helper function it should be > fine. I've split this chunk of code up. > - In the same part, do not remove options the user set on windows when > the global option is changed, just leave them alone and don't change > the logging state for that window. You can just call option_get_number > on w->options and it'll give you the global if the window option is > not set. I've implemented this. > - In cmd_split/new_window_exec you shouldn't call cmdq_error and then > not return an error. Either clean up and make the command fail, or > change it to cmdq_info. I didn't think the failure to log should prevent the creation of the window/pane so I went with cmdq_info. > - Why do you need cmd_string_expand_path? Isn't this already done when > the set-option command is parsed? If not either it should be or > variable expansion should be added for all string options not just > one. cmd_string_parse() chops off the first # character and everything after it unless you put it in quotes. I imagined most people would use the #-options in the logfile name, so they'd use quotes. But when you quote the filename, tildes don't get expanded. Also, while cmd_string_parse() would do variable expansion when you typed a command, the default logfile name is set in the options table, so the name didn't go through cmd_string_parse(), and I needed a way to expand it. So I wanted a function that would take care of both things. But I see that it isn't great to come up with special string arg handling for 1 option. I've removed the function. People will have to quote a filename like ~/tmux-#x-#y-#z.log for set-option like they'd quote anything else. As for the default logfile name, I removed the tilde so I don't need a special function there. > - I'd rather avoid any new files. These functions are small and used > once, they can go somewhere else. Since the logging is enabled/disabled in cmd-set-option.c, that's where I've put the logging functions. > - Can't the logging fd use a bufferevent too? I wasn't clear on whether libevent supports bufferevents on regular files. Your question seemed to suggest that it does, and you'd know better than I would, so that's how the logging is done now.
logging.patch
Description: Binary data
------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
