From: Blue P. <blu...@li...> - 2004-05-01 17:30:19
|
Hi, When it is not possible at all to indent one line, is it possible to escape this in a way? --- Here is an email writen in Yaml: - giving a first url: http://yaml.org/ - ginving another url: \ http://www.another-url.org/this_link_is_far_too_long_for_mail_client_to_allow_spaces.html # and cutting this line would broke the link --- Or perhaps another syntax: - ginving another url: || http://www.another-url.org/this_link_is_far_too_long_for_mail_client_to_allow_spaces.html # and cutting this line would broke the link || --- Or another one closer to heredoc which perl and php are used to: - ginving another url: |<< http://www.another-url.org/this_link_is_far_too_long_for_mail_client_to_allow_spaces.html # and cutting this line would broke the link << ... |
From: Oren Ben-K. <or...@be...> - 2004-05-01 17:43:12
|
On Saturday 01 May 2004 20:34, Blue Prawn wrote: > Hi, > > When it is not possible at all to indent one line, is it possible to escape > this in a way? Axiom: "The double quoted style *always* works". In your case, like this: --- Here is an email writen in Yaml: - giving a first url: http://yaml.org/ - ginving another url: "http://www.another-url.org/this_link_is_far\ _too_long_for_mail_client_to_allow_spaces\ .html" # and cutting this line would broke the link --- Admittedly, not the most readable presentation. Then again, if you have such a long line, no presentation will be very readable anyway. Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-05-01 18:05:13
|
On Sat, May 01, 2004 at 07:34:41PM +0200, Blue Prawn wrote: | --- | Here is an email writen in Yaml: | - giving a first url: http://yaml.org/ | - ginving another url: \ | http://www.another-url.org/this_link_is_far_too_long_for_mail_client_to_allow_spaces.html | # and cutting this line would broke the link In cases like this I often use the double quoted style, zoom: "http://www.another-url.org/this_link_is_far\ too_long_for_mail_client_to_allow_spaces.html" The problem, of course, with this style is that one would have to escape intermediate characters. | Or another one closer to heredoc which perl and php are used to: | - ginving another url: |<< | http://www.another-url.org/this_link_is_far_too_long_for_mail_client_to_allow_spaces.html | # and cutting this line would broke the link | << This is our most frequently proposed feature. I suppose that it isn't any more ugly than double quoted strings... Brian/Oren? Clark |
From: Oren Ben-K. <or...@be...> - 2004-05-01 18:30:22
|
On Saturday 01 May 2004 21:05, Clark C. Evans wrote: > | Or another one closer to heredoc which perl and php are used to: > | - ginving another url: |<< > | http://www.another-url.org/this_link_is_far_too_long_for_mail_client_to_a > |llow_spaces.html # and cutting this line would broke the link > | << > > This is our most frequently proposed feature. I suppose that it > isn't any more ugly than double quoted strings... Brian/Oren? We have considered this, at one time. You can have the same effect by using an indented literal scalar. The benefit of the "terminated" style is that you don't need to indent the scalar. From a YAML point of view, that's a disadvantage; the document structure becomes much less visible. It almost seems as though this should be a flow style rather than a block style, since it uses a marker rather than indentation to denote structure. The following doesn't make much sense, though: --- some: flow: { terminated: <<EOF Text EOF} ... Perhaps if someone comes up with a use case where indenting the text is a problem? The problem isn't long lines (for these, you need to use double quotes anyway). Admittedly, indenting literal scalars costs screen real estate, but they have to be pretty deeply nested for this to make a real difference (you can indent each level by just one space if you want). What's the use case? Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-05-01 20:14:44
|
The use case was to allow a file to be 'embedded' in YAML. However, this is quite easy with sed, so there really isn't a need for this construct. $ sed 's/^/ /' embedd.txt >> file.yaml ;) Clark On Sat, May 01, 2004 at 09:30:19PM +0300, Oren Ben-Kiki wrote: | > | Or another one closer to heredoc which perl and php are used to: | > | - ginving another url: |<< | > | http://www.another-url.org/this_link_is_far_too_long_... | > | << | > | > This is our most frequently proposed feature. I suppose that it | > isn't any more ugly than double quoted strings... Brian/Oren? | We have considered this, at one time. You can have the same effect by | using an indented literal scalar. The benefit of the "terminated" style | is that you don't need to indent the scalar. From a YAML point of view, | that's a disadvantage; the document structure becomes much less visible. | | It almost seems as though this should be a flow style rather than a | block style, since it uses a marker rather than indentation to denote | structure. The following doesn't make much sense, though: | | --- | some: | flow: { terminated: <<EOF | Text | EOF} | ... | | Perhaps if someone comes up with a use case where indenting the text is | a problem? The problem isn't long lines (for these, you need to use | double quotes anyway). Admittedly, indenting literal scalars costs | screen real estate, but they have to be pretty deeply nested for this to | make a real difference (you can indent each level by just one space if | you want). |
From: Blue P. <blu...@li...> - 2004-05-01 20:30:22
|
> What's the use case? The one I said, giving an url in a mail writen in yaml. If you put just only one space at the begining of this line, the mail client will put a linebreak after this space and then the url is not indented, so it is impossible to indent a very long link in an email. And if you cut the link it will hardly break it ! I know it is possible to change the parameters of the mail clients, but it not a good idea to remove it definitively. And remove it just to write an email is quite boring, isn't it? --- bookmarks: - http://yaml.org/ - { <<EOB http://grincheux.codelutin.org/~monnier/wallpapers/debian/debian_C01c.png EOB} ... Then the question is, is it important to permit to write emails in yaml? If you cut the link, a parser will glue it back, but humans? |
From: Clark C. E. <cc...@cl...> - 2004-05-02 02:23:36
|
Are double quotes acceptable? --- bookmarks: - http://yaml.org/ - "http://grincheux.codelutin.org/~monnier/wallpapers/\ debian/debian_C01c.png" ... The solution you have below won't deal with URLs that are uberlong, like this one following (or am I mistaken): --- bookmarks: - "http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&\ Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&\ r=1&f=G&l=50&co1=AND&d=PG01&s1=%22hybrid+widget%22" Best, Clark On Sat, May 01, 2004 at 10:32:28PM +0200, Blue Prawn wrote: | The one I said, giving an url in a mail writen in yaml. | If you put just only one space at the begining of this line, the mail client | will put a linebreak after this space and then the url is not indented, so it | is impossible to indent a very long link in an email. | And if you cut the link it will hardly break it ! | I know it is possible to change the parameters of the mail clients, but it not | a good idea to remove it definitively. And remove it just to write an email | is quite boring, isn't it? | | --- | bookmarks: | - http://yaml.org/ | - { <<EOB | http://grincheux.codelutin.org/~monnier/wallpapers/debian/debian_C01c.png | EOB} | ... | | Then the question is, is it important to permit to write emails in yaml? | If you cut the link, a parser will glue it back, but humans? | | | | | ------------------------------------------------------- | This SF.Net email is sponsored by: Oracle 10g | Get certified on the hottest thing ever to hit the market... Oracle 10g. | Take an Oracle 10g class now, and we'll give you the exam FREE. | http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click | _______________________________________________ | Yaml-core mailing list | Yam...@li... | https://lists.sourceforge.net/lists/listinfo/yaml-core -- Clark C. Evans Prometheus Research, LLC Chief Technology Officer Turning Data Into Knowledge cc...@pr... www.prometheusresearch.com (main) 203.777.2550 (cell) 203.444.0557 |
From: Blue P. <blu...@li...> - 2004-05-02 13:44:37
|
> Are double quotes acceptable? > > --- > bookmarks: > - http://yaml.org/ > - "http://grincheux.codelutin.org/~monnier/wallpapers/\ > debian/debian_C01c.png" > ... Perhaps you didn't read my question. I understood first that yaml was design to be both readable by machines *and* humans. Your answer here does not keep the link clicable by humans any-more! This one *is* clicable for humans: --- bookmarks: - http://yaml.org/ - { "http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=%22hybrid+widget%22" } ... |
From: Clark C. E. <cc...@cl...> - 2004-05-02 15:14:07
|
On Sun, May 02, 2004 at 03:48:52PM +0200, Blue Prawn wrote: | Your answer here does not keep the link clicable by humans any-more! | This one *is* clicable for humans: | --- | bookmarks: | - http://yaml.org/ | - { | "http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=%22hybrid+widget%22" | } | ... I must be missing something, beacuse this one is also clickable by humans, and just as valid. bookmarks: - http://yaml.org/ - http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=%22hybrid+widget%22 ... In short, I don't see what problem the extra construct you propose is solving. Best, Clark |
From: Clark C. E. <cc...@cl...> - 2004-05-02 18:55:52
|
On Sat, May 01, 2004 at 10:32:28PM +0200, Blue Prawn wrote: | If you put just only one space at the begining of this line, the mail client | will put a linebreak after this space and then the url is not indented, so it | is impossible to indent a very long link in an email. Ahh. Got it. So you are saying, that the email client will *change* the data from: --- bookmarks: - http://yaml.org/ - http://grincheux.codelutin.org/~monnier/wallpapers/ ... to --- bookmarks: - http://yaml.org/ - http://grincheux.codelutin.org/~monnier/wallpapers/ ... In this case, if your email client is that broken, send it as an attachment or use double quoted form: --- bookmarks: - http://yaml.org/ - '\ http://grincheux.codelutin.org/~monnier/wallpapers/" ... Clark |
From: Clark C. E. <cc...@cl...> - 2004-05-02 19:35:07
|
On Sun, May 02, 2004 at 02:55:52PM -0400, Clark C. Evans wrote: | --- | bookmarks: | - http://yaml.org/ | - '\ | http://grincheux.codelutin.org/~monnier/wallpapers/" | ... *blush* Thre are two things wrong with this, first, what I meant to write was (first single quote is wrong), --- bookmarks: - http://yaml.org/ - "\ http://grincheux.codelutin.org/~monnier/wallpapers/" ... And after looking at this some, I'm thinking it is wrong beacuse it isn't indented (along time ago it was legal). So, alas, I see what you are referring to. I think the only option is to send the file as an attachment to make sure that the email browser doesn't mangle it. Best, Clark |
From: Blue P. <blu...@li...> - 2004-05-04 20:42:43
|
Clark wrote: > Ahh. Got it. So you are saying, that the email client will *change* [...] > --- > bookmarks: > - http://yaml.org/ > - > http://grincheux.codelutin.org/~monnier/wallpapers/ > ... > > In this case, if your email client is that broken, send it as > an attachment or use double quoted form: > --- > bookmarks: > - http://yaml.org/ > - "\ > http://grincheux.codelutin.org/~monnier/wallpapers/" > ... [...] > And after looking at this some, I'm thinking it is wrong beacuse it > isn't indented (along time ago it was legal). So, alas, I see what > you are referring to. I think the only option is to send the file as an > attachment to make sure that the email browser doesn't mangle it. It would be nice to enable the possiblity to write *real* emails in yaml. We could imagine a lot of applications of this posibility! Let's give you a real life exemple, see the forward recent mail below. -- ---------- Forward Message ---------- Subject: [PEAR-DEV] Image_Magick_Conjure Date: Samedi 1 Mai 2004 15:13 From: Florent Monnier <no...@li...> To: pea...@li... Hello, --- - name: Image_Magick_Conjure - introduction: - This module does not provide any PHP api since its goal is to provide a high level XML interface to Image-Magick. - The final goal could be to get an equivalent for bitmap close to the quality of the POV advanced UI. - index: http://grincheux.codelutin.org/~monnier/php/conjure/ - user-doc: http://grincheux.codelutin.org/~monnier/php/conjure/improved-msl.html - notice: I am not the author of the MSL language, but MSL is still in project in Image-Magick, and is not functionnal yet. - warning: Very alpha but starts to work quite well though, it is usable unlike the actual build-in IM's Conjure which is still in work. Also notice that the MSL format is not standardized yet, but though it could help users wanting to use php-imagick in a very simple way. - future: When the IM build-in conjure will be functionnal, and when it will be included in php-imagick (perhaps in 1, 2 or 3 years), it will still be possible to access the pecl-conjure through this class. - see source: http://grincheux.codelutin.org/~monnier/php/conjure/MSL_Parser.html (Only the main file containing the class respects the Pear coding standard.) - see api phpDoc: http://grincheux.codelutin.org/~monnier/php/conjure/api/ - download: http://grincheux.codelutin.org/~monnier/php/conjure/php-conjure0.01-d.tgz - todo: - Still bugs to correct. - Optimizations possible (leaving lesser layer in memory at the same time with a parsing closer to a dom model). - The main class MSL_Parser.php should be installed in pear path, and not in local. - Lots of improvement to do. - Adapt the design for a web usage (actualy mainly a cli usage), perhaps a MSL-RPC? - Use the transparency of the new php-imagick release. - The list and append grouping types. - The id/idref cache system. - Provide glob for xc:- plasma:- gradient:- etc.. - A "preprocessor" to replace SVG-CSS by inline style (IM lack) - bugs: - Vars used in the structures switch and for can't come from the script, but can only be set outside the script while calling it. - work in progress: Advance SVG import based on importing an element called by its id (since it's quite easy to give a name to an element in Sodipodi). - exemple of possibilities: - An exemple is in the tarball in exemple directory. - \ http://grincheux.codelutin.org/~monnier/lasso/lasso_A05/lasso_A05-1_small06.png ... -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php ------------------------------------------------------- |
From: Clark C. E. <cc...@cl...> - 2004-05-05 17:12:55
|
So, to restate, context: For some transports (in particular, specific email tools), lines greater than a particular length are word-wrapped on the space character without the request of the author; as a result the line where the break occurs will not be properly indented. problem: All of YAML's scalar forms require indentation. In particular, even a double quoted form must be indented to the proper scope. solution: Introduce a "here document" like mechanism so that text can be pro-actively broken by the author, and chunks of texts can be included without indentation. While this breaks the nice indented structures, it solves the transport problem. detail: | Augment the '|' literal and '>' folded style blocks to allow for a "terminator" which specifies the end of the HERE document. For example: --- literal: |=END= this is a non-indented block scalar where carriage returns are significant =END= folded: >""" this is a non-indented block like the =END= one above, only in this case folding process is done, this one """ ... objections: Unlike other requests for including a document "inline" where something like "sed '/^/ /' embed >> file.yaml" will work, this particular problem is with the underlying transport and has no clear work-around. Although, this would enable direct inclusions, the method above would still be preferred for embedding documents. Is this correct statement of the issue? Oren/Brian, what do you think of this set of circumstances and a proposal for a HERE like document mechanism? Clark On Tue, May 04, 2004 at 10:46:08PM +0200, Blue Prawn wrote: | Clark wrote: | > Ahh. Got it. So you are saying, that the email client will *change* | [...] | > --- | > bookmarks: | > - http://yaml.org/ | > - | > http://grincheux.codelutin.org/~monnier/wallpapers/ | > ... | > | > In this case, if your email client is that broken, send it as | > an attachment or use double quoted form: | > --- | > bookmarks: | > - http://yaml.org/ | > - "\ | > http://grincheux.codelutin.org/~monnier/wallpapers/" | > ... | [...] | > And after looking at this some, I'm thinking it is wrong beacuse it | > isn't indented (along time ago it was legal). So, alas, I see what | > you are referring to. I think the only option is to send the file as an | > attachment to make sure that the email browser doesn't mangle it. | | | It would be nice to enable the possiblity to write *real* emails in yaml. | We could imagine a lot of applications of this posibility! | | Let's give you a real life exemple, | see the forward recent mail below. | | | -- | | ---------- Forward Message ---------- | | Subject: [PEAR-DEV] Image_Magick_Conjure | Date: Samedi 1 Mai 2004 15:13 | From: Florent Monnier <no...@li...> | To: pea...@li... | | Hello, | | --- | - name: Image_Magick_Conjure | | - introduction: | - This module does not provide any PHP api since its goal is to provide | a high level XML interface to Image-Magick. | - The final goal could be to get an equivalent for bitmap | close to the quality of the POV advanced UI. | | - index: | http://grincheux.codelutin.org/~monnier/php/conjure/ | | - user-doc: | http://grincheux.codelutin.org/~monnier/php/conjure/improved-msl.html | | - notice: | I am not the author of the MSL language, but MSL is still in project in | Image-Magick, and is not functionnal yet. | | - warning: | Very alpha but starts to work quite well though, | it is usable unlike the actual build-in IM's Conjure which is still in work. | Also notice that the MSL format is not standardized yet, but though | it could help users wanting to use php-imagick in a very simple way. | | - future: | When the IM build-in conjure will be functionnal, and when it will be | included in php-imagick (perhaps in 1, 2 or 3 years), it will still be | possible to access the pecl-conjure through this class. | | - see source: | http://grincheux.codelutin.org/~monnier/php/conjure/MSL_Parser.html | (Only the main file containing the class respects the Pear coding standard.) | | - see api phpDoc: | http://grincheux.codelutin.org/~monnier/php/conjure/api/ | | - download: | http://grincheux.codelutin.org/~monnier/php/conjure/php-conjure0.01-d.tgz | | - todo: | - Still bugs to correct. | - Optimizations possible (leaving lesser layer in memory at the same time | with a parsing closer to a dom model). | - The main class MSL_Parser.php should be installed in pear path, | and not in local. | - Lots of improvement to do. | - Adapt the design for a web usage (actualy mainly a cli usage), | perhaps a MSL-RPC? | - Use the transparency of the new php-imagick release. | - The list and append grouping types. | - The id/idref cache system. | - Provide glob for xc:- plasma:- gradient:- etc.. | - A "preprocessor" to replace SVG-CSS by inline style (IM lack) | | - bugs: | - Vars used in the structures switch and for can't come from the script, | but can only be set outside the script while calling it. | | - work in progress: | Advance SVG import based on importing an element called by its id | (since it's quite easy to give a name to an element in Sodipodi). | | - exemple of possibilities: | - An exemple is in the tarball in exemple directory. | - \ | http://grincheux.codelutin.org/~monnier/lasso/lasso_A05/lasso_A05-1_small06.png | | ... | | -- | PEAR Development Mailing List (http://pear.php.net/) | To unsubscribe, visit: http://www.php.net/unsub.php | | ------------------------------------------------------- | | -- Clark C. Evans Prometheus Research, LLC Chief Technology Officer Turning Data Into Knowledge cc...@pr... www.prometheusresearch.com (main) 203.777.2550 (cell) 203.444.0557 |
From: Oren Ben-K. <or...@be...> - 2004-05-05 18:12:27
|
Clark C. Evans wrote: > So, to restate, > > context: > For some transports (in particular, specific email tools), > lines greater than a particular length are word-wrapped on the > space character without the request of the author... > > problem: > All of YAML's scalar forms require indentation... So far, so good... > solution: > Introduce a "here document" like mechanism... That doesn't really work. - First and foremost, if you arbitrarily fold lines in a "here document," you change their semantics! Now, who guarantees that the length of a line in a "here document" is within the acceptable limit? - Second, if a comment line hits the length threshold and gets word wrapped, the second line will be interpreted by YAML as content. Ouch! --- # A nice, long, descriptive comment ... Will be wrapped into: --- # A nice, long, descriptive comment ... - Finally, if a nested node has properties which hit the line length limit, they'll be word wrapped, resulting in a syntax error: --- 2004: January: 7th: !clarkevans.com,2002/timesheet/entry # ... ... Will be wrapped into: --- 2004: January: 7th: !clarkevans.com,2002/timesheet/entry # ... ... This has no workaround; if you got to the point where indentation + length of node peoperty is over the word-wrapping limit, you are SOL, period. > Is this correct statement of the issue? Oren/Brian, what > do you think of this set of circumstances and a proposal > for a HERE like document mechanism? Even with "here documents", it isn't safe to word-wrap a YAML document and have it survive. You have to be aware of the word-wrap limit and build your document accordingly. Even if you go for broke and use only the flow style, you still have to ensure that comment length is less than the word-wrapping limit (it does solve all the other problems, though). So, "here documents" don't solve the problem in general. If I were to write a generic YAML-over-SMTP transport, they wouldn't help much; since the code will re-style the text anyway, it might as well do so using the double-quoted style and be done with. This leaves the use case of *manually* pasting YAML into an E-mail message. In fact, the specific case of pasting _small_ amounts of YAML into an E-mail; If you are pasting a long YAML stream, you are better off adding it as an attachment, and thereby avoid all word-wrap issues altogether. It seems that if you are pasting a small example, manually, you can do whatever manual work is necessary to fix the problem, and if you don't, well, the readers will probably grok it anyway. I don't see this use case as being compelling enough to be worth the hassle. Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-05-05 18:56:00
|
Blue, I have a question, if you "pre-indent" does your web browser wrap? --- for example: http://somelongurl/thatgoesonforquitesometime/andwouldoftenbewrappedcuzitgoeswaypast80characters/doesleadingspacesgetstripped? ... ie, if you only have leading spaces, does it wrap that as well? It is possible to use another email client? On Wed, May 05, 2004 at 09:12:22PM +0300, Oren Ben-Kiki wrote: | So, "here documents" don't solve the problem in general. If I were | to write a generic YAML-over-SMTP transport, they wouldn't help much; | since the code will re-style the text anyway, it might as well do so | using the double-quoted style and be done with it. Yes, it doesn't seem as if "here" style documents would be a general solution to this problem. And the implementation plus uglyness cost don't seem to justify the hack. I can't think of a good alternative besides suggesting that people should use broken email clients (*grins*). ;) Clark |
From: Brian I. <in...@tt...> - 2004-05-05 19:00:00
|
On 05/05/04 21:12 +0300, Oren Ben-Kiki wrote: > Clark C. Evans wrote: > It seems that if you are pasting a small example, manually, you can do > whatever manual work is necessary to fix the problem, and if you don't, well, > the readers will probably grok it anyway. I don't see this use case as being > compelling enough to be worth the hassle. +1 Cheers, Brian |