On Mon, Dec 21, 2009 at 10:33 AM, Sadrul Habib Chowdhury <[email protected]> wrote: > 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?
I think 100 sounds reasonable. > [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? Yes, definitely! I don't care much about the syntax, but having this would be very nice, I think. >> >> 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. Okay, I'll try to help the user construct a backtick command that would provide this information to his sessions. > 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 Perfect, thanks. :-Dustin _______________________________________________ screen-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/screen-users
