2013/4/26 Markus Mohrhard markus.mohrh...@googlemail.com
But if not the above, I would let the original code be, i.e. revert the
change.
Then please revert. I like how all people who never touched the file
decide the formatting of this file. Oh and the next time you think one of
my calc
On 04/26/2013 12:54 AM, Markus Mohrhard wrote:
If Eike or Kohei disagree with my formatting we can roll it back.
I have the same personal preference as Markus actually. I dislike these
type of aligned tables unless we know that the values would never become
too long, which, for these
On 04/26/2013 02:22 AM, Markus Mohrhard wrote:
2013/4/26 Markus Mohrhard markus.mohrh...@googlemail.com
mailto:markus.mohrh...@googlemail.com
But if not the above, I would let the original code be, i.e.
revert the change.
Then please revert. I like how all people who
Hi *,
What's the benefit of shorter lines compared to formatted table?
http://cgit.freedesktop.org/libreoffice/core/commit/?id=d691181f9ead97bba8970759255ba64f6c26aee6
I personally find the previous one much easier to read. Is it
rule/guideline not to use formatting?
ciao
Christian
2013/4/26 Christian Lohmaier lohma...@googlemail.com
Hi *,
What's the benefit of shorter lines compared to formatted table?
http://cgit.freedesktop.org/libreoffice/core/commit/?id=d691181f9ead97bba8970759255ba64f6c26aee6
Any line longer than 100 characters makes it harder to read it if you
Perhaps a good compromise would be to use a very local macro to abbreviate
the identifiers in the table, and keep the entries as one line, with
alignment of columns, but shorter:
static SvXMLTokenMapEntry aTableRowCellAttrTokenMap[] =
{
#define _(N,T,A) XML_NAMESPACE_##N, XML_##T,
But if not the above, I would let the original code be, i.e. revert the
change.
Then please revert. I like how all people who never touched the file decide
the formatting of this file. Oh and the next time you think one of my calc
changes does not fit your style guide please directly revert.
