From: Peter Stuge <peter@stuge.se>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] About DESCRIPTION in ebuilds needing to end with a dot "."
Date: Sat, 20 Oct 2012 16:27:05 +0200 [thread overview]
Message-ID: <20121020142705.15162.qmail@stuge.se> (raw)
In-Reply-To: <1350713353.12879.57.camel@belkin4>
[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]
Pacho Ramos wrote:
> > So, rephrasing the example Alexandre pasted, consider:
> >
> > x11-libs/qt-core - The Qt toolkit is a comprehensive C++ application
> > development framework.
> >
> > vs.
> >
> > x11-libs/qt-core - A comprehensive C++ application development framework
> >
> > Which one is better, in your opinion?
>
> Well, I my case I would prefer second
I agree, I also like the second example.
> sentence...
http://en.wikipedia.org/wiki/Sentence_(linguistics)#Major_and_minor_sentences
Suggests that even a phrase such as the second example above can be
called a (minor) sentence.
> but it would still end with a dot.
I think that looks ugly and is redundant.
Especially if we were to require that all DESCRIPTION phrases must
always be presented with a full stop, I think it is a very bad idea
to enforce that they are written into the ebuilds. Especially if
there is a rule that they will always be terminated by a full stop
then that should and must be added by tools using the ebuild.
It makes absolutely no sense to have so frequent redundant data in
ebuilds, and it seems like full stop or no full stop is a matter of
presentation policy and should thus happen during presentation.
> But if it sounds rare for you, no problem.
ebuilds are markup and not formatting IMO, and the two shouldn't be
confused. If you want to work on presentation (which is important
too!) then go for it, but in any case I don't think a full stop at
end of descriptions is really worth the cost. All user interfaces are
shitty enough already, and users are unable to deal with information
already, so please don't add redundancy like full stops would be to
the problem.
//Peter
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2012-10-20 14:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-19 19:01 [gentoo-dev] About DESCRIPTION in ebuilds needing to end with a dot "." Pacho Ramos
2012-10-19 19:27 ` Doug Goldstein
2012-10-19 19:36 ` Thomas Sachau
2012-10-19 21:25 ` vivo75
2012-10-20 10:09 ` Ulrich Mueller
2012-10-20 16:51 ` Jeroen Roovers
2012-10-19 20:17 ` Alexandre Rostovtsev
2012-10-19 20:37 ` Michał Górny
2012-10-19 22:37 ` Rich Freeman
2012-10-20 6:09 ` Pacho Ramos
2012-10-20 14:27 ` Peter Stuge [this message]
2012-10-20 14:32 ` Pacho Ramos
2012-10-20 16:14 ` Michał Górny
2012-10-20 10:12 ` Samuli Suominen
2012-10-21 1:34 ` Ben de Groot
2012-10-21 6:37 ` Pacho Ramos
2012-10-21 4:35 ` [gentoo-dev] " Ryan Hill
2012-10-22 4:42 ` Jeroen Roovers
2012-10-30 7:18 ` [gentoo-dev] " Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121020142705.15162.qmail@stuge.se \
--to=peter@stuge.se \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox