Shutting down Org ELPA: No new release of Org on Org ELPA after Org 9.5
Hi all, over the years, Org ELPA at https://orgmode.org/elpa/ has been useful to make it possible to install Org and Org+Contrib as ELPA packages, but maintaining a separate ELPA space just for Org is not necessary. Org 9.5 will be the last release to be distributed on Org ELPA. After 9.5, we won't use Org ELPA for new releases. Past releases will still be available, though maybe not indefinitely. The Org package will continue to be available through GNU ELPA (from https://elpa.gnu.org/packages/) and a new Org-Contrib package will be available from https://elpa.nongnu.org/nongnu/. Only stable releases will be distributed through both GNU and NonGNU ELPA repositories. For those who want to test the unstable version of Org, please install Org from Git: ~$ git clone https://code.orgmode.org/bzg/org-mode.git See https://orgmode.org/manual/Installation.html#Installation If you used Org ELPA and are affected by this change, please tell us if this change affects you. Thanks! -- Bastien
Starting from 9.5, Org contrib will be distributed as a separate NonGNU ELPA package
Hi all, starting from Org 9.5, org-contrib will be distributed as a NonGNU ELPA package. You will find it here: https://elpa.nongnu.org/nongnu/ See for https://orgmode.org/list/87wnzfy60h@bzg.fr/ for context. Thanks, -- Bastien
Re: Starting from 9.5, Org contrib will be distributed as a separate Org ELPA package
Hi all, Bastien writes: > Org 9.5 will ship without the packages in the contrib/ directory. Just FWIW, this is still the plan. > Emacs lisp files in contrib/ will be packaged as an Org ELPA package > that you can install independentely from there. The files will live > in a new org-contrib.git repo on code.orgmode.org. There is a change here - instead of being published as an Org ELPA package, org-contrib will be published as a NonGNU ELPA package. You will find it here: https://elpa.nongnu.org/nongnu/ > In the long run, every Emacs file in org-contrib.git need to find a > proper maintainer (who will decide where to maintain it) or to be > listed in the list of Emacs orphan packages. This is still the case: volunteers are welcome. Thanks, -- Bastien
Re: [PATCH] Apply emacs manual css to org pages
Hi, Kyle Meyer writes: >> # How to create the HTML file >> -TEXI2HTML = makeinfo --html --number-sections >> +TEXI2HTML = makeinfo --html --number-sections --css-ref >> "https://www.gnu.org/software/emacs/manual.css; I made this change and tested it online, the HTML Org manual now looks like the Emacs manual: https://orgmode.org/manual/ Thanks for the suggestion! > Hmm, while I barely ever look at the online manual, I thought I recalled > it having custom styling, and indeed it looks like that was the case: > > https://web.archive.org/web/20171222052224/https://orgmode.org/org.html > > At least based on the Wayback Machine rendering, it seems like the > custom CSS was lost shortly after the snapshot above. > > If you look in the repo for org-manual.css, you can see there is still > handling for it. Yes, I remember I tried to enhance the css for the manual, and I don't remember why this change was reverted. > So, if we're going to go in the direction of this patch, there should be > some mention of the previous approach, why it was dropped, and the > handling for org-manual.css should probably be removed. Perhaps Bastien > can help fill in some details here. In any cas, the Emacs manual css is better than my attempt and using it for Org makes sense IMO. Best, -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Hi Andy and Kyle, Kyle Meyer writes: > Andy Klock writes: > >> Hi all, am I too late? >> >> ‐‐‐ Original Message ‐‐‐ >> On Monday, October 26, 2020 4:07 AM, Bastien wrote: >> >>> If you feel like proposing yourself for maintaining an Org Babel >>> language, that would be super helpful. >> >> Can I throw my hat in to help maintain ob-sql.el ? > > While I of course can't speak for Bastien (and am not sure what this > thread involved behind the scenes here), it doesn't appear that anyone > volunteered for ob-sql. And regardless any help would be greatly > appreciated. FWIW I do confirm that any help is welcome! Nobody is ever "too late" in volunteering for maintaining an ob-* file. Thanks in advance for your time and dedication, -- Bastien
Re: Bug: Logbook drawer and org-adapt-indentation with value headline-data [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi Gustavo, Gustavo Barros writes: > the new release brought the interesting value `headline-data' to the > option `org-adapt-indentation'. However it introduces some issues > regarding the indentation of log entries in the `LOGBOOK' drawer, which > I describe below. I can reproduce this bug, I will try to fix it. Thanks. -- Bastien
Re: Release Org 9.4.2
TEC writes: > I think this conversation deserves it's own thread, perhaps something > like "Org's development forge". Please don't open this topic, as there is no plan here. -- Bastien
Re: [PATCH] Document changes of headline fontification introduced in 979e82fc3
Hi Ihor, Ihor Radchenko writes: > I just got someone confused [1] about the new headline fontification > behaviour when all the headline components inherit the headline face. > I think it will be useful to document the change in ORG-NEWS and show > how to restore the old appearance. Applied (1f4ea532a), thanks a lot. -- Bastien
Re: Bug: org-element does not recognize table.el tables [9.4 (release_9.4-53-g23f941 @ /home/nick/elisp/org-mode/lisp/)]
Hi Jean, Jean Louis writes: > Clarify confusions in the manual and don't break habits and > established features of Org. This is not really helpful because it is too general. Can you make specific suggestions or provide patches for what needs to be addressed? Also, your message sounded harsh. If it is intentional, it is harmful. If it isn't, please make an effort of sending nicer messages. Thanks, -- Bastien
Re: did behaviour of RET change again?
Hi Eric, Eric S Fraga writes: > Just a quick heads-up: > > I have just installed org from git (a few hours ago) and now it seems > that RET no longer indents. Is this intentional? I've not closely followed this, sorry. I see something wrong right now: RET after a headline should only try to indent below the beginning of the headline with org-adapt-indentation is t, but not nil or headline-data. For now, when org-adapt-indentation is headline-data, RET still indents. I will see how to fix this. Also, I'm thinking of using headline-data as the new default for the org-adapt-indentation option. WDYT? I know Kevin as a good overview of the whole topic, maybe he can also advise about what should be done here. Best, -- Bastien
Re: Bug: org-element does not recognize table.el tables [9.4 (release_9.4-53-g23f941 @ /home/nick/elisp/org-mode/lisp/)]
Hi Nick, Nick Dokos writes: > Consider an Org mode file with a table.el table (which I made by > first constructing an Org mode table and then usind `C-c ~' to > convert it): Would it be so bad if org-mode decides to stop supporting table.el tables? I don't see the benefit of supporting both Org tables and tables.el tables, and it calls for confusion. What do you and everyone else think? -- Bastien
Re: W3C violations in Org's HTML export
Hi Timothy, TEC writes: > I don't think this should be forgotten about, so I'm adding it to > https://updates.orgmode.org/#help for now. Thanks - a tip: you can use a summary like this one with Woof: X-Woof-Help: Fix W3C violations in Org's HTML export See https://github.com/bzg/woof#annotations-for-bugs-and-help-requests Also, feel free to submit patches for these issues, ideally by discussing them in separate threads. -- Bastien
Re: [PATCH] org-attach: Consider inlinetasks when calculating attach dir
Applied (de6d90224), thanks. -- Bastien
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
stardiviner writes: > I seems don't have permission to do `git push` directly. I just added you as a "collaborator" on bzg/org-mode. Please clone and push again. If things don't go right, let's sort this out in private. Thanks, -- Bastien
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
stardiviner writes: > Does that means I can push to org-contacts.el directly by myself? Yes indeed. Thanks to you! -- Bastien
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
Ihor Radchenko writes: > stardiviner writes: > >> Sure, I didn't expected that soon bug appears. I checked source code, I >> commented out an condition accidentally. >> Here is the patch. Tested it should work now. > > What about adding support for org-id? Is it necessary to use headline > text as a search string even when org-id is being used (and > org-id-link-to-org-use-id is set to non-nil)? I don't know what's the best solution here, but stardiviner feel free to commit patches yourself, as this is part of contrib/. -- Bastien
Re: Emacs as an Org LSP server
TEC writes: > A little progress update. > > https://github.com/tecosaur/org-lsp now exists. I encourage everyone to work with Timothy on how to make real progress on org-lsp. If needed so, please use https://github.com/tecosaur/org-lsp for reporting issues and suggestions. Timothy, I'm removing this thread from the "Help requests" section on updates.orgmode.org, because perhaps the code is not mature enough to receive concrete help -- but feel free to reopen another call when it is a good time. Thanks, -- Bastien
Re: ox-slimhtml
Hi Laszlo, thanks for ox-slimhtml.el and for announcing it on the list. > Amin was kind enough to poke me to submit and post about my package, > ox-slimhtml. > In a nutshell, it is an org-export backend - transcodes Org elements to > HTML/text output. > > My primary use for it, is to create derived export backends. (picture a/b > testing, for example) > By default, it outputs HTML5, essentially (as it tries to not ignore current > output preferences). > > Within each transcoder, I tried to pick out the relevant core elements > being passed through - what I skipped from the original ox-html > exporter is the domain logic surrounding templating and navigation. > > A sample of the output can be seen here http://bald.cat/ox-slimhtml/ > > From a more detailed perspective, I use it to template the output of > some Org documents (common sources of truth); these include some > minimal Org markup, and as such, they provide convenient > element-by-element programmatic access. This all depends on where > you’d like to organize the logic behind each elements’ transcoding > process, of course - so, for now, I’ll say that it works really nice > for me. YMMV I encourage everyone to try exporting Org documents to HTML using your library and see how it compares with ox-html.el for a daily usage. Thanks! -- Bastien
Re: [PATCH] ob-gnuplot: Fix error on non-string :var assignment
Hi Ihor, Ihor Radchenko writes: > The following gnuplot code stopped working after recent commits adding > support of remote files: > > #+CALL: stress-strain[:file stress-displ-RD-11.png](A=0.87, alpha=38.0, > beta=7.0, inp="p11 DC.txt", tbl="stress-displ-RD-11.txt") > > Note that the code assigns several numerical variables. ob-gnuplot from > master throws error when checking (file-remote-p ...). > > The fix is attached. Applied on master (baf1e7a64), thanks! -- Bastien
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
Hi, Ihor Radchenko writes: > When using org-contacts and org-id simultaneously, org-contacts > unconditionally makes org-store-link use file:name.org:*Headline link > style instead of id:UUID link style expected when using org-id. The > problem does not only appears when storing links to contact.org > headlines, but for any headlines. > > Probably, org-contacts should be integrated with org-id or at least not > interfere with links to ordinary headlines. Agreed. Stardiviner, can you have a look? Thanks, -- Bastien
Re: Release Org 9.4.2
Pankaj Jangid writes: >> But (1) it is not only *our* decision, it's also in the hands of the >> Emacs maintainers, which may think otherwise; (2) all the consequences >> need to be considered, as it is a sensible move; (3) I am on the verge >> of stepping down as a maintainer, so it is not a good time for me to >> push into a direction or another. > > I sensed (3) when I saw an email (last month I guess) about assimilating > parts of Org into Emacs. While that is a good idea. But I don’t have a > very good feeling about you leaving. You have contributed so much. You > have maintained it so well. > > I can understand how it feels when people complain about features. And > sometimes they blame the maintainers for some specific product > directions. But it is bound to happen when they are also attached to the > product. I hope these things have not shaped up your decision. It > happens in a closely knit family. Thanks a lot for the kind words, appreciated. Be reassured, the fact that I shall soon step down has nothing to do with the community: in fact, the community is what kept me motivated for nearly ten years now! This decision is a simple combination of me not having enough time (which can lead to frustrating situations for other contributors) and the fact that I'm confident about Org's future. >> Anyway, I don't think now is the right time to consider this move, as >> there are many more things to achieve. I suggest we discuss this again >> later next year. > > Yes. This is endless. We’ll continue this... ... but I'm very receptive to the real questions: how can we expose the latest Org to more testers? how can we recruit more contributors? If at some point developing Org within Emacs seems to be part of a good solution, I'll be all for it. I definitely prefer this scenario to the one where Org is kicked out Emacs core and moved to a separate, not-installed-by-default, GNU ELPA package. Best, -- Bastien
Re: [final patch] Re: add new link type "contact:" for org-contacts.el
stardiviner writes: > If this is confirmed, I might don't need to add a new patch to add my > name to maintainer. Can you add it directly? That will be more > simple. Of course, done (c822c80ef). Sorry I forgot about this patch, and thanks for your reply. -- Bastien
Re: Release Org 9.4.2
Hi Pankaj, Pankaj Jangid writes: > My question is/are: (1) Why Org is developed outside Emacs, given that > it is a core/built-in package. When Org's development switched to Git (13 years ago, from memory), the release cycle was very short. Way shorter than the release cycle of Emacs. Also, the process for accepting new code contributors was lighter, even when we asked them to sign the FSF copyright assignment. In this context, having a separate Git repo was a huge plus, and Org was not yet included of Emacs. Then Org became part of Emacs, which was a very important move. But still, using a separate repo and a separate mailing list was key in being free to progress at our own pace, which was still quite fast. Today, the release cycle of Org is longer and that of Emacs shorter. So yes, it could make sense to envision a destiny similar to Gnus: Gnus is now developed in Emacs and Org could also be developed in Emacs. But (1) it is not only *our* decision, it's also in the hands of the Emacs maintainers, which may think otherwise; (2) all the consequences need to be considered, as it is a sensible move; (3) I am on the verge of stepping down as a maintainer, so it is not a good time for me to push into a direction or another. > (2) Are there other packages that follow the same process? I don't know. It could be useful to compare Org situation to other packages but at the same time, Org is quite peculiar. Anyway, I don't think now is the right time to consider this move, as there are many more things to achieve. I suggest we discuss this again later next year. Thanks, -- Bastien
Re: [final patch] Re: add new link type "contact:" for org-contacts.el
stardiviner writes: > My patch still in the previous "[UPDATED PATCH]" state. (I attached > in this email) Thanks. It applies correctly on the maint branch but I'd rather apply it againt the master branch, where it fails to apply. Can you replay your changes on top of the main branch, and also add your name as the maintainer? Thanks a lot! -- Bastien
Re: Unhealthy Haskell babel
Hi Lawrence, Lawrence Bottorff writes: > I'm looking into Haskell (latest ghci) again on org-mode. This Sadly enough, we don't have a maintainer for ob-haskell.el. Would you be willing to become the maintainer? Of course, you can always hand it over to someone else when you want to. It is just better to have someone than to have no one. Best, -- Bastien
Re: Emacs as an Org LSP server
Hi Jean, you quoted the GNU Kind Communication Guidelines already in this list: https://www.gnu.org/philosophy/kind-communication.en.html May I draw your attention to this specific sentence: Rather than trying to have the last word, look for the times when there is no need to reply, perhaps because you already made the relevant point clear enough. >From the last 1000 messages, 174 messages come from you and the vast majority of them are not about fixing bugs or directly providing an answer, they are about sharing your opinion on something. Sometimes it is on-topic, sometimes it is not, it is hard to tell, because your message tend to be very long. I strongly suggest you try to think twice about this sentence from the GKCG before writing. Thanks, -- Bastien
Re: Release Org 9.4.2
Hi Pankaj, Pankaj Jangid writes: > Bastien writes: > >> I've released Org 9.4.2, a bugfix release. >> >> This version was merged with the emacs-27 branch: > > This is the only code that goes into stable branch first and then into > ‘master’. Probably we need tweak the process a bit. Sorry, I don't understand your concern here. What should be done differently? -- Bastien
Re: [PATCH] babel latex headers and image generation commands
Matt Huszagh writes: >> Can you provide a patch against etc/ORG-NEWS announce this? > > Attached. Let me know what you think. Applied (2af68d6a4) with a minor modification in the headline. Thanks, -- Bastien
Re: [PATCH] Enhance org-html--build-meta-info
Hi Timothy,
TEC writes:
>> In a nutshell, can you restate what problem is this patch fixing?
>
> There are two things I intend to achieve with this patch:
> 1. DRY* out the existing code. The existing code is quite repetitive in
>structure, and easily lends itself to being extracted to a function.
>This is easier to read, and work with IMO.
> 2. Make use of the DRYer code in (1) to provide a make the meta building
> function more versatile, and then add in the ability for user
> customisation at low-cost (again, thanks to (1)).
Can we approach this with two patches, one with the refactoring and
one with the added functionality?
> Necessary? Not really, I mean the export /works/ without it. I'd argue
> that it's desirable though, as it provides an easy way for a user (such
> as myself) to add useful meta tags not included by default.
This sounds useful.
>> Are there backward compatibility considerations we should take care of?
>
> None AFAIK. Barring this errors that Jens raised, and now have hopefully
> been addressed, this should function /exactly/ as the current
> implementation does, with a minor (beneficial) caveat, mentioned below.
> Just with nicer-to-work-with code and a bit more versatility (IMO, of
> course).
>
> These are the two changes to be mentioned:
> 1. The (or {title} "Org Export") bit I added.
>I believe the current behaviour when no #+title is given is to have a
>blank one (""). I think "Org Export" is preferable, as it's more
>informative than ... nothing.
I think "Org Export" as the default is counter-intuitive, let's stick
to the empty string. (Also, this kind of "small" changes should be
made with consideration of all exporters.)
> 2. Using org-html-encode-plain-text for formatting the content of the
>meta tags. From Jens, I take it that the current org-export-data can
>cause nested HTML tags, which are invalid in this context. Plain text
>should be safer.
Yes, this is better.
>>> +(defun org-html--build-meta-entry (label identity content-format
>>> content-formatters)
>>> + "Construct tag with LABEL=\"IDENTITY\" and content from
>>> CONTENT-FORMAT and CONTENT-FORMATTER."
>>
>> The first line of this defun is too long. You can try M-x checkdoc
>> RET on your elisp files to catch those issues.
>>
>> Thanks,
>
> I see, I'm guessing I'll just need to add a line break.
Nope, the first line of a docstring should be a sentence. You'll have
to reformulate the beginning of the docstring...
Thanks!
--
Bastien
Re: Ignored bugs
Hi Boruch, Boruch Baum writes: > BUG REPORT: 42484 > > + This is of particular concern to me because when it was submitted it > was summarily closed AND ANRCHIVED. When I complained, it was unarchived so > that I could provide a solution and patch of my own, but it has since > been archived AGAIN, so I can't submit an updated patch. Further, it > was never removed from the closed state, so it could easily be > overlooked. (Do I need to explicitly complain that this is awful > management behavior?) So, I have an updated patch that I tried to > submit a few minutes ago that was bounced because the thread is in > read-only archived state. I'm not convinced this should be in Org's core. I think it could be in https://orgmode.org/worg/org-hacks.html You can send a patch against https://code.orgmode.org/bzg/worg/ or ask for an account on https://code.orgmode.org to be able to write directly to Worg. > BUG REPORT: 43954 Please use report-emacs-bug for bugs only. For such suggestions, please discuss them on this list. > BUG REPORT: 43955 > > + code included It looks like 43955 is a better version of 43954. > BUG REPORT: 44133 > > + code included The patch seems interesting. Can you resend it on this list in a dedicated thread? Also, you need to format it as described here: https://orgmode.org/worg/org-contribute.html Thanks, -- Bastien
Release Org 9.4.2
Hi all, I've released Org 9.4.2, a bugfix release. This version was merged with the emacs-27 branch: https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-27 Enjoy! -- Bastien
Re: [PATCH] org-plot abstractions and extension
TEC writes: > Thanks for the feedback on the patches! I tried to get it right after my > previous (and first) attempt, but it looks like there are a few things I > still need to take note of. Big improvement though, nonetheless, > hopefully next time they'll be nothing to change :) Well, It's perfectly fine not to send a perfect patch. Thanks! -- Bastien
Re: Ignored bugs
Hi Boruch, Boruch Baum writes: >> Would you like to elaborate on why making it easy for you to contribute >> something to org-mode that solves your problems should be of concerns to >> the people of this list, especialy if this comes at extra cost to them? > > That is such a classic and revealing paragraph you wrote about yourself! > Maybe paste it on your bathroom mirror and read over every once in a while. > Maybe publicize that paragraph as a policy document for the project? > >> Cheers, > > Not. The tone of your answer sounded harsh. You may have your reasons to be upset, but please let's try our best to avoid such tone. You may want to read the GNU Kind Communication Guidelines: https://www.gnu.org/philosophy/kind-communication.html I re-read them from time to time, they convey useful hints on how to have constructive conversations. Best, -- Bastien
Re: [PATCH] Remove redundant 'function's around lambda
Hi Kyle, Kyle Meyer writes: > Org files don't use a consistent style, despite Org's .dir-locals.el > setting indent-tabs-mode to t, which should probably be changed to match > Emacs's nil value. FWIW, I'm all for setting `indent-tabs-mode' to nil in Org's .dir-locals.el. Your call, of course. -- Bastien
Re: TEC: update the new website ML page?
Hi Russell, Russell Adams writes: > This really needs to state that the Org-mode mailing list is > subscriber only. Membership is open, but that users should subscribe > prior to posting. The Worg page for the ML says that. FWIW, I just slightly updated this page with this paragraph: If you are not a subscriber to the list, you can still send an email to emacs-orgmode@gnu.org, we will add you to the whitelist of people who can reach the list. > As a second request, can we get a link to Worg on the top level bar? I'd rather let Timothy decide on this, as he has the whole picture. Thanks, -- Bastien
Re: [PATCH] (org-remove-occur-highlights) Implements option to remove highlights between points
Kyle Meyer writes: > It might be worth stepping back and describing what your use case for > this change is, and considering other ways to address it (not > necessarily as a change to Org itself). Since the problem needs to be revisited, I've closed this patch. Nicholas, feel free to tackle the initial issue differently and to provide another patch in another dedicated thread. Thanks! -- Bastien
Re: [PATCH] org-preview-latex-fragment dvipng fix for packages in org-latex-packages-alist breaking 'latex' command
Hi,
Sébastien Miquel writes:
> If I've understood your problem correctly, simply using (""
> "fontspec" nil) in org-latex-packages-alist should fix your issue.
Since this conversation died, I'm closing this patch.
Feel free to resubmit it if needed.
--
Bastien
Re: [PATCH] ob-java.el: Allow for more whitespace
ian martins writes: > Two patches are attached. One allows for more whitespace in java code > blocks. The other fixes a bug that would result in a main method being > wrapped in another main method. Closing this now, thanks! -- Bastien
Re: [PATCH] org-manual.org: Remove languages list and update worg link
Bastien writes: > Kyle Meyer writes: > >> ian martins writes: >> >>> I pushed two days ago, but the manual hasn't updated yet. I guess it >>> doesn't update on git hooks like worg. is there a scheduled process or is >>> there something that must be done? >> >> The online manual corresponds to the latest release and updated with >> each release (as far as I know, though hopefully Bastien or others will >> correct me if I'm wrong). > > Yes, that's correct. Closing this patch now. -- Bastien
Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
Hi stardiviner, what is the last state of your patch? Feel free to resend it, I will apply it. Also, do you want to become the maintainer for org-contacts.el? Remember, elisp files in contrib/ will soon be extracted from the repository: https://orgmode.org/list/87wnzfy60h@bzg.fr Still, it's useful to already know who will be in charge. Thanks, -- Bastien
Re: [PATCH] Enhance org-html--build-meta-info
Hi Timothy,
TEC writes:
> Thanks for testing this :) I haven't forgotten about this.
Let's wait for Jens feedback on this patch, since he took care of
testing it so far.
In a nutshell, can you restate what problem is this patch fixing?
Is a new option really necessary here?
Are there backward compatibility considerations we should take care of?
> From 1289e381aff7562df96945aa58838ad966aa9211 Mon Sep 17 00:00:00 2001
> From: TEC
> Date: Thu, 17 Sep 2020 21:27:18 +0800
> Subject: [PATCH] lisp/ox-html.el: make html meta func nicer
>
> * lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
> structure extracted to new function `org-html--build-meta-entry'.
You need to have a separate changelog entry for any new function or
variable.
> The opportunity was taken to extract most metadata info to custom
> variable `org-html-meta-tags', allowing for easy end-user modification.
> ---
> lisp/ox-html.el | 131 +++-
> 1 file changed, 73 insertions(+), 58 deletions(-)
>
> diff --git a/lisp/ox-html.el b/lisp/ox-html.el
> index d2f24f5c6..93014e9c7 100644
> --- a/lisp/ox-html.el
> +++ b/lisp/ox-html.el
> @@ -1425,6 +1425,31 @@ not be modified."
>
> Template :: Styles
>
> +(defcustom org-html-meta-tags
> + '((lambda (_title author _info)
> + (when (org-string-nw-p author)
> + (list "name" "author" author)))
> +(lambda (_title _author info)
> + (when (org-string-nw-p (plist-get info :description))
> + (list "name" "description"
> + (plist-get info :description
> +(lambda (_title _author info)
> + (when (org-string-nw-p (plist-get info :keywords))
> + (list "keywords" (plist-get info :keywords
> +("name" "generator" "Org Mode"))
> + "A list of arguments to be passed to `org-html--build-meta-entry'.
> +Each argument can either be an list which is applied, or a function which
> +generates such a list with signature (TITLE AUTHOR INFO) where TITLE and
> AUTHOR
> +are strings, and INFO a communication plist."
> + :group 'org-export-html
> + :package-version '(Org . "9.5")
> + :type '(repeat
> + (choice
> +(list (string :tag "Meta label")
> + (string :tag "label value")
> + (string :tag "Content value"))
> +function)))
> +
> (defcustom org-html-head-include-default-style t
>"Non-nil means include the default style in exported HTML files.
> The actual style is defined in `org-html-style-default' and
> @@ -1835,78 +1860,68 @@ INFO is a plist used as a communication channel."
>
> ;;; Template
>
> +(defun org-html--build-meta-entry (label identity content-format
> content-formatters)
> + "Construct tag with LABEL=\"IDENTITY\" and content from
> CONTENT-FORMAT and CONTENT-FORMATTER."
The first line of this defun is too long. You can try M-x checkdoc
RET on your elisp files to catch those issues.
Thanks,
--
Bastien
Re: [PATCH] ob-java
ian martins writes: > On Sat, Nov 14, 2020 at 6:48 AM Jarmo Hurri wrote: >> >> >> > It seems that you have changed some classloader settings in the new >> >> > code. I have examples which used to work perfectly; now they still >> >> > compile, but fail to run, throwing exception >> >> > >> >> > java.lang.NoClassDefFoundError >> >> > > This should be fixed with 93087e0b3a. Thanks for reporting, and sorry > I missed your first email. I found it. It went to spam for some > reason. FWIW I'm closing this so that the ob-java thread does not appear on updates.orgmode.org anymore. Thanks, -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Corwin Brust writes: > I did exchange emails with the assignment clerk this past week and we > are not at any roadblocks afaict. I'll update again in not more than > (a fhanish/volunteers') three weeks, even if I have nothing > interesting to report. Does that sound right? Yes, please go ahead and don't hesitate to CC me in your conversation so that I know where you are in the process. > I appreciate your checking in on me! You're welcome, thanks for volunteering! -- Bastien
Re: [PATCH] org-plot abstractions and extension
Hi Timothy, TEC writes: > I'll attach all the patches to this email, so there's no ambiguity. > (crosses fingers for attachments working as expected) Applied, with minor modifications of the changelog entries: - You need to add an entry when creating a new custom variable. - I suggest saying "option" instead of "custom variable". - Sentences should be separated by two spaces and start with an uppercase letter. Also, the convention in Emacs is to avoid whitespaces-only commits, you need to fix whitespaces within other non-whitespaces changes in a commit. Thanks a lot! -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Hi Corwin, Bastien writes: > thanks for volunteering! Let us know when the paperwork is done, I'll > add you as ob-perl.el maintainer then. FWIW, I added you as a maintainer for ob-perl.el on the master branch. Can you confirm the copyright process is over? Sorry if I missed an email saying so already. Best, -- Bastien
Re: Org Capture Menu cannot be fully viewed
Jean Louis writes: > Discussion is brainstorming that may or may not lead to solutions. This list is not a place for brainstorming. Sharing very long emails too frequently might scare other readers away, discouraging them to participate to a constructive discussion. Please make an effort to write shorter emails less frequently. -- Bastien
Re: Org Capture Menu cannot be fully viewed
Hi Tim and Jean, Tim Cross writes: > I have no clue as to why your dragging Emacs custom into this > discussion. I agree with Tim. Let's keep in mind we are more than 2000 subscribers here and make an effort of not letting our conversations drift too much. In-depth analyses are welcome on this list as long as we are trying to stay on-topic. Each message on a forum is a call for attention, let's use it with parsimony and consideration for everyone's time. -- Bastien
Re: Someone to oversee Org bugs as reported with M-x report-emacs-bugs?
Jean Louis writes: > * Bastien [2020-12-11 09:28]: >> Thanks Jean, I agree with most of your points. >> >> Are you volunteering for this task? > > I am anyway answering to people. So I am already doing it. Thanks but we need someone that is willing to personnally take charge of this. > But I did not copy to Org mailing list as I heard it is subscriber > based. Maybe copying the emacs-orgmode@ list won't be necessary when debbugs can forward the email there. > Normally GNU mailing lists are not subscriber based. I don't know about other GNU mailing lists but I'm not under the impression that GNU mailing lists are "normally" not subscriber based. -- Bastien
Re: [PATCH][9.4] Mention org-adapt-indentation as escape hatch in ORG-NEWS
Hi Kévin, Kévin Le Gouguec writes: > If it's not too late for this to make it into 27.2, I think this could > make dealing with the electric-indent-mode kerfuffle easier for > unsuspecting users. Applied, thanks, -- Bastien
Re: Bug: org-capture does not work if called from minibuffer [9.4 (9.4-55-g706ba9-elpaplus @ /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20201207/)]
Hi Omar, thanks for reporting this. Omar Antolín Camarena writes: > I have enable-recursive-minibuffers set to t, and just noticed that > org-capture does not work if called from the minibuffer. > > Steps to reproduce: > > 1. run emacs -Q > 2. evaluate (setq enable-recursive-minibuffers t) in the scratch buffer > 3. Open the minibuffer, say by using C-x C-f > 4. While still in find-file, run M-x org-capture and pick a template (t for > Task seems to be offered by default). > > You should get an error message saying "Can't expand minibuffer to > full frame". Would you be okay with a user-error message like "Cannot call org-capture from the minibuffer" ? -- Bastien
Re: [PATCH] ob-C.el: Fix a number a bugs related to table parameters
Hi Asa, Asa Zeren writes: > Here are a number of fixes to ob-C.el. There is still probably a bunch > of general cleanup to do in this file, but these changes make it work > for me. thanks for the patch. I'm copying Thierry as the (new) maintainer for ob-C.el. -- Bastien
Re: New startup options, showlevels
Hi Gustav, Gustav Wikström writes: > Prompted by a question on StackOverflow, > https://stackoverflow.com/questions/56536184/set-initial-visiblity-to-a-certain-level-in-org-mode, > a few new options are added to the startup setting. thanks -- in the future, I suggest discussing such additions on this list before committing them. In this case, I think we could come up with better option names than "show2levels", even if I don't have a better suggestion right now. > Patch is applied to master as this is non-critical and it is > communicated here and now for full transparency. See commit hash > a71ac14e4, > https://code.orgmode.org/bzg/org-mode/commit/a71ac14e46bb820abdbd2e6651c58179c50eb2fa Mandatory nitpick: the log should contain proper sentences, ending with a dot. I'm mentioning this because your other commit has the same small error. > Hope these new options will be usable for some of you! It sure is, thanks for taking care of this, -- Bastien
Re: Bug fix attached: org-babel sql postgres, fix hardcode
Hi Alan, Alan Light writes: > ob-sql.el does not respect the value of sql-postgres-program, thus > causing problem when running on Windows, etc. > Patch attached. Thanks. Can someone confirm the patch is good? Alan, can you check how to submit a patch with a changelog on this page: https://orgmode.org/worg/org-contribute.html and resubmit it? Best, -- Bastien
Re: updates website broken
Bastien writes: > Fixed, thanks! FWIW I'm now monitoring whether https://updates.orgmode.org is up. -- Bastien
Re: updates website broken
Fixed, thanks! -- Bastien
Re: Someone to oversee Org bugs as reported with M-x report-emacs-bugs?
Thanks Jean, I agree with most of your points. Are you volunteering for this task? -- Bastien
Someone to oversee Org bugs as reported with M-x report-emacs-bugs?
Dear all, as the subject says: it would be nice to have someone overseeing Org bugs that are reported with M-x report-emacs-bugs. These bugs end up in the Emacs debbugs tracking tool: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs https://www.gnu.org/software/emacs/manual/html_node/emacs/Bugs.html They are also sent to the bug-gnu-emacs mailing list: https://mail.gnu.org/mailman/listinfo/bug-gnu-emacs Volunteering for overseeing these bugs does not mean you have to subscribe to this list or to fix all Org bugs there :) First of all, most users use M-x org-submit-bug-report for Org bugs, which is the preferred way of submitting Org bugs. Secondly, most bugs reported with M-x report-emacs-bugs are bugs against old versions of Org, already fixed upstream. So the idea is just to be able to answer one of these: - "Thanks but I cannot reproduce the bug with the latest Org." - "Thanks, I confirm this is a bug, can you forward it to the Org mailing list at emacs-orgmode@gnu.org?" ... and to make sure that you _close_ the bug report when necessary. It is a very nice way to get _some_ work done for Org/Emacs while also being part of the Emacs maintainance larger team. Who's in? -- Bastien
Re: [PATCH] org-plot abstractions and extension
Hi Timothy, TEC writes: > It's now been 1.5 months, so I'm going to bump this thread. Sure - thanks for bumping this. I'm slowly reading emails from the past weeks, I will handle this ASAP. Thanks, -- Bastien
Re: official orgmode parser
Hi Daniele, Daniele Nicolodi writes: > Would it make sense to have one "official" (or a set of) org-mode test > files and the corresponding syntax tree as parsed by org-elements (maybe > in a format easier to read from other programming languages than > s-expressions, json maybe?) to make testing other parser against the > reference implementation easier? I think it is a very good idea. The example file would be also good to help users track for small syntactic changes, when they happen. Would you like to work on such a file? -- Bastien
Re: official orgmode parser
Hi Tom, Tom Gillespie writes: >> which Ruby org-mode parser does Github use? > > I'm pretty sure that github uses https://github.com/wallyqs/org-ruby. > It is ... not compliant, shall we say. I have making some fixes to the > footnote parsing section on my todo list, but I don't expect to get to > it any time in the near future. Can you contact GitHub and see what they use? Whatever they use, I suggest we ask them to support the org library they use to let their users display Org files. Maybe the same should be done with gitlab.com, since they also parse Org files somehow. -- Bastien
Re: [PATCH] org-manual.org: Remove languages list and update worg link
Hi Kyle, Kyle Meyer writes: > ian martins writes: > >> I pushed two days ago, but the manual hasn't updated yet. I guess it >> doesn't update on git hooks like worg. is there a scheduled process or is >> there something that must be done? > > The online manual corresponds to the latest release and updated with > each release (as far as I know, though hopefully Bastien or others will > correct me if I'm wrong). Yes, that's correct. -- Bastien
Re: official orgmode parser
Hi Ken, Ken Mankoff writes: > Yes, I meant to write that I think Org syntax is maybe *not* > context-free, and therefore EBNF can't capture all of it. But it could > still be very helpful and capture most of it. Perhaps. Or you willing to give it a try and report here? -- Bastien
Re: official orgmode parser
Hi Ken, Ken Mankoff writes: > On 2020-10-26 at 09:24 -07, Nicolas Goaziou wrote... >> # This is a comment (1) >> >> #+begin_example >> # This is not a comment (2) >> #+end_example >> >> AFAICT, you cannot distinguish between lines (1) and (2) with EBNF. > > I agree. I think this is a better (correct?) example than the > footnotes on Org Syntax page. Can you suggest a patch? -- Bastien
Re: official orgmode parser
Hi Sébastien, rey-coyrehourcq writes: > Some partial org Parsers (AST or regex...) i found on the web for a > recent state of the art : Thanks -- I've updated https://orgmode.org/worg/org-tools/ with this information. Best, -- Bastien
Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
Hi Stardiviner, stardiviner writes: > You're right. Thanks for suggestion. > I attached new patch now. Applied, thanks. Would you like to be org-contacts.el maintainer? Beware that, since it is in contrib/, it will soon be extracted from org-mode.git and temporarily live in a org-contrib.git repository. Files in this org-contrib.git will wait for maintainers to take over and maintain the file elsewhere, so you'd be free to maintain it where you see fit. -- Bastien
Re: [PATCH] add new link type "contact:" for org-contacts.el
Hi Stardiviner, stardiviner writes: > After waited some days, still no reponse, so I popup this email. I suggest we collectively adopt a convention of waiting at least *one month* before bumping up threads. It might seem long, especially if you initiated the thread with a patch or a bug report, but given the activity on this list, I think it's reasonable. I've documented this suggested policy on Worg, see the section "What to do if you don't receive an answer" : https://orgmode.org/worg/org-mailing-list.html#org3a98a57 Thanks, -- Bastien
Re: Inconsistency between code and manual: org-lowest-priority or org-priority-lowest
Hi Kyle, Kyle Meyer writes: > Daniele Nicolodi writes: > >> On 30/10/2020 05:57, Kyle Meyer wrote: > >>> The org-X-priority -> org-priority-X rename happened in v9.4, with >>> org-X-priority names retained as aliases. So, it sounds like there are >>> some leftover bits in the code. >> >> You are absolutely right. This is what you get when you read the manual >> for the latest version but look at the code for an old one... > > Quickly grepping, a few instances of the old names remain in the code > base, if you're still interested in sending a patch. I fixed the ones I've found in 370cf49cd and ff5fd323b. Thanks! -- Bastien
Re: default :results
Hi Ian, ian martins writes: > The doc says functional mode (=:results value=) is the default for > most Babel libraries [1]. I haven't looked at many, but it is the > default for ob-python and ob-shell. Scripting mode (=:results output > =) is the default for ob-C, and the old ob-java (neither of these > provided a functional mode). > > When I added functional mode to ob-java, I made it the default since > that seemed correct. But that change breaks anyone that relied on > the old default (the workaround is to add a =:results output= > header). I will change the default in the short term to unbreak the > experience, but what, if anything, should be done long term? The default for ob-shell execution was to use the output, not the value. Then we had a long discussion, leading to this: - The default (no :result) is to display the functional value - For some languages, it may break expectations, so in this case we allow a variable that let the default (no :result) use the output instead of the functional value. This is what is being done for ob-shell.el where we have `org-babel-shell-results-defaults-to-output' set to `t'. See https://orgmode.org/list/877dt5trjr@bzg.fr/ for the conclusion of the discussion. Also see `org-babel-shell-results-defaults-to-output' docstring: Let shell execution defaults to ":results output". When set to t, use ":results output" when no :results setting is set. This is especially useful for inline source blocks. When set to nil, stick to the convention of using :results value as the default setting when no :results is set, the "value" of a shell execution being its exit code. > And is this inconsistent behavior across languages something that > should be fixed? or is it intentional or at least not worth doing > anything about? What was suggested is to have a page on Worg listing the behavior of various packages regarding block execution. I started a section on https://orgmode.org/worg/library-of-babel.html with a table -- feel free to add more to this table. Thanks, -- Bastien
Re: [PATCH] ob-java
Hi Jarmo, Jarmo Hurri writes: > (I wonder if it would be possible to have timestamps in worg. I have > bumped into situations before where I have not known the temporal > relationship between worg documentation and current org version.) Good point. I think worg documentation, when related to a specific Org feature, should mention the Org version it relates to, rather than a timestamp. As an additional info, the timestamp is good, but not enough. Let's try to follow this convention from now on. -- Bastien
Re: Bug: unsigned file `archive-contents' on orgmode.org [9.4 (9.4-19-gb1de0c-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201019/)]
Thanks a lot, that's very useful. Something I'm not sure: shall we sign only the "archive-contents" file or both "archive-contents" and "org-MMDD.tar"? For the public key of Org ELPA, where would you expect to download it from? https://orgmode.org/elpa/key.asc or https://pgp.mit.edu or both? -- Bastien
Re: Bug: unsigned file `archive-contents' on orgmode.org [9.4 (9.4-19-gb1de0c-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201019/)]
Hi Jean Louis, Jean Louis writes: > GNU ELPA provides signed archive-contents. Org should provide it too, > isn't it? can you let us know what are the steps involved in signing the archive-contents file? Thanks, -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Hi Palak, Palak Mathur writes: > Paperwork with FSF is now complete. Thanks! I've added you as a maintainer for ob-groovy.el. Let me know (privately) what username you want for your account on https://code.orgmode.org. Best, -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Hi Corwin, thanks for volunteering! Let us know when the paperwork is done, I'll add you as ob-perl.el maintainer then. All best, -- Bastien
Re: [PATCH] ob-java
ian martins writes: > But I want to follow your conventions. I will put the authors of ob-C > and ob-python (Eric Schulte and Dan Davison) as the authors of > ob-java and ob-haxe. The implementations are nearly the same. it > wouldn't make sense for them to have different authors. Thanks for doing so! -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Hi Ken, Ken Mankoff writes: > I'll help maintain ob-screen.el Thanks! I added your name as the ob-screen.el maintainer in commit b499b0827. Best, -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Hi stardiviner, stardiviner writes: > I would like to be a maintainer of ob-clojure.el too. For now, I'd rather have one maintainer per file than several. Contributions are always welcome, of course. If I don't have time to maintain ob-clojure.el correctly next year, I'll ask for someone else. Best, -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Hi Stardiviner, stardiviner writes: > I searched my name in maintainer line. > > Here is the complete list: > ``` > File: lisp/ob-eshell.el > 5 25 ;; Author: stardiviner I added yourself as the maintainer for ob-eshell.el (commit 1d105a429), thanks. My call for ob-* maintainers for Org's core, but of course it's useful to call for maintainers for contrib/ packages too! -- Bastien
Re: [PATCH] ob-gnuplot: handle remote input files
Hi Ferdinand, Ferdinand Pieper writes: > I signed the FSF copyright times a short while ago, so I think this is > no longer necessary. Indeed, thanks. https://orgmode.org/worg/org-contribute.html was not up to date, I've fixed this. -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Hi Palak, Palak Mathur writes: > I have sent that form to the address listed on the form. thank you very much. -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Hi Palak, Palak Mathur writes: > I am willing to take care of ob-groovy.el. thanks. AFAIK you didn't assign your copyright to the FSF. This is needed to be able to commit to Org's core. Can you fill this form and report to me when this is done? https://orgmode.org/request-assign-future.txt Thanks! -- Bastien
Re: New website - back to the old unicorn!
Hi John, John Herrlin writes: > "many others" on the landing page points to > https://orgmode.org/org.html#History-and-Acknowledgments and returns > 404. Fixed, thanks! -- Bastien
Re: New website - back to the old unicorn!
Hi Carsten, Carsten Dominik writes: > P.S. One of the pages advertises that this > > > [[https://upload.wikimedia.org/wikipedia/commons/5/5d/Konigsberg_bridges.png]] > > should inline an image. Does not do it yet for me. What am I > missing? If you export a minimal .org file like the one attached and export it to HTML with C-c C-e h h, it should create a HTML file with an inline image*. Does it not on your side? * https://upload.wikimedia.org/wikipedia/commons/5/5d/Konigsberg_bridges.png; alt="Konigsberg_bridges.png" /> -- Bastien #+title: Test inline image [[https://upload.wikimedia.org/wikipedia/commons/5/5d/Konigsberg_bridges.png]]
Re: Please help by becoming a maintainer for an Org Babel file
Hi Jeremie, Jeremie Juste writes: > I'm willing to take care of ob-R.el. You're in as of 36f4df892. Thank you very much! -- Bastien
Re: org's elpa returns 404
Hi, lockyw...@gmail.com writes: > I used to update org from org's elpa, as documented at: > https://orgmode.org/elpa.html > , by adding this address to the repos: > https://orgmode.org/elpa/ A temporary glitch due to the switch to the new website. Fixed, now. Thanks! -- Bastien
New website - back to the old unicorn!
Dear all, thanks to the initiative and the patient efforts of Timothy, our website has been revamped: new contents, new look and... the old unicorn! Thanks very much to Timothy and to everyone who contributed with feedback and ideas. This is a new basis that we will continue to polish and enhance. Enjoy :) https://orgmode.org -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Tim Cross writes: > Is there a list of org babel files which need maintainers? You can check the list of ob-* files here: https://code.orgmode.org/bzg/org-mode/src/master/lisp If there is no "Maintainer:" in the header, then the file could benefit from having an individual maintainer. -- Bastien
Please help by becoming a maintainer for an Org Babel file
Dear all, we are looking for more maintainers of individual Org Babel files. Jack and Ian are already in, I added myself to ob-clojure.el. If you feel like proposing yourself for maintaining an Org Babel language, that would be super helpful. Thanks a lot! -- Bastien
Starting from 9.5, Org contrib will be distributed as a separate Org ELPA package
Hi all, "Org contrib" refers to the list of Emacs lisp files that you find in the contrib/ directory of Org's repository: https://code.orgmode.org/bzg/org-mode/src/master/contrib The idea of this directory was to have a place where to promote Org packages even if they are not part of Org's core (ie the files that go into Emacs core.) It was also useful as a place to welcome packages from authors who don't sign the FSF copyright assignment. Both reasons are kind of obsolete nowadays: many, if not most useful Org contributions are published elsewhere. Also, mixing authors who signed the FSF assignment and those who don't is never a good idea for a repo, even if the contributions happen in separate spaces. Org 9.5 will ship without the packages in the contrib/ directory. Emacs lisp files in contrib/ will be packaged as an Org ELPA package that you can install independentely from there. The files will live in a new org-contrib.git repo on code.orgmode.org. In the long run, every Emacs file in org-contrib.git need to find a proper maintainer (who will decide where to maintain it) or to be listed in the list of Emacs orphan packages. If you use Org contrib/ files from git, you will have to clone a new repository when the split is done, within the next weeks. If you use org-plus-contrib, you don't have anything to do before Org 9.5 is released. When it is, you will have add Org ELPA to your configuration and install org-contrib from there. If you have any question on this, please let me know! Best, -- Bastien
Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Palak Mathur writes: > Yes, it is going to be some work. I will try to get something > started and share a draft. Can you and Leo work together on this ? Perhaps you can share a first draft (from the user point of view) that Leo can consolidate (from a generic parser point of view) ? Thanks to both for your help! -- Bastien
Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Hi Leo, Leo Vivier writes: > Bastien writes: > >> Sorry, perhaps I was not clear: (1) and (2) do not need to be separate >> documents. > > No, you were quite clear. I just surmised that two documents would be > required, but upon thinking about it some more, (1) and (2) would make > for a cohesive whole. Okay -- perhaps we'll decide otherwise when we can judge by the content. >> Great, thanks for volunteering. I think this is something you should >> perhaps do with a long time Org user, ping-pong'ing with commits, not >> alone. > > Sure, I’d be up for that. Thanks! Anyone else to work on this with Leo? >> Would it be okay for you if we rename worg/dev/org-syntax.org to >> something like worg/dev/org-elements-syntax.org or would that be >> confusing? > > Since we already have worg/dev/org-element-api.org [1], I think the > rename to worg/dev/org-element-syntax.org would be welcome. (Just to be clear, since the quotation context suggests otherwise, I was really asking Nicolas, as he's the author of this document.) -- Bastien
Re: [PATCH] ob-python: Rename exec tmpfile handle to prevent conflict
Hi Jack, Jack Kamm writes: > Thanks Bastien, the Woof! tool looks interesting. Thanks! I'm working on a small woof.el package to make it more useful for both maintainers (setting headers) and users (checking upcoming changes or help requests). > By the way, on seeing this thread again, I realized this patch > probably should have been applied to the maint branch. So I've cherry > picked it into there, and merged back into master. Thanks for this! -- Bastien
Clarification of what to expect from major and minor releases after 9.5
Hi all, I've updated https://orgmode.org/worg/org-maintenance.html to clarify a few points: - we don't have a release schedule; - after Org 9.5, x.y versions like 9.6, 9.7, etc. will be *minor versions*, not major versions. So the next major after 9.5 is 10. - we don't follow semantic versioning: that is, we use the familiar numbering sheme (x.y.z) but the distinction between major (x) and minor (y) is not about incompatible vs compatible changes. Instead, we use what I'd call "Hear ye!" versioning: major Org versions request every users to read the release notes, and minor Org versions request Org contributors and power users to read the release notes. We have no release notes for bugfix-only release. Let me know if something is not clear! All best, -- Bastien
Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Hi Leo, Leo Vivier writes: > Bastien writes: > >> As the first paragraph says: >> >> "This document describes and comments Org syntax as it is currently >> read by its parser (Org Elements)" >> >> while we need a description of Org's syntax from the point of view of >> (1) a human writer and (2) any possible Org parser. > > I agree that (1) and (2) should be two different documents. Sorry, perhaps I was not clear: (1) and (2) do not need to be separate documents. I think both can be described in a single document, my main point was that the current org-syntax.org is from none of these points of view. > (2) would > be especially interesting since there are quite a few projects afoot to > parse Org documents outside of Emacs: > - go-org (Go) > https://github.com/niklasfasching/go-org > - orgize (Rust) > https://docs.rs/orgize/0.8.4/orgize/ > > They are in various stages of advancement, but a design document would > go a long way in federating those efforts. > >> I don't know how difficult it is, but I suspect it is quite a lot of >> work. > > I assume that it would be, yes. However, as someone with a vested > interest in developing an efficient external parser for Org documents, > I’d love to contribute. I’ve been playing around lately with ox.el to > write an exporter to Jupyter (more on that soon), and since it makes > extensive use of org-element.el, I’d have a modicum of knowledge upon > which I could initiate the effort. Great, thanks for volunteering. I think this is something you should perhaps do with a long time Org user, ping-pong'ing with commits, not alone. Nicolas, what's your take on this? Would it be okay for you if we rename worg/dev/org-syntax.org to something like worg/dev/org-elements-syntax.org or would that be confusing? Would you have any advice on how to tackle worg/org-syntax.org in a generic and useful way? -- Bastien
Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Hi Palak, Palak Mathur writes: > I am fairly new to Org. Let me see if I can use it as a markup in an > Editor other than Emacs. I will report on what syntax options are very > Emacs specific, what are general and what can be ported. Thanks! I think it is less a matter of *what* is described in https://orgmode.org/worg/dev/org-syntax.html rather than *how* it is described. As the first paragraph says: "This document describes and comments Org syntax as it is currently read by its parser (Org Elements)" while we need a description of Org's syntax from the point of view of (1) a human writer and (2) any possible Org parser. I don't know how difficult it is, but I suspect it is quite a lot of work. -- Bastien
Re: [PATCH] babel latex headers and image generation commands
Hi Matt, sorry for the delayed answer. Matt Huszagh writes: > Bastien writes: > >> Prefer >> >> * lisp/ob-latex.el (org-babel-latex-preamble): New option for LaTeX >> preamble customization. >> >> "New option" is quite standard, an "option" being a customizable >> variable. In this case, "New option" would probably be enough, given >> the name of the option is quite self-explanatory. Also, some find it >> pedantic, but "LaTeX" is the correct spelling in a changelog I guess. > > Fixed in new patch (attached). Applied as ae35a3459, thanks! >> The first line of the docstring should contain a sentence, so you'd >> need to have a new paragraph after "runtime to the LaTeX preamble." > > Also fixed. Making the first line a full sentence means that some lines > are a little longer than 80 characters. Is this acceptable? > >> What for users who don't have inkscape? > > This is just a default, but I could use a dvisvgm command as the default > instead? Either way, converting a PDF to SVG will require an executable > outside Emacs, but I guess dvisvgm is more likely to be installed for > people using a texlive installation. My personal preference for inkscape > is because it should handle all PDF inputs, whereas there are some cases > where dvisvgm may fail (see > https://github.com/mgieseki/dvisvgm/issues/139) due to changes in > ghostscript. Still, dvisvgm generally does a very good job with PDF > inputs. Let me know your thoughts, I'd be happy to set the default to a > dvisvgm command instead. Let's see what people think when they try it after 9.5. Can you provide a patch against etc/ORG-NEWS announce this? Thanks, -- Bastien
Re: [PATCH] Fixed-pitch tables and code blocks that do not break variable-pitch-mode
Hi Protesilaos, sorry for the delay in replying. Protesilaos Stavrou writes: > Please see the attached diff. An explanation is offered below. This looks good to me -- is this enhancement compatible with older versions of Emacs? I'd like to keep Org compatible with Emacs 25. If so, can you provide a proper patch? Thanks, -- Bastien
Re: [PATCH] Include missing files when sitemap style is tree
Hi Anthony,
Anthony Carrico writes:
> * ox-publish.el (org-publish-sitemap): Include files that have an
> ancestor below base-directory with no published files and sitemap style
> is tree.
thanks for the patch and sorry for the delay in replying. I'm not
sure I understand the bug it fixes: can you briefly describe it or
provide a reproducible recipe?
> +(defun org-publish-dir-name-parent (dir-name)
> + (file-name-as-directory (expand-file-name (concat dir-name ".."
> +
> +(defun org-publish-dir-name-and-parents (dir-name root-dir-name)
> + (pcase dir-name
> + ("" nil)
> + ((or "./" "/" (pred (string= root-dir-name))) (list dir-name))
> + (_ (cons dir-name (org-publish-dir-name-and-parents
> + (org-publish-dir-name-parent dir-name)
> root-dir-name)
> +
> +(defun org-publish-file-name-parents (file root)
> + (org-publish-dir-name-and-parents (file-name-directory file)
> + (file-name-as-directory root)))
> +
You would need to add docstrings for each of the new functions.
Thanks,
--
Bastien
Re: [PATCH] ob-gnuplot: handle remote input files
Hi Ferdinand, Ferdinand Pieper writes: > When passing a remote file like "/ssh:myserver:/myfile.txt" to a > gnuplot block as variable the gnuplot process can not access the > remote data. Applied, thanks! > An example: > > #+begin_src gnuplot :var data="/ssh:myserver:/myfile.txt" > plot data u 1:2 > #+end_src > > Attached is a patch, which instead downloads remote files to a > unique path and passes this new path to gnuplot. > > Please let me know if there's something to improve regarding the > commit message or patch formatting. The commit message and the changelog were perfect, thanks for taking care of this. I simply added "TINYCHANGE". Best, -- Bastien
Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Hi Wes, Wes Hardaker writes: > Ok, I'll try to create a template we can fill out in github next week > (I'm swamped this week with a deadline). If you manage to make any progress on this, please share it with the whole list so that interested people can possibly follow. For the record, I think we should first enhance the Worg documentation on Org's syntax before applying to register Org as a MIME type. https://orgmode.org/worg/dev/org-syntax.html is useful but my feeling is that it describes Org "syntax" from the point of view of the Emacs parser -- we surely need something a bit more agnostic for registering Org as MIME type. I'm adding this as a call for help on https://updates.orgmode.org. Best, -- Bastien
Re: Limitations on Tags ?
Hi David, David Masterson writes: > Just wondering -- what's the limit in the number of tags for a headline? > What if I have a headline with lots of tags or some very long tags? Please try and let us know what happens :) -- Bastien
