Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi Carsten, Carsten Dominik carsten.domi...@gmail.com writes: Keeping this variable a customize variable invites changes also by people who do not really know what they are doing. Turning it into a defvar or defconst and somewhere document how to hack around the restriction if you really need to sounds like a good solution for me. Agreed. `org-emphasis-regexp-components' is now a defvar. Also, I added `org-emphasis-alist' to the manual. -- Bastien
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: We can also use a very simple and tolerant regexp (e.g. =[^\000]+=), and introduce a syntax to escape markers for fine-grained control. FWIW this looks like the correct approach to me. -- Bastien
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hello, Carsten Dominik carsten.domi...@gmail.com writes: First of all, we should not see Org as just another plain text markup language (no offense meant, I am sure, and none taken). Because of its unique treatment of source code inclusion, source code markup, and executability, it is very much unique, I think. Indeed. Or, to put it differently, an external tool wishing to export an /any/ Org document has to implement Babel in addition to the parser. For example, every users setup has some dependency of parser behavior on external variables: todo keywords. The way this is fixed in the sense that we can guarantee a stable parsing of such a system is to tell people that including the TODO keyword definitions with a #+TODO line into the file. So you can have a global setting in a global customization variable to make things easy for yourself and get good behavior in every new file you open, but you can stabilize a file for the parser with in-buffer settings when you need compatibility for other users. There are a few exceptions that Nicolas has pointed out in this thread. The COMMENT keyword is one. We could define an in-buffer setting for it, or we could just fix it, the pain here would be minimal. I think we should only add in-buffer settings for important parts of Org syntax (e.g. TODO keywords). A hard-coded value for small details like COMMENT keyword or EFFORT property is good enough, IMO. The reason why the emphasis regexp components were made configurable in the first place is because when the feature was introduced, I had no idea what would work, and I redesigned this part several times over. Emphasis is a very heuristic system, the character that are allowed before and after the markers are necessarily a compromise, and we will always find people for who the chosen selection will not work. That is why I would like to argue for keeping this part hackable, even if I agree that the official definition should be fixed. Keeping this variable a customize variable invites changes also by people who do not really know what they are doing. Turning it into a defvar or defconst and somewhere document how to hack around the restriction if you really need to sounds like a good solution for me. We can also use a very simple and tolerant regexp (e.g. =[^\000]+=), and introduce a syntax to escape markers for fine-grained control. Nicolas, I would assume that your wish to disallow customization is focused on the regexp components, and the marker characters for emphasis, but not on the possibility to change the in-buffer face that is being used to highlight the stuff in the buffer? That's correct. Regards, -- Nicolas Goaziou
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi again Thank you all for the responses. So as a neewb again, I dont really understand fully all the technical specifications from the above posts, what do you guys recommended i do if i want to start moving and using org now full time in terms of color support? should i use the current emp. method, use another method suggested above which will be 100% supported, wait with my move to org (what is the rough time frame for the new specification)? I would greatly appreciate any help as i am very keen to move over to orgmode full time best Z
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Carsten Dominik carsten.domi...@gmail.com writes: Another example is the emphasis stuff. There are no in-buffer settings for it, and they would be pretty hard to make. An in-buffer way of doing elisp is File Local Variables ; or is that not appropriate ? Maybe the question I'm askign is : why were #+KEYWORD lines favored over emacs' own mechanism of file local variables ? (I did google on this a bit, but no success.) -- Nico.
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi Z, can you show an example on how you use it? Maybe we can find a better way. Nicolas is right that portability is compromised by customizable emphasis. - Carsten On 18.3.2013, at 00:02, zeltak zel...@gmail.com wrote: Hi all i just finished a great conversation on #org-mode with some great people. they told me about this thread and the planned changes that may or may not occur to the syntax and id like to just raise the newbee perspective. I find the ability to add custom emphasise with custom faces invaluable. i find it very easy to add and very useful for me since i use ALOT of color highlights in my academic work. i really hope that there is some way to leave the current mphasise with custom faces options as is thx alot guys Z
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Carsten Dominik carsten.domi...@gmail.com writes: can you show an example on how you use it? Maybe we can find a better way. Nicolas is right that portability is compromised by customizable emphasis. On 18.3.2013, at 00:02, zeltak zel...@gmail.com wrote: I find the ability to add custom emphasise with custom faces invaluable. i find it very easy to add and very useful for me since i use ALOT of color highlights in my academic work. Here is an excerpt from my .emacs, actually stolen from Fabrice Nielson (http://www.mygooglest.com/fni/), that might give some hints how to do interactive color highlighting without any changes to Org-mode: ,-- | ;; *** 14.13 (info (emacs)Highlight Interactively) | | ;; You can use `hi-lock-mode' to highlight words: | ;; `M-x hi-lock-mode RET' | ;; `C-x w h match RET hi-blue RET' | ;; You can also write your settings to the buffer you're using with | ;; `C-x w b', and read them back in again next time with `C-x w i'. | | ;; TODO Have a look at http://www.emacswiki.org/emacs/color-moccur.el for | ;; searching regexp in buffer | | (GNUEmacs | ;; identical token highlighting commands | (when (try-require 'highlight) | | (defface hlt-1 '((t (:background #A0))) nil) | (defface hlt-2 '((t (:background #A0FFA0))) nil) | (defface hlt-3 '((t (:background #A0))) nil) | (defface hlt-4 '((t (:background #FFA0FF))) nil) | (defface hlt-5 '((t (:background #FFA0A0))) nil) | (defface hlt-6 '((t (:background #A0))) nil) | (defface hlt-7 '((t (:background #A0FFA0))) nil) | (defface hlt-8 '((t (:background #A0))) nil) | (defface hlt-9 '((t (:background #FFA0FF))) nil) | (defface hlt-10 '((t (:background #FFA0A0))) nil) | | (global-set-key (kbd C-S-p) 'hlt-previous-highlight) | (global-set-key (kbd C-S-n) 'hlt-next-highlight) | | (defun hlt-highlight-current-word () | (interactive) | (let ((var_name (current-word t))) | (when var_name | (save-excursion | (hlt-highlight-regexp-region | (point-min) | (point-max) | (regexp-quote var_name)) | | ;; emulation of Vim's `*' search | (global-set-key (kbd C-*) 'hlt-highlight-current-word) | )) | | ;; ;; bind the hi-lock commands to more finger-friendly sequences | ;; (define-key hi-lock-map (kbd C-z i) 'hi-lock-find-patterns) | ;; (define-key hi-lock-map (kbd C-z p) 'highlight-phrase) | ;; (define-key hi-lock-map (kbd C-z r) 'unhighlight-regexp) | | ;; (define-key hi-lock-map (kbd C-z h) 'highlight-regexp) | ;; (define-key hi-lock-map (kbd C-z C-h) 'highlight-lines-matching-regexp) | ;; (define-key hi-lock-map (kbd C-z b) 'hi-lock-write-interactive-patterns) | | ;; Highlight based on regexps | (global-set-key [M-f1] 'highlight-regexp) | (global-set-key [M-f2] 'highlight-lines-matching-regexp) | (global-set-key [M-f3] 'hi-lock-mode) | (global-set-key [M-f4] 'hi-lock-write-interactive-patterns) | | ;; highlight current symbol | (when (try-require 'light-symbol) | (light-symbol-mode)) | | ;; highlight current symbol | (setq highlight-symbol-idle-delay 0.5) | (when (try-require 'highlight-symbol) | (highlight-symbol-mode)) `-- -- cheers, Thorsten
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Dear Carsten, Thank you for your quick reply. Let me start by first thanking you for your great work on orgmode, I only recently discovered it (someone referred me to your great talk on youtube) and it made me have the courage to start learning emacs and use orgmode. I (actually me and several colleagues here at the school of public health at Harvard) have been using for the past 4 years a note taking app called notecase pro (http://www.notecasepro.com/) which is nice but not FLOSS and lacking in other areas. I am a post doc who takes alot of notes (30-40) daily which include images and color markings. colors are especially important to us since we use them to mark different commands, research areas, paths, comments and warning so that we have a clear easy to remember color visual clue. We use 15-20 color fg/bg commands. An example note could look like this: http://i.imgur.com/Ncq6ozs.png i am a complete new orgmode user but i am so impressed and overblown with the features and definitely want to transition to use it full time and also convince my colleagues to do so as well. with the help of the #irc channel i was able to use the customizing features for the emphasize symbols to achieve color support . the config now looks like this: '(org-emphasis-alist (quote ((@ (:foreground #B4 :background #FF :weight bold) ) ($ (:foreground #FF) ) (* bold b /b) (/ italic i /i) (_ underline span style=\text-decoration:underline;\ /span) (= org-code code /code verbatim) (~ org-verbatim code /code verbatim) (+ (:strike-through t) del /del That would have worked for me but i understood that there are plans to actually disable these customization's in the next version to allow better portability. If its not to hard It would be great to have a method similar to the customizable emphasis that lets a user define custom colors of FG/BG for inline viewing. I am less concerned about exporting since at least for me i plan to do all the editing/viewing inline inside emacs (though it would be nice of course to be able to use it with mobile org and/or other mobile solutions for when we do field work). I will hold on with starting with the mammoth task of converting my Notecase notes into orgmode until the issues is resolved, i assume i should follow the mailing list to check on this? Sorry for the long email and thank you so much again for all your work, its truly fantastic Z. On Mon, Mar 18, 2013 at 2:08 AM, Carsten Dominik carsten.domi...@gmail.comwrote: Hi Z, can you show an example on how you use it? Maybe we can find a better way. Nicolas is right that portability is compromised by customizable emphasis. - Carsten On 18.3.2013, at 00:02, zeltak zel...@gmail.com wrote: Hi all i just finished a great conversation on #org-mode with some great people. they told me about this thread and the planned changes that may or may not occur to the syntax and id like to just raise the newbee perspective. I find the ability to add custom emphasise with custom faces invaluable. i find it very easy to add and very useful for me since i use ALOT of color highlights in my academic work. i really hope that there is some way to leave the current mphasise with custom faces options as is thx alot guys Z
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
zeltak zel...@gmail.com writes: Dear Carsten, Thank you for your quick reply. Let me start by first thanking you for your great work on orgmode, I only recently discovered it (someone referred me to your great talk on youtube) and it made me have the courage to start learning emacs and use orgmode. [snip] '(org-emphasis-alist (quote ((@ (:foreground #B4 :background #FF :weight bold) ) ($ (:foreground #FF) ) (* bold b /b) (/ italic i /i) (_ underline span style=\text-decoration:underline;\ /span) (= org-code code /code verbatim) (~ org-verbatim code /code verbatim) (+ (:strike-through t) del /del That would have worked for me but i understood that there are plans to actually disable these customization's in the next version to allow better portability. If its not to hard It would be great to have a method similar to the customizable emphasis that lets a user define custom colors of FG/BG for inline viewing. I am less concerned about exporting since at least for me i plan to do all the editing/viewing inline inside emacs (though it would be nice of course to be able to use it with mobile org and/or other mobile solutions for when we do field work). I will hold on with starting with the mammoth task of converting my Notecase notes into orgmode until the issues is resolved, i assume i should follow the mailing list to check on this? Sorry for the long email and thank you so much again for all your work, its truly fantastic Z. I want to add, as one of the people that helped Z with this on IRC--and as another person that made the leap into Emacs largely because of Org, about five years ago--that I think there are a lot of users like this: people who value Org as a tool that is tightly integrated with the power and flexibility of Emacs and Emacs Lisp, who aren't necessarily closely following Org's upstream development or this list (I didn't follow it closely until recently, either), and who are more concerned with keeping Org flexible and customizable enough to exactly fit their needs within Emacs than they are about making it available as yet another plain-text markup language outside of Emacs. Much as my Gnus is heavily customized to my needs at this point, with Elisp-based features such as adaptive scoring and virtual groups that other news and mail readers simply don't have, I would never really dream of reproducing Org outside of Org. And there are plenty of things that I would never expect to work in an external application or parser that speaks the Org format (dynamic blocks that run Elisp, for example), which everyone nonetheless wants to have. Perhaps a compromise could be reached on variables such as `org-emphasis-alist' and others possibly slated for the defconst treatment: instead of doing that, let's consider keeping them customizable but include the default values in the Org format specification. Org users who are never using Org outside of Emacs will never see a problem using custom emphasis marks inside Emacs, unless Org drops the feature. For those who know that they want to use their Org files with some external parser, we could have an `org-rfc-check' function that warns about non-standard values of things like org-emphasis-alist and offers to revert them to the defaults (which would be the same as the values in the spec). What do you think? Is this a crazy scheme? -- Regards, WGG
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Dnia 2013-03-18, o godz. 15:21:54 wgreenho...@riseup.net (W. Greenhouse) napisał(a): Perhaps a compromise could be reached on variables such as `org-emphasis-alist' and others possibly slated for the defconst treatment: instead of doing that, let's consider keeping them customizable but include the default values in the Org format specification. Org users who are never using Org outside of Emacs will never see a problem using custom emphasis marks inside Emacs, unless Org drops the feature. For those who know that they want to use their Org files with some external parser, we could have an `org-rfc-check' function that warns about non-standard values of things like org-emphasis-alist and offers to revert them to the defaults (which would be the same as the values in the spec). What do you think? Is this a crazy scheme? Just Another N00b's 2cents: what about moving such things from core to contrib? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi everyone, first a disclaimer: Nicolas has thought about all things parser a lot more than I have, so he might disagree. But here is my take on the issue. First of all, we should not see Org as just another plain text markup language (no offense meant, I am sure, and none taken). Because of its unique treatment of source code inclusion, source code markup, and executability, it is very much unique, I think. Therefore it deserved a clean definition and a well defined parser, with a goal to make files function correctly in different peoples setup. This is what Nicolas is trying to give to us - aside from turning an incredible parser/exporter mess into a sane system. We used to have as many parsers as exporters, all slightly different, bugs having to be fixed in different ways in each parser. That is gone, with a very limited amount of pain, and I am entirely amazed that this was even possible, let alone that someone had the stamina to do it and the patience it takes to put this, with the small limitations it brings, onto the community. Now, I also agree that it is desirable that Org remains to be a hackable system with as much flexibility as we can allow, and we need to carefully consider where the line is. For example, every users setup has some dependency of parser behavior on external variables: todo keywords. The way this is fixed in the sense that we can guarantee a stable parsing of such a system is to tell people that including the TODO keyword definitions with a #+TODO line into the file. So you can have a global setting in a global customization variable to make things easy for yourself and get good behavior in every new file you open, but you can stabilize a file for the parser with in-buffer settings when you need compatibility for other users. There are a few exceptions that Nicolas has pointed out in this thread. The COMMENT keyword is one. We could define an in-buffer setting for it, or we could just fix it, the pain here would be minimal. Another example is the emphasis stuff. There are no in-buffer settings for it, and they would be pretty hard to make. The reason why the emphasis regexp components were made configurable in the first place is because when the feature was introduced, I had no idea what would work, and I redesigned this part several times over. Emphasis is a very heuristic system, the character that are allowed before and after the markers are necessarily a compromise, and we will always find people for who the chosen selection will not work. That is why I would like to argue for keeping this part hackable, even if I agree that the official definition should be fixed. Keeping this variable a customize variable invites changes also by people who do not really know what they are doing. Turning it into a defvar or defconst and somewhere document how to hack around the restriction if you really need to sounds like a good solution for me. Now to the discussion with Z about additional emphasis definitions which he/she uses for custom highlighting of stuff. Right now this relies on modifying the emph-alist variable. However, for the purpose of in-buffer only highlighting, it is not necessary to go through parser-sensitive code. You can do this simply with additions to font-lock, for example using font-lock-add-keywords or something like this, see also Thorsten's post. If someone wants, I can provide an example for Z's case, and we could encapsulate such behavior into a little library in contrib, to make it easy to configure such behavior. Compromising the parser for this application is not necessary. Nicolas, I would assume that your wish to disallow customization is focused on the regexp components, and the marker characters for emphasis, but not on the possibility to change the in-buffer face that is being used to highlight the stuff in the buffer? - Carsten On 18.3.2013, at 16:21, W. Greenhouse wgreenho...@riseup.net wrote: zeltak zel...@gmail.com writes: Dear Carsten, Thank you for your quick reply. Let me start by first thanking you for your great work on orgmode, I only recently discovered it (someone referred me to your great talk on youtube) and it made me have the courage to start learning emacs and use orgmode. [snip] '(org-emphasis-alist (quote ((@ (:foreground #B4 :background #FF :weight bold) ) ($ (:foreground #FF) ) (* bold b /b) (/ italic i /i) (_ underline span style=\text-decoration:underline;\ /span) (= org-code code /code verbatim) (~ org-verbatim code /code verbatim) (+ (:strike-through t) del /del That would have worked for me but i understood that there are plans to actually disable these customization's in the next version to allow better portability. If its not to hard It would be great to have a method similar to the customizable emphasis that lets a user define custom colors of FG/BG for inline viewing. I am less concerned
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Carsten Dominik carsten.domi...@gmail.com writes: The reason why the emphasis regexp components were made configurable in the first place is because when the feature was introduced, I had no idea what would work, and I redesigned this part several times over. Emphasis is a very heuristic system, the character that are allowed before and after the markers are necessarily a compromise, and we will always find people for who the chosen selection will not work. That is why I would like to argue for keeping this part hackable, even if I agree that the official definition should be fixed. Keeping this variable a customize variable invites changes also by people who do not really know what they are doing. Turning it into a defvar or defconst and somewhere document how to hack around the restriction if you really need to sounds like a good solution for me. To some extend I disagree, I think. Well, a contrib library is of course OK, but I think it's not the right way to go about it. . . Would it be possible to make it easier to make 'custom' highlights? In a previous thread a [cite:key] syntax was suggested. Perhaps, a better way for custom emphasis would be [type:value] allowing for custom functions for each type. E.g. [TYPE:value] would run function a function org-type-keys-TYPE which returns value formatted with a special face. Perhaps this is more cumbersome and perhaps it is no more 'structured' than using customized emphases. –Rasmus -- El Rey ha muerto. ¡Larga vida al Rey!
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi Carsten, Thank you for your very insightful thoughts. I would like to make one note. 2013ko martxoak 18an, Carsten Dominik-ek idatzi zuen: Now to the discussion with Z about additional emphasis definitions which he/she uses for custom highlighting of stuff. Right now this relies on modifying the emph-alist variable. However, for the purpose of in-buffer only highlighting, it is not necessary to go through parser-sensitive code. You can do this simply with additions to font-lock, for example using font-lock-add-keywords or something like this, see also Thorsten's post. If someone wants, I can provide an example for Z's case, and we could encapsulate such behavior into a little library in contrib, to make it easy to configure such behavior. Compromising the parser for this application is not necessary. I use org to write articles which discuss words in foreign languages. These need to be distinctively typeset (in italics), and sometimes need to be set in a special font with coverage for exotic characters. I would find it very useful to be able to define special emphasis environments for these words. Using macros feels too much like writing LaTeX (which I use org to avoid having to write directly, as much as possible...) I see the goal of the syntactic standardization as making it easier to operate with non-emacs tools; as Nicolas said: My point of view is the following: Org (as a format) definition shouldn't depend on Emacs. It should be totally parseable by any language (which is not the case actually, since syntax relies on variables defined in Emacs). IOW, we should work to make it a real plain-text markup format. Personally, I am OK with articles I have written for export never being able to be read by non-emacs tools (as opposed to other uses of org as a database/schedule/agenda, where the ability to access the information in other programs/programming languages would be useful). I sympathize with the goal of making the format accessible to other tools, but I also think the ability to have within emacs additional flexibility wrt. formatting (for both display and export) is worth preserving. -- Aaron Ecay
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi all i just finished a great conversation on #org-mode with some great people. they told me about this thread and the planned changes that may or may not occur to the syntax and id like to just raise the newbee perspective. I find the ability to add custom emphasise with custom faces invaluable. i find it very easy to add and very useful for me since i use ALOT of color highlights in my academic work. i really hope that there is some way to leave the current mphasise with custom faces options as is thx alot guys Z
[O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
David Engster d...@randomsample.de writes: Jambunathan K. writes: Still you haven't answered my Fudging the mail reply headers question to my satisfaction. http://www.gnu.org/software/emacs/manual/html_node/message/Mailing-Lists.html A mailing list poster can use MFT to express that responses should be sent to just the list, and not the poster as well. This will happen if the poster is already subscribed to the list. (Nicolas, I am sorry. I have added OT to this post) I know that. But that doesn't answer the question why Carsten will appear in the To header of a mail that I reply to a mail I receive from Eric S Fraga. See my question here: http://lists.gnu.org/archive/html/emacs-orgmode/2013-02/msg00525.html If I wide reply to your post, I see that the TO header points to the ML. Why it doesn't happen with Eric S Fraga's post? The said behaviour will change based on the phase of moon. I have noticed such fudging of the To headers by Eric for a long time. Unless there is a satisfactory explanataion, I will assume Eric is faking innocence. -David
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Jambunathan K. writes: I know that. But that doesn't answer the question why Carsten will appear in the To header of a mail that I reply to a mail I receive from Eric S Fraga. Because Carsten started the thread and did not set MFT. -David
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
David Engster d...@randomsample.de writes: Jambunathan K. writes: I know that. But that doesn't answer the question why Carsten will appear in the To header of a mail that I reply to a mail I receive from Eric S Fraga. Because Carsten started the thread and did not set MFT. In this very specific thread - the one I am typing right now, Nicolas Goaziou doesn't appear in To - why? Normally, when I wide reply to a Ngz's post it gets sent to him as well as the mailing list. If your argument is right, Ngz should appear in To or CC headers of the post. I see only ML address. So what am I missing? -David
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Jambunathan K. writes: David Engster d...@randomsample.de writes: Jambunathan K. writes: I know that. But that doesn't answer the question why Carsten will appear in the To header of a mail that I reply to a mail I receive from Eric S Fraga. Because Carsten started the thread and did not set MFT. In this very specific thread - the one I am typing right now, Nicolas Goaziou doesn't appear in To - why? Normally, when I wide reply to a Ngz's post it gets sent to him as well as the mailing list. If your argument is right, Ngz should appear in To or CC headers of the post. I see only ML address. So what am I missing? You didn't do a wide reply in 871ubntg32@gmail.com. -David
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
David Engster d...@randomsample.de writes: Jambunathan K. writes: David Engster d...@randomsample.de writes: Jambunathan K. writes: I know that. But that doesn't answer the question why Carsten will appear in the To header of a mail that I reply to a mail I receive from Eric S Fraga. Because Carsten started the thread and did not set MFT. In this very specific thread - the one I am typing right now, Nicolas Goaziou doesn't appear in To - why? Normally, when I wide reply to a Ngz's post it gets sent to him as well as the mailing list. If your argument is right, Ngz should appear in To or CC headers of the post. I see only ML address. So what am I missing? You didn't do a wide reply in 871ubntg32@gmail.com. I don't what that mail is. My Gnus-foo is just OKish. Anyways, S W is what I do on all my mails - those that I reply to on the ML and on those that I reply to from my Inbox. If I reply to ESF's posts, I might have edited the headers myself. Normally - 99% of the cases - I don't edit headers by hand. ps: I don't want to continue this thread further. For your satisfaction, I am willing to concede that I am wrong. -David --
