Re: S-left / S-right with (double) prefix C-u without scheduled time (only date)
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 (26th)
> C-u C-u: S-right: Date does not change
Hmph, that discrepancy between left and right is odd...
Underneath org-timestamp-change is being called with WHAT as hour or
minute. Regardless of whether the timestamp has a time, it's doing
(setq time
(apply #'encode-time
(or (car time0) 0)
(+ (if (eq timestamp? 'minute) n 0) (nth 1 time0))
(+ (if (eq timestamp? 'hour) n 0) (nth 2 time0))
(+ (if (eq timestamp? 'day) n 0) (nth 3 time0))
(+ (if (eq timestamp? 'month) n 0) (nth 4 time0))
(+ (if (eq timestamp? 'year) n 0) (nth 5 time0))
(nthcdr 6 time0)))
So that explains why left shifts the date, as it's essentially starting
from 00:00.
> I would prefer this behaviour instead (my proposal):
> C-u S-left: Add a default time (e.g. 6:00)
> C-u S-right: Add a default time (e.g. 6:00)
> C-u C-u S-left: Add a default time (e.g. 6:00)
> C-u C-u: S-right: Add a default time (e.g. 6:00)
C-u+ is an explicit request to operate on a time part, so that sounds
sensible to me.
> Scheduled date+time Timestamps can afterwards be changed as expected with
> C-u prefix(es).
Yes, and, based on the current design, it should even work without a
prefix for successive calls.
> What I found out until now:
> ( org-schedule nil "12:00" ) adds a time 12:00 to a SCHEDULED date property.
> (if (< (length (org-entry-get nil "SCHEDULED")) 16) (print
> 'scheduled_time_missing) (print 'scheduled_time_existent))
> org-timestamp-has-time-p: could maybe better be used instead for finding
> out if time is not present.
>
> I think this would be a better default behaviour or the current behaviour
> might even be a bug.
I think the current behavior falls into the oversight/bug category,
especially given the left/right discrepancy. Here's a minimal fix that
results in your desired behavior (assuming you don't have a preference
for any particular range of initial times).
diff --git a/lisp/org.el b/lisp/org.el
index 03df139fb..04089c6ec 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14964,7 +14964,8 @@ (defun org-timestamp-change (n what updown
suppress-tmp-delay)
(setq extra (match-string 1 ts))
(when suppress-tmp-delay
(setq extra (replace-regexp-in-string " --[0-9]+[hdwmy]" "" extra
- (when (string-match "^.\\{10\\}.*?[0-9]+:[0-9][0-9]" ts)
+ (when (or (memq what '(hour minute))
+ (string-match "^.\\{10\\}.*?[0-9]+:[0-9][0-9]" ts))
(setq with-hm t))
(setq time0 (org-parse-time-string ts))
(when (and updown
Re: Archiving repeated tasks under corresponding date tree for each repeated item
> 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-agenda? You can show the task every day you complete it by enabling org-agenda-log-mode in your weekly agenda (v l). If your tasks are also archived regularly, you may also need "v A" to include archive files into agenda view. Best, Ihor Gerardo Moro writes: > Dear all, > > I am resending this as I believe it's a useful concept to implement, > especially by those who track their tasks and do weekly/monthly reviews. > > When I archive a repeated task (let's say, a learning project of 15 minutes > every Wednesday day for 2 months), the task gets archived in a date tree > all under the day it was closed (cancelled) as a whole. This means that all > the LOGGED individual instances of repetition are archived on the day the > project got completed. 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. Not sure if I made myself understood! > :)) > > Thanks! > G
Re: Org mode fontification error in # in python and ipython source blocks
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: @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/
On Mon, Nov 2, 2020 at 2:26 AM Sebastian Gimeno
wrote:
> 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 matplotlib.pyplot as plt
> plt.plot([1,2,3])
> plt.show()
> a=1
> print("a={}".format{a})
> #+END_SRC
>
> does not fontify correctly in either python or ipython source blocks.
>
> As a consequence, when exporting the org file to HTML (C-c C-e h h), it
> fails with the following message:
>
> font-lock-fontify-keywords-region: Invalid function: #
>
> If changing the code snippet to:
>
> #+BEGIN_SRC python :results drawer
> import matplotlib.pyplot as plt
> plt.plot([1,2,3])
> plt.show()
> a=1
> print("a=%s" % a)
> #+END_SRC
>
> the block fontifies and the file is exported to HTML correctly.
>
> Can you reproduce this behaviour?
>
> Many thanks in advance!
>
Re: prettify-symbols-mode in org agenda?
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 the body). That change simply preserves 'composition text property in agenda. Best, Ihor William Xu writes: > Hi, > > Is there any plan to support prettify-symbols-mode in org agenda? With > that mode, it would make it easier to, for example, replace the todo > keywords with some nice looking unicode chars. > > From reddit, I found yantar92 has posted some elisp changes to enable the > support: > https://www.reddit.com/r/orgmode/comments/i3upt6/prettifysymbolsmode_not_working_with_orgagenda/ > > -- > William
Re: worg changes
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.
Re: Thoughts on the standardization of Org
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 > which will ignore lines starting with #, do not fail. If the standard > did not allow for arbitrary keywords, would this limit my use? perhaps the standard for e-mail headers (originally, RFC822) might be a useful way of thinking about this issue. it standardizes what it standardizes, and then says, "and, by the way, you can put in almost anything else [X-Mailer, ...], but you can't count on any other node understanding it". over time, new things are standardized (and, so, moved to, e.g., Mailer, and other things aren't. it seems to me this has worked fairly well, and partly this works because of the late Jon Postel's admonition for designing internet protocols: be conservative in what you send, and liberal in what you accept. [1] cheers, Greg [1] i.e., be extremely picky about sticking exactly to the letter of the standard in generating, e.g., documents, but allow for some sloppiness in the format of incoming documents.
Re: Thoughts on the standardization of Org
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 shackled by not > having elisp available to process the macros. They would really only be > usable within Emacs and hence my suggestion that what people really > want, without knowing it, is Emacs everywhere. ;-) [1] > I think the above is perhaps the most critical point. Much of the talk on standardisation seems to be focusing on org's markup layer. This is only a small part of org. Many of my org documents include macros, results from code block evaluation and rely on elisp code execution when certain content changes (such as changing a todo status). Without any of this, the document is not an accurate representation compared to how it is when viewed/used within Emacs. Even the goal of collaborative editing won't work because changing the data outside Emacs won't trigger the macros, functions, code blocks etc to update dependent parts (e.g. changing the TODO status won't result in the timestamp I record in the draw from being updated or updating that value in a table wo't result in re-calculation on formulas etc). One suggested benefit for standardisation was in being able to add a MIME type. Like others have mentioned, I'm unclear on how exactly adding a mime type really helps anyone. Having a MIME type only gives value if you can also have a MIME handler. Nobody except Emacs users have a MIME handler for *.org files and if you are an Emacs user, then Emacs will handle that type based on the built-in type handlers. Even if you had a very basic org parser, about all you might get is some syntax highlighting and maybe some folding support. You are unlikely to have much editing support (for example, you won't know from just the file what the defined keywords are, only the keywords used, same with tags, priorities, etc). People have mentioned that github and other systems support org mode files. I think this is a little misleading - they support a subset of the org-mode markup and can add minimal text highlighting based on that markup. These implementations all seem only partially complete and tend to only handle highlighting for more common languages. While it is great they have this support, to view this as proof of a the viability of an external non-Emacs org-mode is perhaps a little optimistic. The term 'standardisation' might have been a little misleading for this discussion. Much of what people seem to be talking about could be satisfied with a completed syntax reference like the one on worg. This would be sufficient to allow development of systems that are able to parse an org file and render it in specific formats (like github does). Perhaps focusing on how to make this document as clear and complete as possible would be a better effort than trying to define some formal specification of the whole org-mode system.
Re: Tables: missing multi-col/row syntax
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
already
is, will be a non-starter.
I am also concerned with avoiding disrupting previous table. I
think
that non-space double+ pipes should be alright (hence their part
in my
suggestion) as it still maintains that the number of columns is
equal to
the number of pipes. E.g. currently
|| a| b | = 3 columns, and is reformatted to | | a | b |
proposal
|| a| b | = 2 cells, 2+1=3 columns (same)
Thus, an alternate but more likely approach
would be to allow specification of what cells to merge outside
the
table as is done for formulas. It is not elegant, but it would
be a
layer on top of existing syntax, and it would allow the
fundamental
structure of the table to remain the same -- rows of cells. For
example #+TBLCELLMERGE: @2-3$1 or something like that. Thoughts?
Tom
I like how this seems to address the issue while keeping backwards
compatibility, but I have two big concerns:
1. I think this could make it hard to see which cells are
'masked' by a
merge at a glance, and would make associated errors easy
2. I think that for say a table with 2-3 large sub-sections this
could
lead to problematic formating.
Regarding 2, E.g. (content and form made up on the spot)
| Powerpoint | Voltage ripple while drawing 2A continuous load
over Xs || | | | Current ripple while drawing
24V continuous load over Xs ||| || |
||
1s | 5s | 10s | 20s | 30s |
1s | 2s | 5s | 10s | 20 | 30s |
|+-++-+-+-+--+++-++-|
| Kitchen|
3% | 2% | 3% | 1% | 2% |
1% | 4% | 3% | 5% | 3% | 2% |
| Bedroom|
1% | 2% | 1% | 2% | 1% |
2% | 1% | 1% | 1% | 2% | 1% |
#+TBLCELLMERGE: @2-6$1,@7-11$1
vs.
| Powerpoint | Voltage ripple while drawing 2A continuous load
over Xs || Current ripple while drawing 24V continuous load
over Xs |
|| 1s | 5s | 10s | 20s | 30s
| 1s | 2s | 5s | 10s | 20 | 30s
|
|+++-+-+---++++-++-|
| Kitchen| 3% | 2% | 3% | 1% | 2%
| 1% | 4% | 3% | 5% | 3% | 2%
|
| Bedroom| 1% | 2% | 1% | 2% | 1%
| 2% | 1% | 1% | 1% | 2% | 1%
|
(NB: clearer without line wrapping, more concise examples
definitely
available if I thought about it a tad more)
On Mon, Nov 2, 2020 at 1:37 PM TEC wrote:
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-col/row
syntax. The only viable method seems to be re-implementing the
table
using export blocks in every backend you may want to export to
(in
my
case, usually TeX + HTML). This is clumsy, difficult to work
with,
and
could be avoided should org gain support for multi-col/row
syntax.
I appreciate that this would constitute a major change both the
Org's
syntax and the codebase, but I believe such a change is
warranted
by the
advantages it would provide.
Both how this can be implemented while minimising/eliminating
the
chance
of breaking well-formed current table elements, and what syntax
may be
both acceptable and seem sensible to use.
I would anticipate such a feature working by designating two
characters
to indicate "add row" and "add column". For example "|" and
"-".
These
characters would take affect when /immediately following/ (no
space) a
cell separator ("|"), and designate the dimensions of the top
right cell.
Example:
| a | b | c |
|---+---+---|
| a | - | | |
| - | b | . |
| . | | | c |
Would be interpreted just as any current table is.
However,
| hello | there | you |
|---+---+--|
|| two column | cell |
Contains a 2x1 cell.
| a little | test |
|--+--|
|- hello | hi |
| two row | you |
Contains a 1x2 cell. In a more complex example:
| a | b | c |
|---+---+---|
||-- hi | a |
| two x | . |
| three | b |
| c | - | . |
Contains a 2x3 cell.
This is just the first syntax that comes to mind, but hopefully
the
general form of this idea seems viable.
All the best,
Timothy.
Re: Tables: missing multi-col/row syntax
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-starter. Thus, an alternate but more likely approach
would be to allow specification of what cells to merge outside the
table as is done for formulas. It is not elegant, but it would be a
layer on top of existing syntax, and it would allow the fundamental
structure of the table to remain the same -- rows of cells. For
example #+TBLCELLMERGE: @2-3$1 or something like that. Thoughts?
Tom
On Mon, Nov 2, 2020 at 1:37 PM TEC wrote:
>
> 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-col/row
> syntax. The only viable method seems to be re-implementing the
> table
> using export blocks in every backend you may want to export to (in
> my
> case, usually TeX + HTML). This is clumsy, difficult to work with,
> and
> could be avoided should org gain support for multi-col/row syntax.
>
> I appreciate that this would constitute a major change both the
> Org's
> syntax and the codebase, but I believe such a change is warranted
> by the
> advantages it would provide.
>
> Both how this can be implemented while minimising/eliminating the
> chance
> of breaking well-formed current table elements, and what syntax
> may be
> both acceptable and seem sensible to use.
>
> I would anticipate such a feature working by designating two
> characters
> to indicate "add row" and "add column". For example "|" and "-".
> These
> characters would take affect when /immediately following/ (no
> space) a
> cell separator ("|"), and designate the dimensions of the top
> right cell.
>
> Example:
> | a | b | c |
> |---+---+---|
> | a | - | | |
> | - | b | . |
> | . | | | c |
>
> Would be interpreted just as any current table is.
>
> However,
>
> | hello | there | you |
> |---+---+--|
> || two column | cell |
>
> Contains a 2x1 cell.
>
> | a little | test |
> |--+--|
> |- hello | hi |
> | two row | you |
>
> Contains a 1x2 cell. In a more complex example:
>
> | a | b | c |
> |---+---+---|
> ||-- hi | a |
> | two x | . |
> | three | b |
> | c | - | . |
>
> Contains a 2x3 cell.
>
> This is just the first syntax that comes to mind, but hopefully
> the
> general form of this idea seems viable.
>
> All the best,
>
> Timothy.
>
Tables: missing multi-col/row syntax
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-col/row
syntax. The only viable method seems to be re-implementing the
table
using export blocks in every backend you may want to export to (in
my
case, usually TeX + HTML). This is clumsy, difficult to work with,
and
could be avoided should org gain support for multi-col/row syntax.
I appreciate that this would constitute a major change both the
Org's
syntax and the codebase, but I believe such a change is warranted
by the
advantages it would provide.
Both how this can be implemented while minimising/eliminating the
chance
of breaking well-formed current table elements, and what syntax
may be
both acceptable and seem sensible to use.
I would anticipate such a feature working by designating two
characters
to indicate "add row" and "add column". For example "|" and "-".
These
characters would take affect when /immediately following/ (no
space) a
cell separator ("|"), and designate the dimensions of the top
right cell.
Example:
| a | b | c |
|---+---+---|
| a | - | | |
| - | b | . |
| . | | | c |
Would be interpreted just as any current table is.
However,
| hello | there | you |
|---+---+--|
|| two column | cell |
Contains a 2x1 cell.
| a little | test |
|--+--|
|- hello | hi |
| two row | you |
Contains a 1x2 cell. In a more complex example:
| a | b | c |
|---+---+---|
||-- hi | a |
| two x | . |
| three | b |
| c | - | . |
Contains a 2x3 cell.
This is just the first syntax that comes to mind, but hopefully
the
general form of this idea seems viable.
All the best,
Timothy.
Re: Thoughts on the standardization of Org
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 seems unrealistic to standardize Org in a way that make it desirable or even feasible to have *full implementations* in other tools. What makes sense it to have tools that can - *display* org files in a pleasant and useful way - *convert* org files into other formats, with some accepted loss of functionality - *write* org files that then will function properly in Emacs. Orgzly is a fantastic example. It reads and displays Org files, understands enough syntax to provide very useful functionality, and is decent enough to not change stuff that is does not understand and use, so that the files it writes are again fully functional in Emacs. It seems to me that this covers most of what we can hope for, as a basic formula. No definition of Org syntax can fully know what I have done in my personal environment, and therefore will not be able to reproduce that functionality elsewhere. This is intrinsic in Org and Emacs, I think. The efforts to clean up the markup syntax have been fantastic (thank you, in particular, Nicolas), and they have made it possible to have meaningful parsers like the one on github. And they provide a certain guarantee that the three items I list above will work, also going forward. Now, do I want that an arbitrary web browser or email client understands if a file is org syntax, and that clicking on it should open Emacs. Yes, I would like that. So in that sense, a mime type would be useful, for sure. Greetings Carsten On Mon, Nov 2, 2020 at 4:50 PM Eric S Fraga wrote: > 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, note, I only say it might > be interesting. I am not particularly keen on cloud services for all > kinds of reasons including ownership, security, etc. > > My solution is to have Emacs with me at all times so I have org & gnus & > erc & emms & ... :-) I have a Planet Computers Gemini and an > OpenPandora, for this reason, and am awaiting the soon to be available > Pyra with impatience to have a fully open system (open software in the > form of Debian & Emacs and open hardware, as much as is possible at the > moment). > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty > >
Re: Thoughts on the standardization of Org
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, note, I only say it might be interesting. I am not particularly keen on cloud services for all kinds of reasons including ownership, security, etc. My solution is to have Emacs with me at all times so I have org & gnus & erc & emms & ... :-) I have a Planet Computers Gemini and an OpenPandora, for this reason, and am awaiting the soon to be available Pyra with impatience to have a fully open system (open software in the form of Debian & Emacs and open hardware, as much as is possible at the moment). -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
Emacs as an Org LSP server
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 need addressing are: 1. How can we 'package' Emacs into an LSP client? 2. Assuming we use some language as the basis for the host how do we want to pick it? LSP library? Lisp? Are there any outstanding contenders. 3. How much effort is involved? Is it worth it to try to make Org more approachable* (without Emacs)? Lastly, but perhaps even more crucially --- who would be interested in working on this? I certainly am, but this feels like something that would be more viable with a small working group. Who's interested? Timothy. * I can't help but think that this hypothetical LSP server may serve as a 'gateway drug' to Org in Emacs
Re: Thoughts on the standardization of Org
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 telemetry, as well as all the other problems that come from trusting the remote server: https://microsoft.github.io/language-server-protocol/specifications/specification-current/#telemetry_event Either of these items would provide justification for me to exclude LSP from any personal consideration, and for me to strongly recommend against it's use in any capacity. Microsoft and related technologies have no place in my Emacs. I don't care to see Org made easy or functional in Visual Studio. Why contribute to layers which allow an illegal monopoly more market share? Why code for them for free? Because it's supported by: Atom, Brackets, Delphi, Eclipse, Emacs, Kakoune, Kate, VSCode, NeoVim, Sublime Text 3, JupyterLab, and more . -- Timothy
Re: Thoughts on the standardization of Org
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 as all the other problems that come from trusting the remote server: https://microsoft.github.io/language-server-protocol/specifications/specification-current/#telemetry_event Either of these items would provide justification for me to exclude LSP from any personal consideration, and for me to strongly recommend against it's use in any capacity. Microsoft and related technologies have no place in my Emacs. I don't care to see Org made easy or functional in Visual Studio. Why contribute to layers which allow an illegal monopoly more market share? Why code for them for free? #+END_RANT On a milder tone, I think it's silly to send JSON packets every time I type a key, even to a local service. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Thoughts on the standardization of Org
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 straightforward to separate syntax from use (what you call structure versus environment), the two are so intimately tied together that fixing the syntax could make the latter harder to evolve. 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 which will ignore lines starting with #, do not fail. If the standard did not allow for arbitrary keywords, would this limit my use? 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 shackled by not having elisp available to process the macros. They would really only be usable within Emacs and hence my suggestion that what people really want, without knowing it, is Emacs everywhere. ;-) [1] (as an aside, Emacs as an LSP could be interesting, especially if network based) Footnotes: [1] for my sins, I've recently had to use various tools for writing (text & data) including Word, Excel and Teams chats: how *do* people work efficiently in some of these environments? No abbreviations, no registers, no embedded Calc, no line highlighting (I keep losing the cursor), ... -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
Re: Thoughts on the standardization of Org
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 structuring [hierarchy, tables, lists] and markup [links, ??? -- maybe it's all part of "document structure"] technique. (versus, possible "third": agenda, task manager. [that i'm not all that familiar with.]) versus org mode as a computing environment (== "org mode as life", which is to a large extent true for me, as well). the border between these divisions is, of necessity (i suspect) fairly fluid. but, i wonder if one could draw a useful boundary at "babel execute". i.e., on one side, one is definitely in "computing environment". (and, in my notes on your earlier e-mail: "what about calc, used in table formulae?". which you also mention.) i'm neutral on the issue of standardization (though i agree with Daniele Nicolodi that standardization might not bring what everyone wants). i will note that for many years the C language was not a formal "standard", but people figured out how to write "portable" code that worked with the major compilers and runtime environments. (it's nicer today that, e.g., C is an international standard, but that wasn't the first step towards "interoperability".) my bias is i'd love to see "everybody" able to export *and* tangle an org document, possibly within a limited subset, such as those that don't require babel-execute for that purpose. cheers, Greg
Re: Archiving repeated tasks under corresponding date tree for each repeated item
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 requirements: Copying that task for each repeat. There's a command (org-clone-subtree-with-time-shift) that lets you copy a task easily. With that you have different tasks that can be archived separately. I did never use this approach myself though. Perhaps that helps, Julius Dittmar Am 29.10.20 um 08:01 schrieb Gerardo Moro: When I archive a repeated task (let's say, a learning project of 15 minutes every Wednesday day for 2 months), the task gets archived in a date tree all under the day it was closed (cancelled) as a whole. This means that all the LOGGED individual instances of repetition are archived on the day the project got completed. 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.
Re: Thoughts on the standardization of Org
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. I'm glad you've brought this up. I wouldn't want to put in hours of effort for a unlikely benefit. My hope is that registering org as an IANA MIME type will cause it to trickle down into individual MIME registries. The benefit I see here is Org being able to be treated more as a 'first class' plaintext format --- like I see markdown being treated today. Open a ".md" file in Ocular and you see a nice rendered version (I use this as a general, not specific example). Then, if we can package Emacs into an LSP client, we can provide a very well-featured Org experience to dozens of editors, and the "text/*" association will be important to ensure that Org files are opened in those text editors. For people who use editors like VSCode, being able to send an Org file and have it open in VSCode will likely prompt them to install an extension that provides support for .org files... This may be a bit unrealistic, and I'm hugely appreciative of any effort to inform me of any aspects that I may be overlooking. Finally, even if you get your attachment automatically tagged as "text/org", the receiving side needs to have a mime type handler configured to display it. As far as I know, not even Emacs (on the platforms that allow it) registers itself as an handler for any MIME type. Therefore, what you get, assuming that the mail client on the other side behaves correctly and uses "text/*" as a fallback for "text/org" is that your attachment will be displayed in a generic text editor. 1. Could Emacs change to register itself as a text/org handler? 2. See above for why I don't think that opening it in a generic text editor would necessarily be a bad idea. I send Org files as "text/plain" (often even using ".txt" extension to avoid confusion on the receiving side) and I think this is the best choice as it puts the least burden on the receiving side to consume the content and it is displayed inline by most email clients. This seems like a good idea, thanks for sharing it! I don't think that registering "text/org" with the IANA will have the consequences that you hope it has. Thanks for highlighting some potential pitfalls that I haden't considered. As outlined above, in light of your comments I still see this being potentially beneficial/worth the effort, but you've opened my eyes to some complications that I was previously unaware of. Thank you, Timothy.
Re: Thoughts on the standardization of Org
+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 curtails what I can do in Emacs (with org mode) would have significantly negative repercussions. I understand the desire to see org mode's capabilities implemented elsewhere but I think this misses the point: it's Emacs that people actually want implemented elsewhere without realising it. A small example: in teaching, I often use embedded Calc in my org documents (primarily for export via beamer) for inline calculations illustrating concepts. This is *part* of my use of org mode and feels like it's org mode but it's really Emacs that allows me to do this. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
Re: Bug: ox-html.el: Code blocks extend out of box border
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
Re: Thoughts on the standardization of Org
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 starters I'd like to be able to > attach org > files without the type being recognised as > "application/vnd.lotus-organizer" 濫. This is not governed by the presence of an MIME type for Org, but by the mechanism that assigns a MIME type to the file when it is attached tp a message, and this is independent of the IANA MIME type database. You (most probably) already can configure your email client (or operative system) to use "text/x-org" as the mime type for files with extension ".org". Having a IANA MIME type, would only make using "text/org" a bit more "right" (there is nothing that stops you from using the "text/org" mime type without it being registered). If you want the association to be automatic, you need to convince the maintainers of the MIME type association databases to change their defaults. And this is a rather long list of people you have to interact with and convince that "text/org" is a better choice than "application/vnd.lotus-organizer" as the default MIME type for ".org" files. Finally, even if you get your attachment automatically tagged as "text/org", the receiving side needs to have a mime type handler configured to display it. As far as I know, not even Emacs (on the platforms that allow it) registers itself as an handler for any MIME type. Therefore, what you get, assuming that the mail client on the other side behaves correctly and uses "text/*" as a fallback for "text/org" is that your attachment will be displayed in a generic text editor. > I also think it's to our benefit that non-Emacsers become more > comfortable with seeing an org file --- as I see it that improves > our > chances that we can directly share Org files with them, which they > might > be comfortable editing and sending back for example, or that a > generic > tool might think to support Org files. I send Org files as "text/plain" (often even using ".txt" extension to avoid confusion on the receiving side) and I think this is the best choice as it puts the least burden on the receiving side to consume the content and it is displayed inline by most email clients. > So I'd like to assure you that my interest in improving > recognition and > support for Org is motivated by selfish reasons which just so > happen > to potentially benefit non-Emacsers. I don't think that registering "text/org" with the IANA will have the consequences that you hope it has. Cheers, Dan
Re: Thoughts on the standardization of Org
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 >> benefit to those of us who use Org. It is also useful for gaining >> new users (assuming more users is a good thing). > > I don't mind that at all. Consider though how few of Org's abilities > you can use in that context. Headlines, basic text formatting, etc is > fine. It's easy to interpret, and well standardized by now. > > The issue with implementing additional parsers outside of Emacs is the > overhead of exciting high level features like Babel, Exports, > spreadsheet, agenda, etc. Those would be very difficult to > reimplement. For these it would suffice for me if the parsers did not break the features. For example if a table cannot be rendered as table, I want to see it as plain text. Maybe the parser could hide @@latex:@@ blocks in html presentation, but they must be shown when editing … Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Thoughts on the standardization of Org
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 is little more of a markup language with an >>> editor that allows sections folding. You can have this on top of pretty >>> much any markup language using Emacs' outline-minor-mode. >> >> It could become stronger competition for asciidoc by being available in >> more places. > > Why does Org need to compete with asciidoc? I don't see any advantage in > fighting with anyone for market share. That’s something really personal: I would prefer to use org at work :-) >> Having an acceptance criterion for “supports basic org-mode >> presentation” and “can edit org-files without breaking editing in >> org-mode” could help adoption. > > Acceptance criterion for what? Adoption of what? Acceptance criterion for „this is good enough to show an org-mode document at gitlab/sr.ht/…“. A minimum requirement so people who write a new library have something to target. Adoption: For example for editing in the browser. It would be nice to have basic editing support in gitlab — with sufficient support for users to not break org. There are many places where people cannot actually run full Emacs, because Emacs can do far too much. If you have an online editor and anyone can file a pull-request, you really won’t want to have support for running arbitrary code. But in the actual export you might want it (after checking what you’ll run). #+begin_src bash :exports results echo rm -rf / echo 0day-exploit-against-docker #+end_src > 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 > gain from that. I am missing ways to allow people to do small changes. For example to enable people to change text in my RPG in an online-editor (i.e. gitlab) and file a pull-request without ever leaving the browser. Building a full org-mode parser is a daunting task for all but those who don’t know enough to do it well. So people who start will most likely not know enough to get a basic parser right. Defining a subset as basic-org-target would give people a target they can actually aim for. And then defer to full Emacs, if they want to do more. > As explained many times now, you don't a formal specification for this: > the specification is the org-mode implementation itself. I won’t argue against that because I see it the same way :-) Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Bug: org ELPA unsigned [9.4 (9.4-19-gb1de0c-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201019/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
With the package-check-signature I cannot download org-mode from Org
ELPA. Please consider making it available for SSL users.
signal(error ("Unsigned file ‘archive-contents’ at https://orgmod...;))
error("Unsigned file `%s' at %s" "archive-contents"
"https://orgmode.org/elpa/;)
#f(compiled-function () #)()
package--with-response-buffer-1("https://orgmode.org/elpa/;
#f(compiled-function () #) :file
"archive-contents.sig" :async nil :error-function #f(compiled-function ()
#) :noerror t)
package--check-signature("https://orgmode.org/elpa/; "archive-contents" "(1
(org . [(20201102) ( ) \"Outline-ba..." nil #f(compiled-function
( good-sigs) #) #f(compiled-function ()
#))
#f(compiled-function () #)()
package--with-response-buffer-1("https://orgmode.org/elpa/;
#f(compiled-function () #) :file
"archive-contents" :async nil :error-function #f(compiled-function ()
#) :noerror nil)
package--download-one-archive(("org" . "https://orgmode.org/elpa/;)
"archive-contents" nil)
package--download-and-read-archives(nil)
package-refresh-contents()
funcall-interactively(package-refresh-contents)
call-interactively(package-refresh-contents record nil)
command-execute(package-refresh-contents record)
execute-extended-command(nil "package-refresh-contents" nil)
funcall-interactively(execute-extended-command nil "package-refresh-contents"
nil)
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
Emacs : GNU Emacs 28.0.50 (build 25, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.14.8, Xaw3d scroll bars)
of 2020-11-01
Package: Org mode version 9.4 (9.4-19-gb1de0c-elpa @
/home/data1/protected/.emacs.d/elpa/org-20201019/)
--
Thanks,
Jean Louis
⎔ λ 퍄 팡 팚
Re: Thoughts on the standardization of Org
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 gain from that. [...] As explained many times now, you don't a formal specification for this: the specification is the org-mode implementation itself. However, I will not discourage anyone from working on some form of standardization, other than pointing out that IMO it is an exercise with very limited usefulness, impact and future. I think there are absolutely some benefits for Org users. I am personally interested in registering Org as an IANA MIME type. What will this do? Well, for starters I'd like to be able to attach org files without the type being recognised as "application/vnd.lotus-organizer" 濫. test.org Description: Lotus Organizer I also think it's to our benefit that non-Emacsers become more comfortable with seeing an org file --- as I see it that improves our chances that we can directly share Org files with them, which they might be comfortable editing and sending back for example, or that a generic tool might think to support Org files. So I'd like to assure you that my interest in improving recognition and support for Org is motivated by selfish reasons which just so happen to potentially benefit non-Emacsers. I hope that clarifies my view of the proposal, Timothy
Re: Thoughts on the standardization of Org
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 with an >> editor that allows sections folding. You can have this on top of pretty >> much any markup language using Emacs' outline-minor-mode. > > It could become stronger competition for asciidoc by being available in > more places. Why does Org need to compete with asciidoc? I don't see any advantage in fighting with anyone for market share. > Having an acceptance criterion for “supports basic org-mode > presentation” and “can edit org-files without breaking editing in > org-mode” could help adoption. 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 gain from that. > That would be the only part I’d really expect from standardization: > There would be a clear-cut point when a tool could claim compatibility > with org level N or by components (i.e. basic presentation, code-blocks, > …). > > Having org-files parsed as html on a VCS-infopage is pretty nice. As explained many times now, you don't a formal specification for this: the specification is the org-mode implementation itself. However, I will not discourage anyone from working on some form of standardization, other than pointing out that IMO it is an exercise with very limited usefulness, impact and future. Cheers, Dan
Re: Bug: headline folding broken by whitespace
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 space, and even used highlight-regexp to confirm all >> spaces. >> >> It did not occur for me. > > Well, then I'm out of guesses. > > In any case, for those who can trigger the issue (using the example from > this thread as well as the examples from the related threads) on > ee3c3b554 up through 47bf6005b (as I can, with a vanilla Emacs 27.1), > e8070d71a should resolve it. I cannot trigger the problem on emacs 27.1 when it was launched with -q. However I can trigger the issue on emacs 27.1 when spacemacs is used. This is using latest org-mode package which I built from latest git files. The problem seems to be due in part to org-cycle-show-empty-lines which is one of the functions in org-cycle-hook. I say this based on two the observations that the problem goes away if either of these two things are done: 1. Remove org-cycle-show-empty-lines from org-cycle-hook. 2. Set org-cycle-separator-lines (whose default value is 2) to some large value, e.g., 5. As far as I can tell the values of org-cycle-hook and org-cycle-separator-lines are the same whether spacemacs is used or not. Yet the problem is seen only on spacemacs. So it appears that some other feature is used within spacemacs which interferes with org-cycle-show-empty-lines. I have not been able to figure this out, because there are just too many org related features enabled or customized within spacemacs.
Re: Thoughts on the standardization of Org
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 Org. It is also useful for gaining > new users (assuming more users is a good thing). I don't mind that at all. Consider though how few of Org's abilities you can use in that context. Headlines, basic text formatting, etc is fine. It's easy to interpret, and well standardized by now. The issue with implementing additional parsers outside of Emacs is the overhead of exciting high level features like Babel, Exports, spreadsheet, agenda, etc. Those would be very difficult to reimplement. Using Org as a replacement for basic Markdown on sites looks like it's already been done successfully. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
