Martin Rottensteiner writes:
> In my setup in org 9.4 the behaviour is like this for a scheduled date
> without scheduled time (for example SCHEDULED: <2020-10-27>:
> C-u S-left: Date changes to date before (26th)
> C-u S-right: Date does not change
> C-u C-u S-left: Date changes to date before (2
> It would be great if each of these individual "task
> happenings" were archived under the date and time they were completed
> individually, and not just all as one block. This way I could get weekly
> reviews that take those into account.
What about trying to do your weekly review using org-agen
I have same problem sometimes in different babel languages.
I would like to know what caused this problem too.
Can you send me a message after you solved problem? Thanks in advance. :)
smile
[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:
Feel free to prepare a patch using my code and send it here.
I think the following function should be sufficient to preserve
pretty-symbols composition:
(el-patch-defun org-agenda-highlight-todo ...
I have added only 3 lines to the original org-agenda-highlight-todo (see
el-patch-add instances in
ian martins writes:
> Thanks. I pushed. The docs for java are here [1].
>
> It looks like many of the language pages don't pick up their formatting.
> Mine did the same at first. Is it fine if I fix them?
Yes, please, and in general feel free to make improvements and fixes.
Thanks.
Eric,
> For instance, in my recent org documents, I have added a #+calc: keyword
> which I use for embedded calc lines. This allows me to have a clearly
> labelled line that Calc will recognise and that I can process using a
> filter before export while also ensuring that other tools, e.g. ones
>
Eric S Fraga writes:
>
> A more subtle issue, and one that I raised earlier, is the underlying
> infinite customization provided by Emacs. Some of my macros are elisp
> code. A standard for the structure of org mode documents could exist
> but using such standard-compliant documents would be
Tom Gillespie writes:
Any support for something like this would need to retain
backward
compatibility as well to avoid older versions reformatting the
tables
due to e.g. the presence of a double pipe. I also think that
extending
the table syntax in ways that makes it more complex than it
a
Any support for something like this would need to retain backward
compatibility as well to avoid older versions reformatting the tables
due to e.g. the presence of a double pipe. I also think that extending
the table syntax in ways that makes it more complex than it already
is, will be a non-starte
Hi all,
This is a pretty major 'feature request', but I think also an
important
one.
When developing large tables, it can often be /necessary/ to start
using
multi-column/row cells for clarity, and sensible exporting
results.
As far as I am aware, in Org does not currently have any
multi-
Dear all,
this is an interesting discussion to read, and I think lots of clever
people have made this an interesting discussion. So I hesitated to even
join the discussion, because I am quite removed from current development
and no longer feel qualified to guide it. Still, my 5c.
For me, it see
On Monday, 2 Nov 2020 at 16:23, Russell Adams wrote:
> #+BEGIN_RANT
> [...]
> #+END_RANT
Apologies for my comment then! :-( I am fully sympathetic to the views
you have expressed.
Let me rephrase, therefore: it could be interesting to see Emacs as a
SaaS which processes org mode documents. But
Hi Everyone,
From the Org standardisation effort the idea of using Emacs as the
basis
of an LSP server for Org has been mentioned a few times.
I thought this deserved it's own thread so here it is :)
I'm quite keen to investigate the viability of this idea.
Some key questions that I think nee
Russell Adams writes:
On Mon, Nov 02, 2020 at 02:56:58PM +, Eric S Fraga wrote:
(as an aside, Emacs as an LSP could be interesting, especially
if
network based)
LSP is a standard from Microsoft:
https://github.com/Microsoft/language-server-protocol/
It allows networked JSON and telem
On Mon, Nov 02, 2020 at 02:56:58PM +, Eric S Fraga wrote:
> (as an aside, Emacs as an LSP could be interesting, especially if
> network based)
#+BEGIN_RANT
LSP is a standard from Microsoft:
https://github.com/Microsoft/language-server-protocol/
It allows networked JSON and telemetry, as well
On Monday, 2 Nov 2020 at 17:22, Greg Minshall wrote:
> i wonder if it's possible (ignoring the possible utiltiy) to divide org
> mode into two (maybe three?) things.
Everything is possible! Whether it's desirable or not is a different
question. :-)
Although at first glance, it would seem straig
Eric,
i was thinking of replying to your earlier post on the power of emacs.
now i guess i'll ask my question or make my vague point or whatever.
i wonder if it's possible (ignoring the possible utiltiy) to divide org
mode into two (maybe three?) things.
first is "org mode as a document structur
Hi Gerardo,
I am by far no expert, but I think with the kind of setup you currently
use your goal cannot be reached: The repeating task you use is one
single task, and it will be archived as that one single task.
There's a different way to approach repeating tasks though that might
meet your req
Daniele Nicolodi writes:
On 02/11/2020 10:02, TEC wrote:
I think there are absolutely some benefits for Org users. I am
personally interested in registering Org as an IANA MIME type.
I don't think that registering Org as IANA MIME type will have
the
consequences you hope it has.
Hmmm.
+1 for everything that both Pankaj and Tim have said.
I've said this elsewhere: for me, the power of org mode is that it is
Emacs. Org allows me to leverage the power of Emacs more easily for
what I want to do (everything from project management to dissemination
of various sorts).
Anything that
Please note that changes from this patch cause clipping of popups with language
labels (pre.src:before).
--
Best regards,
Vladislav Glinsky
signature.asc
Description: OpenPGP digital signature
On 02/11/2020 10:02, TEC wrote:
> I think there are absolutely some benefits for Org users. I am
> personally interested in registering Org as an IANA MIME type.
I don't think that registering Org as IANA MIME type will have the
consequences you hope it has.
> What will this do? Well, for starter
Russell Adams writes:
> On Sun, Nov 01, 2020 at 05:17:19PM -0800, Ken Mankoff wrote:
>>
>> 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
>> b
Daniele Nicolodi writes:
> On 02/11/2020 00:10, Dr. Arne Babenhauserheide wrote:
>>
>> 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
)
#) :noerror t)
package--check-signature("https://orgmode.org/elpa/"; "archive-contents" "(1
(org . [(20201102) ( ) \"Outline-ba..." nil #f(compiled-function
(&optional good-sigs) #) #f(compiled-function ()
#))
#f(compiled-function () #)()
pack
Daniele Nicolodi writes:
Acceptance criterion for what? Adoption of what?
It seems to me that some see a the adoption of a simplified
version of
the Org markup language outside Emacs and the org-mode
implementation as
something desirable. However, I don't see what the Org community
would
On 02/11/2020 00:10, Dr. Arne Babenhauserheide wrote:
>
> 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
Kyle Meyer writes:
> Russell Adams writes:
>
>> On Sat, Oct 31, 2020 at 01:58:25PM -0400, Kyle Meyer wrote:
>>> As I mentioned elsewhere in the thread, my guess is that Russell was
>>> using your example as is, rather than adding the space on the line
>>> (where X is below).
>>
>> No. I added a s
On Sun, Nov 01, 2020 at 05:17:19PM -0800, Ken Mankoff wrote:
>
> 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 Or
29 matches
Mail list logo
