It seems many packagers have committed new summary text for their packages, and I thank you all for that.
Next on my list are insane descriptions. For instance, just take a look at the description for enlightenment (many pages in length) and various packages using ``quoting'' or ''quoting''. Many packages also try to do a bullet list using '*' or '-', usually with a random amount of spacing.
Question 1: Should we use '', "", or the UTF-8 quote characters? If we use LaTeX style ``double'' and `single' formatters then it's trivial for the session programs to either use ˵˶ or «» depending on the locale.
Question 2: What's the maximum permitted length of a description? For some stuff like enlightenment there's a short essay in the description.
Question 3: How should a description be bulletted? Using '*' or the UTF-8 '•' marker?
One such example:
-------------------------------------------------------------- Mousepad is a text editor for Xfce based on Leafpad. The initial reason for Mousepad was to provide printing support, which would have been difficult for Leafpad for various reasons.
Although some features are under development, currently Mousepad has following features:
* Complete support for UTF-8 text * Cut/Copy/Paste and Select All text * Search and Replace * Font selecton * Word Wrap * Character coding selection * Auto character coding detection (UTF-8 and some codesets) * Manual codeset setting * Infinite Undo/Redo by word * Auto Indent * Multi-line Indent * Display line numbers * Drag and Drop * Printing --------------------------------------------------------------
Now, this format makes it very difficult for PackageKit to display the description test in a sane way. PackageKit already joins lines together to fit properly on the word-wrapped length, but preserving paragraph markers.
If the bullet format was: -------------------------------------------------------------- Although some features are under development, currently Mousepad has following features:
* Complete support for UTF-8 text * Is has multiple features of note * Like this one * But this is not important * And this one --------------------------------------------------------------
The session tools could do multilevel indenting with the correct locale UTF-8 character (•, ‣, etc).
Comments please.
Richard.
Le Lun 15 décembre 2008 16:37, Richard Hughes a écrit :
Next on my list are insane descriptions.
Specs files and most notably human-targeted text inside them are UTF-8. Please do not invent any broken application-side transcoding system. Writing correctly encoded text is the packager and translator responsability.
If the fugly ASCII-zation some packagers use offends you, 1. write a best practices wiki page with recommended UTF-8 sequences 2. get it reviewed/approved by FPC and FESCO 3. open bugs for offending packages 4. get some broken-ASCII checks added to our package linting/review tools.
This is how our guidelines process works, it's long and bureaucratic but it ensures everyone has its say and no gratuituous bikesheding is pushed on packagers.
Question 2: What's the maximum permitted length of a description?
What matters is not the description length but its quality and usefulness to users. Some domains use long descriptions, because the target audience expects them.
Note that that because rpmlint insists on forcing 79 character line-wraps to help dumb terminal users, it's effectively impossible right now to get correct paragraph flow and breaks in descriptions (aye for optimizing the minority case at the expense of everyone else).
Nicolas Mailhot wrote:
Le Lun 15 décembre 2008 16:37, Richard Hughes a écrit :
Next on my list are insane descriptions.
Specs files and most notably human-targeted text inside them are UTF-8. Please do not invent any broken application-side transcoding system. Writing correctly encoded text is the packager and translator responsability.
+1
If the fugly ASCII-zation some packagers use offends you,
- write a best practices wiki page with recommended UTF-8 sequences
- get it reviewed/approved by FPC and FESCO
- open bugs for offending packages
- get some broken-ASCII checks added to our package linting/review
tools.
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII. Description is an area almost completely left to the maintainer's discretion (we've talked to the enlightenment maintainer about taking out some of the marketing-speak but otherwise kept a pretty much hands-off approach).
ASCii can be useful on the console whether the system is setup with a utf-8 locale (which is our default, and therefore if we do mandate using an encoding other than ASCii it's what we should use) or something more limited (for instance, Asian countries still haven't settled on utf-8 everywhere.)
Note that this is an area where I'd change my stance if package maintianers were to say that they want to have this sort of change. I just want to avoid alienating maintainers with conformance to this sort of rule on descriptions without a higher return.
This is how our guidelines process works, it's long and bureaucratic but it ensures everyone has its say and no gratuituous bikesheding is pushed on packagers.
+1
Question 2: What's the maximum permitted length of a description?
What matters is not the description length but its quality and usefulness to users. Some domains use long descriptions, because the target audience expects them.
+1
Note that that because rpmlint insists on forcing 79 character line-wraps to help dumb terminal users, it's effectively impossible right now to get correct paragraph flow and breaks in descriptions (aye for optimizing the minority case at the expense of everyone else).
If we were to mandate an encoding standard, we could make this work similar to how various wikis and blogs take plain-text input and turn it into formatted text. Given my penchant for python, I like ReStructuredText[1]_ for this but I'm sure we could get into a huge flamewar over the right text-formatting language to use.
.. _[1]: http://docutils.sourceforge.net/rst.html
-Toshio
Le lundi 15 décembre 2008 à 08:41 -0800, Toshio Kuratomi a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
And I'm opposed to continuing to abuse ASCII glyphs and pretend they stand for something other than their creators intended. One couldn't avoid it when the available encoding didn't provide a clean way to write some stuff, but doing it in 2008 is plain dumb.
People who want to write pure ASCII descriptions in UTF-8 locales just have to find a wording that does not put them in the situation where non-ASCII UTF-8 is the clean way to write things. They're no more special than the people whose stuff we refuse because it uses non-standard deprecated legacy encodings.
Description is an area almost completely left to the maintainer's discretion
The encoding isn't.
ASCii can be useful on the console whether the system is setup with a utf-8 locale (which is our default, and therefore if we do mandate using an encoding other than ASCii it's what we should use) or something more limited (for instance, Asian countries still haven't settled on utf-8 everywhere.)
But Red Hat and Fedora did. And our default Asian locales are UTF-8.
If someone acually wants a pure ASCII environment, he should work on an en_US@ASCII locale and stop trying to mess up the distro UTF-8 defaults.
Note that this is an area where I'd change my stance if package maintianers were to say that they want to have this sort of change. I just want to avoid alienating maintainers with conformance to this sort of rule on descriptions without a higher return.
Red Hat didn't choose UTF-8 over ASCII just to annoy ASCII users. UTF-8 brings very desirable text features. Letting the ASCII crowd mandate avoiding the use of non-ASCII UTF-8 negates the original encoding change decision, and brings back the stupid brittle transcoding hacks that UTF-8 was supposed to eliminate (as the OP message clearly shows).
I'd rather have our package descriptions look good in our default encoding and default GUI update tool than have them look good in marginally used legacy equipments that do not support current technical standards.
On Mon, 2008-12-15 at 19:18 +0100, Nicolas Mailhot wrote:
Red Hat didn't choose UTF-8 over ASCII just to annoy ASCII users. UTF-8 brings very desirable text features. Letting the ASCII crowd mandate avoiding the use of non-ASCII UTF-8 negates the original encoding change decision, and brings back the stupid brittle transcoding hacks that UTF-8 was supposed to eliminate (as the OP message clearly shows).
When we are talking about paragraph boundaries and lists, that leaves the area of 'transcoding hacks' and enters the realm or markup.
Le lundi 15 décembre 2008 à 13:34 -0500, Matthias Clasen a écrit :
On Mon, 2008-12-15 at 19:18 +0100, Nicolas Mailhot wrote:
Red Hat didn't choose UTF-8 over ASCII just to annoy ASCII users. UTF-8 brings very desirable text features. Letting the ASCII crowd mandate avoiding the use of non-ASCII UTF-8 negates the original encoding change decision, and brings back the stupid brittle transcoding hacks that UTF-8 was supposed to eliminate (as the OP message clearly shows).
When we are talking about paragraph boundaries and lists, that leaves the area of 'transcoding hacks' and enters the realm or markup.
This part is not “transcoding hacks”, it's letting paragraphs flow naturally instead of forcing 79-column lines and then eating all the LFs (including paragraph breaks) at yum/pk time in an effort to stitch the bits back together.
Le lundi 15 décembre 2008 à 21:52 +0200, Muayyad AlSadi a écrit :
Question 1: Should we use '', "", or the UTF-8 quote characters? If we
for some crazy reason unicode has removed mirrored proprietary from quotes
It's not some crazy reason. What you call left quote in ASCII was always defined as the grave accent. The grave accent was never a mirror of '. Some people abused it this way. With unicode there was no reason for the abuse to continue so it returned to its initial intended definition.
Le lundi 15 décembre 2008 à 21:50 +0100, Nicolas Mailhot a écrit :
Le lundi 15 décembre 2008 à 21:52 +0200, Muayyad AlSadi a écrit :
Question 1: Should we use '', "", or the UTF-8 quote characters? If we
for some crazy reason unicode has removed mirrored proprietary from quotes
It's not some crazy reason. What you call left quote in ASCII was defined as the grave accent.
(ISO TC 97/SC 2 meeting, October 29-31, 1963, according to http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html BTW)
It's not some crazy reason. What you call left quote in ASCII was always defined as the grave accent. The grave accent was never a mirror of '. Some people abused it this way. With unicode there was no reason for the abuse to continue so it returned to its initial intended definition.
--
I was talking about U+2018-U+201F not grave accent
so I suggest using "" quotes not any of U+2018-U+201F
U+2018 LEFT SINGLE QUOTATION MARK U+2019 RIGHT SINGLE QUOTATION MARK ... U+201C LEFT DOUBLE QUOTATION MARK U+201D RIGHT DOUBLE QUOTATION MARK
they are mirrors of each other they used to be so before things went out of mind
and the typographic directed quotation marks U+2018 and U+2019 as in < http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
this won't work because unicode no longer mark them as mirrors in Arabic one should write U+2019 then text then U+2018 ie. reversed because renderers no longer mirror them
On Monday 15 December 2008 10:18:11 am Nicolas Mailhot wrote:
Le lundi 15 décembre 2008 à 08:41 -0800, Toshio Kuratomi a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
And I'm opposed to continuing to abuse ASCII glyphs and pretend they stand for something other than their creators intended. One couldn't avoid it when the available encoding didn't provide a clean way to write some stuff, but doing it in 2008 is plain dumb.
Granted, UTF-8 glyphs can be abused as well; see %changelog in the following:
http://cvs.fedoraproject.org/viewvc/rpms/perl-Convert-UUlib/devel/perl-Conve... http://cvs.fedoraproject.org/viewvc/rpms/lzop/devel/lzop.spec?revision=1.14&...
You even used two different glyphs for "fixed the license"!
Regards,
Le lundi 15 décembre 2008 à 14:03 -0800, Conrad Meyer a écrit :
Granted, UTF-8 glyphs can be abused as well; see %changelog in the following:
None of those are proeminently exposed to users in the default distro installer and none of those pretend a glyph is something else than what it was defined.
On Mon, 2008-12-15 at 14:03 -0800, Conrad Meyer wrote:
Granted, UTF-8 glyphs can be abused as well; see %changelog in the following:
http://cvs.fedoraproject.org/viewvc/rpms/perl-Convert-UUlib/devel/perl-Conve... http://cvs.fedoraproject.org/viewvc/rpms/lzop/devel/lzop.spec?revision=1.14&...
Yeah, these always felt like "UTF-8 because I can!!" not actually adding value at all.
Nicolas Mailhot wrote:
Le lundi 15 décembre 2008 à 08:41 -0800, Toshio Kuratomi a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
And I'm opposed to continuing to abuse ASCII glyphs and pretend they stand for something other than their creators intended. One couldn't avoid it when the available encoding didn't provide a clean way to write some stuff, but doing it in 2008 is plain dumb.
I must have missed the 'fancy quotes' keys on my keyboard. Not to mention that ˵˶ don't seem to be in any of the fonts I'm using (newsreader, terminal, FF's text entry box...) and therefore show up as ugly boxes.
Le lundi 15 décembre 2008 à 19:16 -0600, Matthew Woehlke a écrit :
Nicolas Mailhot wrote:
Le lundi 15 décembre 2008 à 08:41 -0800, Toshio Kuratomi a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
And I'm opposed to continuing to abuse ASCII glyphs and pretend they stand for something other than their creators intended. One couldn't avoid it when the available encoding didn't provide a clean way to write some stuff, but doing it in 2008 is plain dumb.
I must have missed the 'fancy quotes' keys on my keyboard.
Complain to your xkb maintainer. Mine has «»“”‘’‚„
Nicolas Mailhot wrote:
Le lundi 15 décembre 2008 à 19:16 -0600, Matthew Woehlke a écrit :
Nicolas Mailhot wrote:
Le lundi 15 décembre 2008 à 08:41 -0800, Toshio Kuratomi a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
And I'm opposed to continuing to abuse ASCII glyphs and pretend they stand for something other than their creators intended. One couldn't avoid it when the available encoding didn't provide a clean way to write some stuff, but doing it in 2008 is plain dumb.
I must have missed the 'fancy quotes' keys on my keyboard.
Complain to your xkb maintainer. Mine has «»“”‘’‚„
And those would be what buttons again?
" is a clearly-marked key on my keyboard. Those others are not. Until mainstream keyboards (including "mainstream in the U.S.") have actual keys for fancy quotes, I think asking/requiring people to use something other than " is arguably unreasonable.
Saying "xkb supports it" doesn't help if I have no idea how to make xkb generate those characters (plus, what do I do if I'm not using X?).
Le mardi 16 décembre 2008 à 12:02 -0600, Matthew Woehlke a écrit :
Nicolas Mailhot wrote:
Le lundi 15 décembre 2008 à 19:16 -0600, Matthew Woehlke a écrit :
Nicolas Mailhot wrote:
Le lundi 15 décembre 2008 à 08:41 -0800, Toshio Kuratomi a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
And I'm opposed to continuing to abuse ASCII glyphs and pretend they stand for something other than their creators intended. One couldn't avoid it when the available encoding didn't provide a clean way to write some stuff, but doing it in 2008 is plain dumb.
I must have missed the 'fancy quotes' keys on my keyboard.
Complain to your xkb maintainer. Mine has «»“”‘’‚„
And those would be what buttons again?
Those would be whatever the maintainer of your xkb layout wants them to be. Adding this stuff to an xkb layout is not rocket science and has been possible for a long time.
" is a clearly-marked key on my keyboard. Those others are not. Until mainstream keyboards (including "mainstream in the U.S.") have actual keys for fancy quotes, I think asking/requiring people to use something other than " is arguably unreasonable.
There is not need to mark stuff on keyboards to assign keycodes to them and indeed several millions on people have generated the euro using unmarked keys for several years when it was introduced.
Saying "xkb supports it" doesn't help if I have no idea how to make xkb generate those characters (plus, what do I do if I'm not using X?).
Then you're not writing human text, you're writing computer code.
Nicolas Mailhot wrote:
Le mardi 16 décembre 2008 à 12:02 -0600, Matthew Woehlke a écrit :
And those would be what buttons again?
Those would be whatever the maintainer of your xkb layout wants them to be. Adding this stuff to an xkb layout is not rocket science and has been possible for a long time.
So one of they keys on my keyboard should do something other than what I expect?
Saying "xkb supports it" doesn't help if I have no idea how to make xkb generate those characters (plus, what do I do if I'm not using X?).
Then you're not writing human text, you're writing computer code.
Huh?
Le mardi 16 décembre 2008 à 12:36 -0600, Matthew Woehlke a écrit :
Nicolas Mailhot wrote:
Le mardi 16 décembre 2008 à 12:02 -0600, Matthew Woehlke a écrit :
And those would be what buttons again?
Those would be whatever the maintainer of your xkb layout wants them to be. Adding this stuff to an xkb layout is not rocket science and has been possible for a long time.
So one of they keys on my keyboard should do something other than what I expect?
Bzzt. On an average keyboard, about 50% of the alt-ed space is not marked and let to the implementators discretion. Without going into Canadian six-level key complexity, four-level xkb layouts are the norm and I dare you to find a keyboard where all four levels are marked.
Then you're not writing human text, you're writing computer code. Huh?
No efforts are expended by console maintainers to make it keep up with the curreent demands of human text. Its target is “debugging things gone wrong” ¹
¹ “I know the discussions I've had with distributions on these subjects they are thinking X is the user interface full stop, except for debug/things gone wrong.” (Alan Cox, 2008-12-01).
Nicolas Mailhot wrote:
Le mardi 16 décembre 2008 à 12:36 -0600, Matthew Woehlke a écrit :
Nicolas Mailhot wrote:
Le mardi 16 décembre 2008 à 12:02 -0600, Matthew Woehlke a écrit :
And those would be what buttons again?
Those would be whatever the maintainer of your xkb layout wants them to be. Adding this stuff to an xkb layout is not rocket science and has been possible for a long time.
So one of they keys on my keyboard should do something other than what I expect?
Bzzt. On an average keyboard, about 50% of the alt-ed space is not marked and let to the implementators discretion. Without going into Canadian six-level key complexity, four-level xkb layouts are the norm and I dare you to find a keyboard where all four levels are marked.
So you're infringing on shortcut space instead? Well... as long as you aren't using letters I suppose that isn't horrible (or else, using alt+shift), but doesn't solve how to tell people such key combinations exist in the first place.
(Sigh. I need to file a bug against TB not defaulting to utf8.)
Le mardi 16 décembre 2008 à 13:17 -0600, Matthew Woehlke a écrit :
Nicolas Mailhot wrote:
Bzzt. On an average keyboard, about 50% of the alt-ed space is not marked and let to the implementators discretion. Without going into Canadian six-level key complexity, four-level xkb layouts are the norm and I dare you to find a keyboard where all four levels are marked.
So you're infringing on shortcut space instead?
This is not “infringing on shortcut space” this is using a normal four-level or more xkb layout.
The vast majority of xkb layouts are four level. That includes the en_US intl layout which is probably the most used one.
Nicolas Mailhot wrote:
Le mardi 16 décembre 2008 à 13:17 -0600, Matthew Woehlke a écrit :
Nicolas Mailhot wrote:
Bzzt. On an average keyboard, about 50% of the alt-ed space is not marked and let to the implementators discretion. Without going into Canadian six-level key complexity, four-level xkb layouts are the norm and I dare you to find a keyboard where all four levels are marked.
So you're infringing on shortcut space instead?
This is not "infringing on shortcut space" this is using a normal four-level or more xkb layout.
What's the fourth level? Not alt, that's used for accelerators. Not ctrl, shift, meta, or any combination thereof, as those are for shortcuts. That leaves... menu, and combinations thereof. If menu+something does something special, I sure don't know about it.
You still haven't answered the education question.
Le mardi 16 décembre 2008 à 14:06 -0600, Matthew Woehlke a écrit :
What's the fourth level?
Read the xkb docs or look at the options the gnome keyboard switching applet offers you.
You still haven't answered the education question.
Education happens just like for any other computer stuff. If you want a more specific answer, start by an exhaustive description of the existing education solutions and why you feel they can't apply in this case.
On Tuesday 16 December 2008 20:06:57 Matthew Woehlke wrote:
What's the fourth level? Not alt, that's used for accelerators. Not ctrl, shift, meta, or any combination thereof, as those are for shortcuts. That leaves... menu, and combinations thereof. If menu+something does something special, I sure don't know about it.
You still haven't answered the education question.
It's usually "Alt Gr" or "AltGr" (alternative graphic) and that is (again, *usually*) the "right alt" key. My keyboard has it labelled that way, so it is not intended for accelerators.
Bill Crawford wrote:
On Tuesday 16 December 2008 20:06:57 Matthew Woehlke wrote:
What's the fourth level? Not alt, that's used for accelerators. Not ctrl, shift, meta, or any combination thereof, as those are for shortcuts. That leaves... menu, and combinations thereof. If menu+something does something special, I sure don't know about it.
You still haven't answered the education question.
It's usually "Alt Gr" or "AltGr" (alternative graphic) and that is (again, *usually*) the "right alt" key. My keyboard has it labelled that way, so it is not intended for accelerators.
I did, in fact, know that :-), and I understand that's typical of non-US keyboards. My US keyboard however has two keys labeled "Alt". Both of them do, in fact, work to activate the menu (or other accelerators).
...which is the point I was trying to make to Nicolas; when dealing with current US keyboards, there is no precedent for a compose key. That's a lot of inertia to overcome, and (to respond to Nicolas' other comment), there IS NO EDUCATION SYSTEM IN PLACE right now, that I am aware of.
I keep waiting for a proposal to fix that. I haven't heard one yet.
(Bill: I've sort of hijacked your post, sorry about that :-).)
On Thursday 18 December 2008 16:46:42 Matthew Woehlke wrote:
Bill Crawford wrote:
...
It's usually "Alt Gr" or "AltGr" (alternative graphic) and that is (again, *usually*) the "right alt" key. My keyboard has it labelled that way, so it is not intended for accelerators.
I did, in fact, know that :-), and I understand that's typical of non-US keyboards. My US keyboard however has two keys labeled "Alt". Both of them do, in fact, work to activate the menu (or other accelerators).
Ah, I see what you mean (you didn't spell that out and I was a little slow of thinking today for some reason).
...which is the point I was trying to make to Nicolas; when dealing with current US keyboards, there is no precedent for a compose key. That's a lot of inertia to overcome, and (to respond to Nicolas' other comment), there IS NO EDUCATION SYSTEM IN PLACE right now, that I am aware of.
Ah again. The compose thing is different altogether; my preferred key for that is the "right windows key" (not something that's expected by keyboard design) and in any case the idea of "compose key" isn't really expected by most people coming from another (Windows) universe either, so it doesn't really qualify as "intuitive" [wrong word, of course!] by most people's standards.
I keep waiting for a proposal to fix that. I haven't heard one yet.
That part isn't easily fixable (hire a truck with a loudspeaker to go around and tell people? reminds me of a scene from the Blues Brothers ...)
(Bill: I've sort of hijacked your post, sorry about that :-).)
If you meant me, no problem :o) if you meant the other Bill, I think he stopped reading the thread already ;o)
Le jeudi 18 décembre 2008 à 10:46 -0600, Matthew Woehlke a écrit :
...which is the point I was trying to make to Nicolas; when dealing with current US keyboards, there is no precedent for a compose key. That's a lot of inertia to overcome, and (to respond to Nicolas' other comment), there IS NO EDUCATION SYSTEM IN PLACE right now, that I am aware of.
So is your argument that because there is inertia, trying something new won't work, because inertia will necessarily win?
Or is your argument that takeup will be difficult in the US?
I hope you realise that Fedora is an international project, and that to overcome inertia, you need by definition to start something new in the first place.
Even MS has magic symbols on something similar to xkb's 3rd and 4th levels, and I've not seen it hurting either windows or US people in the USA.
People will be educated the way they are educated computer-side. Someone will RTFM or discover accidently the features, other people will notice he manages to input pretty stuff, and the tricks will spread.
So get some perspective. People manage this kind of computer novelty all the time. The markup Richard is so enamoured of is just as hard to educate about.
Nicolas Mailhot wrote:
So is your argument that because there is inertia, trying something new won't work, because inertia will necessarily win?
Or is your argument that takeup will be difficult in the US?
I've been saying that for the last several messages, and trying to get you to propose a means of starting to overcome said inertia.
I hope you realise that Fedora is an international project,
I do. I also realize that there is a certain amount of US influence on technology. (Some of it, alas, is from a certain Redmond company that doesn't care as much as they might about international users. Unfortunately, said company also exerts a lot of control on hardware, which is part of the problem.)
Even MS has magic symbols on something similar to xkb's 3rd and 4th levels, and I've not seen it hurting either windows or US people in the USA.
Um... no, those would be the META and MENU keys. As I already pointed out, one of those is already generally used for shortcuts. (And I'm saying that not just from personal experience, but also from usability discussions regarding assignment of shortcut keys.)
The markup Richard is so enamoured of is just as hard to educate about.
I disagree. I'm already exposed to that sort of markup, whereas I /don't/ have an AltGr / Compose key on my keyboard.
Perhaps in an absolute sense (i.e. starting with someone totally ignorant of both systems) that is true. In a practical sense, there is already inertia for markdown, if only because people do something similar to it already. While the playing field may be level for some people, I think that markdown is likely more wide-spread.
Le jeudi 18 décembre 2008 à 14:15 -0600, Matthew Woehlke a écrit :
Nicolas Mailhot wrote:
So is your argument that because there is inertia, trying something new won't work, because inertia will necessarily win?
Or is your argument that takeup will be difficult in the US?
I've been saying that for the last several messages, and trying to get you to propose a means of starting to overcome said inertia.
The means of overcoming inertia is to ignore it and do what you wanted to do anyway. The means of not overcoming inertia is to wait for something to overcome inertia to do stuff.
On Thu, 2008-12-18 at 21:27 +0100, Nicolas Mailhot wrote:
The means of overcoming inertia is to ignore it and do what you wanted to do anyway. The means of not overcoming inertia is to wait for something to overcome inertia to do stuff.
The way to get stuff done is to ask users to stick to a trivial standard (that most people are already using) that takes no more work. If you're asking packagers to paste random UTF-8 characters from "Character Map", into a spec file, then we've failed, as people are not going to do that.
Richard.
On Mon, 15 Dec 2008, Nicolas Mailhot wrote:
Le Lun 15 décembre 2008 16:37, Richard Hughes a écrit :
Next on my list are insane descriptions.
Specs files and most notably human-targeted text inside them are UTF-8. Please do not invent any broken application-side transcoding system.
+1.
If we make description (or any field) a special format and try to rely on it I think you'll find that ISVs and 3rd party providers of packages will ignore it/not know about it and then screw up PK. It's better to accept all sorts of wackiness and live with it. If the package maintainer wants their descriptions to be useful to people then they can clean them up to look better in PK.
Having said that an rpmlint check that says no description can be > than 512bytes might not be a terrible thing.
-sv
On Mon, Dec 15, 2008 at 7:37 AM, Richard Hughes hughsient@gmail.com wrote:
Although some features are under development, currently Mousepad has following features:
- Complete support for UTF-8 text
- Cut/Copy/Paste and Select All text
- Search and Replace
- Font selecton
- Word Wrap
- Character coding selection
- Auto character coding detection (UTF-8 and some codesets)
- Manual codeset setting
- Infinite Undo/Redo by word
- Auto Indent
- Multi-line Indent
- Display line numbers
- Drag and Drop
- Printing
Putting feature lists in descriptions is stupid. Obviously, you would have to update the description after each release which is stupid. It is most likely that feature lists in descriptions are simply cut & paste jobs from an upstream web site which is stupid.
On Mon, Dec 15, 2008 at 08:34:33AM -0800, Christopher Stone wrote:
Putting feature lists in descriptions is stupid. Obviously, you would have to update the description after each release which is stupid. It is most likely that feature lists in descriptions are simply cut & paste jobs from an upstream web site which is stupid.
I happen to think that it's reasonable to do this in some circumstances -- where the upstream website author has written a good, concise description of the package, and is clearly more familiar with the package than the Fedora maintainer. And in any case, what is wrong with feature lists (even if they need to be updated)? If someone has gone to the effort of doing 'yum info package' then it's quite likely they're interested in the features of that package.
Rich.
On Mon, Dec 15, 2008 at 9:42 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Mon, Dec 15, 2008 at 08:34:33AM -0800, Christopher Stone wrote:
Putting feature lists in descriptions is stupid. Obviously, you would have to update the description after each release which is stupid. It is most likely that feature lists in descriptions are simply cut & paste jobs from an upstream web site which is stupid.
I happen to think that it's reasonable to do this in some circumstances -- where the upstream website author has written a good, concise description of the package, and is clearly more familiar with the package than the Fedora maintainer. And in any case, what is wrong with feature lists (even if they need to be updated)? If someone has gone to the effort of doing 'yum info package' then it's quite likely they're interested in the features of that package.
Rich.
So, why not just go to the upstream website? Spec file descriptions are not the place to look for feature lists...
I am certain that in 100% of all cases where feature lists are in spec files, these lists are out of date, inaccurate, and not updated with new features. I also maintain that in 100% of all cases like this, the package maintainer is just being lazy and simply cut&pasted the feature list from the upstream web site, and has no intention whatsoever of actually keeping the list up to date and accurate.
On Mon, Dec 15, 2008 at 09:47:40AM -0800, Christopher Stone wrote:
So, why not just go to the upstream website? Spec file descriptions are not the place to look for feature lists...
Because I want to have 'yum search' do something useful and find those features. eg. If I want a blog tool with spam filtering that's supported in Fedora, how do you propose to answer that question by going to a website?
I am certain that in 100% of all cases where feature lists are in spec files, these lists are out of date, inaccurate, and not updated with new features.
Well, I'll assert that you're wrong, but if there are any packages which are like this, file bugs for them ...
Rich.
On Monday 15 December 2008 09:55:49 am Richard W.M. Jones wrote:
On Mon, Dec 15, 2008 at 09:47:40AM -0800, Christopher Stone wrote:
So, why not just go to the upstream website? Spec file descriptions are not the place to look for feature lists...
Because I want to have 'yum search' do something useful and find those features. eg. If I want a blog tool with spam filtering that's supported in Fedora, how do you propose to answer that question by going to a website?
Doesn't yum do OR searches by default still? That "feature" made searching for multiple terms pretty useless.
Regards,
On Mon, 15 Dec 2008, Conrad Meyer wrote:
On Monday 15 December 2008 09:55:49 am Richard W.M. Jones wrote:
On Mon, Dec 15, 2008 at 09:47:40AM -0800, Christopher Stone wrote:
So, why not just go to the upstream website? Spec file descriptions are not the place to look for feature lists...
Because I want to have 'yum search' do something useful and find those features. eg. If I want a blog tool with spam filtering that's supported in Fedora, how do you propose to answer that question by going to a website?
Doesn't yum do OR searches by default still? That "feature" made searching for multiple terms pretty useless.
No.
It does multiple term results like google does: - items matching all the terms - items matching most of the terms - items matching any of the terms
-sv
On Mon, 15 Dec 2008, Christopher Stone wrote:
On Mon, Dec 15, 2008 at 9:42 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Mon, Dec 15, 2008 at 08:34:33AM -0800, Christopher Stone wrote:
Putting feature lists in descriptions is stupid. Obviously, you would have to update the description after each release which is stupid. It is most likely that feature lists in descriptions are simply cut & paste jobs from an upstream web site which is stupid.
I happen to think that it's reasonable to do this in some circumstances -- where the upstream website author has written a good, concise description of the package, and is clearly more familiar with the package than the Fedora maintainer. And in any case, what is wrong with feature lists (even if they need to be updated)? If someone has gone to the effort of doing 'yum info package' then it's quite likely they're interested in the features of that package.
Rich.
So, why not just go to the upstream website? Spec file descriptions are not the place to look for feature lists...
Well, to be fair - 'yum search' does search description. So there are two ways of looking at this:
1. we can overload description with keywords, etc and then yum search can find them there. :( 2. we can work on the keyword additional metadata I talked about a month or so ago here.
-sv
On Mon, 2008-12-15 at 15:37 +0000, Richard Hughes wrote:
It seems many packagers have committed new summary text for their packages, and I thank you all for that.
Next on my list are insane descriptions. For instance, just take a look at the description for enlightenment (many pages in length) and various packages using ``quoting'' or ''quoting''. Many packages also try to do a bullet list using '*' or '-', usually with a random amount of spacing.
Question 1: Should we use '', "", or the UTF-8 quote characters? If we use LaTeX style ``double'' and `single' formatters then it's trivial for the session programs to either use ˵˶ or «» depending on the locale.
GNU is wrong and ` is not the mate of '. '' or "" or utf8 quotes are fine.
- ajax
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
+1
please just "" or '' the use of UTF-8 fancy quotations should be done by the renderer
Right. Should I file bugs for packages that use ``quotes'' or just change them?
If you would like a perl/sed script to do that just tell me I play good perl kong fu
Le mardi 16 décembre 2008 à 19:32 +0200, Muayyad AlSadi a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
+1
please just "" or '' the use of UTF-8 fancy quotations should be done by the renderer
No it should not. This is the road to incompatible software and piles of quirks (as in, everyone just has to edit text in Microsoft word because input and rendering logic has been implemented there instead of a generic standard encoding level)
2008/12/16 Nicolas Mailhot nicolas.mailhot@laposte.net:
Le mardi 16 décembre 2008 à 19:32 +0200, Muayyad AlSadi a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
+1
please just "" or '' the use of UTF-8 fancy quotations should be done by the renderer
No it should not. This is the road to incompatible software and piles of quirks (as in, everyone just has to edit text in Microsoft word because input and rendering logic has been implemented there instead of a generic standard encoding level)
-- Nicolas Mailhot
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
+1
It's not piles of quirks it's a simple parser. Take wiki syntax for example. All wikis(i know) rely on simple syntax that uses ASCII characters to display somewhat structured and formatted content. And it's common to use "*" to mark unordered list. And also different languages have different types of quotes for example in Bulgarian the quoted text looks like this : ,, quote " . And if someone wants to translate the package summary he must go trough the UTF symbol table to find the specific quote symbol. This can be simply solved with a parser.
The representation should be different from the content.
And if a machine will display some text to a person then machine code must be written.
Le mardi 16 décembre 2008 à 20:38 +0200, Nikolay Vladimirov a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
+1
It's not piles of quirks it's a simple parser.
ROTFL. Sorry.
Take wiki syntax for example. All wikis(i know) rely on simple syntax that uses ASCII characters to display somewhat structured and formatted content.
Wiki support UTF-8 just fine
And it's common to use "*" to mark unordered list.
And it's common to use xml tags and all kinds of other stuff but that's irrelevant because spec syntax is plain text not wiki markup.
And also different languages have different types of quotes for example in Bulgarian the quoted text looks like this : ,, quote " .
Converting text to the appropriate typography rules and symbols is part of the job of the translator (just like applying the correct grammar and syntax ordering rules). Translating has never been limited to word-by-word conversion.
And if someone wants to translate the package summary he must go trough the UTF symbol table to find the specific quote symbol.
If someone does not have the quote symbols appropriate to his language in his keyboard layout he should get the maintainer of this layout to fix it.
This can be simply solved with a parser.
It can not. Unicode is a monster but people jumped on it because it was still simpler than all the parsers and quirks and “smart” parser rules that antedated it.
The representation should be different from the content.
This is not representation this is text encoding. Chosing the font style and size is representation.
And if a machine will display some text to a person then machine code must be written.
And the spec to write machine code in this context is plain text that uses the UTF-8 standard.
2008/12/16 Nicolas Mailhot nicolas.mailhot@laposte.net:
Le mardi 16 décembre 2008 à 20:38 +0200, Nikolay Vladimirov a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
+1
It's not piles of quirks it's a simple parser.
ROTFL. Sorry.
uh? It's a development discussion forum if you think I said something stupid or plain braindamadge. Explain why it's stupid. Don't ROTFL and stuff, please.
Take wiki syntax for example. All wikis(i know) rely on simple syntax that uses ASCII characters to display somewhat structured and formatted content.
Wiki support UTF-8 just fine
yes. i ment the actual syntax like it uses "*" to mark unordered list but it displays "unicode bullet" ( i can't find it on my layout) Like it detects depth with ident and replaces '*' to look nicely.
And it's common to use "*" to mark unordered list.
And it's common to use xml tags and all kinds of other stuff but that's irrelevant because spec syntax is plain text not wiki markup.
I'm not talking about syntax in specs, i'm talking about package kit. I agree that there must be some standard for writing descriptions with limitations like: length, ident, spacing ... I don't agree with using UTF characters in summaries . Like in mutt i can use an utf character to display threads ( it's some angle symbol) but i can't see this symbol with some ssh or something ( yes, my software is buggy ) My point is that mutt allowed me to use only ASCII chars for displaying the threads.
So if i'm using some really outdated client to connect to my fedora host ( like telnet or serial or something) And I use command-line tools to browse packages and read summaries I will not see these UTF symbols.
As I understand the problem is that PackageKit can't display stuff. So let's make stuff more standard and leave PackageKit to do all the friendly displaying.
And also different languages have different types of quotes for example in Bulgarian the quoted text looks like this : ,, quote " .
Converting text to the appropriate typography rules and symbols is part of the job of the translator (just like applying the correct grammar and syntax ordering rules). Translating has never been limited to word-by-word conversion.
Yes. But why do I have to do all the stuff when a machine can do it.
And if someone wants to translate the package summary he must go trough the UTF symbol table to find the specific quote symbol.
If someone does not have the quote symbols appropriate to his language in his keyboard layout he should get the maintainer of this layout to fix it.
This can be simply solved with a parser.
It can not. Unicode is a monster but people jumped on it because it was still simpler than all the parsers and quirks and "smart" parser rules that antedated it.
The representation should be different from the content.
This is not representation this is text encoding. Chosing the font style and size is representation.
It is representation since the encoding will be changed mainly because in the current summaries don't look so great and are pretty chaotic in style. Using UTF isn't going to make them more structured and standard. Maintainers will.
And if a machine will display some text to a person then machine code must be written.
And the spec to write machine code in this context is plain text that uses the UTF-8 standard.
-- Nicolas Mailhot
-- NV
Le mardi 16 décembre 2008 à 22:02 +0200, Nikolay Vladimirov a écrit :
2008/12/16 Nicolas Mailhot nicolas.mailhot@laposte.net:
Le mardi 16 décembre 2008 à 20:38 +0200, Nikolay Vladimirov a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
+1
It's not piles of quirks it's a simple parser.
ROTFL. Sorry.
uh? It's a development discussion forum if you think I said something stupid or plain braindamadge. Explain why it's stupid. Don't ROTFL and stuff, please.
There are not enough hours in my free time to expand on all the problems trying to work around 7-bit encoding limitations without going Unicode causes.
There is abundant literature about it (both in paper and digital form).
It's all “simple” problems with “easy” solutions and when you pile up all the resulting quirks you put the Egyptians pyramids to shame.
As a bonus this stuff is highly non-standard and incompatible by contruction.
So when you claim this is a “simple” problem-space I'll ROTFL. Better people than you and me hit a wall trying to solve it properly. In the end after many failures they wrote the Unicode standard.
Take wiki syntax for example. All wikis(i know) rely on simple
syntax
that uses ASCII characters to display somewhat structured and formatted content.
Wiki support UTF-8 just fine
yes. i ment the actual syntax like it uses "*" to mark unordered list but it displays "unicode bullet" ( i can't find it on my layout) Like it detects depth with ident and replaces '*' to look nicely.
You are free to write specs using wiki, tex, or sgml entities markup. You are free to use a text editor, a word processor, an hexadecimal, or whatever.
We expect you to convert this syntax to correct plain text in UTF-8 encoding before publication by Fedora. This is the common ground all our package manipulating tools understand and there is no way we're going to teach them some other markup just because you can't find some UTF-8 symbol in your layout.
If you can't write UTF-8 bullets, and can't be bothered to launch something like gucharmap, use a sed of awk or whatever converter on your spec files before pushing them Fedora-side, don't ask others to add code to many tools to workaround your problems.
And it's common to use "*" to mark unordered list.
And it's common to use xml tags and all kinds of other stuff but
that's
irrelevant because spec syntax is plain text not wiki markup.
I'm not talking about syntax in specs,
The discussion is about the human text found in spec files.
So if i'm using some really outdated client to connect to my fedora host ( like telnet or serial or something) And I use command-line tools to browse packages and read summaries I will not see these UTF symbols.
So what? Your choice. The distro English encoding is UTF-8. If you want things to work perfectly in the default locale use UTF-8 aware tools. We can't be responsible for your choice to use buggy, legacy, outdated tools. Any ASCII-oriented tool will mostly sort-of work, and anything outside the mostly sort-of perimeter is the price you pay for using limited tools.
If you want an ASCII-only mode (a real one, not the “I know it's UTF-8 but please use only ASCII so I don't hit bugs in my tools”) open an English ASCII localization group.
As I understand the problem is that PackageKit can't display stuff.
The problem is people wrote garbage in some spec files using ASCII-limited tools, and the PK maintainer would like this garbage corrected so normal users are not exposed to ASCII quirks.
So let's make stuff more standard and leave PackageKit to do all the friendly displaying.
PK is not the only tool involved, the standard already exists, and is feature-complete without needing workaround code.
And also different languages have different types of quotes for example in Bulgarian the quoted text looks like this : ,, quote " .
Converting text to the appropriate typography rules and symbols is
part
of the job of the translator (just like applying the correct grammar
and
syntax ordering rules). Translating has never been limited to word-by-word conversion.
Yes. But why do I have to do all the stuff when a machine can do it.
If a machine can do it get a machine to output proper UTF-8 encoded specfile text your side.
It is representation since the encoding will be changed
The encoding won't be changed
mainly because in the current summaries don't look so great
Because they have mistakes. Their authors just have to correct their mistakes. This is no different from grammar errors and you don't expect PK to fix the text grammar errors don't you?
and are pretty chaotic in style. Using UTF isn't going to make them more structured and standard. Maintainers will.
Which is the whole point. This is not a technical problem. The current UTF-8 technical infrastructure is sufficient and there is not need to write magic text correcting code. People just have to do some editorial work and proof and correct their text themselves, making sure it displays fine using simple standard UTF-8 text rendering engines.
On Tue, 2008-12-16 at 21:21 +0100, Nicolas Mailhot wrote:
We expect you to convert this syntax to correct plain text in UTF-8 encoding before publication by Fedora. This is the common ground all our package manipulating tools understand and there is no way we're going to teach them some other markup just because you can't find some UTF-8 symbol in your layout.
If you can't write UTF-8 bullets, and can't be bothered to launch something like gucharmap, use a sed of awk or whatever converter on your spec files before pushing them Fedora-side, don't ask others to add code to many tools to workaround your problems.
So how does using untypable unicode bullets magically tell PackageKit that this is part of a list ? And which of the many bullet-like characters in Unicode do you want to bless for this ?
If you ask me, something very simple like http://en.wikipedia.org/wiki/Markdown is best for situations like this where you want to include light markup into text without letting the markup totally overwhelm the surrounding document.
Matthias Clasen wrote:
On Tue, 2008-12-16 at 21:21 +0100, Nicolas Mailhot wrote:
We expect you to convert this syntax to correct plain text in UTF-8 encoding before publication by Fedora. This is the common ground all our package manipulating tools understand and there is no way we're going to teach them some other markup just because you can't find some UTF-8 symbol in your layout.
If you can't write UTF-8 bullets, and can't be bothered to launch something like gucharmap, use a sed of awk or whatever converter on your spec files before pushing them Fedora-side, don't ask others to add code to many tools to workaround your problems.
So how does using untypable unicode bullets magically tell PackageKit that this is part of a list ? And which of the many bullet-like characters in Unicode do you want to bless for this ?
Well, U+2022 BULLET is the clear winner.
behdad
If you ask me, something very simple like http://en.wikipedia.org/wiki/Markdown is best for situations like this where you want to include light markup into text without letting the markup totally overwhelm the surrounding document.
Ok, it seems that i made a mess of my ideas in the process of writing
My general ranting isn't against Unicode it's against using special Unicode characters(bullets, and the "<<" thing). A clean summary can be written with clear guidelines and common characters.
Is there any real benefit in using unicode bullet symbol, the double arrow thing or quotes different from " ?
Le mardi 16 décembre 2008 à 23:39 +0200, Nikolay Vladimirov a écrit :
Ok, it seems that i made a mess of my ideas in the process of writing
My general ranting isn't against Unicode it's against using special Unicode characters(bullets, and the "<<" thing). A clean summary can be written with clear guidelines and common characters.
A clean summary will be written with clear guidelines and correctly encoded text.
Is there any real benefit in using unicode bullet symbol,
There is a real benefit if you want bullets displayed on the user systems.
the double arrow thing or quotes different from " ?
The double arrow thing is a quoting form. It is the correct quoting form for my country. As others noted each locale is going to have a correct quoting form which is not necessarily ".
Since I'm no native American English speaker, I won't comment on what the correct American English form is. As long as it's not a clear encoding violation like the “use accents as quotes” thing.
because I feel that you wasn't listen to me I'll attach a picture from gedit
the first line is "simple" with the UTF8 fancy quotes in the second line I replaced simple with an Arabic word notice that because quotes are marked to be neutral in direction followed by RTL chars they are treated as RTL chars but because they are no longer mirrored they appear to us like )simple(
On Tue, Dec 16, 2008 at 04:20:07PM -0500, Matthias Clasen wrote:
So how does using untypable unicode bullets magically tell PackageKit that this is part of a list ? And which of the many bullet-like characters in Unicode do you want to bless for this ?
You have confused character encoding and semantic markup.
Unicode is character encoding
HTML tags or similar are semantic markup
Trying to extrapolate semantic markup from random ascii symbols is not a reliable or robust path, particularly when you come to internationalise things.
If you ask me, something very simple like http://en.wikipedia.org/wiki/Markdown is best for situations like this where you want to include light markup into text without letting the markup totally overwhelm the surrounding document.
Possibly, however package data in rpm headers is not wiki markdown and the specification for RPM doesn't imply you can treat it that way.
On Tue, 2008-12-16 at 17:25 -0500, Alan Cox wrote:
On Tue, Dec 16, 2008 at 04:20:07PM -0500, Matthias Clasen wrote:
So how does using untypable unicode bullets magically tell PackageKit that this is part of a list ? And which of the many bullet-like characters in Unicode do you want to bless for this ?
You have confused character encoding and semantic markup.
Unicode is character encoding
HTML tags or similar are semantic markup
Thanks Alan, I know that quite well.
Trying to extrapolate semantic markup from random ascii symbols is not a reliable or robust path, particularly when you come to internationalise things.
One hopes the ascii symbols in most package descriptions are not entirely random... and extrapolating something from them can be quite reliable if is there is a mutual understanding about the interpretation. Hence my reference to markdown.
Possibly, however package data in rpm headers is not wiki markdown and the specification for RPM doesn't imply you can treat it that way.
The specification for RPM doesn't imply anything about the description field. And this thread is about how to possibly improve the situation by agreeing on some form of interpretation.
On Tue, Dec 16, 2008 at 05:40:36PM -0500, Matthias Clasen wrote:
Unicode is character encoding HTML tags or similar are semantic markup
Thanks Alan, I know that quite well.
Trying to extrapolate semantic markup from random ascii symbols is not a reliable or robust path, particularly when you come to internationalise things.
One hopes the ascii symbols in most package descriptions are not entirely random... and extrapolating something from them can be quite
There is no reason to assume * for example is a bullet point, it could be a footnote indicator, maths or ascii art. The Unicode bullet on the other hand is uneqivocably a bullet point.
So extracting from UTF-8 is safer, but extracting at all is dangerous
The specification for RPM doesn't imply anything about the description field. And this thread is about how to possibly improve the situation by agreeing on some form of interpretation.
Right - the field is plain UTF-8 textual data and has been for years. You want to add a semantic version of it. That is fine but use a new header for the field the way RPM intends things to be added.
2008/12/17 Alan Cox alan@redhat.com:
On Tue, Dec 16, 2008 at 05:40:36PM -0500, Matthias Clasen wrote:
Right - the field is plain UTF-8 textual data and has been for years. You want to add a semantic version of it. That is fine but use a new header for the field the way RPM intends things to be added.
That seems like a good solution.
On Tue, 16 Dec 2008, Matthias Clasen wrote:
Possibly, however package data in rpm headers is not wiki markdown and the specification for RPM doesn't imply you can treat it that way.
The specification for RPM doesn't imply anything about the description field. And this thread is about how to possibly improve the situation by agreeing on some form of interpretation.
Then it shouldn't be discussed here, as fedora is not the only user/consumer of rpm.
-sv
Nikolay Vladimirov nikolay@vladimiroff.com wrote:
2008/12/16 Nicolas Mailhot nicolas.mailhot@laposte.net:
Le mardi 16 décembre 2008 à 19:32 +0200, Muayyad AlSadi a écrit :
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
+1
please just "" or '' the use of UTF-8 fancy quotations should be done by the renderer
No it should not. This is the road to incompatible software and piles of quirks (as in, everyone just has to edit text in Microsoft word because input and rendering logic has been implemented there instead of a generic standard encoding level)
Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
+1
It's not piles of quirks it's a simple parser. Take wiki syntax for example. All wikis(i know) rely on simple syntax that uses ASCII characters to display somewhat structured and formatted content.
I know three (moin-moin, twiki, and trac), and they use very different syntaxes, with wildly different ranges of features. /That/ is the kind of problem being hinted at above.
Nicolas Mailhot (nicolas.mailhot@laposte.net) said:
please just "" or '' the use of UTF-8 fancy quotations should be done by the renderer
No it should not. This is the road to incompatible software and piles of quirks (as in, everyone just has to edit text in Microsoft word because input and rendering logic has been implemented there instead of a generic standard encoding level)
I fail to see how using the neutral quote character ", a perfectly valid standard unicode character, is the road to incompatible software and piles of quirks.
Frankly, I'm surprised you don't sign your mail "Nicolas" - think of all the extra high bits you could use!
Bill
Le mardi 16 décembre 2008 à 15:16 -0500, Bill Nottingham a écrit :
Nicolas Mailhot (nicolas.mailhot@laposte.net) said:
please just "" or '' the use of UTF-8 fancy quotations should be done by the renderer
No it should not. This is the road to incompatible software and
piles of
quirks (as in, everyone just has to edit text in Microsoft word
because
input and rendering logic has been implemented there instead of a generic standard encoding level)
I fail to see how using the neutral quote character ", a perfectly valid standard unicode character, is the road to incompatible software and piles of quirks.
And I didn't object to «"», I object to using accents instead of quote characters.
Frankly, I'm surprised you don't sign your mail "Nicolas" - think of all the extra high bits you could use!
This is just another encoding abuse and it's not better than the ASCII abuse of grave.
You want to write a latin "A" you use the Unicode latin "A" codepoint (which is the same as the ASCII codepoint)
You want to write a quote you use a Unicode quote codepoint " or “” or «» there are several valid solutions in the general punctuation block http://www.unicode.org/charts/PDF/U2000.pdf
You want to write a bullet you use the U+2022 bullet codepoint, something in the dingbat block, or just plain en/em dash. http://www.unicode.org/charts/PDF/U2000.pdf http://www.unicode.org/charts/PDF/U2700.pdf
You do not use a O (oh) because it is vaguely similar to a 0 (zero) You do not use an accent because it is vaguely similar to a quote You do not use a cyrillic a because it looks like a latin a You do not use a star when what you want is a bullet and there is a standard way to encode bullets.
You encode your text properly using the correct choices in our standard encoding so our tools can display it properly without human or computer second-guessing.
Nicolas Mailhot wrote:
Le mardi 16 décembre 2008 à 15:16 -0500, Bill Nottingham a écrit :
I fail to see how using the neutral quote character ", a perfectly valid standard unicode character, is the road to incompatible software and piles of quirks.
And I didn't object to «"», I object to using accents instead of quote characters.
And I didn't see anyone disagree. You do, however, seem to be advocating "fancy" quotes over ", which still sees far more usage (and which everyone knows how to type).
Le mardi 16 décembre 2008 à 14:58 -0600, Matthew Woehlke a écrit :
Nicolas Mailhot wrote:
Le mardi 16 décembre 2008 à 15:16 -0500, Bill Nottingham a écrit :
I fail to see how using the neutral quote character ", a perfectly valid standard unicode character, is the road to incompatible software and piles of quirks.
And I didn't object to «"», I object to using accents instead of quote characters.
And I didn't see anyone disagree. You do, however, seem to be advocating "fancy" quotes over ", which still sees far more usage (and which everyone knows how to type).
I wrote that if you wanted fancy quotes displayed you had to type fancy quotes in your text, yes (not accents, primes, or something else that looks similar but isn't).
On Tue, 2008-12-16 at 14:58 -0600, Matthew Woehlke wrote:
Nicolas Mailhot wrote:
Le mardi 16 décembre 2008 à 15:16 -0500, Bill Nottingham a écrit :
I fail to see how using the neutral quote character ", a perfectly valid standard unicode character, is the road to incompatible software and piles of quirks.
And I didn't object to «"», I object to using accents instead of quote characters.
And I didn't see anyone disagree. You do, however, seem to be advocating "fancy" quotes over ", which still sees far more usage (and which everyone knows how to type).
The problem is that PK currently alters the description text (I think mainly to work around a bug/feature¹) substituting "fancy quotes" for "normal" quotes (which I think is why this thread started, to try and fix that in the packages!). Nicolas thinks tools altering the data in this way is bad, and I tend to agree, with descriptions being what they are now it's not possible to know that the alteration is always good. He also seems to haave a secondary argument that for lists, using o is bad but ∘ is good. I'm not sure I agree there, but I see his point.
Personally I think the use of '"', ., *, •, o or ∘ ... are fine, just as long as all the tools are displaying the same non-invisible bytes².
¹ https://bugzilla.redhat.com/show_bug.cgi?id=459155
² Changing whitespace is different, I think, so the tools can do readable wrapping ... but I'm prepared to be shown we shouldn't do that in yum/whatever either (what we have now is certainly somewhat magic).
On Tue, 2008-12-16 at 17:30 -0500, James Antill wrote:
Personally I think the use of '"', ., *, •, o or ∘ ... are fine, just as long as all the tools are displaying the same non-invisible bytes².
Right, this discussion is going nowhere, and there are a lot of egos in play. At the moment I'm thinking PK should just do this:
--------------------------------------------- This is a spec file description or an update description in bohdi.
The following things 'were' fixed: - Fix `dave' - Fubar update because of "security" --------------------------------------------
This will be converted by gnome-packagekit into:
--------------------------------------------- This is a spec file description or an update description in bohdi.
The following things ‘were’ fixed: • Fix ‘dave’ • Fubar update because of “security” ---------------------------------------------
The double quotes will be marked translated as left and right chars (so « and » can be used), the LaTeX single quotes (and double will be expanded and "- " converted to bullets.
If you're doing to use ☠ or ☢ in a spec file, then the text box is going to look rubbish and be all on one line. If you use a description longer than a few hundred words, gnome-packagekit will truncate it.
Now I'm going to go back to coding, rather than talking to angry people.
Richard.
Le Mer 17 décembre 2008 10:49, Richard Hughes a écrit :
On Tue, 2008-12-16 at 17:30 -0500, James Antill wrote:
Personally I think the use of '"', ., *, •, o or ∘ ... are fine, just as long as all the tools are displaying the same non-invisible bytes².
Right, this discussion is going nowhere, and there are a lot of egos in play. At the moment I'm thinking PK should just do this:
So now you are defining a new gnome-PK only syntax that won't work in yum, rpm, urpmi, apt, synaptic, gnorpm, yumex, anaconda, LSB rpm, etc and will encourage people to produce badly encoded descriptions instead of fixing their text.
And you can't even be bothered to get it reviewed at the distro level (let alone upstream rpm or lsb-side)
While you are at it, please also integrate a spell and grammar checker so users are not exposed to spelling and grammar mistakes and packagers do not have to worry about grammar or spell problems.
Seriously. This stuff is already defined and standardised. You may not like what the currebt official choices are, but workarounding them at your app level instead of fixing them at the right level (upstream, ie in this case in the distro spec files) is not the right thing to do.
On Wed, 2008-12-17 at 11:01 +0100, Nicolas Mailhot wrote:
Le Mer 17 décembre 2008 10:49, Richard Hughes a écrit :
On Tue, 2008-12-16 at 17:30 -0500, James Antill wrote:
Personally I think the use of '"', ., *, •, o or ∘ ... are fine, just as long as all the tools are displaying the same non-invisible bytes².
Right, this discussion is going nowhere, and there are a lot of egos in play. At the moment I'm thinking PK should just do this:
So now you are defining a new gnome-PK only syntax that won't work in yum, rpm, urpmi, apt, synaptic, gnorpm, yumex, anaconda, LSB rpm, etc and will encourage people to produce badly encoded descriptions instead of fixing their text.
Ohh, it'll work just fine. In other frontends you'll get:
This is a description, la al la. List of things fixed: - one - two - three
and in GNOME PK you'll get UTF8 bullets and paragraph unwinding.
And you can't even be bothered to get it reviewed at the distro level (let alone upstream rpm or lsb-side)
No, I'm fed up of being flamed.
While you are at it, please also integrate a spell and grammar checker so users are not exposed to spelling and grammar mistakes and packagers do not have to worry about grammar or spell problems.
ROFL.
Seriously. This stuff is already defined and standardised. You may not like what the currebt official choices are, but workarounding them at your app level instead of fixing them at the right level (upstream, ie in this case in the distro spec files) is not the right thing to do.
* Fri Feb 08 2008 Nicolas Mailhot <nicolas.mailhot at laposte.net> - 1:1.09-3 ⌚ gcc 4.3 rebuild
* Mon Aug 13 2007 Nicolas Mailhot <nicolas.mailhot at laposte.net> ♣ 1:1.09-2 ✓ Fix License
So, you've discussed those changes with upstream, defined a set of enumerated values, and standardised the other spec files right?
I tend to agree with Matthias, markdown http://en.wikipedia.org/wiki/Markdown seems to be the best compromise, and I'll adjust my formatter to adhere to this.
Richard.
Le Mer 17 décembre 2008 12:19, Richard Hughes a écrit :
- Fri Feb 08 2008 Nicolas Mailhot <nicolas.mailhot at laposte.net>
- 1:1.09-3
⌚ gcc 4.3 rebuild
So, you've discussed those changes with upstream, defined a set of enumerated values, and standardised the other spec files right?
This is plain UTF-8 text that passes the current guidelines, that passes rpmlint, and without non-standard magic post-processing markup application side. It works in vi, emacs, eclipse, gedit, etc the same way.
Which is what standardisation are about. Apps do not have to know about a special syntax and I don't have to know about special app quirks because we use the same plain UTF-8 text without magic spec.
Le Mer 17 décembre 2008 12:56, Nicolas Mailhot a écrit :
Le Mer 17 décembre 2008 12:19, Richard Hughes a écrit :
- Fri Feb 08 2008 Nicolas Mailhot <nicolas.mailhot at laposte.net>
- 1:1.09-3
⌚ gcc 4.3 rebuild
So, you've discussed those changes with upstream, defined a set of enumerated values, and standardised the other spec files right?
This is plain UTF-8 text that passes the current guidelines, that passes rpmlint, and without non-standard magic post-processing markup application side. It works in vi, emacs, eclipse, gedit, etc the same way.
And it seems to work in all the MUAs we've used too.
OTOH your stuff will only work in PK, and in the course of trying to workaround badly encoded text you'll break correctly encoded text (and probably mess up the display thoroughly for some locales).
I guess I'll just have to add packagekit to the list of apps with broken unicode support we track in the Fonts SIG. You call that ego I call that regression.
2008/12/17 Nicolas Mailhot nicolas.mailhot@laposte.net:
Le Mer 17 décembre 2008 12:56, Nicolas Mailhot a écrit :
Le Mer 17 décembre 2008 12:19, Richard Hughes a écrit :
- Fri Feb 08 2008 Nicolas Mailhot <nicolas.mailhot at laposte.net>
- 1:1.09-3
⌚ gcc 4.3 rebuild
So, you've discussed those changes with upstream, defined a set of enumerated values, and standardised the other spec files right?
This is plain UTF-8 text that passes the current guidelines, that passes rpmlint, and without non-standard magic post-processing markup application side. It works in vi, emacs, eclipse, gedit, etc the same way.
And it seems to work in all the MUAs we've used too.
OTOH your stuff will only work in PK, and in the course of trying to workaround badly encoded text you'll break correctly encoded text (and probably mess up the display thoroughly for some locales).
I guess I'll just have to add packagekit to the list of apps with broken unicode support we track in the Fonts SIG. You call that ego I call that regression.
-- Nicolas Mailhot
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Should we bring this to FESCO ? Since as I understand you're saying the current solution is a regression and the only good solution is AllRPMdistros wide.
On Wed, 2008-12-17 at 09:49 +0000, Richard Hughes wrote:
The following things 'were' fixed:
- Fix `dave'
- Fubar update because of "security"
This will be converted by gnome-packagekit into:
This is a spec file description or an update description in bohdi.
The following things ‘were’ fixed: • Fix ‘dave’ • Fubar update because of “security”
I don't understand why you want to mess with it at all? Why can't you show exactly what's in bodhi, or exactly what's in the rpm headers?
On Wed, 2008-12-17 at 09:00 -0800, Jesse Keating wrote:
I don't understand why you want to mess with it at all? Why can't you show exactly what's in bodhi, or exactly what's in the rpm headers?
Because people file bugs when word wrapping is not done correctly
People also don't use the UTF8 chars in update descriptions or spec file changelogs, and quite understandably, there's no bullet key on most keyboards. Using a * is so 1980's.
Richard.
On Wed, 17 Dec 2008, Richard Hughes wrote:
On Wed, 2008-12-17 at 09:00 -0800, Jesse Keating wrote:
I don't understand why you want to mess with it at all? Why can't you show exactly what's in bodhi, or exactly what's in the rpm headers?
Because people file bugs when word wrapping is not done correctly
People also don't use the UTF8 chars in update descriptions or spec file changelogs, and quite understandably, there's no bullet key on most keyboards. Using a * is so 1980's.
Richard, I'm sorry but I think if you're going to suggest a specialized format for the description tag and/or try to change pkgs to comply with this format or file bugs about non-complying pkgs then your suggestion should go to the Fedora Packaging or Fesco for approval. A change to the existing standard is going to need approval from more folks.
You may also consider approaching the opensuse and mandriva folks to make sure they are onboard, too.
-sv
On Wed, 2008-12-17 at 18:56 +0000, Richard Hughes wrote:
Because people file bugs when word wrapping is not done correctly
Your point? Our spec files have a 79 char limit on them, and anything that tries to be smaller than that gets what it deserves. You're taking raw data with no defined markup, trying to apply some rules to that is just going to run you into problems.
People also don't use the UTF8 chars in update descriptions or spec file changelogs, and quite understandably, there's no bullet key on most keyboards. Using a * is so 1980's.
And what's wrong with the 1980s? What added value does (I don't even know the compose sequence for this) • have over * ? Are you going to tell me that somebody is going to see: * foo * Bar * Baz
and not comprehend that it's a list of items? Are there really no other issues with package management that you could be working on?
On Wed, Dec 17, 2008 at 06:56:58PM +0000, Richard Hughes wrote:
Because people file bugs when word wrapping is not done correctly
Word wrapping is an separate issue.
People also don't use the UTF8 chars in update descriptions or spec file changelogs, and quite understandably, there's no bullet key on most keyboards. Using a * is so 1980's.
So add a new rpm header using semantic markup. You could even use an XML markup if you wanted.
Richard Hughes hughsient@gmail.com wrote:
On Wed, 2008-12-17 at 09:00 -0800, Jesse Keating wrote:
I don't understand why you want to mess with it at all? Why can't you show exactly what's in bodhi, or exactly what's in the rpm headers?
Because people file bugs when word wrapping is not done correctly
Then the packa- gers should fix the word- wrap- ping bugs!
People also don't use the UTF8 chars in update descriptions or spec file changelogs, and quite understandably, there's no bullet key on most keyboards. Using a * is so 1980's.
They do use UTF-8 characters just fine, thank you. Not all of them, perhaps not even the ones you are most fond of. BZ away, sending appropiate patches.
Richard Hughes wrote:
On Tue, 2008-12-16 at 17:30 -0500, James Antill wrote:
Personally I think the use of '"', ., *, •, o or ∘ ... are fine, just as long as all the tools are displaying the same non-invisible bytes².
Right, this discussion is going nowhere, and there are a lot of egos in play. At the moment I'm thinking PK should just do this:
This is a spec file description or an update description in bohdi.
The following things 'were' fixed:
- Fix `dave'
- Fubar update because of "security"
This will be converted by gnome-packagekit into:
This is a spec file description or an update description in bohdi.
The following things ‘were’ fixed: • Fix ‘dave’ • Fubar update because of “security”
The double quotes will be marked translated as left and right chars (so « and » can be used), the LaTeX single quotes (and double will be expanded and "- " converted to bullets.
Few things: 1) Why convert " => “” ? " is correct punctuation already. 2) The concern I see with conversion to bullets and `' pairs is not how things that fit the use case are converted but how things that don't fit the use case are converted. ie:
This was due to dave's library's bug #12345
upstream's changelog said: `Dave's patch broke this'
# 12345 fixed
- and + formatting fixed for floating point numbers
If you're doing to use ☠ or ☢ in a spec file, then the text box is going to look rubbish and be all on one line. If you use a description longer than a few hundred words, gnome-packagekit will truncate it.
Now I'm going to go back to coding, rather than talking to angry people.
PackageKit is, of course, your baby but you're trying to add formatting to a field that doesn't have any formatting rules inside Fedora or cross-distro. Please be careful (especially before introducing even more invasive formatting like Markdown, textile, or reStructuredText as that will wreak havoc with a great number of descriptions that don't expect those formatting transformations to be applied.)
-Toshio
On Wed, 2008-12-17 at 09:31 -0800, Toshio Kuratomi wrote:
PackageKit is, of course, your baby
No, it's an upstream project where we try to work with al the distros to solve a common problem. It's certainly not my baby.
but you're trying to add formatting to a field that doesn't have any formatting rules inside Fedora or cross-distro.
Right. And I think markdown in spec files and update descriptions makes perfect sense. If the text doesn't have such formatting, or it's invalid, PK will just return the text with no processing.
Richard.
Richard Hughes wrote:
On Wed, 2008-12-17 at 09:31 -0800, Toshio Kuratomi wrote:
PackageKit is, of course, your baby
No, it's an upstream project where we try to work with al the distros to solve a common problem. It's certainly not my baby.
In that case, you're going to have a lot of problems with adding Markdown in PackageKit upstream. I doubt heavily that we'll be able to get people within Fedora to agree to format their %descriptions as markdown let alone the larger community of distributions. I've already mentioned reStructuredText which is popular in the python community and preformatted text (whether ASCii or utf-8) is also going to have adherents.
but you're trying to add formatting to a field that doesn't have any formatting rules inside Fedora or cross-distro.
Right. And I think markdown in spec files and update descriptions makes perfect sense. If the text doesn't have such formatting, or it's invalid, PK will just return the text with no processing.
The problem is that Markdown and other non-intrusive formats (like reStructuredText) don't have enough information to tell if it's "invalid". For instance, if my Bodhi comments have:
# Fix an issue with char *foobar and all void* on gcc-5 # Fix call to __init__ in python bindings.
Markdown will mangle what I intended because there are three constructs in there that look like valid Markdown.
To use a non-intrusive format, we need to specify the format being used either in a specification or as metadata to the %description tag. Both of those solutions would have to be hashed out with the rpm authors.
-Toshio
On Wed, 2008-12-17 at 13:04 -0800, Toshio Kuratomi wrote:
In that case, you're going to have a lot of problems with adding Markdown in PackageKit upstream.
http://www.packagekit.org/pk-faq.html#markup
I doubt heavily that we'll be able to get people within Fedora to agree to format their %descriptions as markdown let alone the larger community of distributions.
I don't want people to change anything. If you use markdown syntax (or something similar to the syntax) then everything just works. If you use something oddball (☠), then PackageKit is going to give up and just display the text as it is, probably with incorrect wrapping.
The problem is that Markdown and other non-intrusive formats (like reStructuredText) don't have enough information to tell if it's "invalid". For instance, if my Bodhi comments have:
# Fix an issue with char *foobar and all void* on gcc-5 # Fix call to __init__ in python bindings.
Then you're going to get two titles. Seriously - who does that? If you follow what 99% of other people are doing and either do:
* lists * that - most - people + use
Then it'll just work.
Markdown will mangle what I intended because there are three constructs in there that look like valid Markdown.
Right, it'll make italic the "foobar and all void" line. I really don't think putting code in update descriptions is a good idea, for the very point of them is to tell people if they need to do the update. A better message would be:
* Fix compile on GCC-5
and then provide a link to the mailing list with more information. If that's not acceptable, writing "*foobar and all void *" would prevent it being marked italic.
To use a non-intrusive format, we need to specify the format being used either in a specification or as metadata to the %description tag. Both of those solutions would have to be hashed out with the rpm authors.
That's never going to happen. Most busy people struggle with good descriptions and bodhi update text in plain text, ask them to do it in SGML/html/some-other-markup and even less people will be bothered.
Richard.
On Thu, 2008-12-18 at 14:09 +0000, Richard Hughes wrote:
On Wed, 2008-12-17 at 13:04 -0800, Toshio Kuratomi wrote:
In that case, you're going to have a lot of problems with adding Markdown in PackageKit upstream.
http://www.packagekit.org/pk-faq.html#markup
I doubt heavily that we'll be able to get people within Fedora to agree to format their %descriptions as markdown let alone the larger community of distributions.
I don't want people to change anything.
% cat ../pkg.description2markdown-html.py #! /usr/bin/python -tt
import os, sys, markdown2, yum
yb = yum.YumBase() yb.conf.cache = os.geteuid() != 0
for pkg in yb.pkgSack.returnPackages(patterns=sys.argv[1:]): sep = "\n" + "-" * 79 print "=" * 79 print pkg, pkg.repoid, sep print pkg.description, sep print markdown2.markdown(pkg.description), sep
...after a quick search the following package descriptions will need to be changed:
perl-Regexp-Shellish-0.93-4.fc9 txt2tags-2.5-4.fc9 geeqie-1.0-0.4.alpha1.fc9 tinyca2-0.7.5-3.fc7 moreutils-0.28-3.fc9 alpine-2.00-1.fc9 FEDORA-2008-5191
...the biggest problem seems to be parsing lists, for instance lists with a "large" indent like " * item 1" which markdown parses as a <pre><code> block or using lists but using '-' or 'o' etc. instead of '*', so markdown again fails to parse them as lists (I also assume it'll fail to parse • too).
I'm actually somewhat impressed by how well it does, but it still requires a change in behaviour for a known tag ... and obviously doesn't work anywhere near as well as what we have in yum (which just does wrapping).
The problem is that Markdown and other non-intrusive formats (like reStructuredText) don't have enough information to tell if it's "invalid". For instance, if my Bodhi comments have:
# Fix an issue with char *foobar and all void* on gcc-5 # Fix call to __init__ in python bindings.
Then you're going to get two titles. Seriously - who does that? If you follow what 99% of other people are doing and either do:
- lists
- that
- most
- people
- use
Then it'll just work.
Not quite. For instance:
msg = """\ If you follow what x% of other people are doing and do:
* lists * that - most - people + use
Then it'll just work. """
msg = """\ If you follow what y% of other people are doing and do: * lists * that - most - people + use
Then it'll just fail. """
...it also seems to pass &blah; straight through to the html output, although maybe that's a bug in the module?
On Thu, 2008-12-18 at 10:57 -0500, James Antill wrote:
perl-Regexp-Shellish-0.93-4.fc9 txt2tags-2.5-4.fc9 geeqie-1.0-0.4.alpha1.fc9 tinyca2-0.7.5-3.fc7 moreutils-0.28-3.fc9 alpine-2.00-1.fc9 FEDORA-2008-5191
Cool, that's a much smaller list that I expected. Thanks for looking into this.
...the biggest problem seems to be parsing lists, for instance lists with a "large" indent like " * item 1" which markdown parses as a
<pre><code> block or using lists but using '-' or 'o' etc. instead of '*', so markdown again fails to parse them as lists (I also assume it'll fail to parse • too).
Yes, I think we just need to standardize. Most packages I've seen fall into the "already work" camp.
I'm actually somewhat impressed by how well it does, but it still requires a change in behaviour for a known tag ... and obviously doesn't work anywhere near as well as what we have in yum (which just does wrapping).
Right, I too am impressed with markdown. I've written a GObject for gnome-packagekit that decodes markdown to pango or text output in a simple fast pass.
Not quite. For instance:
msg = """\ If you follow what x% of other people are doing and do:
- lists
- that
- most
- people
- use
Then it'll just work. """
msg = """\ If you follow what y% of other people are doing and do:
- lists
- that
- most
- people
- use
Then it'll just fail.
Ahh, my simple markup parser is a bit more tolerant to this and formats the bullets correctly.
Richard.
On Thu, 2008-12-18 at 16:17 +0000, Richard Hughes wrote:
On Thu, 2008-12-18 at 10:57 -0500, James Antill wrote:
perl-Regexp-Shellish-0.93-4.fc9 txt2tags-2.5-4.fc9 geeqie-1.0-0.4.alpha1.fc9 tinyca2-0.7.5-3.fc7 moreutils-0.28-3.fc9 alpine-2.00-1.fc9 FEDORA-2008-5191
Cool, that's a much smaller list that I expected. Thanks for looking into this.
That wasn't a canonical list (I'm not sure we can easily generate that without just having users say XYZ looks wrong), although from my testing there aren't "many" packages that contain "\n " which is one of the problems:
x = yb.pkgSack.returnPackages() x = filter(lambda x: x.description.find('\n ') != -1, x) x = yum.packageSack.packagesNewestByName(x) # F9, len(x) == 213
...my point was more that although there might not be a lot of them there _are_ known packages which will fail. So we can't just say "everything works, and we have new features".
Not quite. For instance:
msg = """\ If you follow what x% of other people are doing and do:
- lists
- that
- most
- people
- use
Then it'll just work. """
msg = """\ If you follow what y% of other people are doing and do:
- lists
- that
- most
- people
- use
Then it'll just fail.
Ahh, my simple markup parser is a bit more tolerant to this and formats the bullets correctly.
So, it's not markdown then surely? Can you point to some python that implements your version?
On Thu, Dec 18, 2008 at 7:56 AM, James Antill james@fedoraproject.org wrote:
So, it's not markdown then surely? Can you point to some python that implements your version?
This still needs to go before our packaging committee methinks.
And if its approved as a Review Should or a Must, it would absolutely be super keen if reviewers had a toolized way to check for conformance so we can catch this for anything submitted moving forward.
-jef"deliberately going to edit his packages descriptions to break markdown in rawhide, without it being obvious that he's doing it"spaleta
On Thu, 2008-12-18 at 09:10 -0900, Jeff Spaleta wrote:
This still needs to go before our packaging committee methinks.
Yes. I'm still talking with the other distros, and most are /okay/ with the idea. 99% of package don't need any changes, it's only the 1% that already look different to the others.
And if its approved as a Review Should or a Must, it would absolutely be super keen if reviewers had a toolized way to check for conformance so we can catch this for anything submitted moving forward.
Yes, I'm going to play with rpmlint and see if I can add some simple rules.
Richard.
Richard Hughes hughsient@gmail.com wrote:
On Thu, 2008-12-18 at 09:10 -0900, Jeff Spaleta wrote:
This still needs to go before our packaging committee methinks.
Yes. I'm still talking with the other distros, and most are /okay/ with the idea. 99% of package don't need any changes, it's only the 1% that already look different to the others.
I.e., 99% of packages are just fine with normal text, and you want to futz around for the sake of the remaining 1%, thus risking breakage in the vast amjority that works dandy today?
Doesn't sound very reasonable to me.
2008/12/18 Richard Hughes hughsient@gmail.com:
Ahh, my simple markup parser is a bit more tolerant to this and formats the bullets correctly.
What output format are you targetting at with your parser/transformator? Note that we already have two python markdown implementations in the distro.
- Thomas
On Thu, 2008-12-18 at 20:01 +0100, Thomas Moschny wrote:
What output format are you targetting at with your parser/transformator? Note that we already have two python markdown implementations in the distro.
It's in C, not python. It's also outputting to PangoMarkup rather than HTML.
Richard.
Richard Hughes (hughsient@gmail.com) said:
Personally I think the use of '"', ., *, •, o or ∘ ... are fine, just as long as all the tools are displaying the same non-invisible bytes².
Right, this discussion is going nowhere, and there are a lot of egos in play.
Pointed out without other comment.
This is a spec file description or an update description in bohdi.
The following things 'were' fixed:
- Fix `dave'
- Fubar update because of "security"
This will be converted by gnome-packagekit into:
This is a spec file description or an update description in bohdi.
The following things ‘were’ fixed: • Fix ‘dave’ • Fubar update because of “security”
Dumb question. All the complaints I've seen that come in are about word-wrapping, but your main example is about character escaping/transliteration. Why not just do the word-wrapping, and leave it at that? (Note that PK at the moment wordwraps badly, which causes other issues.)
Bill
Bill Nottingham (notting@redhat.com) said:
This is a spec file description or an update description in bohdi.
The following things ‘were’ fixed: • Fix ‘dave’ • Fubar update because of “security”
Dumb question. All the complaints I've seen that come in are about word-wrapping, but your main example is about character escaping/transliteration. Why not just do the word-wrapping, and leave it at that? (Note that PK at the moment wordwraps badly, which causes other issues.)
Alternatively, if we remove the requirement on the spec data itself to be manually wrapped with newlines, this could (theoretically) sort itself out fairly well.
Bill
On Wed, 2008-12-17 at 16:48 -0500, Bill Nottingham wrote:
Dumb question. All the complaints I've seen that come in are about word-wrapping, but your main example is about character escaping/transliteration. Why not just do the word-wrapping, and leave it at that? (Note that PK at the moment wordwraps badly, which causes other issues.)
Yes, I've fixed the word wrapping in the client tools now. I've also removed all the " and ' replacement logic.
So, if you use valid markdown in your bohdi descriptions, or in your package descriptions then gnome-packagekit will attempt to convert elements to PangoMarkup. If it comes across anything oddball, it'll just show the untouched line instead.
Richard.
On 15.12.2008 16:37, Richard Hughes wrote:
[...] Next on my list are insane descriptions. For instance, just take a look at the description for enlightenment (many pages in length)
FYI, this was noticed, reported, discussed and forgotten again: https://www.redhat.com/archives/fedora-packaging/2008-September/msg00011.htm...
[...]
CU knurd
Thorsten Leemhuis wrote:
On 15.12.2008 16:37, Richard Hughes wrote:
[...] Next on my list are insane descriptions. For instance, just take a look at the description for enlightenment (many pages in length)
FYI, this was noticed, reported, discussed and forgotten again: https://www.redhat.com/archives/fedora-packaging/2008-September/msg00011.htm...
<nod> The Guidelines portion had some traction then wandered off.
The Enlightenment description in specific, though, has been changed: https://www.redhat.com/archives/fedora-packaging/2008-September/msg00031.htm...
(Verified that this is what's in cvs.)
-Toshio