Re: bug#59882: Multiple versions of Org in load-path problem
Hi Tim, org-mode and emacs developers, * Tim Cross [2023-02-04; 07:01 +11]: > Ihor Radchenko writes: >> Max Nikulin writes: >>> On 27/12/2022 16:47, Ihor Radchenko wrote: Can you then try to test using Emacs 28? The main question if whether this has been fixed in newer Emacs releases or it is also something to do with OS environment. >>> I see quite the same issue with Emacs-28.2 in Debian testing. Compile >>> buffer displays a bit more warnings and usual `org-assert-version' >>> warnings and errors are present as well. It might have another level of >>> complexity due to .eln files. I am unsure what happens with calls to >>> undefined macros. >> >> I asked people around to test using Debian, and we do have a >> confirmation that Debian + Emacs 27 and Debian + Emacs 28 do trigger the >> error. >> >> I also installed Debian 11.6.0 on virtual machine, and I was also able to >> trigger the error, following the provided steps, using the Emacs 27 >> installed via apt-get. >> >> The problem seems to be real and appears to be some combination of >> Debian/Ubuntu + Emacs. >> >> Considering the popularity of Debian-based distros, may someone take a >> closer look on what may be going on? Since the latest Emacs release also >> suffers from the problem, I am afraid that the issue will be present in >> the coming Emacs 29 as well (I recall no related fixes in recent Emacs). > > I don't run Debian or Ubuntu anymore. However, I do recall that debian > does use a modified Emacs startup which is not part of the standard > Emacs distribution. They do this to enable the ability to have multiple > versions of Emacs installed at the same time. that would be /usr/share/emacs/site-lisp/debian-startup.el Ciao; Gregor -- -... --- .-. . -.. ..--.. ...-.-
Re: [BUG] Incorrect display of folded headings after cycling with subheading with VISIBILITY content/children
On 14 February 2023, Bruno Barbier wrote: Daniel Hubmann writes: After using org-cycle-overview (or org-cycle-content) and then using org-cycle-set-visibility-according-to-property I get this: * Heading Lvl 1...** Heading Lvl 2 with VISIBILITY content... *** Heading Lvl 3... I'm observing the same behavior. Similar things have been happening to me since the middle of last year. See: https://lists.gnu.org/archive/html/emacs-orgmode/2022-07/msg00368.html https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00811.html (my screenshots are gone by they looked like what's been described) Ihor did some work but the problem is still going on now and then, in the sort of way that seems unreproducible to me. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.18 ppm (Mauna Loa Observatory, 2023-02-13)
How to export org-agenda to ICS to show in iCal
Hi,
For months I have been wanting to be able to export my scheduled tasks to
ICS to be able to see it it iCal, which is very visually pleasing and
easier for me to grasp my agenda. Plus, I can see it in the context of my
work tasks, which i don't have in orgmode.
I tried this:
(add-to-list 'org-agenda-custom-commands
'("o" "Agenda to ICS"
;((agenda "" nil)
((alltodo ""
nil
("/Users/agilev/Dropbox/emacs.ics")
...unsuccessfully.
It shows the list in Emacs, but there is no ICS exported. I wonder what i
am doing wrong.
Maybe somebody knows a way to do it differently not using the agenda? Maybe
a function that I can cron to export my scheduled tasks or a hook for every
time i changed my agenda files?
Thanks so much in advance1
A.G.
Re: [BUG] Incorrect display of folded headings after cycling with subheading with VISIBILITY content/children
Daniel Hubmann writes: > ... > After using org-cycle-overview (or org-cycle-content) and then using > org-cycle-set-visibility-according-to-property I get this: > > * Heading Lvl 1...** Heading Lvl 2 with VISIBILITY content... > *** Heading Lvl 3... > I'm observing the same behavior. Org mode version 9.6.1 Bruno
Re: [PATCH] remove unused code in ob-octave.el
On Fri, Feb 10 2023, Max Nikulin wrote: > On 10/02/2023 04:21, Leo Butler wrote: >> In lisp/ob-octave.el: >> What is the point of ob-octave-prep-session:octave or its brother, >> ob-octave-prep-session:matlab? >> These two functions are unused in the existing code. > > Have you checked the following? I am not familiar with org-babel code. > > grep -nH org-babel-prep-session lisp/ob-core.el > lisp/ob-core.el:1041: (prep-cmd (intern (concat > "org-babel-prep-session:" lang > lisp/ob-core.el:1050: (error "No org-babel-prep-session function for > %s!" lang)) > > Do test passes when you patch is applied? It might mean that test > coverage is not perfect. Yes, the tests pass after removing the code. I can see from your and Ihor's response that my suggestion is wrongheaded. After looking more carefully at ob-core, I am not sure how I could write a test for the prep-session code, though. The comment and docstring in ob-template.el does not help me, I am afraid. And the existing session-related tests do not touch the prep-session code. I'll poke around in other ob-*.el code and see if I can figure it out. Leo
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
On 14/02/2023 22:59, Jean Louis wrote: What Ihor proposed is time stamp like: 2023-02-14 Tue 12:00:00 +0800 @UTC I am not sure that combination of +0800 and UTC was intentional. The following is redundant, but there is nothing wrong while offset and time zone identifier are in agreement: 2023-02-14 Tue 12:00:00 +0800 @Asia/Singapore
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
Jean Louis writes: * Max Nikulin [2023-02-14 14:45]: On 14/02/2023 16:45, to...@tuxteam.de wrote: > On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler > wrote: > > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: > > > Then just representation must be clear: @UTC is unclear > > > in those > > > cases, but @RELTOUTC would be clear. > > > > @RELTOUTC seems unfortunate, as it states only the obvious. > > If at all, > > it should be @AHEADUTC or @BEHINDUTC or some abbreviation > > of it, but as > > said above, it seems not necessary to me. > > That's what the "+" and "-" do, anyway. TZ=Etc/GMT-8 date '+%F %a %T %z %Z' 2023-02-14 Tue 19:37:01 +0800 +08 TZ=Etc/GMT+8 date '+%F %a %T %z %Z' 2023-02-14 Tue 03:38:24 -0800 -08 Notice sign in time zone identifier is opposite to time offset. However I am against RELTOUTC/AHEADUTC/BEHINDUTC. From my point of view +0800/-0800 is clear enough. P.S. Last +08/-08 are really time zone abbreviations, not offset, however unlike "BST" & Co. they are acceptable to specify offset unambiguously. That is different use case Max. For this use case I am in full agreement, that is what is used anyway worldwide. What Ihor proposed is time stamp like: 2023-02-14 Tue 12:00:00 +0800 @UTC Though I just say when we put "UTC" that means normally "UTC time zone" and such has no prefix that is positive or negative, can be zero. Sigh. UTC is not a time zone. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* Max Nikulin [2023-02-14 14:45]: > On 14/02/2023 16:45, to...@tuxteam.de wrote: > > On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote: > > > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: > > > > Then just representation must be clear: @UTC is unclear in those > > > > cases, but @RELTOUTC would be clear. > > > > > > @RELTOUTC seems unfortunate, as it states only the obvious. If at all, > > > it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as > > > said above, it seems not necessary to me. > > > > That's what the "+" and "-" do, anyway. > > TZ=Etc/GMT-8 date '+%F %a %T %z %Z' > 2023-02-14 Tue 19:37:01 +0800 +08 > > TZ=Etc/GMT+8 date '+%F %a %T %z %Z' > 2023-02-14 Tue 03:38:24 -0800 -08 > > Notice sign in time zone identifier is opposite to time offset. However I am > against RELTOUTC/AHEADUTC/BEHINDUTC. From my point of view +0800/-0800 is > clear enough. > > P.S. Last +08/-08 are really time zone abbreviations, not offset, however > unlike "BST" & Co. they are acceptable to specify offset > unambiguously. That is different use case Max. For this use case I am in full agreement, that is what is used anyway worldwide. What Ihor proposed is time stamp like: 2023-02-14 Tue 12:00:00 +0800 @UTC Though I just say when we put "UTC" that means normally "UTC time zone" and such has no prefix that is positive or negative, can be zero. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [TIP] Exporting Maxima results to LaTeX
On Sat, Feb 11 2023, Max Nikulin wrote:
> On 09/02/2023 03:40, Leo Butler wrote:
>> On Wed, Feb 08 2023, Max Nikulin wrote:
>>> I am curious if it is possible to avoid duplication by e.g. using noweb.
>>
>> ... I am not aware of how to
>> remove that duplication--all the examples I have found in the worg
>> source do what I have done above.
>
> I have tried
Recursive evaluation of code blocks! Of course! THANK YOU!
>
> For debugging of the inner src block it is necessary to swap escaping
> with the outer #+begin_src.
Yes, it should be possible to recursive edit in indirect buffers. I
don't see how to do that.
> I have not figured out how to add some text in between of the exported
> source code example and its result.
See the attached. You need to name a code block and manually insert the
#+RESULT: stanza where you want the result put.
Thanks to Max and Eric for their comments. I have incorporated the
comments in the attached.
Leo
#+TITLE: Tip for exporting Maxima results to LaTeX
#+AUTHOR: Leo Butler
#+OPTIONS: H:3 toc:t num:t tags:nil todo:nil
#+LATEX_CLASS: article
#+LATEX_HEADER: \usepackage{color} \usepackage[margin=2cm]{geometry}
#+LATEX_COMPILER: lualatex
#+PROPERTY: header-args:maxima :eval export :exports results :results raw drawer
* Goal
Generate LaTeX code from Maxima code.
* Setup
** maxima-init.lisp
The command =org-babel-execute:maxima= in =lisp/ob-maxima.el= uses the Maxima command ~batchload~ to execute Maxima code. This is a very tight-lipped loader, so we over-write ~batchload~ with ~batch~. We also ~load~ an init file:
#+name: maxima-init.lisp.org
#+begin_src org :exports code :results replace
,#+name: maxima-init.lisp
,#+begin_src maxima :tangle maxima-init.lisp :exports none
(defun $batchload (file) (mfuncall '$batch file))
($load "./maxima-init.mac")
,#+end_src
#+end_src
On tangling, this produces the ~common-lisp~ output file ~maxima-init.lisp~. It will be pre-loaded into Maxima.
#+RESULTS: maxima-init.lisp.org
#+name: maxima-init.lisp
#+begin_src maxima :tangle maxima-init.lisp :exports none
(defun $batchload (file) (mfuncall '$batch file))
($load "./maxima-init.mac")
#+end_src
** maxima-init.mac
Next, we need to create an init file for Maxima that will provide an output printer that produces @@latex:\LaTeX{}@@ output. One option would be to use the ~imaxima~ printer. Here is another option that uses the ~alt-display~ package.
The code replaces the default printer with ~org_tex_display~. It also sets the ~epilog~ prompt, so that the final ~#+begin_example~ is terminated.
#+name: maxima-init.mac.org
#+begin_src org :exports code :results replace
,#+name: maxima-init.mac
,#+begin_src maxima :tangle maxima-init.mac :exports none :eval none
load("alt-display.mac") $
set_prompt('epilog,printf(false,"~%#+end_example")) $
define_alt_display(org_tex_display(x),
block([],
printf(true,"#+end_example~%#+begin_export latex~%"),
printf(true,"\\textcolor{blue}{(\\~a~d)} ",outchar,linenum-1),
tex(second(x)),
printf(true,"~&#+end_export~%#+begin_example~%(input) "))) $
set_alt_display(2,org_tex_display) $
display2d:true $
printf(true,"#+begin_example~%(input) ") $
linenum : 0 $
,#+end_src
#+end_src
#+RESULTS: maxima-init.mac.org
#+name: maxima-init.mac
#+begin_src maxima :tangle maxima-init.mac :exports none :eval none
load("alt-display.mac") $
set_prompt('epilog,printf(false,"~%#+end_example")) $
define_alt_display(org_tex_display(x),
block([],
printf(true,"#+end_example~%#+begin_export latex~%"),
printf(true,"\\textcolor{blue}{(\\~a~d)} ",outchar,linenum-1),
tex(second(x)),
printf(true,"~&#+end_export~%#+begin_example~%(input) "))) $
set_alt_display(2,org_tex_display) $
display2d:true $
printf(true,"#+begin_example~%(input) ") $
linenum : 0 $
#+end_src
* An example
Here is an example that computes the partial derivatives of a composite function.
** Org code
#+name: chain-rule.org
#+begin_src org :exports both :results replace
,#+name: chain-rule
,#+begin_src maxima :exports both :cmdline -p ./maxima-init.lisp
(gradef(f(u,v),f_1(u,v),f_2(u,v)), 'done);
diff(f(x^2-y^2,x*y),x);
diff(f(x^2-y^2,x*y),y);
,#+end_src
#+end_src
** Maxima code
#+RESULTS: chain-rule.org
The first line defines the partial derivatives of \(f(u,v)\) with repect to \(u\) and \(v\). The second and third lines compute the partial derivatives of the composite \(f(x²-y²,xy)\).
** Result of evaluation; LaTeX output
The ~batch~ printer echos each input line; it prints the output of
each command line that ends in a semi-colon (=;=). The result of a
line ending in a dollar sign (=$=) is not printed. The
~org_tex_display~ printer wraps each echoed input line in an ~example~
block and prints the output as it would appear in an =imaxima=
session.
#+RESULTS: chain-rule
** Two annoyances
The initial line =read and interpret...= and that final, dangling
input line with ~gnuplot_close()~ are nuisances. They can be easily
suppres
Re: [PATCH] Allow customizing commands affected by `org-fold-catch-invisible-edits' (was: Should we extend org-catch-invisible-edits to more interactive commands? (was: Catching invisible edits: probl
Ihor Radchenko writes on Sun 12 Feb 2023 15:23: > [...] I want to implement more generic feature. > See the attached patch. This sounds very promising. I find the doc and the two relevant docstrings clear. However, I could not have it work for my case so far. I tried to add "(undo . insert)", "(undo . delete-backward)" and "(undo . delete)" to 'org-fold-catch-invisible-edits-commands', one by one and together, and all values of 'org-fold-catch-invisible-edits'. Any clue of what I am doing wrong? Thanks. -- EOST (École et Observatoire des Sciences de la Terre) ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr 5 rue René Descartes [bureau 110] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France | [ slot available for rent ]
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote: > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: [...] > > Then just representation must be clear: @UTC is unclear in those > > cases, but @RELTOUTC would be clear. > > > > @RELTOUTC seems unfortunate, as it states only the obvious. If at all, > it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as > said above, it seems not necessary to me. That's what the "+" and "-" do, anyway. Cheers -- t signature.asc Description: PGP signature
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* Heinz Tuechler [2023-02-14 12:44]: > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: > > * to...@tuxteam.de [2023-02-12 16:50]: > > > On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: > > > > * Ihor Radchenko [2023-02-10 13:48]: > > > > > Jean Louis writes: > > > > > > > > > > > If you start adding in Org "fixed" time with UTC offset, that is a > > > > > > new > > > > > > type of timestamp, as it is not common in world. > > > > > > > > > > It is how ISO8601 defines offsets. > > > > > > > > - did you say you wish to represent time with UTC time zone by using > > > > UTC offset? > > > > > > > > - and I said, UTC time is always without offset, and if any is > > > > represented then it must be +00 > > > > > > > > - and now you say that ISO8601 defines offsets... sorry, you are > > > > confusing me and readers. > > > > > > It is not about "the offset OF UTC". It is about "the offset > > > RELATIVE TO UTC". > > > > Yes, surely is clear to me personally. > > If 2022-11-12 12:00+02 # 12:00 UTC+2 should mean that local time is > 2022-11-12 12:00 and that it is 2 hours _ahead_ of UTC, then it seems > intuitively clear to me. I would assume that holds for many others > as well. Exactly that. Never said anything different. Discussion started from something like this: 2022-11-12 12:00+02 @UTC and that is different case, where Ihor was suggesting that: 2022-11-12 12:00 is UTC time, not local time, where by +02 is offset (I say not UTC offset) to be added or deducted on that time. > > That we got for sure. > > > > Then just representation must be clear: @UTC is unclear in those > > cases, but @RELTOUTC would be clear. > > > > @RELTOUTC seems unfortunate, as it states only the obvious. If at all, > it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as > said above, it seems not necessary to me. As idea I understand Ihor and other person on Internet. But as implementation by using @UTC or by using date time representation as UTC time with offset (not UTC offset), I think it will be confusing for people, unless there is new tag invented to make sure of it. Any idea is fine: 2022-11-12 12:00+02 @UTC-SUM 2022-11-12 12:00+02 @UTC-TO 2022-11-12 12:00+02 @TO-UTC but not 2022-11-12 12:00+02 @UTC As that would be confusing. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
On 14/02/2023 16:45, to...@tuxteam.de wrote: On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote: Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: Then just representation must be clear: @UTC is unclear in those cases, but @RELTOUTC would be clear. @RELTOUTC seems unfortunate, as it states only the obvious. If at all, it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as said above, it seems not necessary to me. That's what the "+" and "-" do, anyway. TZ=Etc/GMT-8 date '+%F %a %T %z %Z' 2023-02-14 Tue 19:37:01 +0800 +08 TZ=Etc/GMT+8 date '+%F %a %T %z %Z' 2023-02-14 Tue 03:38:24 -0800 -08 Notice sign in time zone identifier is opposite to time offset. However I am against RELTOUTC/AHEADUTC/BEHINDUTC. From my point of view +0800/-0800 is clear enough. P.S. Last +08/-08 are really time zone abbreviations, not offset, however unlike "BST" & Co. they are acceptable to specify offset unambiguously.
Re: [FR] Side-by-side images during export (was: [BUG] Org-mode Side-by-Side Images [9.5.3 (release_9.5.3-3-gd54104)])
* Ihor Radchenko [2023-02-13 17:50]:
> Gustaf Waldemarson writes:
>
> > Does something like that already exist in org-mode? Alternatively,
> > what is the recommended and most portable approach to placing images
> > side-by-side?
>
> No, AFAIK.
Org is already a text structure that has elementary objects defined,
as you said, not everything is granular, but there is no limit what
users can define in Org.
Elementary Objects:
https://www.dougengelbart.org/content/view/110/460/#2a1a
So anything can be elementary object, no matter in what kind of a
system.
By having that in mind, I think other objects could be used to get
what user wants.
In Asciidoctor I can make table with invisible lines, and position
pictures inside of cells, or place some text on sides. There exists
Asciidoc export for Org. What you read is now my thoughts about it,
development towards possible solution:
| My left | My right |
|-+--|
| left| right|
Giving this with Asciidoc Org export:
[width="80%",options="header"]
|
| My left| My right
| left| right
|
Then this here:
| [[./img/a.jpg]] | [[./img/b.jpg]] |
Get correctly exported as:
[width="80%"]
|
| image:./img/a.jpg[]| image:./img/b.jpg[]
|
in Asciidoctor.
One can use that as fundamental point. Instead of using Asciidoctor
export, one could use source blocks to generate LaTeX export by using
Asciidoctor markup.
Here is only the idea:
#+BEGIN_SRC asciidoctor-to-latex
[width="80%"]
|
| image:./img/a.jpg[]| image:./img/b.jpg[]
|
#+END_SRC
Then based on following function, one can conevert that above:
(defun rcd-asciidoc-snippet-no-header-footer-to-latex (text)
"Return LaTeX for Asciidoc snippet TEXT without header and footer."
(let* ((text (rcd-asciidoctor text "-s" "-b" "docbook5"))
(text (rcd-pandoc-convert-string text "docbook" "latex")))
text))
(rcd-asciidoc-snippet-no-header-footer-to-latex "
[width=\"80%\"]
|
| image:./img/a.jpg[]| image:./img/b.jpg[]
|
") ➜ "\\begin{longtable}[]{@{}
>{\\raggedright\\arraybackslash}p{(\\columnwidth - 2\\tabcolsep) *
\\real{0.4000}}
>{\\raggedright\\arraybackslash}p{(\\columnwidth - 2\\tabcolsep) *
\\real{0.4000}}@{}}
\\toprule\\noalign{}
\\endhead
\\bottomrule\\noalign{}
\\endlastfoot
\\includegraphics{./img/a.jpg} & \\includegraphics{./img/b.jpg}
\\end{longtable}
"
and by using the above think process, it is possible to make
following, by using the Org snippet:
#+BEGIN_SRC org-to-asciidoc-to-latex
| [[./img/a.jpg]] | [[./img/b.jpg]] |
#+END_SRC
then such Org snippet can be converted to Asciidoc, then to docbook5,
then to LaTeX or to HTML.
Solution is right there by using pandoc, asciidoctor and "elementary
objects" as Org Babel source blocks.
And this may not be the only solution.
> There are two problems:
> 1. We currently lack object-granular control over export attributes.
>Attributes for images are set for the whole paragraph and Org uses a
>paragraph starting with image as a special case, assigning paragraph
>to the image.
By using above method, that is solved for each individual user how
they wish and want. It does not need much adaptation IMHO.
> 2. There is no easy universal way to create side-by-side images for all
>possible backends.
As if you do not control those backends, there is also no need for that.
However, by using the above method, it is possible to solve it for all
backends straight from Org, by only adding conversion function.
> The best thing we might provide is merging multiple images into one
> using, for example, a LaTeX minipage export to create merged image
> to be included into the exported document.
Merging multiple images sounds to me as hard coding.
Providing small conversion functions for various exports like HTML,
Org would just make it work.
I did not provide final example in this e-mail, but now you could, I
gave you the thought process and functionality.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
[BUG] Incorrect display of folded headings after cycling with subheading with VISIBILITY content/children
Org mode version 9.6 (9.6-g30314c @
/home/hubisan/.emacs.default/straight/build/org/)
GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33,
cairo version 1.16.0) of 2023-01-03
Have the following org file contents (using emacs -q):
* Heading Lvl 1
** Heading Lvl 2 with VISIBILITY content
:PROPERTIES:
:VISIBILITY: content
:END:
*** Heading Lvl 3
** Another Heading Lvl 2
After using org-cycle-overview (or org-cycle-content) and then using
org-cycle-set-visibility-according-to-property I get this:
* Heading Lvl 1...** Heading Lvl 2 with VISIBILITY content...
*** Heading Lvl 3...
If I use :VISIBILITY: children I get this ("Another Heading Lvl 2" is
hidden):
* Heading Lvl 1
** Heading Lvl 2 with VISIBILITY content
:PROPERTIES:
:VISIBILITY: content
:END:
*** Heading Lvl 3...
Tried to debug it, but didn't find the cause. Happens after exiting
save-restriction.
Best wishes
Daniel
Re: Link type in org-mode, but with org-roam ?
* Cletip Cletip [2023-02-13 19:08]: > I'm going to get straight to the point and try to be as concise as > possible, just for context: I've been using org-mode every day for at least > 2 years. I want to make it my personal knowledge/information manager. I > understand code relatively quickly, I understand less when it comes to > writing it. I've done a lot of research on note-taking methods... well, you > can see my profile I think. Where is the profile? I like note-taking researcher profiles. 🤓 > So, my goal: to make a concise system with org-mode, org-roam, org-attach, > org-agenda etc... a "classic" goal for some of us :). Good that I have given up on that puzzle of making Org database, rather using PostgreSQL database straight, and deriving Org out of it. > The problem: need to make "queryable" notes to do more or less complex > operations. For example, run the code of all headings/notes that have the > tag "ubuntu", to allow me to reinstall my computer for example. This > problem is trivial to solve with tags (a simple "dolist" is enough), but > tags will not always be enough... So you need to be able to store > "value-key" data, in order to make "select me all the people with a phone > number starting with 06" queries. This works perfectly well with this: > https://github.com/d12frosted/vulpea#metadata. I have seen that link, and I understand the attempt. > This gives things of the following conceptual form: > note1(where the metadata is stored) -> relationship -> > note2/OrValue. Okay, it is good concept. > What is stored in the database must be only the IDs (not the titles > of the note for example), but the description is there for the > user. This allows not to have a controlled vocabulary: when > searching, we look for a note id, and not a string. On the other > hand, what is displayed to the user in the notes is the description, > which is very practical. Yes. Very handy. > note1 is therefore the id of a note (in the org-roam sense). Why not call it "Note ID" then? > Relation is the id of the "metadata"/type of the desired relation. Yes, sure understandable. > And note2/Value is the value of the relationship, which may be an id of > another note or just a value. Yes, sure understandable, though complicated without reason. > In practice, it is therefore in this form: > - [[id:20230112135328669948][Name you want, but respect the idea of the > concept behind the id]] :: [[id:20220617105453042719][Another note]] > - [[id:20230112135328669948][a metadata only with a value]] :: just > a value Who knows what it means... I like to understand your thoughts. > The concept is close to the "In-Buffer Settings", with a "#+": it's > a key-value. Except that In-Buffer Settings, org-mode can't > understand that there is a link or something else, org-mode > understands just a string, which will be parsed to modify org-mode's > behaviour on that file, or for a export, etc. Something similar but not same is here. This is generated Org snippet: * http://dantorop.info/project/emacs-animation/lisp1.html [0/0] [0%] :Emacs:WWW-bookmark: :PROPERTIES: :UUID: 38484E86-CBCB-46B8-907F-CEBA90DA9F4D :END: WWW: [[http://dantorop.info/project/emacs-animation/lisp1.html]] There are many properties on the above snippet, which one cannot see directly. They are held in the database. It all goes in momentum. The UUID is the hyperlink, I press M-TAB on it and get straight to object, to edit properties of all kinds, and what you see below is not all, there are tags, timestamps, related people, related other objects, etc. Anything is possible ID 31724 Date created "2020-11-10 02:29:52.72204+03" Date modified "2023-02-14 11:29:47.202234+03" User created "maddox" User modified "maddox" Time zone "1" Start Date and Time nil End Date and Time nil Markup Type "Default (Text)" Elementary object type "WWW" Elementary object subtype "Default" Name "http://dantorop.info/project/emacs-animation/lisp1.html"; Hyperlink "http://dantorop.info/project/emacs-animation/lisp1.html"; Arguments nil Description nil Text nil Internal information "" Parent ID "GNU Emacs" Author nil Permission "Default" Revision nil Number of pages nil Language nil File size nil Time length nil Width nil Height nil Hash nil GPG Signature nil Pages nil Related people
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: * to...@tuxteam.de [2023-02-12 16:50]: On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: * Ihor Radchenko [2023-02-10 13:48]: Jean Louis writes: If you start adding in Org "fixed" time with UTC offset, that is a new type of timestamp, as it is not common in world. It is how ISO8601 defines offsets. - did you say you wish to represent time with UTC time zone by using UTC offset? - and I said, UTC time is always without offset, and if any is represented then it must be +00 - and now you say that ISO8601 defines offsets... sorry, you are confusing me and readers. It is not about "the offset OF UTC". It is about "the offset RELATIVE TO UTC". Yes, surely is clear to me personally. If 2022-11-12 12:00+02 # 12:00 UTC+2 should mean that local time is 2022-11-12 12:00 and that it is 2 hours _ahead_ of UTC, then it seems intuitively clear to me. I would assume that holds for many others as well. That we got for sure. Then just representation must be clear: @UTC is unclear in those cases, but @RELTOUTC would be clear. @RELTOUTC seems unfortunate, as it states only the obvious. If at all, it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as said above, it seems not necessary to me. Heinz
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* to...@tuxteam.de [2023-02-12 16:50]: > On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: > > * Ihor Radchenko [2023-02-10 13:48]: > > > Jean Louis writes: > > > > > > > If you start adding in Org "fixed" time with UTC offset, that is a new > > > > type of timestamp, as it is not common in world. > > > > > > It is how ISO8601 defines offsets. > > > > - did you say you wish to represent time with UTC time zone by using > > UTC offset? > > > > - and I said, UTC time is always without offset, and if any is > > represented then it must be +00 > > > > - and now you say that ISO8601 defines offsets... sorry, you are > > confusing me and readers. > > It is not about "the offset OF UTC". It is about "the offset > RELATIVE TO UTC". Yes, surely is clear to me personally. That we got for sure. Then just representation must be clear: @UTC is unclear in those cases, but @RELTOUTC would be clear. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
