Re: Ping Packagers

[Dustin Kirkland]

On Mon, Dec 21, 2009 at 10:33 AM, Sadrul Habib Chowdhury
<address@hidden> 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