 | | Re: // and ** vs {} and [] (was: testing in rtl...)
|
|
(...) That's what I used to think too -- but I'm not so sure anymore... (...) the double slash and (2) the http: prefix. (...) I've never seen anyone write anything like that before. But in any case, it's got two leading slashes instead of one. (...) (21 years ago, 30-May-03, to lugnet.publish, lugnet.admin.nntp)
|
| |
| | Re: // and ** vs {} and [] (was: testing in rtl...)
|
|
(...) Since you don't think most of the above are problems because they are not on word boandaries, how do you reconcile that with FTX's support for bolding, italicizing, or underlining part of a word, such as in the example in the FTX quick start (...) (21 years ago, 30-May-03, to lugnet.publish, lugnet.admin.nntp)
|
| |
| | Re: // and ** vs {} and [] (was: testing in rtl...)
|
|
(...) If // and ** proved superior to {} and [], then going back and removing {} and [] (and of course automatically converting existing pages to // and **) would certainly be an option. (...) But it's only an issue under one obscure set of (...) (21 years ago, 30-May-03, to lugnet.publish, lugnet.admin.nntp)
|
| |
| | Re: // and ** vs {} and [] (was: testing in rtl...)
|
|
(...) I'm not sure what your above comment has to do with FTX supporting non-word aligned positions for the formatting characters, no matter which character set is used. I was attempting to point out that // and ** would seem to be more troublesome (...) (21 years ago, 31-May-03, to lugnet.publish, lugnet.admin.nntp)
|
| |
| | Re: // and ** vs {} and [] (was: testing in rtl...)
|
|
(...) Oh I agree that // and ** are potentially more troublesome than {} and [] in normal text -- and that's why {} and [] were chosen instead. But I think the "troublesome" part may be entirely solveable from a coding standpoint. (...) It depends. (...) (21 years ago, 31-May-03, to lugnet.publish, lugnet.admin.nntp)
|
| |
| | Re: // and ** vs {} and [] (was: testing in rtl...)
|
|
(...) Can't speak for Mozilla, but OEQuotefix doesn't react on the above line (or any other of Brian's suggestions), it seems to only process special characters at the beginning, and ending, of a word, and does nothing if special chars overlap, like (...) (21 years ago, 1-Jun-03, to lugnet.publish, lugnet.admin.nntp)
|
