* Dustin Kirkland had this to say on [20 Dec 2009, 21:18:04 -0600]: [snip] > >> 33increase_max_winmsg_renditions.dpatch > > > > I think 256 is a bit too excessive. I am going to increase it to 128 > > instead, which I honestly think should be more than enough. > > Hmm, what's the actual cost? Some memory? How much? Would it be > realistic to make this dynamically allocated?
The cost of increasing to 256 is not much, in fact, it can be increased to an even larger value, say 1024, without causing any performance issues. But it wouldn't make any sense to me. > I maintain a project that provides a layer on top of Screen called > Byobu. We make heavy use of the hard status formatting with a series > of several dozen toggle on/off status scripts. With 1920x1080 > displays, and an 8 pitch font, there's a lot of room across the bottom > of the screen. > > See for an example this screenshot (with almost everything toggled on): > http://rookery.canonical.com/~kirkland/Byobu.png uh, ew! > For each color change, I also use \005{-} to "undo" it, and bring it > back to the native color. This means that each color change costs 2 > against that 128 or 256 number. They add up quickly. > > I appreciate your bumping it up to 128. We will probably continue to > carry a patch for 256 in Ubuntu. Assuming it's not too expensive, it > would be nice if you would reconsider. Thanks. Let's put it this way, I will definitely reconsider if someone is trying to use a caption/hardstatus string that requires more than 128 changes ;) > > I am also considering increasing the oft requested window limit. That > > will probably require a bit more work than just changing the define. > > Definitely would be nice. I'm currently hitting the limit at 40 > windows. What are you thinking for a limit? Again, a dynamic malloc > would be nice (haven't looked at the code to judge the feasibility, > though). I don't think there will be much of a problem using dynamic malloc in the current code. However, it can be problematic for when we merge in the scripting support. For example, a script could store the window pointers somewhere, and use them in a callback. A dynamic malloc will either cause this to crash, or require complicated checks in the script (or the script loaders). So to keep it 'forward-compatible', perhaps increase the default limit to 100, and allow increasing the limit only when creating a new session. How does that sound? [snip] > > > >> 56-source-file-not-found-warning.dpatch > > > > I disagree with this change. I think the error message is appropriate. > > Understood. Would you support an additional, new directive that would > source-if-found, but throw no warning if not? Something like > "-source" or "@source" a la Makefile syntax? Perhaps 'source -q'? I quite like the idea of a generic syntax for suppressing error messages for all commands, using '@' or somesuch as a prefix, though. So either 'source -q' or all '@command' will suppress the error messages. Sounds good? > >> 58-show-encoding-hardstatus.dpatch > > > > I don't like this patch. I wouldn't want more string escapes unless they > > are really useful. In this case, I am not convinced that showing the > > encoding in the caption is all that useful. This information is available > > in 'info'. Is there a use case where that's not enough? > > I'm not sure. An Ubuntu user complained about this, and provided a > patch that seemed to work for me. It didn't bother me as a packager, > so I included it. If it's ill-advised, or evil somehow, I can drop it > and inform the user that upstream rejected it. The problem here is this: the caption/hardstatus string is way too complex as it is. Adding more clutter to it is only going to make things worse. So unless really necessary, I plan to not add any more escapes. In this case, if there is a use-case that the user needs to be aware of the encoding in a particular window frequently enough, then this issue can be reconsidered. Eventually, when scripting support comes in, this kind of thing will be more possible, and users can add anything in there. But for now, what we have, is what we have :) "Perfection is reached not when there is nothing left to add, but when there is nothing left to take away." is the philosophy I am trying to follow. [snip] > > > > I can't get the rest of them at the moment, setting an "Internal Server > > Error" from launchpad. > > Sorry about that. There was a Launchpad maintenance window recently, > maybe you hit that. Yep, they came back up. But I haven't had a chance to look at them yet. > Thanks for going over these! > > In the future, what's the currently preferred mechanism for patch > submission? Devel mailing list, bug tracker, or otherwise? I think I would prefer the bug-tracker at savannah [1]. That way there's less chance of a patch getting lost. Any activity in the bug-tracker will now send mails to the devel mailing list, too. [1] https://savannah.gnu.org/bugs/?group=screen Cheers, Sadrul _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
