The original discussion about string cropping started at https://github.com/firebug/firebug/pull/34.

What should be implemented/improved? At the moment we just have one general pref for string cropping named extensions.firebug.stringCropLength and one for the lines inside the Script panel called extensions.firebug.maxScriptLineLength. And for many other strings we have a fixed cropping length.

To make things more flexible we should introduce more cropping prefs. The question is whether we should add a pref for each string type or just a few general ones. Many different prefs allow the greatest flexibility but can also be confusing and need more work when wanting to adjust many different strings. A few general cropping settings allow adjusting the cropping for many different strings inside the UI at the same time but also don't allow individual settings.

Sebastian

I just saw that we already have some other preferences related to specific string cropping:

extensions.firebug.cache.responseLimit extensions.firebug.displayedAttributeValueLimit extensions.firebug.netDisplayedPostBodyLimit extensions.firebug.netDisplayedResponseLimit extensions.firebug.netParamNameLimit

Unfortunately we have two naming conventions: "Limit" and "Length". I suggest to also change "Limit" to "Length" within this issue to unify them. "Limit" should better be used for prefs, which limit the number of displayed elements, as we already do for e.g. extensions.firebug.console.logLimit.

Sebastian

Nice summary.

Some others: extensions.firebug.textWrapWidth (this one is not use to crop but break lines) extensions.firebug.sourceLinkLabelWidth

Agree, that the naming convention is not perfect, but please do not rename, it breaks users settings. Having nice docs like "How to customize string limits in Firebug UI" would be more effective.

Of course, having clean naming rules for future prefs is great idea.

Honza

Agree, that the naming convention is not perfect, but please do not rename, it breaks users settings. I'm aware of that. How about implementing something, which allows moving the user settings to the new prefs?

Having nice docs like "How to customize string limits in Firebug UI" would be more effective. Could be done additionally. Reminds me of having to rework the FAQs...

Of course, having clean naming rules for future prefs is great idea. Should we create another contributor rules page for this? Or reuse the stone, in which we already carved the rule about when to backport patches? ;-)

Sebastian

How about implementing something, which allows moving the user settings to the new prefs? It could be source of more problems.

I keep the same attitude as with the string-keys, the naming is not perfect, but it'll never be perfect and (constant) changing is rather a bad practice.

Reminds me of having to rework the FAQs... Yes! We need to discuss that, the current page is too complicated... https://getfirebug.com/wiki/index.php/FAQ

I like e.g. this page: http://aws.amazon.com/s3/faqs/#What_is_Amazon_S3

Should we create another contributor rules page for this? Or reuse the stone, in which we already carved the rule about when to backport patches? ;-) heh, yes there is a lot of free space on that stone.. :)

I don't know what rules we can come up with, do you have some suggestions?

Honza

I keep the same attitude as with the string-keys, the naming is not perfect, but it'll never be perfect and (constant) changing is rather a bad practice. It doesn't have to be perfect but at least good. :-) Changing wouldn't happen constantly but just once according to to-be-written rules as we have them for the coding style. Anyway, that's not something we would have to do immediately. If that requires more discussion, we should continue this somewhere else.

Yes! We need to discuss that, the current page is too complicated... https://getfirebug.com/wiki/index.php/FAQ

I like e.g. this page: http://aws.amazon.com/s3/faqs/#What_is_Amazon_S3 Actually I already started with that some months ago. I'll send you an email with what I have so far.

I don't know what rules we can come up with, do you have some suggestions? A few, but here's not the place to discuss them. I'll set up a page for these things.

Sebastian