[Out-of-Thread] Re: [RFC] Org syntax (draft)

[Out-of-Thread] Re: [RFC] Org syntax (draft)

[Jambunathan K]

David Engster <deng@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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[David Engster]

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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Jambunathan K]

David Engster <deng@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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[David Engster]

Jambunathan K. writes:
> David Engster <deng@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.fsf@gmail.com>.

-David

Re: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Jambunathan K]

David Engster <deng@randomsample.de> writes:

> Jambunathan K. writes:
>> David Engster <deng@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.fsf@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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[zeltak]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 997 bytes --]

Re: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Carsten Dominik]

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 <zeltak@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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Thorsten Jolitz]

Carsten Dominik <carsten.dominik@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 <zeltak@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 "#FFFFA0"))) nil)
|         (defface hlt-2 '((t (:background "#A0FFA0"))) nil)
|         (defface hlt-3 '((t (:background "#A0FFFF"))) nil)
|         (defface hlt-4 '((t (:background "#FFA0FF"))) nil)
|         (defface hlt-5 '((t (:background "#FFA0A0"))) nil)
|         (defface hlt-6 '((t (:background "#FFFFA0"))) nil)
|         (defface hlt-7 '((t (:background "#A0FFA0"))) nil)
|         (defface hlt-8 '((t (:background "#A0FFFF"))) 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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[zeltak]

[-- Attachment #1: Type: text/plain, Size: 3436 bytes --]

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 "#B40000" :background
"#FFDDDD" :weight bold) "" "") ("$" (:foreground "#FF0000") "" "") ("*"
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.dominik@gmail.com>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 <zeltak@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
>
>

[-- Attachment #2: Type: text/html, Size: 5533 bytes --]

Re: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[W. Greenhouse]

zeltak <zeltak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 "#B40000" :background
> "#FFDDDD" :weight bold) "" "") ("$" (:foreground "#FF0000") "" "")
> ("*" 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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Marcin Borkowski]

Dnia 2013-03-18, o godz. 15:21:54
wgreenhouse@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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Carsten Dominik]

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 <wgreenhouse@riseup.net> wrote:

> zeltak <zeltak@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 "#B40000" :background
>> "#FFDDDD" :weight bold) "" "") ("$" (:foreground "#FF0000") "" "")
>> ("*" 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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Rasmus]

Carsten Dominik <carsten.dominik@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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Aaron Ecay]

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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Samuel Wales]

On 3/18/13, W. Greenhouse <wgreenhouse@riseup.net> wrote:
> 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

I think this is a good idea.

===

Here is a brainstorm involving an old idea:

If the problem is external parsers vs. flexibility, I wonder if it
might be possible to have zeltak's cake and eat it too.  This applies
to more than just coloring in the buffer transiently.

In the case of color, $[face :foreground "red"]we can actually color
something in a way that external parsers can understand and export
backends can support$[end].  To some degree, at least.

We can do so $[face :foreground "yellow" :underline t]using a syntax
that will work for other features also and can be upgraded$[end].  Not
only for faces.  Just change "face" to the name of your feature.

Every feature that uses the $[] syntax starts out as experimental or
in the user's .emacs.  Then after we experiment with a feature and
decide it's worth being a default, we add it to the RFC and no longer
call it Emacs-only.

One big win is that Emacs and external parsers need only understand
the $[] notation, and do not need to come up with new parsing
techniques for syntax, because it is a Lisp lambda list.  Even the
user can do this.

All sorts of things then come for free.  For example, quoting,
escaping, nesting, pretty-printing, exporting, hiding, making the $[]
parts look human-friendly by making them invisible or collapsing them,
and so on.  They are all available for new features that need syntax,
including user-defined ones.

A possibility for what it's worth.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY
can get it.  There is NO hope without action.  This means YOU.

Re: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Nicolas Richard]

Carsten Dominik <carsten.dominik@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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[zeltak]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 860 bytes --]

Re: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Nicolas Goaziou]

Hello,

Carsten Dominik <carsten.dominik@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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Bastien]

Hi Carsten,

Carsten Dominik <carsten.dominik@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: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Bastien]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@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