Re: org-ctrl-c-minus includes bullet in links
yes, in recent maint. thanks for testing. On 7/9/21, Mark Barton wrote: > > >> On Jul 9, 2021, at 6:12 PM, Samuel Wales wrote: >> >> this might be a bad bug report. it seems intermittent. >> >> recent maint. >> >> create headers each with a link on it. mark all. org-ctrl-c-minus. >> >> this has incorrectly put - as part of the link descriptions. >> >> -- >> The Kafka Pandemic >> >> Please learn what misopathy is. >> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html >> > > > I realize you said it was intermittent, but is this example below what you > are describing except that it worked in my case? > > ** TODO test org-ctrl-c-minus > [2021-07-09 Fri 18:49] > *** [[x-devonthink-item://27605B38-B418-4B49-A086-DFEFBAAD5FC5][Ragged point > inn_2021-07-02]] > *** > [[x-devonthink-item://%3c8d99415d-20fc-4e2d-b41b-9cc43d97b...@gmail.com%3E][Re: > First Aid Class]] > > I then highlighted the two headings with links and used org-ctrl-c-minus to > get: > > ** TODO test org-ctrl-c-minus > [2021-07-09 Fri 18:49] > - [[x-devonthink-item://27605B38-B418-4B49-A086-DFEFBAAD5FC5][Ragged point > inn_2021-07-02]] > - > [[x-devonthink-item://%3c8d99415d-20fc-4e2d-b41b-9cc43d97b...@gmail.com%3E][Re: > First Aid Class]] > > I compiled from the master branch yesterday. > "GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.5.0, NS appkit-2022.50 > Version 11.4 (Build 20F71)) > of 2021-07-08" > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: org-ctrl-c-minus includes bullet in links
> On Jul 9, 2021, at 6:12 PM, Samuel Wales wrote: > > this might be a bad bug report. it seems intermittent. > > recent maint. > > create headers each with a link on it. mark all. org-ctrl-c-minus. > > this has incorrectly put - as part of the link descriptions. > > -- > The Kafka Pandemic > > Please learn what misopathy is. > https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html > I realize you said it was intermittent, but is this example below what you are describing except that it worked in my case? ** TODO test org-ctrl-c-minus [2021-07-09 Fri 18:49] *** [[x-devonthink-item://27605B38-B418-4B49-A086-DFEFBAAD5FC5][Ragged point inn_2021-07-02]] *** [[x-devonthink-item://%3c8d99415d-20fc-4e2d-b41b-9cc43d97b...@gmail.com%3E][Re: First Aid Class]] I then highlighted the two headings with links and used org-ctrl-c-minus to get: ** TODO test org-ctrl-c-minus [2021-07-09 Fri 18:49] - [[x-devonthink-item://27605B38-B418-4B49-A086-DFEFBAAD5FC5][Ragged point inn_2021-07-02]] - [[x-devonthink-item://%3c8d99415d-20fc-4e2d-b41b-9cc43d97b...@gmail.com%3E][Re: First Aid Class]] I compiled from the master branch yesterday. "GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.5.0, NS appkit-2022.50 Version 11.4 (Build 20F71)) of 2021-07-08"
Re: [Bug] org-startup-folded documentation
Axel Svensson writes: > org-version: 9.4.6 > > The documentation for the variable org-startup-folded is not up to date. It > states that the variable can be nil or non-nil, but the program logic makes > a difference between the values 't, 'content, 'showeverything, > 'show2levels, 'show3levels, 'show4levels, and 'show5levels. The docstring mentions fold, nofold, and other options on master and maint, albeit not stating that you can set those values with setq: > Non-nil means entering Org mode will switch to OVERVIEW. > > This can also be configured on a per-file basis by adding one of > the following lines anywhere in the buffer: > >#+STARTUP: fold (or overview, this is equivalent) >#+STARTUP: nofold(or showall, this is equivalent) >#+STARTUP: content >#+STARTUP: showlevels ( = 2..5) >#+STARTUP: showeverything > > Set org-agenda-inhibit-startup to a non-nil value if you want > to ignore this option when Org opens agenda files for the first > time. Best, Ihor
Re: [PATCH] [BUG] Bad fontification in full displayed links
Juan Manuel Macías writes: > As a possible fix I'm attaching this patch. > + (add-face-text-property start visible-start face-property) > + (add-face-text-property visible-start visible-end face-property) > + (add-face-text-property visible-end end face-property) Why not just (add-face-text-property start end face-property)? Best, Ihor
org-ctrl-c-minus includes bullet in links
this might be a bad bug report. it seems intermittent. recent maint. create headers each with a link on it. mark all. org-ctrl-c-minus. this has incorrectly put - as part of the link descriptions. -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [PATCH] Allow tangling to a list of files
On Fri, 9 Jul 2021 at 22:28, Vladimir Lomov wrote:
> Hello,
> ** Greg Minshall [2021-07-07 09:56:06 +0300]:
>
> > Vladimir,
>
> >> I couldn't find in Org manual how tangling should work if there are
> >> several source code blocks with the same file name for ':tangle'. The
> >> Org manual section "15.8 Extracting Source Code" is a bit
> >> obscure. There are these two sentences
>
> > i think what Tim answered is correct. but, i believe the "desired"
> > approach is to put all those blocks to be tangled to the same file under
> > a headline with a property drawer containing something like:
> >
> > :header-args+::tangle "submsim.jl"
> >
>
> Hmm, the more I read the manual and your answers the less I understand. As
> I
> said I didn't find in the manual any mention of feature you and Tim
> referring
> to. Besides I didn't find definition of [source] code block. If Org
> document
> has several #+BEGIN/END_SRC constructions is this the one "code block" or
> not?
> May be they are different if they use different "language" identifier?
> Again,
> I didn't find any definition or explanation in the manual. This is either
> lack
> of documentation or feature of how Org deals with source blocks. In my
> opinion, this is undocumented feature.
>
> > i believe this is for performance of tangling, but possibly the
> > "multiple source blocks to same :tangle'd file" feature may disappear?
>
> Personally, I don't find the documentation lacking in this area. I think
it is quite clear and the use of multiple source blocks and multiple
destination files is within the scope of documented features. Therefore,
I'm not in a good position to suggest what modifications to the
documentation are necessary. However, I did use literate programming before
org mode, so perhaps my understanding or expectations have been influenced
by thiat.
Perhaps if I outline my understanding and the sections from the manual
which guide my interpretation, that will help.
If we start from a high level literate programming perspective, we can
assume a file can contain multiple source blocks. This is largely the whole
idea. You have a file which has source code and 'pros' mixed together. To
distinguish them, source code is wrapped in a source block. In org, this
means a block of the form
+begin_src
...
+end_src
To provide some additional functionality, the source block definition above
can be extended with a number of useful options, including specifying the
language of the source code and the :tangle option. e.g.
+begin_src emacs-lisp :tangle yes
...
+end_src
The above block will be tangled as emacs lisp code and written to the
default output file, which is the org filename with a language appropriate
extension. e.g. if the org file is my-code.org, the tangled output file
will be my-code.el
The org manual states in the section on extracting source code
"When Org tangles code blocks, it expands, merges, and transforms
them. Then Org recomposes them into one or more separate files, as
configured through the options. During this tangling process, Org
expands variables in the source code, and resolves any noweb style
references (see *note Noweb Reference Syntax::)."
I think the above paragraph largely describes the feature of supporting
both multiple code blocks (which are expanded, merged and transformed) and
multiple destination files ("...recomposes them into one or more separate
files...").
The manual then goes on to describe the :tangle option
"The ‘tangle’ header argument specifies if the code block is exported to
source file(s)."
Note the use of 'file(s)" to indicate one or more files. The documentation
goes on to explain that the tangle argument can have the vaules "yes", "no"
or a FILENAME. If the argument is a file name
"Export the code block to source file whose file name is derived
from any string passed to the ‘tangle’ header argument. Org
derives the file name as being relative to the directory of the Org
file’s location. Example: ‘:tangle FILENAME’."
So, at this point we know
- An org file can contain multiple source blocks
- Org will expand, merge and transform source blocks as required
- By default, a tangled block will be written to a source file with the
same base name as the org file it comes from with a language appropriate
extension
- If the :tangle option specifies a filename, that filename will be used
for *that* block
I think the above covers the behaviour where you have multiple source
blocks in an org file and you use the :tangle FILENAME option to send the
tangled output to different files. The fact there is a test case for this
behaviour further confirms this is expected behaviour.
The only undocumented behaviour is the use of a function instead of a
filename to specify the destination for tangled output. I was not aware
that this functionality is uspported and have not yet tried it. If this
does indeed work, it does need to be added to the manual.
--
Tim Cross
Re: A requires/provides approach to linking source code blocks
Tim, > On Jul 8, 2021, at 12:32 PM, Tim Cross wrote: > > My concern here is with the additional complexity. This is already a > somewhat complex aspect of org mode and the behaviour you describe can > effectively be done using noweb, although as you say, not as > declarative in style. This (and the rest of what you said) is very well taken. I share your concern that adding features to an already rich feature suite will make babel very difficult to penetrate. Best, Chuck p.s. Extracting code from src blocks need not depend on `org-babel-tangle' and friends. Custom exporters have to potential to render code using attribute keys and other export features. And such exporters have the virtue of not adding complexity to the org code base.
Re: [WDYT] org-attach-sync better remove an empty attachment directory?
Colin Baxter writes: >> Tim Cross writes: > We could introduce multiple possibilities to choose from. > >>> > >>> 1. Ask in case of an empty directory if it should be deleted. > >>> 2. Don't ask. Don't touch an empty directory. (The state now.) > >>> 3. Don't ask. Delete empty directory. > >>> > >>> We could also make 3. the default setting. > >> > >> I made a mistake here. > >> > >> If we do this I vote for option 1. (not 3.) as default (following > >> the suggestion by Colin) since it is the most interactive > >> variant. If the question gets annoying the user can switch to > >> one of the other options. > >> > > > That seems quite resonable to me. > > And me. Thanks! I pushed respective code. Critique is always welcome.
Re: A requires/provides approach to linking source code blocks
Tim wrote: > This could just be me, but recently, I'm becoming very concerned > about the growth of additional features and options in org mode. Count me in. I have been mostly been hanging around in the shadows, but this is serious enough for me to wave a flag on the right side. I would go as far as saying that several suggestions have been so niche, as to be labeled feature bloats. They can be made available as user-added extensions through melpa, but should stay outside org itself. just my ¢2 Rasmus
Re: [PATCH] Change default latex compiler to latexmk
Timothy writes: > Pushed :) For future reference, should I be less wary of pushing commits > I'm confident in and haven't had any negative feedback on? Yes, sure. > p.s. updates.orgmode.org is returning a 502 error again Fixed, thanks. PS: I'm off next week but will be more available from 20-30 July. -- Bastien
Re: [PATCH] Change default latex compiler to latexmk
Bastien writes: > You can consider this an explicit approval :) Even if we do something > wrong, we can always discuss and revert it. > > Thanks! Pushed :) For future reference, should I be less wary of pushing commits I'm confident in and haven't had any negative feedback on? -- Timothy p.s. updates.orgmode.org is returning a 502 error again
Re: [wip-cite-new] Merging tomorrow?
On Friday, 9 Jul 2021 at 09:36, William Denton wrote: > Is the citation work big enough to move the version number for the > next full release to 10? I guess it doesn't break anything (i.e. fully backwards compatible) so no real need to bump the version number? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-579-gfdb98a : Latest paper written in org: https://arxiv.org/abs/2106.05096
[Bug] org-startup-folded documentation
org-version: 9.4.6 The documentation for the variable org-startup-folded is not up to date. It states that the variable can be nil or non-nil, but the program logic makes a difference between the values 't, 'content, 'showeverything, 'show2levels, 'show3levels, 'show4levels, and 'show5levels.
Re: [PATCH] Change default latex compiler to latexmk
Hi Timothy, Timothy writes: > Bastien writes: > >> I let Timothy decide. > > I consider this patch fit to merge. I'm just under the impression that > this I should only push files I'm listed as a maintainer for without > explicit approval. You can consider this an explicit approval :) Even if we do something wrong, we can always discuss and revert it. Thanks! -- Bastien
Re: [PATCH] Change default latex compiler to latexmk
Bastien writes: > I let Timothy decide. I consider this patch fit to merge. I'm just under the impression that this I should only push files I'm listed as a maintainer for without explicit approval. -- Timothy
Re: [PATCH] Change default latex compiler to latexmk
"Bruce D'Arcus" writes: > Can we merge this patch now? I let Timothy decide. -- Bastien
Re: File local setting for export directory?
"Loris Bennett" writes: > Eric Abrahamsen writes: > >> Loris Bennett writes: >> >>> Hi Eric, >>> >>> Eric Abrahamsen writes: >>> "Loris Bennett" writes: > Hi, > > I want to export an org file to a pdf and have the pdf created in > subdirectory relative to the org file. > > What's the simplest way to set the export directory in a file local way? I suggested the attached diff a while ago, but no one seemed very interested. I think it might already do what you want. diff --git a/lisp/ox.el b/lisp/ox.el index 9cf62078a..77cafb20d 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -6417,6 +6417,20 @@ Return file name as a string." "Output file: " pub-dir nil nil nil (lambda (n) (string= extension (file-name-extension n t)) extension)) + (pub-dir (or pub-dir +(and subtreep (org-entry-get + nil "EXPORT_PUB_DIR" 'selective)) +(org-with-point-at (point-min) + (catch :found +(let ((case-fold-search t)) + (while (re-search-forward + "^[ \t]*#\\+EXPORT_PUB_DIR:[ \t]+\\S-" + nil t) +(let ((element (org-element-at-point))) + (when (eq 'keyword (org-element-type element)) +(throw :found + (org-element-property +:value element)) (output-file ;; Build file name. Enforce EXTENSION over whatever user ;; may have come up with. PUB-DIR, if defined, always has >>> >>> Thanks for the patch - it is exactly what I needed. >>> >>> I'm surprised no-one was interested, although I suppose back then I was >>> probably also one of the uninterested :-) >> >> Oh I'm not blaming anyone! There are a lot of patches coming down here, >> and a lot of ideas for Org, and it's hard to keep up. I don't think I >> did a very good job of stating my case, either. >> >> I actually hadn't thought of how the latex process might go haywire with >> an absolute export file name. My motivation was simply that "next to my >> *.org" files is pretty much never where I want exported files to end up. >> I want to send them to ~/tmp, or to a directory that's shared with >> colleagues via syncthing. In fact what I really want is to export to the >> value of ATTACH_DIR, because then I can immediately use all the attach >> tools on the exported files. >> >> Latex compilation is a nice additional argument, though! > > It's a month later and, having updated Org in the meantime, I'm having > to patch again. > > What would be the way forward in terms of getting the patch into Org? I can't find any response to this question from 1st September 2020. I am still interested in having this in Org and would be willing to offer my extremely modest Elisp skills and moderately modest Git skills to help move this along, assuming it gets enough thumbs up. To recap: Eric's patch allows one to define a subdirectory into which a file generated by exporting will be written, e.g. #+EXPORT_PUB_DIR: ./export This has worked well for me for exporting to PDF Cheers, Loris -- This signature is currently under construction.
Re: [PATCH] Allow tangling to a list of files
‐‐‐ Original Message ‐‐‐ On Friday, July 9th, 2021 at 8:26 AM, Vladimir Lomov wrote: > Hello, > > ** Greg Minshall minsh...@umich.edu [2021-07-07 09:56:06 +0300]: > > > Vladimir, > > > > I couldn't find in Org manual how tangling should work if there are > > > > > > several source code blocks with the same file name for ':tangle'. The > > > > > > Org manual section "15.8 Extracting Source Code" is a bit > > > > > > obscure. There are these two sentences > > > i think what Tim answered is correct. but, i believe the "desired" > > > > approach is to put all those blocks to be tangled to the same file under > > > > a headline with a property drawer containing something like: > > -- > > > > :header-args+::tangle "submsim.jl" > > > > Hmm, the more I read the manual and your answers the less I understand. As I > > said I didn't find in the manual any mention of feature you and Tim referring > > to. Besides I didn't find definition of [source] code block. If Org document > > has several #+BEGIN/END_SRC constructions is this the one "code block" or not? > > May be they are different if they use different "language" identifier? Again, > > I didn't find any definition or explanation in the manual. This is either lack > > of documentation or feature of how Org deals with source blocks. In my > > opinion, this is undocumented feature. +1 for clarifying the docs. My point is that there is even a unit test designed to check in which order different source blocks are tangled to the same file. Hence it is a desired feature. If the documentation lacks the description of this feature, then the documentation needs to be updated. > > > i believe this is for performance of tangling, but possibly the > > > > "multiple source blocks to same :tangle'd file" feature may disappear? > > > cheers, Greg > > WBR, Vladimir Lomov > > > > How do I get HOME?
Re: A requires/provides approach to linking source code blocks
On 09/07/2021 02:32, Tim Cross wrote: Marko Schuetz-Schmuck writes: I would find it useful to have a more declarative way for specifying sequence. I imagine e.g. using "#+REQUIRES:" and "#+PROVIDES:" to capture dependency and then have the exporter compute a sequence satisfying these. I would think that this makes the maintenance of the dependencies more convenient. My concern here is with the additional complexity. This is already a somewhat complex aspect of org mode and the behaviour you describe can effectively be done using noweb, although as you say, not as declarative in style. There was a feature request for dependencies between code blocks to run them in proper order a half of a year ago. I think, it is better to try such feature as an extension of org, as a separate package. I suspect that some non-obvious issue may arise. Likely, to be convenient, it will be desired to autofill requires/provides attributes using some tools related to particular language. The question is whether org code is organized in such way, so extensions of this kind are possible without code duplication. Maybe API could be adjusted. On the other hand, even maintaining of stable semi-internal API sometimes is significant burden. P.S. I am reading the mail list through NNTP news.gmain.io. I have noticed that personal copies sometimes arrives without mail list address. Sorry if you will have to manually add it to reply.
Re: [wip-cite-new] Merging tomorrow?
Is the citation work big enough to move the version number for the next full release to 10? Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator.
Re: [PATCH] Change default latex compiler to latexmk
Can we merge this patch now? On Wed, Jun 30, 2021 at 7:14 AM Bruce D'Arcus wrote: > > Looks good, Bastien, and I think reflects the consensus of that thread. > > But trying just now, I'm not able to apply the patch on my local repo > for whatever reason, so haven't tested it. > > > > On Wed, Jun 30, 2021 at 6:48 AM Bastien wrote: > > > > Hi Bruce, > > > > "Bruce D'Arcus" writes: > > > > > What's the status of this patch? > > > > Can you quickly review it and say whether it's good? > > > > Thanks, > > > > -- > > Bastien
Re: Citations merged!
Congratulations What time is the parade? On Fri, Jul 9, 2021 at 8:03 AM Julian M. Burgos wrote: > Amazing! Thank you to everyone that contributed. I am looking forward to > start playing with this. :) > > Nicolas Goaziou writes: > > > Hello, > > > > It took years, but citations are now full part of Org syntax. > > > > Thanks to everyone involved over the time! > > > > Now, it needs to be documented, but that will come a bit later. > > > > Regards, > > > -- > Julian Mariano Burgos, PhD > Hafrannsóknastofnun, rannsókna- og ráðgjafarstofnun hafs og vatna/ > Marine and Freshwater Research Institute > Botnsjávarsviðs / Demersal Division > Fornubúðir 5, IS-220 Hafnarfjörður, Iceland > www.hafogvatn.is > Sími/Telephone : +354-5752037 > Netfang/Email: julian.bur...@hafogvatn.is > >
Re: [PATCH] Allow tangling to a list of files
Hello, ** Greg Minshall [2021-07-07 09:56:06 +0300]: > Vladimir, >> I couldn't find in Org manual how tangling should work if there are >> several source code blocks with the same file name for ':tangle'. The >> Org manual section "15.8 Extracting Source Code" is a bit >> obscure. There are these two sentences > i think what Tim answered is correct. but, i believe the "desired" > approach is to put all those blocks to be tangled to the same file under > a headline with a property drawer containing something like: > > :header-args+::tangle "submsim.jl" > Hmm, the more I read the manual and your answers the less I understand. As I said I didn't find in the manual any mention of feature you and Tim referring to. Besides I didn't find definition of [source] code block. If Org document has several #+BEGIN/END_SRC constructions is this the one "code block" or not? May be they are different if they use different "language" identifier? Again, I didn't find any definition or explanation in the manual. This is either lack of documentation or feature of how Org deals with source blocks. In my opinion, this is undocumented feature. > i believe this is for performance of tangling, but possibly the > "multiple source blocks to same :tangle'd file" feature may disappear? > cheers, Greg --- WBR, Vladimir Lomov -- How do I get HOME? signature.asc Description: PGP signature
Re: Citations merged!
Amazing! Thank you to everyone that contributed. I am looking forward to start playing with this. :) Nicolas Goaziou writes: > Hello, > > It took years, but citations are now full part of Org syntax. > > Thanks to everyone involved over the time! > > Now, it needs to be documented, but that will come a bit later. > > Regards, -- Julian Mariano Burgos, PhD Hafrannsóknastofnun, rannsókna- og ráðgjafarstofnun hafs og vatna/ Marine and Freshwater Research Institute Botnsjávarsviðs / Demersal Division Fornubúðir 5, IS-220 Hafnarfjörður, Iceland www.hafogvatn.is Sími/Telephone : +354-5752037 Netfang/Email: julian.bur...@hafogvatn.is
Re: Citations merged!
Nicolas, > It took years, but citations are now full part of Org syntax. as others are saying and thinking, thank you all very much. being an ignorant observer of this process, i was (not surprised, but, still) in amazement at all the expertise and technical work so many put in to developing and refining this feature. a wonderful example. cheers, Greg
Re: Citations merged!
Wow, congratulations! Yours, Christian Nicolas Goaziou writes: > Hello, > > It took years, but citations are now full part of Org syntax. > > Thanks to everyone involved over the time! > > Now, it needs to be documented, but that will come a bit later. > > Regards,
Re: Citations merged!
Amazing news, thank you very much Nicolas and to everybody else who contributed! András On Fri, 9 Jul 2021 at 11:47, Bruce D'Arcus wrote: > > Thanks for all your work on this Nicolas: really nice job! > > On Fri, Jul 9, 2021, 2:54 AM Nicolas Goaziou wrote: >> >> Hello, >> >> It took years, but citations are now full part of Org syntax. >> >> Thanks to everyone involved over the time! >> >> Now, it needs to be documented, but that will come a bit later. >> >> Regards, >> -- >> Nicolas Goaziou >>
Re: Citations merged!
Thanks for all your work on this Nicolas: really nice job! On Fri, Jul 9, 2021, 2:54 AM Nicolas Goaziou wrote: > Hello, > > It took years, but citations are now full part of Org syntax. > > Thanks to everyone involved over the time! > > Now, it needs to be documented, but that will come a bit later. > > Regards, > -- > Nicolas Goaziou > >
[PATCH] [BUG] Bad fontification in full displayed links
Hi, To reproduce the bug: 1. Put some link: [[target][description]] 2. Run `org-toggle-link-display' As a possible fix I'm attaching this patch. Best regards, Juan Manuel >From caf32a7e1fb1b4bddfa011520f5403d5b6b19ddd Mon Sep 17 00:00:00 2001 From: Juan Manuel Macias Date: Tue, 8 Jun 2021 01:55:02 +0200 Subject: [PATCH] org.el: prevent partial fontification when a link is displayed full * lisp/org.el (org-activate-links): apply `face-property' variable in other cases when handle invisible parts in bracket links --- lisp/org.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 1bd9e02eb..b55d8798a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5224,9 +5224,11 @@ This includes angle, plain, and bracket links." ,(or (org-link-get-parameter type :display) 'org-link)) properties))) + (add-face-text-property start visible-start face-property) (add-text-properties start visible-start hidden) -(add-face-text-property visible-start visible-end face-property) + (add-face-text-property visible-start visible-end face-property) (add-text-properties visible-start visible-end properties) + (add-face-text-property visible-end end face-property) (add-text-properties visible-end end hidden) (org-rear-nonsticky-at visible-start) (org-rear-nonsticky-at visible-end))) -- 2.31.1
org-bibtex does not recognise @Comment
I've noticed that "org-bibtex-import-from-file" will not import from bib files which begin with the standard bibtex mode-line heading of @Comment -*- mode: bibtex; -*- Bib files with any @Comment line are similarly rejected. This is rather unfortunate.
Re: Slowing down new features
Hi Tim, > This is all beginning to feel like we are running very close to the > tipping point at which time we will have something that is so complex > that only a very few people are able to maintain the code base and keep > the system stable. New maintainers are discouraged because of the code > complexity. We could end up in a position where really important issues > cannot be addressed or addressed in a timely manner because of the > overall complexity of the code base and time it takes to fix and test > and dependence on a very few number of maintainers who are already > swamped with work. > > At some point, I think we may want to consider a temporary freeze on new > functionality and spend a few months just focusing on bug fixes and code > base improvements or re-factoring. It might also be worthwhile providing > some guidelines or criteria/procedures for assessing proposed new > features to avoid a perception of new features being accepted/rejected > based on personality, loudness of voice or some other real or perceived > and irrelevant basis. I’ve got some changes that improve existing features that I know I’d like to push (and would be happy to maintain), but I get the same feeling as you that overall that we’ve been working on a lot of new things and it would be worth taking some time to refine what’s here instead of adding more. That said, I’m not sure a hard freeze would be the best way to approach this, I’d be more of a fan of just a shift in focus and maybe deferring some ideas to be considered later. FWIW, these are the new things I’d like to push: • ob-julia • inline src block fortification • smart generated export preamble • a new LaTeX src block syntax highlighting option (this actually isn’t that much code) These are all currently maturing in my config, and in particular the “smart generated export preamble” and new LaTeX syntax highlighting option have been massaged into a state I’m very happy with over a number of months. All the best, *Timothy*
Re: [wip-cite-new] Merging tomorrow?
On Friday, 9 Jul 2021 at 15:58, Timothy wrote: > This could be as simple as a way of handling links to named > images/tables/etc. when exporting. Maybe start a new thread, with a clear indication of what is missing in the current version with respect to referencing. I use internal references all the time (to figures, tables, equations) and it works great, at least for LaTeX export. Is it that other export engines don't do what is needed? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-579-gfdb98a : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [wip-cite-new] Merging tomorrow?
Hi Nicolas, In light of all the thoughts expressed on referencing, I no longer think it's a good idea to have referencing capabilities in wip-cite-new. I think referencing should get a bit of attention, as citation has here, but a much smaller separate effort now appears more appropriate to me. This could be as simple as a way of handling links to named images/tables/etc. when exporting. Update: I see wip-cite-new has been merged 🎉. Still sending this because I think my sentiment is worth sharing and I'd like to prompt a discussion on references (I'll probably give this a bit of a think then start a new thread in a few days). -- Timothy William Denton writes: > On 8 July 2021, Bruce D'Arcus wrote: > >> And the implementation challenges raised by John Kitchin and Joost >> Kremers (namely the candidate list is different) make this better to >> deal with using a different mechanism. >> >> As a package developer that supports org-cite, I really don't want to >> be worrying about internal references and such. >> >> And as a user, I don't see the benefit of doing so. >> >> Effectively, these seem more like org internal links. > > I agree with all this. Personally, I'd never expect a citation system like > this > to handle internal references. The way librarians think about citations and > referencing, these are different. > > > Bill -- Timothy
Re: Bug: Unexpected behavior marking recurring tasks as DONE
Hi Bhavin,
On 7/8/21 8:19 PM, Bhavin Gandhi wrote:
Hello Alan,
Thank you for sharing a detailed description.
[...]
I think this is same issue as reported in this bug report:
https://orgmode.org/list/87o8c8xp9b@gmail.com/
Thank you for the pointer to this -- clearly I missed it in my initial
search of the mailing list archive, but I agree it appears to be the
same issue. I'm glad to know that somebody has reproduced it.
Second, if I bulk-process a habit via org-agenda-bulk-action, the task
is simply marked DONE. Bot the recurrence and the LAST_REPEAT field
are ignored, but the time stamp is only entered into the LOGBOOK once:
** DONE Walk
CLOSED: [2021-07-07 Wed 11:26] SCHEDULED: <2021-07-07 Wed .+1d>
:PROPERTIES:
:STYLE: habit
:LAST_REPEAT: [2021-07-06 Tue 15:33]
:END:
:LOGBOOK:
- State "DONE" from "TODO" [2021-07-07 Wed 11:26]
- State "DONE" from "TODO" [2021-07-06 Tue 15:33]
:END:
I was not able to reproduce this correctly, I will try to reproduce it
again later.
I had a difficult time reproducing this one reliably. If I remember
correctly, I could only reproduce it when I set a key binding to
org-store-link. It is a binding I never use, I only set it because it
was in seemingly every org config on the planet when I first started
with orgmode, and I certainly don't explicitly invoke it when processing
in bulk.
Looking back at my last emails, I realize I have submitted a pretty
lousy bug report -- sorry for that! The init.el I used for debugging is
attached, though it relies on straight and use-package for reasons of
time and convenience. The org settings as-written have reproduced both
behaviors reliably for me so far, and removing the "!" from
org-todo-keywords has fixed them both. I am a bit pressed for time at
the moment, but later today or over the weekend I will put together a
more vanilla init.el that hopefully reproduces both problems (or reveals
a package conflict...). I have also attached my test file, though it is
not substantively different from the one you used yourself in the
previous thread.
Best regards,
Alan
;;; -*- lexical-binding: t -*-
(defvar bootstrap-version)
(let ((bootstrap-file
(expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
(bootstrap-version 5))
(unless (file-exists-p bootstrap-file)
(with-current-buffer
(url-retrieve-synchronously
"https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el";
'silent 'inhibit-cookies)
(goto-char (point-max))
(eval-print-last-sexp)))
(load bootstrap-file nil 'nomessage))
(straight-use-package 'use-package)
(setq straight-use-package-by-default t)
(eval-when-compile
(require 'use-package))
(require 'bind-key)
(setq use-package-always-defer t)
(setq use-package-verbose nil)
(use-package org
:defer nil
:bind (("C-c l" . org-store-link)
("C-c a" . org-agenda))
:mode ("\\.\\(org\\|org_archive\\)$" . org-mode)
:init
(setq org-directory "~/org-dev"
org-agenda-files (list org-directory))
:custom
(org-log-done 'time)
(org-log-redeadline 'time)
(org-log-reschedule 'time)
(org-log-into-drawer t)
(org-log-state-notes-insert-after-drawers nil)
(org-todo-keywords
'((sequence "TODO(t)" "|" "DONE(x!)"
test.org
Description: Lotus Organizer
Re: A requires/provides approach to linking source code blocks
Marko Schuetz-Schmuck writes: > I would find it useful to have a more declarative way for specifying > sequence. I imagine e.g. using "#+REQUIRES:" and "#+PROVIDES:" to > capture dependency and then have the exporter compute a sequence > satisfying these. I would say that declaring an explicit ordering of blocks via noweb is quite declarative. The tensions seems more to be between implicit and explicit ordering. I'm quite a fan of letting the computer compute things, but in the context of literate programming I tend to prefer explicit over implicit. IMHO that's the main point of literate programming: Be more explicit and document all the details. Try not to hide important aspects. If you have so many blocks that maintaining the order of the concatenation seems like a burden and tiresome I would argue that you are doing it wrong. Because in the end you need quite a good understanding of the final order of the blocks or else maintaining the implicit order via require/provide will also get out of hand. I also second Tims concerns about the additional complexity and feature creep. -- Until the next mail..., Stefan.
Re: Citations merged!
Nicolas Goaziou writes: > Hello, > > It took years, but citations are now full part of Org syntax. > > Thanks to everyone involved over the time! > > Now, it needs to be documented, but that will come a bit later. > Well done Nicolas and all those who assisted. Definitely a non-trivial addition and one which I think many will find very useful. -- Tim Cross
