Karl Voit writes:
> For reasons explained in my Orgdown-related articles[1] I would
> propose to use this chance to introduce a different term for the
> Org-mode lightweight markup language in contrast to the Org-mode
> Elisp implementation in order to push the syntax in a tool-agnostic
> way. We
Hi,
* TEC wrote:
>
> I'm still hoping for that discussion :P
>
> To the Org community, if you have thoughts on this - please share them
> :)
For reasons explained in my Orgdown-related articles[1] I would
propose to use this chance to introduce a different term for the
Org-mode lightweight marku
"Bruce D'Arcus" writes:
>> I just tried with clean Emacs:
>>
>> #+beg #+begin_ -> list of completions, all in lower
>> case
>> #+BEG #+BEGIN_ -> list of completions, all in upper
>> case
>
> Perhaps at some point the upper case should just be removed?
I am not sure if it is a good idea from ba
On Sat, Oct 23, 2021 at 9:41 AM Ihor Radchenko wrote:
>
> Carlos Pita writes:
>
> >>> But then c-a-p is very lenient since it lists lower and upper case block
> >>> variants even when I typed a lower case prefix, and upper case usually
> >>> will go first in the list, hence promoting a seemingly
Carlos Pita writes:
>>> But then c-a-p is very lenient since it lists lower and upper case block
>>> variants even when I typed a lower case prefix, and upper case usually
>>> will go first in the list, hence promoting a seemingly bad practice.
>>
>> Could you clarify what is "c-a-p"?
>
> Yes, I
Hi Carlos,
Just a minor point from me, this really should be a new thread IMO. While not
much may have happened with the IETF RFC, it’s still something on my mind that I
hope to get back to eventually.
All the best,
Timothy
Hi Igor,
> The conversation was about keywords and similar constructs (i.e.
> ^#+keyword). You are looking at property drawer and properties inside.
> There is no preference here, though internally properties in property
> drawer are all converted to upper case.
Ok, thank you very much for the cl
Carlos Pita writes:
>> Org is standardized on lower case. Uppercase is used in the manual as
>> a poor man's bold, and supported for historical reasons.
>
> But C-c C-x p still inserts stuff like:
>
>:PROPERTIES:
>:ARCHIVE: ...
>:END:
>
> Maybe it should be updated or maybe I don't f
Hi,
in https://list.orgmode.org/87tuuw3n15@nicolasgoaziou.fr/#t it's stated:
> Org is standardized on lower case. Uppercase is used in the manual as
> a poor man's bold, and supported for historical reasons.
But C-c C-x p still inserts stuff like:
:PROPERTIES:
:ARCHIVE: ...
:END:
Hello again,
I'm still a fan of Org as an IETF registered MEME type, but I recently
heard of what Rust did to get text/rust registered on Linux systems:
https://bugs.freedesktop.org/show_bug.cgi?id=90487
Perhaps we could submit a similar patch?
--
Timothy.
> On Oct 24, 2020, at 10:40 AM, Bastien wrote:
>
> Palak Mathur writes:
>
>> Yes, it is going to be some work. I will try to get something
>> started and share a draft.
>
> Can you and Leo work together on this ?
>
> Perhaps you can share a first draft (from the user point of view) that
Palak Mathur writes:
> Yes, it is going to be some work. I will try to get something
> started and share a draft.
Can you and Leo work together on this ?
Perhaps you can share a first draft (from the user point of view) that
Leo can consolidate (from a generic parser point of view) ?
Thanks to
Hi Leo,
Leo Vivier writes:
> Bastien writes:
>
>> Sorry, perhaps I was not clear: (1) and (2) do not need to be separate
>> documents.
>
> No, you were quite clear. I just surmised that two documents would be
> required, but upon thinking about it some more, (1) and (2) would make
> for a cohe
Sent from my iPhone
> On Oct 24, 2020, at 7:50 AM, Bastien wrote:
>
> Hi Palak,
>
> Palak Mathur writes:
>
>> I am fairly new to Org. Let me see if I can use it as a markup in an
>> Editor other than Emacs. I will report on what syntax options are very
>> Emacs specific, what are general
Bastien writes:
> Sorry, perhaps I was not clear: (1) and (2) do not need to be separate
> documents.
No, you were quite clear. I just surmised that two documents would be
required, but upon thinking about it some more, (1) and (2) would make
for a cohesive whole.
> Great, thanks for volunteer
Hi Leo,
Leo Vivier writes:
> Bastien writes:
>
>> As the first paragraph says:
>>
>> "This document describes and comments Org syntax as it is currently
>> read by its parser (Org Elements)"
>>
>> while we need a description of Org's syntax from the point of view of
>> (1) a human writer
Hi there,
Bastien writes:
> As the first paragraph says:
>
> "This document describes and comments Org syntax as it is currently
> read by its parser (Org Elements)"
>
> while we need a description of Org's syntax from the point of view of
> (1) a human writer and (2) any possible Org pars
Hi Palak,
Palak Mathur writes:
> I am fairly new to Org. Let me see if I can use it as a markup in an
> Editor other than Emacs. I will report on what syntax options are very
> Emacs specific, what are general and what can be ported.
Thanks! I think it is less a matter of *what* is described i
> On Oct 24, 2020, at 7:09 AM, Bastien wrote:
>
> Hi Wes,
>
> Wes Hardaker writes:
>
>> Ok, I'll try to create a template we can fill out in github next week
>> (I'm swamped this week with a deadline).
>
> If you manage to make any progress on this, please share it with the
> whole list s
Hi Wes,
Wes Hardaker writes:
> Ok, I'll try to create a template we can fill out in github next week
> (I'm swamped this week with a deadline).
If you manage to make any progress on this, please share it with the
whole list so that interested people can possibly follow.
For the record, I think
Hello,
"Lennart C. Karssen" writes:
> Wouldn't it be a good idea to standardise on either uppercase or
> lowercase? Limitting the standard to only one of the two case options
> will probably spark a huge debate on which one to choose because one
> side would have to change their behaviour. But a
Hi all,
On 01-10-2020 05:40, TEC wrote:
>
> Bastien writes:
>
>> If there is absolutely zero burden put on the shoulders of Org's
>> maintainers, then I'm all for it.
>
> From the look of things, there's just effort in the initial creation.
>
>>> I think it would serve well the proliferation
> On Oct 6, 2020, at 2:03 PM, TEC wrote:
>
>
> Wes Hardaker writes:
>
>> Ok, I'll try to create a template we can fill out in github next week
>> (I'm swamped this week with a deadline).
>
> Sounds good :) I'm fairly busy for the next ~month and a half anyway so
> I'm happy to accommodate
Wes Hardaker writes:
Ok, I'll try to create a template we can fill out in github next
week
(I'm swamped this week with a deadline).
Sounds good :) I'm fairly busy for the next ~month and a half
anyway so
I'm happy to accommodate delays.
Would it be a good idea to use the markdown RFC as
TEC writes:
> Wes Hardaker writes:
>
> > IETF person here. If you want help or a co-author, I can help if
> > needed.
> >
> > [not a mime expert, but I've been involved with the IETF for ~25
> > years]
>
> Fantastic! I've never summited an RFC or interacted with the IETF
> before in my life,
Wes Hardaker writes:
IETF person here. If you want help or a co-author, I can help
if needed.
[not a mime expert, but I've been involved with the IETF for ~25
years]
Fantastic! I've never summited an RFC or interacted with the IETF
before
in my life, so that sounds great to me :)
Tha
TEC writes:
> > Is anyone willing to move forward with this registration?
>
> In about two months, I am.
IETF person here. If you want help or a co-author, I can help if needed.
[not a mime expert, but I've been involved with the IETF for ~25 years]
--
Wes Hardaker
TEC writes:
> I see. Would there be someone well suited to check that everything is
> accurate? I wouldn't feel confident auditing the whole document by
> myself.
Well, "we" of course includes Nicolas and other core contributors, but
anyone is welcome. This should not be done by a single person
Bastien writes:
You register once and for all? Is there some red tape involved
in
maintaining the registration?
Assuming I haven't misread/missed anything, the only thing that we
might
cause a change is if the specification changes - but since it
looks like
we can just link to our speci
Hi Timothy,
TEC writes:
>> Is anyone willing to check that there are no constraints?
>
> I've read through https://tools.ietf.org/html/rfc6838 and I couldn't
> see any constraints placed on us beyond the initial registration's
> requirements.
You register once and for all? Is there some red ta
Bastien writes:
If there is absolutely zero burden put on the shoulders of Org's
maintainers, then I'm all for it.
From the look of things, there's just effort in the initial
creation.
I think it would serve well the proliferation and
popularization of org-mode.
Agreed.
This is the
Hi,
What are the pros?
About the cons: maybe we need to look more into the requirements.
I am looking at https://tools.ietf.org/html/rfc2048 and the one that
concerns me a little is 2.2.6: I guess somebody would need to write a
bit of docs about security concerns. Or you can go the way Markdown
Hi,
What are the pros?
About the cons: maybe we need to look more into the requirements.
I am looking at https://tools.ietf.org/html/rfc2048 and the one that
concerns me a little is 2.2.6: I guess somebody would need to write a
bit of docs about security concerns. Or you can go the way Markdown
Hi,
hj-orgmod...@hj.proberto.com writes:
> I do not have much insight into all the possible outcomes (i.e. I am
> clueless about such outcomes) except one outcome - orgmode MIME type
> gets registered.
If there is absolutely zero burden put on the shoulders of Org's
maintainers, then I'm all f
I do not have much insight into all the possible outcomes (i.e. I am
clueless about such outcomes) except one outcome - orgmode MIME type
gets registered. I think it would serve well the proliferation and
popularization of org-mode. I.e. I do not see any negatives, only
positives. After su
I'm still hoping for that discussion :P
To the Org community, if you have thoughts on this - please share them
:)
Timothy.
Me earlier:
> Bastien writes:
>> Let's discuss this with care, and consider all possible outcomes.
>
> This is /exactly/ what I was hoping to prompt with this email.
> I
Just a quick note from me.
Bastien writes:
Let's discuss this with care, and consider all possible
outcomes.
This is /exactly/ what I was hoping to prompt with this email.
I think it would be a nice idea (assuming feasibility), but it's
certainly not something to rush.
All the best,
Timot
Hi,
stardiviner writes:
> I would like to see this result too. Great to know this :)
Well, there is no "result" expected yet, because we did not yet
agreed to make a formal request.
Let's discuss this with care, and consider all possible outcomes.
Thanks,
--
Bastien
I would like to see this result too. Great to know this :)
TEC writes:
> Hi everyone,
>
> Prompted by the fact that Markdown is registered as a MIME type
> (RFC7763) and perusing the MIME registration procedure (RFC6838),
> I wonder if it may be possible to register Org as a MIME type?
>
> The
That would be very nice indeed.
/Gustav
From: Emacs-orgmode on behalf of
TEC
Sent: Friday, September 4, 2020 4:44:50 PM
To: org-mode-email
Subject: Shower thought: submit an IETF RFC to register Org as a MIME type
Hi everyone,
Prompted by the fact that
Hi everyone,
Prompted by the fact that Markdown is registered as a MIME type
(RFC7763) and perusing the MIME registration procedure (RFC6838),
I wonder if it may be possible to register Org as a MIME type?
There are a few parts of RFC6838 in particular which give me hope,
such
as:
[§4.9] uni
41 matches
Mail list logo
