Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi Nicolas, Nicolas Goaziou 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)
Hi Carsten, Carsten Dominik 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)
Hello, Carsten Dominik 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 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 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)
Carsten Dominik 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 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 wrote:
> zeltak 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 "" "") ("/" italic "" "") ("_" underline "
>> " "") ("=" org-code
>> "" "" verbatim) ("~" org-verbatim "" ""
>> verbatim) ("+" (:strike-through t) "" ""
>>
>> 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 s
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)
zeltak 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 "" "") ("/" italic "" "") ("_" underline "
> " "") ("=" org-code
> "" "" verbatim) ("~" org-verbatim "" ""
> verbatim) ("+" (:strike-through t) "" ""
>
> 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)
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 "" "") ("/" italic "" "") ("_" underline "" "") ("=" org-code ""
"" verbatim) ("~" org-verbatim "" "" verbatim) ("+"
(:strike-through t) "" ""
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
wrote:
> 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 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 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 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 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)
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 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)
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)
David Engster writes: > Jambunathan K. writes: >> David Engster 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 > > --
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Jambunathan K. writes: > David Engster 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 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: > 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
[O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
David Engster 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
