Hi all,
Following what I've read on the list I've developed thoughts on
what the
best approach might be. My current thinking is that it may be
possible
to have Org registered as a standard in such a way that it does
not
constrain our development efforts.
How?
We forgo locking down the
Asa Zeren writes:
>
> In these concerns I see one major flaw. The way they are worded at present
> implies that the Emacs implementation of org is the "one true implementation,"
> and that all tools in other environments are auxiliary. I believe that if we
> want org to grow, then it needs to
Hi,
I agree with your sentiment Asa. It would indeed be good to "standardize" Org.
It's worth spending a few words here reasoning about what this standardization
would mean. The text below are not specifically to you, Asa. But to the list.
As food for thought on this topic. FWIW.
It's easy to
Asa Zeren writes:
> Also another note is that the worg syntax document does begin to specify
> this. My point is to bring this out into a separate document.
Why should this be in a separate document? The obvious place for a
standard is worg, and the way forward is to improve what’s there.
Best
> see discussion on Mauro's thread about
> the fact that it is probably just easier to use Emacs directly if you
> need to export
> to a certain format in a specific way. It is free software after all.
I would like to add, that this is pretty easy to do, and also to make
independent of the users
Hi Corwin,
thanks for volunteering! Let us know when the paperwork is done, I'll
add you as ob-perl.el maintainer then.
All best,
--
Bastien
Hi Timothy,
TEC writes:
> I feel that this also ties into my earlier idea of putting Emacs
> as/inside an LSP server for Org. I suspect there may be a a lot
> of
> potential in making it dead easy to use Emacs as a tool.
I'm too busy to help on this, but I think it's a very good idea and
I feel that this also ties into my earlier idea of putting Emacs
as/inside an LSP server for Org. I suspect there may be a a lot
of
potential in making it dead easy to use Emacs as a tool.
I'm rather busy over the next few weeks, but I'd be happy to
spearhead a
project in this direction.
On Sat, Oct 31, 2020 at 08:22:01PM -0400, Asa Zeren wrote:
> First, I would like to repeat the importance of developing standards
> for org-mode. If we want to expand the influence of org, tooling must
> expand beyond Emacs.
I disagree. There are other open text based formats outside of
Emacs.
Hi All,
This patch is just a quick addition to export dictionary for polish language.
Things which were translated:
- Continued from previous page -> Ciąg dalszy poprzedniej strony
- Continued on next page-> Kontynuacja na następnej stronie
Let me know if it's ok.
Karol Wójcik>From
Dr. Arne Babenhauserheide writes:
Asa Zeren writes:
Also another note is that the worg syntax document does begin
to specify
this. My point is to bring this out into a separate document.
Why should this be in a separate document? The obvious place for
a
standard is worg, and the way
Thanks for the comments.
Both of you have raised some very good points, but I think that there has been
some confusion as to a number of my arguments. I hope to clarify some things
below.
On Sun Nov. 1, 2020, at 1:20AM Tom Gillespie wrote:
> My general take is that any active work toward
Dr. Arne Babenhauserheide wrote:
> Why should this be in a separate document? The obvious place for a
> standard is worg, and the way forward is to improve what’s there.
It does not necessarily need to be in a separate file, and if it is it should be
in worg or another communally owned place,
Hi all,
Thank you for your comments on my post "Thoughts on the Standardization of Org."
I appreciate all the feedback you have given me, I feel that, based off of the
responses, there have been a number of miscommunications as to my intention.
First, I did not mean the post to be primarily an
Hi Steven,
Sorry for the delayed response.
> The problem, however, is that what is exported to html and displayed in the
> exported block is either the actual UUID or the tempfile path and not the
> results from evaluating the R code. In the case of the tempfile, the tempfile
> exists but is
TEC writes:
>
> Hence, any and all concerns about feature parity etc. are completely
> resolved. One 'just' needs to implement the bindings and piping (as
> opposed to the whole shebang).
>
Something that I am missing when hacking on org-mode is some form of api
reference. Things like
Hi,
I am using emacs 27.1 and org-plus-contrib 20201026.
I am having problems with the fontification of python and ipython source
blocks when the code contains curly brackets "{}" (other course blocks are
ok). For instance, the following snippet
#+BEGIN_SRC python :results drawer
import
Can confirm that. Thanks for your work!
Best,
Ruiyang
> On Nov 1, 2020, at 4:44 PM, Kyle Meyer wrote:
>
> Kyle Meyer writes:
>
>> It looks like the query went away with dbb375fdf (Simplify Babel calls
>> evaluation, 2016-06-16), which was included in the 9.0 release. Based
>> on a quick
Hi Jack,
I have cloned the git master. Running without configuration ("make
vanilla"), emacs correctly fontifies the source block and it also gets
exported to HTML. It seems that it is a configuration problem. Sorry for
not double checking first!
Many thanks for your help!
Cheers,
Sebastian
To all who argue that Org is too tightly coupled to Emacs to consider working
with it outside of Emacs, I point to GitHub. The fact that GitHub natively
renders Org files "well enough" is a huge benefit to those of us who use Org.
It is also useful for gaining new users (assuming more users
Hi Sebastian --
> I am having problems with the fontification of python and ipython source
> blocks when the code contains curly brackets "{}" (other course blocks are
> ok). For instance, the following snippet
>
> #+BEGIN_SRC python :results drawer
> import matplotlib.pyplot as plt
>
Kyle Meyer writes:
> It looks like the query went away with dbb375fdf (Simplify Babel calls
> evaluation, 2016-06-16), which was included in the 9.0 release. Based
> on a quick glance at that commit, I don't think that was an intentional
> change.
>
> I won't take a closer look at this until at
Hi Jack,
thanks for replying!
The error does not happen using "emacs -q" (built-in package: org 9.3). I
haven't tried with the git version yet. i will and let you know.
Cheers,
Sebastian
On Sun, Nov 1, 2020 at 9:19 PM Jack Kamm wrote:
> Hi Sebastian --
>
> > I am having problems with the
On 10/9/20 3:24 PM, c.bu...@posteo.jp wrote:
Do you receive double mails? Doesn't it bother you?
Normally I would agree with you, but there is a very simple explanation
for this particular list: This mailing list is very high traffic and
people can't pay attention all the time.
I
Gustav Wikström writes:
> But maybe my issue rather lies in how the visibility toggling with
> S-TAB functions. The file property drawer is open in OVERVIEW and
> CONTENT but hidden in SHOW ALL. My intuition says that the
> file-property drawer should be closed for all toggle-states. Thoughts?
I
On 01/11/2020 17:13, Russell Adams wrote:
> On Sat, Oct 31, 2020 at 08:22:01PM -0400, Asa Zeren wrote:
>> First, I would like to repeat the importance of developing standards
>> for org-mode. If we want to expand the influence of org, tooling must
>> expand beyond Emacs.
>
> I disagree. There are
Daniele Nicolodi writes:
> Maybe the standardization should cover only the "static" parts of Org
> (ie no table formulas, no babel, no agenda, no exporters, etc). However,
> in this case, what is left is little more of a markup language with an
> editor that allows sections folding. You can have
Jack Kamm writes:
> The attached patch adds a "project" option for org-link-file-path-type.
>
> When this is set, links to files under the current project root will be
> relative, while links elsewhere are absolute.
Thanks, that sounds useful.
> It relies on project.el, which appears to have
28 matches
Mail list logo
