Re: Org, Hyperbole, and eev
On Sun, 26 Jun 2022 at 21:50, Robert Weiner wrote: > > So here is a simple implementation that is not unlike your own > though the functions are a bit simpler and more clearly documented > _without a listing of every possible test case type_ and requires > neither Hyperbole nor Org until you want to activate things as > buttons: Hi Robert, I think that the part in "_..._"s above deserves a detailed answer. I started using GNU/Linux in the mid-90s. Before that my favorite languages were Icon and Forth. In Forth I could do AMAZING things in less than 50 lines of code, but my programs would usually become confusing and unmanageable when they grew bigger than that. There is a famous book by Fred Brooks called "The Mythical Man-Month", and one of its chapters is called "Plan to Throw One Away": https://wiki.c2.com/?PlanToThrowOneAway I took that slogan seriously. Most of the time when I realized that something that I was doing by hand could be automated I would write a first attempt to automate it - _as a prototype_, that I regarded partly a program and partly as a way to help me think how that task could be structured, and that would probably be "thrown away" if I needed a cleaner solution later. In Forth it was very easy to implement both strange interfaces and little languages, in this sense: https://wiki.c2.com/?LittleLanguage In Emacs less so, but I could still do lots of funny things using eval-last-sexp to use sexps as buttons. When we are writing throwaway code "planning to throw one away" then using tests in comments is a very good way to document the code. And when I rewrite my prototypes I usually prefer to document them using text ***AND*** executable examples rather than just text. One of the effects of using this style is that the users of eev see that they can use that style in their notes too - and with that their notes become much closer to being "executable notes", in this sense, http://angg.twu.net/eev-intros/find-here-links-intro.html than they would be if they believed that they had to write the docs of their functions as just text. You are sort of saying that having tests in comments is bad style. Well, it's not. =/ [[]], Eduardo Ochs http://angg.twu.net/#eev
Re: [PATCH] Fix caption format for custom latex src block
Ihor Radchenko writes:
> I think that it will be better if you use
> org-latex--caption/label-string instead. It will take care about short
> captions as well.
Changing this to (?c . ,caption-str) yields for the original example
\caption{\caption{Perform inter-sample interpolation.}
}
I could use substring to remove the leading \caption{ and trailing
}. What do you think?
Matt
Re: [PATCH] Fix behavior of lambda default header arg vars
Hi Ihor, Modifications made and split into two patches. Let me know if any remaining issues. Thanks Matt >From fdc6e103932c68b450c72d44d062b4746ec2202c Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Mon, 27 Jun 2022 20:41:02 -0700 Subject: [PATCH 1/2] ob-core.el: Fix behavior of lambda default header arg vars * lisp/ob-core.el: Permit multiple :var default header arguments when using closures. --- lisp/ob-core.el | 5 + 1 file changed, 5 insertions(+) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 7a9467b0e..80086f12c 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -2718,6 +2718,11 @@ parameters when merging lists." (pcase pair (`(:var . ,value) (let ((name (cond +;; Default header arguments can accept lambda +;; functions. We uniquely identify the var +;; according to the full string contents of +;; the lambda function. + ((functionp value) value) ((listp value) (car value)) ((string-match "^\\([^= \f\t\n\r\v]+\\)[ \t]*=" value) (intern (match-string 1 value))) -- 2.31.1 >From 7af7ad3990410ca388c841e045ec66ce694b404a Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Mon, 27 Jun 2022 20:42:27 -0700 Subject: [PATCH 2/2] ob-core.el: Improve org-babel-default-header-args docstring * lisp/ob-core.el: Provide example illustrating one benefit of using closures as default header arguments. Additionally, explain how to provide the same type of header argument multiple times in the default alist. --- lisp/ob-core.el | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 80086f12c..6c3c79126 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -478,12 +478,14 @@ For the format of SAFE-LIST, see `org-babel-safe-header-args'." This is a list in which each element is an alist. Each key corresponds to a header argument, and each value to that header's value. The value can either be a string or a closure that -evaluates to a string. The closure is evaluated when the source -block is being evaluated (e.g. during execution or export), with -point at the source block. It is not possible to use an -arbitrary function symbol (e.g. 'some-func), since org uses -lexical binding. To achieve the same functionality, call the -function within a closure (e.g. (lambda () (some-func))). +evaluates to a string. + +A closure is evaluated when the source block is being +evaluated (e.g. during execution or export), with point at the +source block. It is not possible to use an arbitrary function +symbol (e.g. 'some-func), since org uses lexical binding. To +achieve the same functionality, call the function within a +closure (e.g. (lambda () (some-func))). To understand how closures can be used as default header arguments, imagine you'd like to set the file name output of a @@ -500,7 +502,16 @@ this with: Because the closure is evaluated with point at the source block, the call to `org-element-at-point' above will always retrieve -information about the current source block.") +information about the current source block. + +Some header arguments can be provided multiple times for a source +block. An example of such a header argument is :var. This +functionality is also supported for default header arguments by +providing the header argument multiple times in the alist. For +example: + +'((:var . \"foo=\\\"bar\\\"\") + (:var . \"bar=\\\"foo\\\"\"))") (put 'org-babel-default-header-args 'safe-local-variable (org-babel-header-args-safe-fn org-babel-safe-header-args)) -- 2.31.1
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
> > > > AFAIU, there are no nonfree payment services, except some crypto > > payments. > > In Europe, at least, there is bank transfer. If you go to a bank > branch, I think, you can do transfers to someone else's account without > running any particular software. Bank uses free software on their system? Or are we to merely shift to services where nonfree software runs on somebody else's computer? Go to an internet kiosk and make the payment? VR
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > AFAIU, there are no nonfree payment services, except some crypto > payments. In Europe, at least, there is bank transfer. If you go to a bank branch, I think, you can do transfers to someone else's account without running any particular software. > So, does what you say imply that GNU packages should not provide any > donation options, except crypto (via free payment software)? Yes, sad to say they should not directly offer donation methods. The FSF manages to accept credit card donations without making donors run nonfree software. But it is not easy to arrange that. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: [PATCH] Re: [BUG] Adding note to heading without newline at the end
"Samuel Banya" writes: > 8. I then used C-c C-c, and received the following example output: > ``` > * tes > :LOGBOOK: > - Note taken on [2022-06-27 Mon 22:38] \\ > Adding note with org-log-into-drawer enabled > :END: > t > ``` > > Let me know if this is the desired output in that respect, or if this > fulfills the weird edge case present. Note that the headline "* test" is split into "* tes...t". It is certainly not desired. I see the same issue on my side. I also suspect that the offending functions are the same (but you may need to check). Best, Ihor
Re: [PATCH] Re: [BUG] Adding note to heading without newline at the end
So I went through the same steps as before: 1. Pulled the latest Emacs Org Mode 2. Ran the following command in a terminal to get a clean Emacs without a config: emacs -Q -L ./lisp -l org 3. Create a new org file 4.. Type (literally) the following: * test 5. You will get a file containing "* test" exactly, no newline at the end 6. Do __not__ save the file 7. I then set the 'org-log-into-drawer' variable to true by evaluating the following environment variable with 'M-:': 'M-:' (setq org-log-into-drawer t) This returned 't' in the minibuffer. 8. I then used C-c C-c, and received the following example output: ``` * tes :LOGBOOK: - Note taken on [2022-06-27 Mon 22:38] \\ Adding note with org-log-into-drawer enabled :END: t ``` Let me know if this is the desired output in that respect, or if this fulfills the weird edge case present. Thanks, Sam On Mon, Jun 27, 2022, at 6:18 AM, Ihor Radchenko wrote: > "Samuel Banya" writes: > > I checked 'org.el' which has the related 'org-add-note' function present. > > > > This appears to call the 'org-add-log-setup' function, and passes the > > 'note' argument to it. > > > > I then took a look at the 'org-add-log-setup' function. > > > > From the bug's nature itself, it most likely is moving the cursor > > incorrectly to the previous line above it, when it should be really doing > > it on the line AFTER it. > > > > This to me is probably the 'moving' section that should be modified: > > ``` > > (move-marker org-log-note-marker (point)) > > ``` > > > > It's probably the position that needs to be recalculated or adjusted > > accordingly. > > The offending function is different. This piece of code is admittedly > slightly tricky - org-add-log-setup does not determine where the note > will be inserted. It defers note taking to org-add-log-note, which, in > turn defers saving the note text to the time user presses C-c C-c in the > note buffer. > > The function doing the actual insertion is org-store-log-note and the > function determining where to insert the note is org-log-beginning. > > Note that the patch I attached in my earlier message contains the fix. > What is left is studying a similar edge case reported in the reply to my > patch: > > Tor Kringeland : > >> Thanks! This fixes the bug (which was present in both Org 9.5 and 9.6) > >> for me. However, my original bug, which is only present in Org 9.6, is > >> still there. Do the same thing but set org-log-into-drawer to t. Then > > That is, you need to follow the same steps, but set org-log-into-drawer > to t before creating a note. > > Best, > Ihor >
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Tim Cross writes: > Given that the FSF has a link to PayPal on their donations page , I > think we can do the same for the org project. All that is required is > that we do like the FSF does and put a bit of text beside it stating > "Not recommended - requires nonfree Javascript". > I also notice the FSF will also accept donations via credit card. There > is no credit card processing service which is based on libre software, > so the FSF is using non-free software to process those donations as > well (I guess technically, they are not directly encouraging people use > the non-free credit card processing service, but apparently it is OK for > the FSF to use it to process those donations?). There is an important difference here. FSF does provide a JS-free donation option because it has a special agreement with payment services to accept credit card payments without JS (according to RMS [1]). [1] https://orgmode.org/list/e1noymk-0002tu...@fencepost.gnu.org We do not have such an option for Org. Also, note that Liberapay is better at least because they may add some JS-free options in future and they did have free JS in the past that unfortunately had some issues and had to be removed: https://github.com/liberapay/liberapay.com/issues/1279 > We should also include a postal address where people could send in > donations to provide an alternative for those who really don't want to > use the non-free service (which doens't have to be paypal of course - > any of them would likely be as good). Then we need someone with stable postal address to handle such donations. Also, what about privacy of the address? Alternatively, we can just provide a contact email to discuss alternative donation options in general (with postal being one of the options). > I do notice that RMS says "should not" rather than "must not", which I > think provides some 'wriggle room'. Provided we provide some way to > donate without using non-free software and state that we do not > recommend using service which uses non-free Javascript (they all > seem to at some level) and provided we are prepared to switch to a libre > solution if and when one becomes available (which I doubt it ever will), > we are probably OK. We would definitely prefer Libre solution if there were any. I think that a real working option could be adding some explanation text describing the FSF-compliance of the donations to https://liberapay.com/org-mode page. Best, Ihor
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Michael Powe writes: > Anyone completely serious about a refusal to use nonfree tools for > making donations will send a check in the mail, literally. Would providing something like "Contact us via email if you prefer to make a donation using alternative mechanism" help if we add such statement to https://liberapay.com/org-mode page? Best, Ihor
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
On 6/27/2022 19:42, Tim Cross wrote: Tom Gillespie writes: GNU packages should not steer people towards running nonfree software. As a consequence, they should not suggest people donate using payment services that _require_ the donor to run a nonfree program. A slight variant of Ihor's question. While GNU packages should not steer people toward nonfree software, I assume that there is nothing that prohibits GNU contributors from accepting donations via non-free systems. This thread suggests that it is no other option if devs also do not want to steer people toward cryptocurrencies (which some consider to be as ethically important as not steering people toward nonfree software). My question is whether the website for a GNU package can include links to the websites of individual developers with a note that you can provide financial support to the project by supporting individuals. In the end the user still winds up using nonfree JS, but is GNU living up to its principles by virtue of the extra layer of indirection? Given that https://www.fsf.org/about/ways-to-donate/ does include paypal as an option, with a disclaimer, is a disclaimer not a sufficient solution for GNU packages as well? Given that the FSF has a link to PayPal on their donations page , I think we can do the same for the org project. All that is required is that we do like the FSF does and put a bit of text beside it stating "Not recommended - requires nonfree Javascript". We should also include a postal address where people could send in donations to provide an alternative for those who really don't want to use the non-free service (which doens't have to be paypal of course - any of them would likely be as good). You don't chop down a tree by snipping off the branches at the top. Anyone completely serious about a refusal to use nonfree tools for making donations will send a check in the mail, literally. I raised the point about FSF using PayPal months ago, when this thread started. The response was thunderous silence. I don't like PP as a company. Its profits finance the activities of some truly repugnant people. The JS connection widget is about the most innocuous bit of that company. I only use PP when a CC won't work - mostly, buying overseas, which purchases my bank blocks without exception. No business from which I purchase regularly uses any other payment service. That's the reality of the commercialization of the internet. It blows chunks, but here we are. I don't want to hear about ethical purity from people using products made by Apple, one of the most corrupt and corrupting companies on the planet; or, from those who shop at Amazon - ditto. I've never purchased a book from Amazon, but three times I've purchased products through its "marketplace," and I used to subscribe to its Prime video service. I don't buy products made in China (e.g., clothes, ceramics). But, it's impossible to write this message without using products made there. These kinds of casual lapses of ethical behavior are organic to our present network design. If someone finds a payment processor that uses free software, and is available for users in the US, I certainly will sign up for it. That the FSF isn't using one suggests such services are thin on the ground, or nonexistent. Thanks. mp -- "Do not neglect to do good, and to share what you have." - Hebrews 13:16a Michael Powe Naugatuck CT USA po...@ctpowe.net
Re: We have asynchronous sessions, why have anything else?
The Jupyter project is one approach to this. It currently has dozens of kernels for different languages, and new kernels can certainly be made. The emacs-jupyter package provides one implementation of an interface. It is complex, and relies on a compiled module for the zeromq message passing library. I am not advocating for this as the solution for org-babel, but it is an interesting case study. You can even connect to remote kernels. I use it a lot. On Mon, Jun 27, 2022 at 8:56 PM Tim Cross wrote: > > Tom Gillespie writes: > > >> I am not even sure if all the babel backends support try-except. > >> Think about ob-gnuplot or, say, ob-latex. > > > > Indeed many do not. Defining some standard "features" > > for org babel language implementations is something that > > is definitely of interest so that we can provide clear interfaces > > for things like stdio, error handling, return values, async, > > file output, remote execution, sessions, return value caching, > > module discovery/tangling, execution from file vs stdin, execution > > without a file system path, runtime environment specification, > > and much more. However, at the moment there is only a preliminary > > survey of a subset of these that was put together by Ian Martins. > > > > https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html > > > >> the two could be unified if we expand the functionality of the async > filter > > > > While this might be possible, I would definitely hold off on this because > > the changes in semantics absolutely will break many users' blocks. We > > barely knew what the impact of changing the default return value for > shell > > blocks would be. > > > > I absolutely look forward to the day when this can be done safely and > > with confidence, but I think we need a much stronger handle on babel > > interfaces in general before such a change could even be considered. > > > > At the moment each ob lang impl pretty much has to be considered > > to be completely unique, even if the text looks like bash for e.g. > > shell, comint, and screen. Users are known to rely on undocumented > > quirks of the ob lang impls that can differ wildly in their semantics. > > > > Well said Tom. > > As you point out, there are numerous deficiencies with the current > implementation, despite the fact it all sort of works. To get the sort > of improvements and consistency users want, I suspect this needs more > than just small tweaks around the edges. > > To some extent, I see the current babel implementation as similar to a > prototype. It has worked well and we have learnt a lot about what people > want to use it for and the type of functionality they are wanting and > what some of the core challenges are. Now comes the next step, which is > definitely non-trivial. We need to take all that knowledge and > consolidate it into a single model from which we can define the > interfaces and associated APIs. A big job which will take considerable > time. > > -- John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: We have asynchronous sessions, why have anything else?
Tom Gillespie writes: >> I am not even sure if all the babel backends support try-except. >> Think about ob-gnuplot or, say, ob-latex. > > Indeed many do not. Defining some standard "features" > for org babel language implementations is something that > is definitely of interest so that we can provide clear interfaces > for things like stdio, error handling, return values, async, > file output, remote execution, sessions, return value caching, > module discovery/tangling, execution from file vs stdin, execution > without a file system path, runtime environment specification, > and much more. However, at the moment there is only a preliminary > survey of a subset of these that was put together by Ian Martins. > > https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html > >> the two could be unified if we expand the functionality of the async filter > > While this might be possible, I would definitely hold off on this because > the changes in semantics absolutely will break many users' blocks. We > barely knew what the impact of changing the default return value for shell > blocks would be. > > I absolutely look forward to the day when this can be done safely and > with confidence, but I think we need a much stronger handle on babel > interfaces in general before such a change could even be considered. > > At the moment each ob lang impl pretty much has to be considered > to be completely unique, even if the text looks like bash for e.g. > shell, comint, and screen. Users are known to rely on undocumented > quirks of the ob lang impls that can differ wildly in their semantics. > Well said Tom. As you point out, there are numerous deficiencies with the current implementation, despite the fact it all sort of works. To get the sort of improvements and consistency users want, I suspect this needs more than just small tweaks around the edges. To some extent, I see the current babel implementation as similar to a prototype. It has worked well and we have learnt a lot about what people want to use it for and the type of functionality they are wanting and what some of the core challenges are. Now comes the next step, which is definitely non-trivial. We need to take all that knowledge and consolidate it into a single model from which we can define the interfaces and associated APIs. A big job which will take considerable time.
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Tom Gillespie writes: >> GNU packages should not steer people towards running nonfree software. >> As a consequence, they should not suggest people donate using payment >> services >> that _require_ the donor to run a nonfree program. > > A slight variant of Ihor's question. > > While GNU packages should not steer people toward nonfree software, > I assume that there is nothing that prohibits GNU contributors from > accepting donations via non-free systems. > > This thread suggests that it is no other option if devs also do not want > to steer people toward cryptocurrencies (which some consider to be as > ethically important as not steering people toward nonfree software). > > My question is whether the website for a GNU package can include links > to the websites of individual developers with a note that you can provide > financial support to the project by supporting individuals. In the end the > user still winds up using nonfree JS, but is GNU living up to its principles > by virtue of the extra layer of indirection? > > Given that https://www.fsf.org/about/ways-to-donate/ does include paypal > as an option, with a disclaimer, is a disclaimer not a sufficient solution for > GNU packages as well? Given that the FSF has a link to PayPal on their donations page , I think we can do the same for the org project. All that is required is that we do like the FSF does and put a bit of text beside it stating "Not recommended - requires nonfree Javascript". We should also include a postal address where people could send in donations to provide an alternative for those who really don't want to use the non-free service (which doens't have to be paypal of course - any of them would likely be as good). I also notice the FSF will also accept donations via credit card. There is no credit card processing service which is based on libre software, so the FSF is using non-free software to process those donations as well (I guess technically, they are not directly encouraging people use the non-free credit card processing service, but apparently it is OK for the FSF to use it to process those donations?). I do notice that RMS says "should not" rather than "must not", which I think provides some 'wriggle room'. Provided we provide some way to donate without using non-free software and state that we do not recommend using service which uses non-free Javascript (they all seem to at some level) and provided we are prepared to switch to a libre solution if and when one becomes available (which I doubt it ever will), we are probably OK. However, I am surprised that out of all the options, the FSF uses PayPal.
Re: Org and Hyperbole
Robert Weiner writes: > Yes, I no longer have time to maintain it and based on quality > standards don't wish to re-release it unless one or more highly > experienced Emacs package developers want to take it on, as it is a > good size package. Such a person would have to have developed > significant Emacs packages like Org or Hyperbole and have reasonable > time to answer questions and make updates as issues and requests came > in. Familiarity with a multitude of object-oriented languages would > also be useful. Such volunteers are welcome. Please don't offer if > you have the desire but not the experience. > > In the event no such party appears, when I do find time to make some > necessary updates for a release, I'll do my best to get to it and then > make a release that you can check out. Ah! I saw your old source code repositories for OO-Browser on Sourceforge and Savanah, but didn't look close enough to see they were significantly out-of-date. Warning to others that may go looking. -- David Masterson
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
> GNU packages should not steer people towards running nonfree software. > As a consequence, they should not suggest people donate using payment services > that _require_ the donor to run a nonfree program. A slight variant of Ihor's question. While GNU packages should not steer people toward nonfree software, I assume that there is nothing that prohibits GNU contributors from accepting donations via non-free systems. This thread suggests that it is no other option if devs also do not want to steer people toward cryptocurrencies (which some consider to be as ethically important as not steering people toward nonfree software). My question is whether the website for a GNU package can include links to the websites of individual developers with a note that you can provide financial support to the project by supporting individuals. In the end the user still winds up using nonfree JS, but is GNU living up to its principles by virtue of the extra layer of indirection? Given that https://www.fsf.org/about/ways-to-donate/ does include paypal as an option, with a disclaimer, is a disclaimer not a sufficient solution for GNU packages as well?
Re: We have asynchronous sessions, why have anything else?
> I am not even sure if all the babel backends support try-except. > Think about ob-gnuplot or, say, ob-latex. Indeed many do not. Defining some standard "features" for org babel language implementations is something that is definitely of interest so that we can provide clear interfaces for things like stdio, error handling, return values, async, file output, remote execution, sessions, return value caching, module discovery/tangling, execution from file vs stdin, execution without a file system path, runtime environment specification, and much more. However, at the moment there is only a preliminary survey of a subset of these that was put together by Ian Martins. https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html > the two could be unified if we expand the functionality of the async filter While this might be possible, I would definitely hold off on this because the changes in semantics absolutely will break many users' blocks. We barely knew what the impact of changing the default return value for shell blocks would be. I absolutely look forward to the day when this can be done safely and with confidence, but I think we need a much stronger handle on babel interfaces in general before such a change could even be considered. At the moment each ob lang impl pretty much has to be considered to be completely unique, even if the text looks like bash for e.g. shell, comint, and screen. Users are known to rely on undocumented quirks of the ob lang impls that can differ wildly in their semantics. Best! Tom
Re: Org mode export accessibility
Thanks for looping me in. I'm not subscribed to emacs-orgmode --- so feel free to forward if you find the thoughts below materially useful. As a long-term org-mode user --- and an even longer term TeX user: here are some thoughts: 1. Accessibility as word used in isolation has now become mostly meaningless, to be concrete one has to ask "Accessibility to whom"? 2. So in the following, everything I say is with respect to users with visual impairments. 3. It's incorrect to define "Accessibility" in terms of a specific user access tool or technology -- that usage is marketing jargon for a specific Access Solution like a screenreader --- so I refrain in general from defining this in terms of Screenreaders. With those meta-thoughts out of the way: A: Org-generated documents are mostly well-structured documents, and not in general a user-interface e.g. (WebApp); so with regard to export -- either HTML or LaTeX/PDF --- ARIA is mostly irrelevant. B: The LaTeX->PDF pipeline *can* produce tagged PDF with respect to document structure eg. Sectioning, but only if you use pdflatex or pdftex i.e. LaTeX/Tex->dvi->[ps]->pdf is lossy with respect to structure present in the markup; this is a short-coming of DVI which predates the thought of document structure making it through to the output. C: pdftex and pdflatex were built in the late 90's by a student in Prague (Hanu Than? from memory) --- only reason I know this is that I got Adobe to fund that project when at Adobe in the 90's. It's a very good piece of work that essentially uses PDF directly as the "Device Independent" format rather than the original dvi. DVI as designed in the 70's was device-independent for the time, ie it did not hardwire printer controls and could be mapped to various print mechanisms. For the 90s, by which time Document Structure meant a lot more than being some version of inkjet printer driver independent, the afore mentioned project used PDF as the Device-Independent format --- and leveraged the Tagged PDF bits from PDF 1.4 to achieve the result. D: All that said, it is likely still easier to go from org->HTML directly and produce content that is easier to machine-process --- rather than go through one more level of indirection via LaTeX and PDF; however there may well be additional constraints in a publication workflow, e.g. publisher wants to only publish final-form -- and yes, in this case, HTML and PDF are both final-form. E: Finally, note that in (D) I said "machine processable" not "Accessible"; machine-processable is a pre-requisite to "repurpose " what you publish, and making that result usable by different user communities is a direct consequence of suche machine-processability. Hope this helps. -- --Raman Thanks, --Raman(I Search, I Find, I Misplace, I Research) ♉ Id: kg:/m/0285kf1 瑩 -- Thanks, --Raman(I Search, I Find, I Misplace, I Research) ♉ Id: kg:/m/0285kf1 瑩
Re: feature proposal: export to html headless
On 27/06/2022 19:11, Uwe Brauer wrote: [it isn't an answer for you because you want it in the menu. others will field that. and it's similar to your code.] Right, I hope somebody does, because it looks rather complicated when I look for it in ox.el Isn't the following entry of the export menu is what you are asking for? I am unsure however if "headless" in your request is the same as "body-only" in the Org code. [C-b] Body only:Off [C-v] Visible only: Off ^^^ [C-s] Export scope: Buffer[C-f] Force publishing: Off [C-a] Async export: Off
Re: Got an org-element warning: How to report?
Hi Ihor,
* Ihor Radchenko [2022-06-27; 19:38]:
> Gregor Zattler writes:
>>> Are you seeing the same warning? ("Invalid search bound ...")
>>
>> no, it's
>>
>> Cached element is incorrect in xxx.org. (Cache tic up to date: "yes")
>> Resetting.
>>
>> The element is: "(headline (:raw-value
>> The real element is: "(fixed-width (:begin...
>> Cache around :begin:
>> (headline (:raw-value...
>>
>>
>> And there is no backtrace, I'm still working in this Emacs
>> session at the moment.
>
> This one is tricky. I can only try to do something if you observe the
> warning frequently.
>
> If you do, you can add
> (setq org-element--cache-self-verify 'backtrace)
> (setq org-element--cache-self-verify-frequency 1.0)
>
> to your config
ok, did so.
> and later share (possibly privately) the backtrace.
ok, will do if this happens.
Ciao; Gregor
--
-... --- .-. . -.. ..--.. ...-.-
Re: [PATCH] org-agenda-with-point-at-orig-entry: Fix body indentation
"Aaron L. Zeng" writes: > --- > lisp/org-agenda.el | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks! Applied onto main via ac7b8f9d2 with amendments to the commit message. I have added TINYCHANGE cookie a more detailed changelog entry. Best, Ihor
Re: feature proposal: export to html headless
>>> "SW" == Samuel Wales writes: > [it isn't an answer for you because you want it in the menu. others > will field that. and it's similar to your code.] Right, I hope somebody does, because it looks rather complicated when I look for it in ox.el smime.p7s Description: S/MIME cryptographic signature
[PATCH] Improve look of agenda on graphical displays
The attached patch improves the look of the agenda time grid and separator line on graphical displays. It was inspired by org-modern.el by Daniel Mendler. From dba6d68019c74232f581a55ab012fd9d06f53434 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Mon, 27 Jun 2022 14:04:00 +0200 Subject: [PATCH] Improve look of agenda on graphical displays * lisp/org-agenda.el (org-agenda-block-separator) (org-agenda-time-grid, org-agenda-current-time-string): Improve default visual elements on graphical displays. Inspired by org-modern.el by Daniel Mendler . --- lisp/org-agenda.el | 27 +++ 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index a66d6e116..495fd5454 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -131,13 +131,18 @@ name and week number or the separator lines." :group 'org-agenda :type 'boolean) -(defcustom org-agenda-block-separator ?= +(defcustom org-agenda-block-separator + (if (and (display-graphic-p) + (char-displayable-p ?─)) + ?─ +?=) "The separator between blocks in the agenda. If this is a string, it will be used as the separator, with a newline added. If it is a character, it will be repeated to fill the window width. If nil the separator is disabled. In `org-agenda-custom-commands' this addresses the separator between the current and the previous block." :group 'org-agenda + :version "29.1" :type '(choice (const :tag "Disabled" nil) (character) @@ -1539,11 +1544,12 @@ the variable `org-agenda-time-grid'." :type 'boolean) (defcustom org-agenda-time-grid - '((daily today require-timed) -(800 1000 1200 1400 1600 1800 2000) -".." -"") - + (let ((graphical (and (display-graphic-p) +(char-displayable-p ?┄ +`((daily today require-timed) + (800 1000 1200 1400 1600 1800 2000) + ,(if graphical " ┄ " "..") + ,(if graphical "┄┄┄" ""))) "The settings for time grid for agenda display. This is a list of four items. The first item is again a list. It contains symbols specifying conditions when the grid should be displayed: @@ -1563,6 +1569,7 @@ times that have a grid line. The fourth item is a string placed after the grid times. This will align with agenda items." :group 'org-agenda-time-grid + :version "29.1" :type '(list (set :greedy t :tag "Grid Display Options" @@ -1584,10 +1591,14 @@ will align with agenda items." :type 'boolean) (defcustom org-agenda-current-time-string - "now - - - - - - - - - - - - - - - - - - - - - - - - -" + (if (and (display-graphic-p) + (char-displayable-p ?⭠) + (char-displayable-p ?─)) + "⭠ now ───" +"now - - - - - - - - - - - - - - - - - - - - - - - - -") "The string for the current time marker in the agenda." :group 'org-agenda-time-grid - :version "24.1" + :version "29.1" :type 'string) (defgroup org-agenda-sorting nil -- 2.30.2
Re: Got an org-element warning: How to report?
Gregor Zattler writes:
>> Are you seeing the same warning? ("Invalid search bound ...")
>
> no, it's
>
> Cached element is incorrect in xxx.org. (Cache tic up to date: "yes")
> Resetting.
>
> The element is: "(headline (:raw-value
> The real element is: "(fixed-width (:begin...
> Cache around :begin:
> (headline (:raw-value...
>
>
> And there is no backtrace, I'm still working in this Emacs
> session at the moment.
This one is tricky. I can only try to do something if you observe the
warning frequently.
If you do, you can add
(setq org-element--cache-self-verify 'backtrace)
(setq org-element--cache-self-verify-frequency 1.0)
to your config and later share (possibly privately) the backtrace.
Backtrace is not recorded by default because it slows things down.
Best,
Ihor
Re: [PATCH] Improve "Speeding Up Your Agendas" chapters
Stefan Kangas writes: > > > These options can be applied to selected agenda views. For more > > > details about generation of agenda views, see the docstrings for the > > > relevant variables, and this > > > [[https://orgmode.org/worg/agenda-optimization.html][dedicated Worg > > > page]] for agenda > > ^ (missing trailing ".") Note that the "." is on the next line (you can't see it in the patch though). > Thanks, I'll update the patch. Please see the attached. From 34912156ef5e10ad435be7aa7fbb5025124f481a Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sun, 26 Jun 2022 13:07:46 +0200 Subject: [PATCH] Document org-agenda-ignore-properties in manual * doc/org-manual.org (Speeding Up Your Agendas): Document org-agenda-ignore-properties. --- doc/org-manual.org | 11 +++ 1 file changed, 11 insertions(+) diff --git a/doc/org-manual.org b/doc/org-manual.org index 4c2e968e7..1926329ac 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -21041,6 +21041,17 @@ number. Here are tips to speed up: (setq org-agenda-use-tag-inheritance nil) #+end_src + #+vindex: org-agenda-ignore-drawer-properties +- Disable parsing of some drawer properties: + + #+begin_src emacs-lisp + (setq org-agenda-ignore-drawer-properties '(effort appt stats category)) + #+end_src + + The drawer properties you can disable in the agenda are effort + estimates (~effort~), appointments (~appt~), statistics (~stats~) + and subtree-local categories (~category~). + These options can be applied to selected agenda views. For more details about generation of agenda views, see the docstrings for the relevant variables, and this [[https://orgmode.org/worg/agenda-optimization.html][dedicated Worg page]] for agenda -- 2.30.2
Re: Got an org-element warning: How to report?
Hi Ihor,
* Ihor Radchenko [2022-06-27; 18:20]:
> Gregor Zattler writes:
>
>> Hello org-mode devs, Ihor,
>>
>> today, when opening several org files for my agenda, I got a
>>
>> Warning (org-element-cache): ...
>
> Thanks for reporting!
> This is probably similar to
> https://list.orgmode.org/87a69ypk1m.fsf@localhost/T/#t
>
> Are you seeing the same warning? ("Invalid search bound ...")
no, it's
Cached element is incorrect in xxx.org. (Cache tic up to date: "yes") Resetting.
The element is: "(headline (:raw-value
The real element is: "(fixed-width (:begin...
Cache around :begin:
(headline (:raw-value...
And there is no backtrace, I'm still working in this Emacs
session at the moment.
Ciao; Gregor
--
-... --- .-. . -.. ..--.. ...-.-
Re: org-cite: only last names and et al. for more than two coauthors
On Mon, Jun 27, 2022 at 1:13 AM M. Pger wrote:
> I've recently tried to switch to org-cite, but I still have some problems
> with the basics.
First, org-cite is a framework for citations. When reporting issues
related to it, you really need to identify what processor(s) you are
seeing the behavior with.
> Consider the following entry:
>
> @article{akey2022,
> title = {This is the title},
> shorttitle = {This is the short title},
> author = {Surname1, Name1 and Surname2, Name2 and Surname3, Name3},
> year = {2022},
> (truncated)
> }
>
> I want to have something like: "as shown by Surname1 et al. (2022), ...",
> i.e. something one can get with natbib \citet command. With org-ref it worked
> like a charm.
>
> I've tried the syntax presented in
> https://blog.tecosaur.com/tmio/2021-07-31-citations.html#more-exporting, that
> is:
> [cite/t/c:@akey2022]
> but I ended with a 'wrong type argument' error.
>
> I then tried [cite/t:@akey2022]: exporting succeeds. However, I end up with
> "as shown by Surname1, Name1 and Surname2, Name2 and Surname3, Name3 (2022),
> ...".
>
> How can I correctly specify the options mentioned above? Is there a complete
> and updated tutorial available somewhere?
[cite/t:@key] should work as you expect in natbib, biblatex, csl.
Possible issues, depending on which of those you're using:
- some error with the bib file; or a mismatch between the file and the
bibtex dialect or something
- the citation style
A complete MWE would help.
Bruce
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Richard Stallman writes: > GNU packages should not steer people towards running nonfree software. > As a consequence, they should not suggest people donate using payment services > that _require_ the donor to run a nonfree program. AFAIU, there are no nonfree payment services, except some crypto payments. So, does what you say imply that GNU packages should not provide any donation options, except crypto (via free payment software)? Best, Ihor
Re: [PATCH] Re: [BUG] Adding note to heading without newline at the end
"Samuel Banya" writes: > I checked 'org.el' which has the related 'org-add-note' function present. > > This appears to call the 'org-add-log-setup' function, and passes the 'note' > argument to it. > > I then took a look at the 'org-add-log-setup' function. > > From the bug's nature itself, it most likely is moving the cursor incorrectly > to the previous line above it, when it should be really doing it on the line > AFTER it. > > This to me is probably the 'moving' section that should be modified: > ``` > (move-marker org-log-note-marker (point)) > ``` > > It's probably the position that needs to be recalculated or adjusted > accordingly. The offending function is different. This piece of code is admittedly slightly tricky - org-add-log-setup does not determine where the note will be inserted. It defers note taking to org-add-log-note, which, in turn defers saving the note text to the time user presses C-c C-c in the note buffer. The function doing the actual insertion is org-store-log-note and the function determining where to insert the note is org-log-beginning. Note that the patch I attached in my earlier message contains the fix. What is left is studying a similar edge case reported in the reply to my patch: Tor Kringeland : >> Thanks! This fixes the bug (which was present in both Org 9.5 and 9.6) >> for me. However, my original bug, which is only present in Org 9.6, is >> still there. Do the same thing but set org-log-into-drawer to t. Then That is, you need to follow the same steps, but set org-log-into-drawer to t before creating a note. Best, Ihor
Re: Got an org-element warning: How to report?
Gregor Zattler writes:
> Hello org-mode devs, Ihor,
>
> today, when opening several org files for my agenda, I got a
>
> Warning (org-element-cache): ...
Thanks for reporting!
This is probably similar to
https://list.orgmode.org/87a69ypk1m.fsf@localhost/T/#t
Are you seeing the same warning? ("Invalid search bound ...")
Best,
Ihor
Got an org-element warning: How to report?
Hello org-mode devs, Ihor, today, when opening several org files for my agenda, I got a Warning (org-element-cache): ... which is 7100 characters long and contains private data (filenames headlines, ...) Is this interesting for debugging, if so, does it still make sense if I first anonymize the sensitive data with xx? This is with a newly build emacs and org-mode main from yesterday. I will store the warnings buffer for a few days in case it's interesting. Ciao; Gregor -- -... --- .-. . -.. ..--.. ...-.-
Re: We have asynchronous sessions, why have anything else?
Ivar Fredholm writes: > I believe the two could be unified if we expand the functionality of > the async filter to look for 'exception' tags. Then each language > implementation must only put the org-babel src block in a try-except > type construction and put the error message into the except block. I am not even sure if all the babel backends support try-except. Think about ob-gnuplot or, say, ob-latex. Best, Ihor
Re: [PATCH] describe how to override Author
Robert Pluim writes:
> diff --git a/org-contribute.org b/org-contribute.org
Maybe add the details to org-maintenance.org instead?
This is more of a technical detail needed for maintainers, not for the
committers.
> +1. Command line: src_sh{git commit --author='First Last
> '}
I think we usually prefer source blocks to inline source blocks.
> +2. =VC=: Set the 'Author:' field in log-edit mode (requires setting
> + `log-edit-setup-add-author').
'Author:' -> =Author:=
`log-edit-setup-add-author' -> ~log-edit-setup-add-author~
Best,
Ihor
Re: [PATCH] Improve "Speeding Up Your Agendas" chapters
Ihor Radchenko writes: > Does it have to be inside the main chapters of the manual? > I really hope that users do not _normally_ have to know about these > tricks. I've never needed it, FWIW. However, it also feels misplaced among the appendixes. I guess this is subjective: I prefer chapters that deal exhaustively with their topic. > > Subject: [PATCH 2/2] Document org-agenda-ignore-drawer-properties in manual > > > > * doc/org-manual.org (Speeding Up Your Agendas): Document > > org-agenda-ignore-drawer-properties. > > Note that org-agenda-ignore-drawer-properties is obsolete. > > > These options can be applied to selected agenda views. For more > > details about generation of agenda views, see the docstrings for the > > relevant variables, and this > > [[https://orgmode.org/worg/agenda-optimization.html][dedicated Worg page]] > > for agenda > ^ (missing trailing ".") Thanks, I'll update the patch.
Re: [PATCH] Improve "Speeding Up Your Agendas" chapters
Stefan Kangas writes: > Subject: [PATCH 1/2] Move appendix on performance in manual to agenda chapter > > * doc/org-manual.org (Speeding Up Your Agendas): Move section to > chapter "Agenda Views". Does it have to be inside the main chapters of the manual? I really hope that users do not _normally_ have to know about these tricks. > Subject: [PATCH 2/2] Document org-agenda-ignore-drawer-properties in manual > > * doc/org-manual.org (Speeding Up Your Agendas): Document > org-agenda-ignore-drawer-properties. Note that org-agenda-ignore-drawer-properties is obsolete. > These options can be applied to selected agenda views. For more > details about generation of agenda views, see the docstrings for the > relevant variables, and this > [[https://orgmode.org/worg/agenda-optimization.html][dedicated Worg page]] > for agenda ^ (missing trailing ".") Best, Ihor
Re: [BUG] random org-mode warning [9.5.4 (9.5.4-g7c61a3 @ /home/cro/.emacs.default/straight/build/org/)]
Cristi Constantin writes: > Than you for the response! I tried the fix you suggested, but I still > see this: > > Warning (org-element-cache): org-element--cache: Org parser error in > 2022-log.org::179869. Resetting. > The error was: (error "Invalid search bound (wrong side of point)") This is unfortunate. I have also seen this issue recently but I cannot figure out what is the cause just yet. However, I have only seen the problem a handful of times recently. If you are still seeing the warning regularly, would you mind trying to revert 4487acc63, 93821b431, e156e5425, e5e7ae36c one by one and check if reverting solves the problem? Best, Ihor
