Re: Links to javascript-based websites from orgmode.org: Paypal and Github
briangpowell writes: > I respect your position & predicament > ... > Suggest you stay away from PayPal & ALL the other methods you > suggested--PayPal for example has been shutting down the accounts of > "freedom fighters" & can & will continue to do so whenever they wish, for > whatever reason they choose Clarification: I personally do not have legal issues with using cryprocurrencies as long as Ukrainian (which I am a citizen of) jurisdiction is considered. However, cryptocurrencies can be problematic depending on the country where you want to use the cryptocurrencies. Some countries straight ban the cryptocurrencies, some limit their usage as a payment media, some have tricky issues with taxing (for example, it is common that cryptocurrencies are considered similarly to stocks and are a subject of special/increased/multiple taxation). See https://en.wikipedia.org/wiki/Legality_of_cryptocurrency_by_country_or_territory I would be unfair if we leave no option for contributors from the countries with tricky crypto status or contributors who do not want to use crypto for other reasons (e.g. Bastien voiced against crypto). In this thread, I am not particularly concerned about the payment processor. The discussion about free software options for payment has happened a bit earlier and we concluded that we have no options involving banks (unfortunately). FSF also does not provide a legal solution as organization. At this point, I'd rather discuss the fair distribution of donations across Org contributors. AFAIK, liberapay provides a pretty decent policy on this and allows people to donate to Org developers without a need to choose whom to donate to (yet there is still an option in liberapay to donate to individual developers directly). See https://liberapay.com/about/teams Best, Ihor
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Understood Ihor I respect your position & predicament But I've published my public key address; I know you're an avid & prolific donor of free software--watch your code donations submitted daily--I'll continue to support free software forever of course & thanks very much to RMS & the FSF for starting the free software movement & supporting its growth for many years Suggest you stay away from PayPal & ALL the other methods you suggested--PayPal for example has been shutting down the accounts of "freedom fighters" & can & will continue to do so whenever they wish, for whatever reason they choose You have permission to use my name as your fake software developer "nom de guerre" & I can relay the funding to you in whatever manner you desire--PayPal is fine...until they ban me from that--notes can be made during the transaction of what the project is that you're developing or whatever & then I can relay the money I pay my taxes on crypto gains; but, if I make no money on the transaction in such a transaction, well then I owe no taxes, so I wouldn't have to worry about that--and what laws would you be violating in your country? None that I can think of Just out of curiosity: What country do you reside? Is it Russia? Last I heard Russia is accepting BitCoin for oil, right? I mean, just look what happened in Canada: Truckers used a funding site, funding site was shuttered & bank accounts seized & the list of everyone that donated was published "accidentally" If they used Monero instead, then NONE of the above problems would have manifested--Monero is as NOT trackable & its uncensorable On Sun, Jun 19, 2022 at 9:22 PM Ihor Radchenko wrote: > Richard Stallman writes: > > > > I have been recently exploring Liberapay and stumbled upon > > > https://liberapay.com/about/teams. > > > > Is it possible to make a donation through Liberapay without running > > any nonfree software? Including nonfree Javascript software send > > by the site itself? > > > > And is it possible for the intended recipients to receive the money > > without running nonfree software including JS? > > > > If the answers are yes and yes, maybe that system is ethical and good. > > Otherwise, it is not a solution, only a different variation of the > problem. > > AFAIU, no and no. See > > https://list.orgmode.org/CAFm0skG_-80iQ-TO-hduvVt_GHQWosOHBeHJ61dyA=wng8v...@mail.gmail.com/T/#m322d74a1efb4e3773ae2df7b6bda4505c4b5fa15 > > It looks like there is no free option as long as banks are involved. > > Cryptocurrencies are easier in terms of software freedom, but their > legal status is not stable (e.g. cryptocurrency is illegal in the > country I now live in). > > Best, > Ihor > >
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Richard Stallman writes: > > I have been recently exploring Liberapay and stumbled upon > > https://liberapay.com/about/teams. > > Is it possible to make a donation through Liberapay without running > any nonfree software? Including nonfree Javascript software send > by the site itself? > > And is it possible for the intended recipients to receive the money > without running nonfree software including JS? > > If the answers are yes and yes, maybe that system is ethical and good. > Otherwise, it is not a solution, only a different variation of the problem. AFAIU, no and no. See https://list.orgmode.org/CAFm0skG_-80iQ-TO-hduvVt_GHQWosOHBeHJ61dyA=wng8v...@mail.gmail.com/T/#m322d74a1efb4e3773ae2df7b6bda4505c4b5fa15 It looks like there is no free option as long as banks are involved. Cryptocurrencies are easier in terms of software freedom, but their legal status is not stable (e.g. cryptocurrency is illegal in the country I now live in). Best, Ihor
[BUG] Adding note to heading without newline at the end
Consider the following buffer #+begin_example * test #+end_example without a newline at the end. Calling `org-add-note' will result in an error and the note being placed /before/ the heading.
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Yuge fan of RMS, Richard M Stallman & the OrgMode community--long time user of GNU software & OrgMode As always, much agree with RMS But, suggest donations to support free software be made using Monero--I use the open source "MyMonero" wallet software; its cryptocurrency software--its free & open source & donors can make uncensorable donations as privately as they would like in a currency that cannot be seized by banksters or the NWO NaZi governments running things to hell right now All a software engineer need do is publish a public key number Here's mine for example: 42JjWPnWmWYQaLmtnDyMjC8sCG6YmZ1ViTiJfHWZrSbKfuMWQ27qduYHttrsxYRCyf4UHbFAWQk4y4nTfuUf2jfGD7LWzne On Sun, Jun 19, 2022 at 11:54 AM Richard Stallman wrote: > [[[ 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. ]]] > > > I have been recently exploring Liberapay and stumbled upon > > https://liberapay.com/about/teams. > > Is it possible to make a donation through Liberapay without running > any nonfree software? Including nonfree Javascript software send > by the site itself? > > And is it possible for the intended recipients to receive the money > without running nonfree software including JS? > > If the answers are yes and yes, maybe that system is ethical and good. > Otherwise, it is not a solution, only a different variation of the problem. > > -- > 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: Orgmode plain list bullet : change automatically with list depth
Edouard Debry writes: > Are you sure bullet lists are irrelevant to org ? > > I tried without success to make a list without "-" or "+" in my > *scratch*. > Sorry, I wasn't clear enough. The 'marker' which is at the start of a list item is important to org. What isn't important is the type of list marker i.e. '-', '+', and '*' are all the same token which designate the start of a list item when the first character of an indented line. There is no relationship to item nesting depth. The point I was trying to make is that the token when used to convey other meanings, like nesting depth, sits at the 'human' layer and therefore, should be 'tweaked' using font-lock i.e. if you want different tokens to mark different list nesting levels, use font-lock to adjust the appearance of the token at each level rather than changing underlying syntax to give '-', '+' and '*' additional meanings they don't have at the code layer now. This also has the advantage of not imposing a specific use for different tokens on all users i.e. some users might want to use all 3 tokens in a list, but not simply to reflect nesting levels. The disadvantage of using font-lock is that currently, defining the regular expression can be hard. However, I think other work being done to allow font-lock to leverage off information supplied by the parser might simplify that situation. So to be clear, I was not saying that the ability to have different characters to represent different nesting depth in lists was misguided, only implementing that as part of the syntax and having org enforce it with actual characters in the file was. Remapping to a different character for display purposes based on the depth of the list item is perfectly fine and in-line with similar techniques to do things like replacing multiple '*' in headers with different single unicode characters (like the various 'bullets' packages do).
Re: About 'inline special blocks'
Juan Manuel Macías writes:
> To add some ideas that have been occurring to me these days...
>
> I am more and more convinced that inline special blocks, by their
> nature, should not support fine tune options or anything like
> attr_latex, attr_html, etc. like its older brothers, as it would produce
> an overly complicated syntax. Big brothers are independent of the
> paragraph and there it makes sense to add lines with attr_latex, etc.,
> since it is a line-oriented syntax. Bringing that into the paragraph is
> unnecessarily overloading the paragraph and breaking the social contract
> of lightweight markup, where paragraphs should still look like
> paragraphs.
>
Agree. I think your reasoning here is spot on.
> Another argument against possible fine-tuning within inline special
> blocks, for export purposes, is that (in my opinion) direct formatting
> is a practice that should be avoided as much as possible in a document.
> A document with a lot of direct formatting is an inconsistent document.
> In html, all possible formatting should be controlled by style sheets;
> in LaTeX, by (re)defining macros, commands and environments in the
> preamble or in a .sty file; in odt using character styles.
>
Agreed. In fact, I use in-line blocks so rarely that at first I wasn't
going to respond as I really didn't have much skin in the game when it
comes to inline blocks. The reason I dond't use them much is pretty much
the same as your reasoning above.
> Perhaps if we detach special blocks from fine-tuning possibilities we
> lose some (export) flexibility, but we gain in a clearer implementation
> of these elements and keep Org aseptic about the output format. And in
> any case, if someone needs a fine-tuning in a certain case, there are
> always the export filters. Or it can be implemented in a similar way to
> inline tasks, with a default format function (for html, latex, etc),
> which can be changed via a defcustom.
>
I also like this approach. We need some form of escape hatch. However,
for uncommon edge cases, I would rather have a slightly less convenient
escape hatch and a simple consistent general syntax than a more complex
syntax which is difficult to maintain and keep consistent and reliable.
> Starting from that, a syntax like this in Org:
>
> %[name]{contents}
>
> Would produce in LaTeX, by default:
>
> \name{contents}
>
> in html:
>
> contents>
or should that be contents?
>
> in odt:
>
> contents
>
> and so on.
>
> In short, I think it would be enough to simply implement something like
> this.
>
Sound reasoning IMO.
Re: About 'inline special blocks'
Hi, Christian,
Thanks for your comments.
Christian Moe writes:
> Hi,
>
> This makes sense to me.
>
> Note: For the html output in your example, I expect you don't mean
> contents>, but contents. That
> would give the desired custom style controle of the output, and would
> parallel the behavior of special blocks.
You are absolutely right, it is my fault. These days I'm doing a work
with a lot of xml, and I've mixed things up in my head :-). In html the
expected form is as you say. Apologize for the confusion.
> If "inline special blocks" will be able to nest, they will have an
> advantage over org macros, which cannot.
>
> Apart from nesting, an org macro could do the same job, but less
> elegantly. The suggested inline syntax would not require commas to be
> escaped in the contents. And it would be somewhat more concise and far
> more legible, as illustrated in the below example (with working macros,
> imagined inline special blocks, and a CSS implementation):
>
> #+begin_example
> #+macro: fmt @@html: class="$1">$2latex:\$1{$2}odt: text:style-name="$1">$2@@
> #+html_head: .highlight {background-color: yellow;}
> #+html_head:.smallcaps {font-variant: small-caps;}
>
> This is some {{{fmt(highlight, highlighted text)}}} and this is some
> {{{fmt(smallcaps, text in small caps)}}}.
>
> This is some %[highlight]{highlighted text} and this is some
> %[smallcaps]{text in small caps}.
> #+end_example
I have used macros a lot in the past for these purposes. But the problem
of having to escape commas and the somewhat confusing (and ugly) syntax
of macros has led me to rarely use them now. Links have been a good
replacement for me, but they still have their limitations (the most
important, as Ihor commented, not being able to include a link within
the description. But we can't put footnotes either). I actually think
that inline special blocks could be tremendously useful and versatile.
And, in syntactic terms, an important point in favor of Org against
Markdown, which if I'm not mistaken does not have anything similar (I
hardly use md, so I'm not very aware).
Best regards,
Juan Manuel
Re: About 'inline special blocks'
Juan Manuel Macías writes:
> To add some ideas that have been occurring to me these days...
>
Hi,
This makes sense to me.
Note: For the html output in your example, I expect you don't mean
contents>, but contents. That
would give the desired custom style controle of the output, and would
parallel the behavior of special blocks.
If "inline special blocks" will be able to nest, they will have an
advantage over org macros, which cannot.
Apart from nesting, an org macro could do the same job, but less
elegantly. The suggested inline syntax would not require commas to be
escaped in the contents. And it would be somewhat more concise and far
more legible, as illustrated in the below example (with working macros,
imagined inline special blocks, and a CSS implementation):
#+begin_example
#+macro: fmt @@html:$2latex:\$1{$2}odt:$2@@
#+html_head: .highlight {background-color: yellow;}
#+html_head:.smallcaps {font-variant: small-caps;}
This is some {{{fmt(highlight, highlighted text)}}} and this is some
{{{fmt(smallcaps, text in small caps)}}}.
This is some %[highlight]{highlighted text} and this is some
%[smallcaps]{text in small caps}.
#+end_example
Yours,
Christian
> I am more and more convinced that inline special blocks, by their
> nature, should not support fine tune options or anything like
> attr_latex, attr_html, etc. like its older brothers, as it would produce
> an overly complicated syntax. Big brothers are independent of the
> paragraph and there it makes sense to add lines with attr_latex, etc.,
> since it is a line-oriented syntax. Bringing that into the paragraph is
> unnecessarily overloading the paragraph and breaking the social contract
> of lightweight markup, where paragraphs should still look like
> paragraphs.
>
> Another argument against possible fine-tuning within inline special
> blocks, for export purposes, is that (in my opinion) direct formatting
> is a practice that should be avoided as much as possible in a document.
> A document with a lot of direct formatting is an inconsistent document.
> In html, all possible formatting should be controlled by style sheets;
> in LaTeX, by (re)defining macros, commands and environments in the
> preamble or in a .sty file; in odt using character styles.
>
> Perhaps if we detach special blocks from fine-tuning possibilities we
> lose some (export) flexibility, but we gain in a clearer implementation
> of these elements and keep Org aseptic about the output format. And in
> any case, if someone needs a fine-tuning in a certain case, there are
> always the export filters. Or it can be implemented in a similar way to
> inline tasks, with a default format function (for html, latex, etc),
> which can be changed via a defcustom.
>
> Starting from that, a syntax like this in Org:
>
> %[name]{contents}
>
> Would produce in LaTeX, by default:
>
> \name{contents}
>
> in html:
>
> contents>
>
> in odt:
>
> contents
>
> and so on.
>
> In short, I think it would be enough to simply implement something like
> this.
>
> Best regards,
>
> Juan Manuel
Re: Elisp assertion for debugging
Ypo writes: > I am trying to debug my init file: C-u prefix is not working. > > I am using the elisp-bug-hunter package that has saved me many times in > the past. But it doesn't work fine this time though, so it seems I need > an “assertion elisp” to debug my init file. > > What elisp expression would return nil when C-u prefix works and non-nil > when C-u prefix doesn't work? > > I have tried > > (eq (key-binding "C-u C-SPC") 'nil) > > but it is probably a nonsense. > > Best regards This might work: (unless (eq 'universal-argument (keymap-lookup global-map "C-u")) (error "C-u has been redefined")) Note that you don't need to quote nil: 'nil = nil Also, this question is not really about org-mode; posting to the emacs mailing list might increase your chance to get a good answer. Best regards,
Elisp assertion for debugging
I am trying to debug my init file: C-u prefix is not working. I am using the elisp-bug-hunter package that has saved me many times in the past. But it doesn't work fine this time though, so it seems I need an “assertion elisp” to debug my init file. What elisp expression would return nil when C-u prefix works and non-nil when C-u prefix doesn't work? I have tried (eq (key-binding "C-u C-SPC") 'nil) but it is probably a nonsense. Best regards
Re: Keybinding doubt about ARG
Ypo writes: > Working, thanks Bruno! > Thanks for the feedback. > I needed it, because what I was using is not working well: > > (global-set-key (kbd "M-n") (kbd "C-u 1 C-v")) FWIW, your previous method works for me in org mode buffers (emacs 28 -Q and my custom emacs 29 with custom org). And: (define-key global-map (kbd "M-n") (kbd "C-u 1 C-v")) works too. Best regards, > From some time ago, it doesn't work in .org buffers, although it works > in elisp buffers. > > In .org buffers I receive this message: > > After 0 kbd macro iterations: command-execute: Keyboard macro terminated > by a command ringing the bell > > Best regards > > El 19/06/2022 a las 18:49, Bruno Barbier escribió: >> Ypo writes: >> >>> Is it possible to use ARG when defining keybindings? >>> >>> For the command (scroll-up-command ARG) I want to define this >>> keybind: >>> >>> >>> (define-key global-map (kbd "M-n") 'scroll-up-command 1) >>> >>> >>> But: >>> >>> eval-region: Wrong number of arguments: define-key, 4 >> I don't think that 'define-key' allows to specify extra arguments. >> >> But, you can easily define your own command. >> >> (defun my-scroll-up-of-1 () >>(interactive) >>(scroll-up-command 1)) >> >> (define-key global-map (kbd "M-n") 'my-scroll-up-of-1) >>
Re: Keybinding doubt about ARG
Bruno Barbier writes: > But, you can easily define your own command. > > (defun my-scroll-up-of-1 () > (interactive) > (scroll-up-command 1)) > > (define-key global-map (kbd "M-n") 'my-scroll-up-of-1) Or simply doing something like: (define-key global-map (kbd "M-n") (lambda () (interactive) (scroll-up-command 1))) Best regards, Juan Manuel
Re: Is ob-latex maintained ?
Aloha Edouard, According to the table of core languages supported by Babel, https://orgmode.org/worg/org-contrib/babel/languages/index.html, there is no maintainer for ob-latex. The information in the table is taken from the ob-*.el files, which indicate a maintainer if there is one. hth, Tom Edouard Debry writes: Indeed, you can make the src block work (produce a png) by adding imagemagick in the src block. It works because the generation process is completely different. But my main concern is that there is a bug in "ob-latex" : when you want to produce a png without imagemagick, either it does not work, although it should, or it produces a svg ! By the way, I did ask on this mailing list a previous question about generating svg from tikz/latex src blocks. It did not work with imagemagick, but it works well without (also with htlatex), provided your default settings is 'dvisvgm. This is also why I wonder if there is a maintainer for "ob-latex", such previously mentioned bug should/could be corrected. Regards "Fraga, Eric" writes: On Friday, 17 Jun 2022 at 13:48, DEBRY.Edouard wrote: Unfortunately not. If I remember well, this setting is for math environments, whether you want to preview them as png or svg, it does not work for src blocks. Well, my src blocks work although I use imagemagick and then have the following extra settings for the LaTeX src blocks: #+property: header-args:latex :fit yes :results file :exports results #+property: header-args:latex+ :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry 1200 If you have ImageMagick installed, maybe try this? -- Thomas S. Dye https://tsdye.online/tsdye
Re: Keybinding doubt about ARG
Working, thanks Bruno! I needed it, because what I was using is not working well: (global-set-key (kbd "M-n") (kbd "C-u 1 C-v")) From some time ago, it doesn't work in .org buffers, although it works in elisp buffers. In .org buffers I receive this message: After 0 kbd macro iterations: command-execute: Keyboard macro terminated by a command ringing the bell Best regards El 19/06/2022 a las 18:49, Bruno Barbier escribió: Ypo writes: Is it possible to use ARG when defining keybindings? For the command (scroll-up-command ARG) I want to define this keybind: (define-key global-map (kbd "M-n") 'scroll-up-command 1) But: eval-region: Wrong number of arguments: define-key, 4 I don't think that 'define-key' allows to specify extra arguments. But, you can easily define your own command. (defun my-scroll-up-of-1 () (interactive) (scroll-up-command 1)) (define-key global-map (kbd "M-n") 'my-scroll-up-of-1)
Re: Keybinding doubt about ARG
Ypo writes: > Is it possible to use ARG when defining keybindings? > > For the command (scroll-up-command ARG) I want to define this > keybind: > > > (define-key global-map (kbd "M-n") 'scroll-up-command 1) > > > But: > > eval-region: Wrong number of arguments: define-key, 4 I don't think that 'define-key' allows to specify extra arguments. But, you can easily define your own command. (defun my-scroll-up-of-1 () (interactive) (scroll-up-command 1)) (define-key global-map (kbd "M-n") 'my-scroll-up-of-1)
Re: [BUG] Could not resolve host: updates.orgmode.org
Ihor Radchenko writes: >> dig @9.9.9.9 updates.orgmode.org >> is not returning any record, and I'm not able to open >> https://updates.orgmode.org/ > > Confirmed. > > Bastien? Fixed -- a mistake I made yesterday, sorry for the inconvenience. Thanks for the heads up! PS: DNS are propagating, it may take a few hours to be available everywhere. -- Bastien
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. ]]] > I have been recently exploring Liberapay and stumbled upon > https://liberapay.com/about/teams. Is it possible to make a donation through Liberapay without running any nonfree software? Including nonfree Javascript software send by the site itself? And is it possible for the intended recipients to receive the money without running nonfree software including JS? If the answers are yes and yes, maybe that system is ethical and good. Otherwise, it is not a solution, only a different variation of the problem. -- 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)
Keybinding doubt about ARG
Is it possible to use ARG when defining keybindings? For the command (scroll-up-command ARG) I want to define this keybind: (define-key global-map (kbd "M-n") 'scroll-up-command 1) But: eval-region: Wrong number of arguments: define-key, 4
Re: Proposal: 'executable' org-capture-templaes
Max Nikulin writes: > On 18/06/2022 22:05, Arthur Miller wrote: >> Max Nikulin writes: >>> On 11/06/2022 12:26, Ihor Radchenko wrote: Max Nikulin writes: > Imagine what would happen if Emacs decided to show several capture menus > with keymap non-blocking interface in different virtual desktops. >> Different Emacs processes, or just different Emacs frames? > > I mean single Emacs process perhaps with multiple frames spread over monitors > and virtual desktops. I am unsure if Emacs can create windows for different > X11 > displays, but let's leave it aside and inter-process file locks as well. Allright then; in that case what Ihor suggests, a variable somewhere, should do. I suggest that variable be the capture buffer itself. I'll try to implement this in a day or two; just need some time from other things in life. >> In case of different Emacs processes, there is no way to guarantee >> consistence >> unless one locks file in the file system. Windows can do it, I am not sure >> what >> is Linux API to do this, don't know if Emacs exposes this functionality, have >> never tried. >> Otherewise, if it is only different Emacs frames/clients, the capture should >> always find the capture buffer and return that one instead of creating new >> ones. That way there is only one capture buffer, so multiple captures should >> not >> be possible, i.el, it creates same effect as locking the input to >> minibuffer. I >> am not sure how org-capture does, I haven't studied the code in-depth yet, >> but >> what I see currently a user cancels it with C-c C-k. org-capture buffer could >> setup hooks to clean everything, even if user kills buffer by other means, >> c-x >> k, or whatever. It maybe already does, as said I haven't looked at those >> details. > > Arthur, be reasonably skeptical concerning my ideas or suggestions, it seems I > have not managed to convince e.g. Ihor. :-). I think this would be quite a big and radical change in some important parts of Org, so I really want to make sure that a fundamental error does not happen. It would be a horrible thing if someones file with maybe lots of data from the past gets messed up. That must not happen, so I really value the input and would like to make sure use cases we have to take care of. > I believe, multiple capture menus should be possible in parallel even within > single frame since it may contain several windows and user experience should > be > better than now. Keymap-based selection opens a road in this direction since > menu may be non-modal, but it requires a bit different design. That sounds like a new feature. You are correct, keymaps do open in that direction. That would be possible to tuck on the routine that saves the temporary buffer (whatever is called with C-c C-c). When user press C-c C-c in a capture buffer, that is the only time when interaction with real a file on the disk happends, right? Everythign else is done in a temporary buffer in ram. User can physically press it only in one capture buffer, so it least in theory, multiple capture shouldn't be impossible or too hard to implement. But, lets do it after the rework of the menu thing? > Waiting for return value to get capture template is not possible any more. A > kind of continuations should be passed to the function creating menu buffer > instead. E.g. it can be some state object that stores snapshot of data > necessary > to fill capture template, export options, etc. and functions in menu entries > that accept this state object as argument or obtain it from a dynamic > variable. The state object likely should be a buffer-local variable. For > non-blocking menu, entries should contain callbacks or menu may have single > callback that is able to process static data from menu entries. I happened to send the code yesterday by misstake only to one participant, unfortunately, it wasn't ment; I seem to have pressed S w instead of S W and wasn't looking at the address on top, so unfortunately you probably haven't seen the code. However I have to rework it again because I did a bit bad design in handling of one feature; I'll try to do it tomorrow. However the idea is that the selection menu framework have no idea who is calling it and why. It can not possibly know that either. It is entirely up to the caller, so for that reason a caller can setup a handler that gets entire template passed back and can do what it wants with it. Current org-mks & Co don't really know who is calling than and why, but locking happens automatically due to nature how the input is read (via minibuffer). In case of new menu handling, the client has to do locking on its own, so it is a bit more extra, but client can just buffer-get-create to get an existing buffer before calling org-select, so it shouldn't be too much of the work. I think. I'll test tomorrow or so. > As a result, capture can not be processed till filling of a template (and so > till adding it to the target buffer) within a
Re: Orgmode plain list bullet : change automatically with list depth
Thanks for your information complement. Indeed, I know too few about
emacs to guess that by myself.
And it works !
For anyone interested, here are the settings :
(font-lock-add-keywords 'org-mode
'(("^ *\\([-]\\) "
(0 (let* ((depth (org-list--depth (save-match-data
(org-element-at-point
(bullet (cond ((= depth 1) "●")
((= depth 2) "◆")
((= depth 3) "▪")
((= depth 4) "▸")
((= depth 5) "•")
((= depth 6) "↪")
(t "↪"
(prog1 () (compose-region (match-beginning 1)
(match-end 1) bullet)))
Many thanks for your help.
Regards
Ihor Radchenko writes:
> Edouard Debry writes:
>
>> The key point is the regexp. I do not know if it is possible to capture
>> the depth level with a regexp. That is why I tried to use
>> org-list--depth in :
>>
>> ...
>> but it seems that "org-element-at-point" messes things.
>
> Sorry, I though that I gave you enough information to fix the issue.
>
> Just wrap (org-element-at-point) into save-match-data:
> (save-match-data (org-element-at-point))
>
> That's it.
>
> P.S. I actually plan to fix `org-element-at-point' modifying match data
> (which is not documented), but it will probably be a part of a bigger
> font-lock-related patchset.
>
> Best,
> Ihor
Re: Creating animated gif from latex src blocks
Here is what I am able to do :
- write a latex src block with several tikz blocks inside (as described
in the tex.stackexchange link)
- export in a gif with pdf+imagmagick
- open the gif in emacs and start the animation
- insert the gif into the org file and start animation
But there is a trick for this to work, the default latex header is
"\\documentclass{article} ...", which fails but, replacing it
by "\\documentclass[tikz]{standalone} ..." succeeds.
Regards
"Fraga, Eric" writes:
> On Saturday, 18 Jun 2022 at 00:26, Edouard Debry wrote:
>> As a matter of fact, you can, but I will check out the latex package you
>> mentioned
>>
>> "Fraga, Eric" writes:
>>
>>> Check out the animate LaTeX package. I don't believe you can create
>>> such the actual animation from tikz itself.
>
> Clarification: I believe(d) that you cannot generate an animated GIF;
> animation is possible, of course. But if you can generate an animated
> GIF directly from tikz, please let me know how as it would be useful in
> some cases.
>
> Thank you,
> eric
Re: Orgmode plain list bullet : change automatically with list depth
Edouard Debry writes: > The key point is the regexp. I do not know if it is possible to capture > the depth level with a regexp. That is why I tried to use > org-list--depth in : > > ... > but it seems that "org-element-at-point" messes things. Sorry, I though that I gave you enough information to fix the issue. Just wrap (org-element-at-point) into save-match-data: (save-match-data (org-element-at-point)) That's it. P.S. I actually plan to fix `org-element-at-point' modifying match data (which is not documented), but it will probably be a part of a bigger font-lock-related patchset. Best, Ihor
Re: Orgmode plain list bullet : change automatically with list depth
What I am looking forward to is
1) not modifying the true "bullet" in the raw text, it will always be
"-" I just want the appearance to look "nicer"
2) having a bullet appearance level depth specific, e.g.
▪ this is first level of a list
▪ still first level
➤ this is the second level
➤ this is again the second level
• a third level
➤ yet another second level
which means that de facto a specific bullet appearance would be
associated to a specifc list level depth, e.g. • is 3, ▪ is 1 (I assume
index begins at 1 ?)
Built like this, putting this list into the first level of another one
would shift all levels depth by +1 and consequently change the
appearance.
Currently, appearance is changed by :
(font-lock-add-keywords 'org-mode
'(("^ *\\([-]\\) "
(0 (prog1
()
(setq bullet "•")
(compose-region (match-beginning 1) (match-end
1) bullet))
The key point is the regexp. I do not know if it is possible to capture
the depth level with a regexp. That is why I tried to use
org-list--depth in :
(font-lock-add-keywords 'org-mode
'(("^ *\\([-]\\) "
(0 (let* ((depth (org-list--depth
(org-element-at-point)))
(bullet (cond ((= depth 1) "•")
((= depth 2) "▸")
(t "-"
(prog1 () (compose-region (match-beginning 1)
(match-end 1) bullet)))
but it seems that "org-element-at-point" messes things.
Samuel Wales writes:
> sure.
>
> iiuc i think op wants 2 things:
>
> 1] graphical bullets. i.e. not the - + etc. that are in the org
> plain text as saved to disk.
> 2] each level of a list to have the same bullet style
>
> examples of 2]:
>
> a conforming list:
>
> - this is level 1. for this list, we always want level 1 to
> use the - bullet style in the org plain text.
> + this is level 2. for this list, we always want level 2
> to use the + bullet style in the org plain text.
> + another level 2
> - another level 1
> + another level 2
> + the + is CONSISTENT with the + in the level 2 of the
> previous list item
>
> a non-conforming list:
>
> - this is level 1. for this list, we always want level 1 to
> use the - bullet style in the org plain text.
> + this is level 2. for this list, we always want level 2
> to use the + bullet style in the org plain text.
> + another level 2
> - another level 1
> * another level 2
> * these * markers are INCONSISTENT with the + markers in
> the level 2 previous list item.
>
> the idea is for org [as opposed to fontification] to enforce this
> level correspondence. whenever we do a bullet style change at any
> level, org could change ALL BULLETS AT THE SAME LEVEL. this keeps the
> list conforming.
>
> currently, org does not do this. instead, it allows you to
> say that /demotion/ makes a + when you have a -. but
> without enforcement, the list can quickly become
> non-conforming after the user edits it.
>
> this idea is independent (orthogonal) to fontification /
> displayed graphical glyph. i think op's 2] idea can make
> sense. and then fontification / displayed graphical glyph
> can be done perhaps with a fontification package.
>
> in any case, fontification can merely say that + looks
> like or so. orthogonal to levels.
>
> On 6/17/22, Ihor Radchenko wrote:
>> Samuel Wales writes:
>>
>>> i wonder if org could do the semantics in the text, while
>>> fontification could do the appearance only.
>>>
>>> org allows you to change the bullet style [real text bullets rather
>>> than fontification] upon demotion.
>>>
>>> thus, you can have it consistent that demoting + from top level will
>>> create - on level 2 for 1 item. until you change it.
>>>
>>> but org does not enforce by level. so you can't keep the results of
>>> your demotion strategy in the rest of the list. an enforced scheme
>>> would have it so that a change to new bullet style at a level, or
>>> level 1 otherwise, would style that level.
>>
>> Could you please provide an example. I do not understand what you are
>> trying to suggest.
>>
>> Best,
>> Ihor
>>
Re: Orgmode plain list bullet : change automatically with list depth
Are you sure bullet lists are irrelevant to org ? I tried without success to make a list without "-" or "+" in my *scratch*. Regards Tim Cross writes: > Samuel Wales writes: > >> sure. >> >> iiuc i think op wants 2 things: >> >> 1] graphical bullets. i.e. not the - + etc. that are in the org >> plain text as saved to disk. >> 2] each level of a list to have the same bullet style >> >> >> examples of 2]: >> >> a conforming list: >> >> - this is level 1. for this list, we always want level 1 to >> use the - bullet style in the org plain text. >> + this is level 2. for this list, we always want level 2 >> to use the + bullet style in the org plain text. >> + another level 2 >> - another level 1 >> + another level 2 >> + the + is CONSISTENT with the + in the level 2 of the >> previous list item >> >> >> a non-conforming list: >> >> >> - this is level 1. for this list, we always want level 1 to >> use the - bullet style in the org plain text. >> + this is level 2. for this list, we always want level 2 >> to use the + bullet style in the org plain text. >> + another level 2 >> - another level 1 >> * another level 2 >> * these * markers are INCONSISTENT with the + markers in >> the level 2 previous list item. >> >> >> the idea is for org [as opposed to fontification] to enforce this >> level correspondence. whenever we do a bullet style change at any >> level, org could change ALL BULLETS AT THE SAME LEVEL. this keeps the >> list conforming. >> >> currently, org does not do this. instead, it allows you to >> say that /demotion/ makes a + when you have a -. but >> without enforcement, the list can quickly become >> non-conforming after the user edits it. >> >> this idea is independent (orthogonal) to fontification / >> displayed graphical glyph. i think op's 2] idea can make >> sense. and then fontification / displayed graphical glyph >> can be done perhaps with a fontification package. >> >> in any case, fontification can merely say that + looks >> like or so. orthogonal to levels. >> >> > > Sorry, but I think this idea is misguided. > > The 'bullets' in lists are largely irrelevant to org. Lists are > determined by the indentation level. I don't think org actually cares > about wither an item starts with '-', '+', or '*'. I also don't think it > matters (from an org perspective) if a list has a mix of different > bullets. This might be 'offensive' for users, but is largely irrelevant > for org. > > This means the questions now becomes "Do we add the additional complexity > and possible performance hit to enforce bullet consistency?" and "Are > there any use cases where people might want different bullets at the > same level in a list?". > > As having mixed bullets does not impact on org export, I'm inclined to > leave this as a user issue i.e. if you want things to be consistent, > then be consistent. The current behaviour I think is pretty good i.e. if > you start using a different bullet, new items at the same level will use > that bullet and when you shift an item to be at the parent level, it > will change the bullet to be the same as the parents. If you indent an > item, it will use the same bullet as the parent, but you can change it > and then all additional items at that level will use the same bullet. > > As the bullet type has no baring on org's processing of lists, I think > this is a purely presentation issue and therefore anything we want to do > wrt enforcement should in fact occur at the font-lock layer. e.g. allow > code which will just set the bullet to some preferred mapping based on > level. As the user won't see which 'real' character is being used, it > won't matter if it uses mixed bullet styles. This also has the advantage > that the user can just use the one bullet 'type' and see different > bullet rendering based on level, so you won't have any 'inconsistency' > anyway as all entries just use the same bullet.
Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)
On Sat, Jun 18, 2022 at 11:31 PM David Lukeš wrote: > > > I suspect that multiple json formats may be available in the wild. Some > > parsed as a list of strings and some parsed as a list of numbers. > > > The JSON schema allows either: > > Ah, thanks for looking this up! I created CSL, and have helped develop the data schema. BTW, just to look forward, it's likely we'll change the date property to prefer an EDTF string; same as biblatex does now. Bruce
Re: Is ob-latex maintained ?
Indeed, you can make the src block work (produce a png) by adding imagemagick in the src block. It works because the generation process is completely different. But my main concern is that there is a bug in "ob-latex" : when you want to produce a png without imagemagick, either it does not work, although it should, or it produces a svg ! By the way, I did ask on this mailing list a previous question about generating svg from tikz/latex src blocks. It did not work with imagemagick, but it works well without (also with htlatex), provided your default settings is 'dvisvgm. This is also why I wonder if there is a maintainer for "ob-latex", such previously mentioned bug should/could be corrected. Regards "Fraga, Eric" writes: > On Friday, 17 Jun 2022 at 13:48, DEBRY.Edouard wrote: >> Unfortunately not. >> >> If I remember well, this setting is for math environments, whether you >> want to preview them as png or svg, it does not work for src blocks. > > Well, my src blocks work although I use imagemagick and then have the > following extra settings for the LaTeX src blocks: > > #+property: header-args:latex :fit yes :results file :exports results > #+property: header-args:latex+ :imagemagick yes :iminoptions -density 600 > :imoutoptions -geometry 1200 > > If you have ImageMagick installed, maybe try this?
Re: [BUG] Could not resolve host: updates.orgmode.org
Bhavin Gandhi writes: > updates.orgmode.org doesn't seem to have any DNS record (A or CNAME)? > > dig @9.9.9.9 updates.orgmode.org > is not returning any record, and I'm not able to open > https://updates.orgmode.org/ Confirmed. Bastien?
Re: About 'inline special blocks'
To add some ideas that have been occurring to me these days...
I am more and more convinced that inline special blocks, by their
nature, should not support fine tune options or anything like
attr_latex, attr_html, etc. like its older brothers, as it would produce
an overly complicated syntax. Big brothers are independent of the
paragraph and there it makes sense to add lines with attr_latex, etc.,
since it is a line-oriented syntax. Bringing that into the paragraph is
unnecessarily overloading the paragraph and breaking the social contract
of lightweight markup, where paragraphs should still look like
paragraphs.
Another argument against possible fine-tuning within inline special
blocks, for export purposes, is that (in my opinion) direct formatting
is a practice that should be avoided as much as possible in a document.
A document with a lot of direct formatting is an inconsistent document.
In html, all possible formatting should be controlled by style sheets;
in LaTeX, by (re)defining macros, commands and environments in the
preamble or in a .sty file; in odt using character styles.
Perhaps if we detach special blocks from fine-tuning possibilities we
lose some (export) flexibility, but we gain in a clearer implementation
of these elements and keep Org aseptic about the output format. And in
any case, if someone needs a fine-tuning in a certain case, there are
always the export filters. Or it can be implemented in a similar way to
inline tasks, with a default format function (for html, latex, etc),
which can be changed via a defcustom.
Starting from that, a syntax like this in Org:
%[name]{contents}
Would produce in LaTeX, by default:
\name{contents}
in html:
contents>
in odt:
contents
and so on.
In short, I think it would be enough to simply implement something like
this.
Best regards,
Juan Manuel
[BUG] Could not resolve host: updates.orgmode.org
updates.orgmode.org doesn't seem to have any DNS record (A or CNAME)? dig @9.9.9.9 updates.orgmode.org is not returning any record, and I'm not able to open https://updates.orgmode.org/ -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: Proposal: 'executable' org-capture-templaes
On 18/06/2022 15:25, Ihor Radchenko wrote: Max Nikulin writes: Note that there is not much happening when capture menu is called. Only the link is stored into link ting. Otherwise, no capture data is altered. All the fragile staff is happening after selecting capture template. Ihor, magic is impossible. If several captures may be requested in parallel then snapshot of data required to fill capture template should be stored somewhere at the moment when capture is initiated. Otherwise the user may kill the buffer she is going to capture before selecting particular template. Sure. That somewhere can be buffer-local variable inside the capture menu buffer. Or global variable. Or closure. How is it relevant to the capture menu? Before menu buffer is created, caller can not assign a buffer-local variable. So to be transparent for snapshot of capture data, menu should support such variable and should pass it further when template is chosen. Otherwise the capture data may be lost with temporary buffer. The function calling menu should gather values from all variables necessary for capture to build some state passed to menu implementation. Of course, using global variables will limit things to a single capture, but it just means that if a user starts capture, leaves the capture menu buffer, and then starts another capture, only the last capture will be handled. Just like we have now. Now user may leave capture menu by either selection of a template or by aborting menu. In the case of keymap-based menu there is no such restriction, so org-capture and menu implementation should be adjusted in some way to avoid bad surprises for users. Currently several capture menu instances may be requested though org-protocol (or calling org-capture from emacsclient). The behavior is rather confusing. New menu may help to fix the issue, that is why I raised the question about parallel captures.
Re: Proposal: 'executable' org-capture-templaes
On 18/06/2022 22:05, Arthur Miller wrote: Max Nikulin writes: On 11/06/2022 12:26, Ihor Radchenko wrote: Max Nikulin writes: Imagine what would happen if Emacs decided to show several capture menus with keymap non-blocking interface in different virtual desktops. Different Emacs processes, or just different Emacs frames? I mean single Emacs process perhaps with multiple frames spread over monitors and virtual desktops. I am unsure if Emacs can create windows for different X11 displays, but let's leave it aside and inter-process file locks as well. In case of different Emacs processes, there is no way to guarantee consistence unless one locks file in the file system. Windows can do it, I am not sure what is Linux API to do this, don't know if Emacs exposes this functionality, have never tried. Otherewise, if it is only different Emacs frames/clients, the capture should always find the capture buffer and return that one instead of creating new ones. That way there is only one capture buffer, so multiple captures should not be possible, i.el, it creates same effect as locking the input to minibuffer. I am not sure how org-capture does, I haven't studied the code in-depth yet, but what I see currently a user cancels it with C-c C-k. org-capture buffer could setup hooks to clean everything, even if user kills buffer by other means, c-x k, or whatever. It maybe already does, as said I haven't looked at those details. Arthur, be reasonably skeptical concerning my ideas or suggestions, it seems I have not managed to convince e.g. Ihor. I believe, multiple capture menus should be possible in parallel even within single frame since it may contain several windows and user experience should be better than now. Keymap-based selection opens a road in this direction since menu may be non-modal, but it requires a bit different design. Waiting for return value to get capture template is not possible any more. A kind of continuations should be passed to the function creating menu buffer instead. E.g. it can be some state object that stores snapshot of data necessary to fill capture template, export options, etc. and functions in menu entries that accept this state object as argument or obtain it from a dynamic variable. The state object likely should be a buffer-local variable. For non-blocking menu, entries should contain callbacks or menu may have single callback that is able to process static data from menu entries. As a result, capture can not be processed till filling of a template (and so till adding it to the target buffer) within a single function. Instead first function prepares set of callbacks and renders a buffer with menu. When user activates a menu entry, a callback either just modifies the state object to change some option or starts some action (fills capture template and inserts result to the target document) and notifies caller that the menu should be destroyed. E.g. if some special symbol is returned from the menu entry callback than it means change of some option, so menu should be retained, otherwise it is action and the menu buffer is not necessary any more. So despite I earlier opposed to executable menu entries, they are quite natural way to implement non-blocking menu. State object specific to menu instance should be added in some way convenient for developers. More work may be necessary however to make org-capture really convenient and reliable. Capture menu should display some summary of captured data otherwise it is impossible to decide which template should be chosen in the case of several simultaneous capture buffers. It is better to save capture data somewhere on disk while while menu is displayed to recover it after a crash. I agree with you that completing read is a good alternative, but it is a bit like discussion about GUI vs. terminal. I am personally heavy user of Helm, but not everyone is I believe. I mentioned completing-read because I consider it as a test of API quality. It should be possible to plug alternative menu implementation and completing read may be a simple enough variant. It is blocking, but in the case of capture "push to capture queue" could be used to postpone the action. P.S. Notice text properties for entries in the following modal menu: Timothy to emacs-orgmode. [PATCH] New remote resource download policy. Sun, 12 Jun 2022 22:43:07 +0800. https://list.orgmode.org/87mteiq6ou@gmail.com
Re: Simplified Org mode for newcomer Emacs veterans (was: Org mode and Emacs (was: Convert README.org to plain text README while installing package))
Tim Cross writes: > I'm not convinced we actually need to do anything (yet). Most of the > 'issues' raised by Eli were IMO theoretical rather than real. WE see > few, if any, issues or bug reports relating to most of the points he > raised. I'm also not convinced regarding some of the arguments regarding > casual or 'seldom' users. For me, many of the issues felt somewhat > contrived and actively looking for reasons why increased use of org in > Emacs was a "bad thing". This is a similar wording to my previous reply to Eli (I think it was to Eli). The answer was that the emacs-devel discussion _was the bug report_. Eli sometimes uses Org, but finds many things too much for him. Other complaints are from Org non-users who are not interested to give bug reports because they stopped short at the first try of using Org. Not to say that I agree with all the complaints, but they should be discussed here at least. > This is not to say some of his points don't warrant some consideration. > However, they do seem largely general 'theoretical' and based on a > preconception of what an emacs mode is. In many ways, Org is not a > 'normal' emacs mode. In some ways, it is a collection of modes with glue > to make them interoperate a little better. It is therefore possible, > many of the normal 'best practices', especially with respect to key > bindings, may not apply. Surely, Org is a collection of at least org-agenda-mode and org-mode :) The irony is that 'best practices' are not implemented by Emacs itself (look at the number of default Emacs bindings!). In any case, we should still try to extract something useful out of the received feedback. > I'm not fond of the 'magic' approach whereby special modes get activated > because some specific data is 'seen' in the buffer. For example, only > loading table editing mode because a table was seen or when the user > enters a line which looks like the start of a table. I much prefer a > system which allows me to enable the modes I want - similar I guess to > how we handle babel languages. However, that could just be me. It would > be good though that if we do support some form of 'dynamic' loading if > Emacs first asks i.e. "It looks like your editing a table. Shal I load > org-table-minor-mode?" sort of thing. I also dislike that idea. I proposed it as a part of brainstorming, hoping other ideas to be proposed by Eli. Alas... > So my approach would be to break things up into their own minor modes, > but by default, load them all. This will deal with the issue of not > impacting existing users. Typically, those who will care about not > loading additional unwanted bindings or features will also be the same > set of people who will be willing to customise their setup and they can > easily remove/turn off the modes they don't want. > > ... > One area which might be worth starting with would be to create an org > minor mode which only provides basic org navigation, folding and > font-locking support - no babel, no export, no agenda. reduced task > management key bindings. Essentially a minor mode which would render org > files in a 'clean' readable format, allow basic navigation and editing > and some basic/simple todo management. This would be the preferred mode > for seldom/casual users not interested in the full org experience. I tend to agree: 1. We modularize some of the key bindings and overriding defaults (like org-special-ctrl-o in org-open-line) into minor modes. They will be enabled by default. 2. We create an org-clean-mode (aka clean-mode in Emacs master) that disables/toggles those minor modes. > Likewise, how does org deal with an org file which includes some feature > the user has turned off. Consider a babel minor mode. Do we allow the > user to edit the babel blocks without loading that mode? Doe we warn > them the mode is not being loaded due to personal configuration? Do we > just disable all babel support if they don't load babel minor mode? I think I was not very clear in my previous message. There is no way we disable parts of Org syntax. That will require refactoring of org-element and many other functions. Not acceptable. What we can disable/change is some of the default bindings + certain customizations. The minor modes I propose will simply bind/unbind groups of Org bindings and toggle certain custom variables between Org-preferred and Emacs-default-ish. > The one big area which does concern me slightly with introducing this > sort of modularity is with debugging and support. For example, to > reproduce the environment where an issue is encountered, we may need to > also know more about exactly which set of minor modes as been enabled > and possibly the order they are enabled. Even just basic testing will > become more complex as you may need to test with different minor mode > permutations. We may need to add some additional debugging and reporting > functionality to assist in this area. I do not think that we should
Re: [PATCH] Re: No mathematics in Texinfo exports
Rudolf Adamkovič writes: >> `org-export-with-latex' is a global setting. I do not think that >> texinfo equivalent should be global. It should only be declared inside >> ox-texinfo. > > That makes perfect sense. Please see the new patch attached to this > message. What do you think? > -(:texinfo-compact-itemx nil "compact-itemx" org-texinfo-compact-itemx))) > +(:texinfo-compact-itemx nil "compact-itemx" org-texinfo-compact-itemx) > +;; Redefine regular options. > +(:with-latex nil "tex" org-texinfo-with-latex))) Looks reasonable. >> As for the default value, it would be better if the option were set >> depending on the installed Texinfo version. If the installed Texinfo >> supports math, set it to t. Otherwise, nil. Of course, users will be >> able to override the default as they wish. > > I looked at both ox-texinfo.el and texinfo.el, and I found no function > or variable that would give the installed Texinfo version. > > Do we pull the version from "makeinfo --version" and then parse it? If > so, does that functionality belong to Org (ox-texinfo.el) or Emacs > (texinfo.el) instead? I also wonder how we could test it so that it > will not break. I would appreciate any ideas and/or pointers from you. First of all, checking version should probably be controlled by some customization. Especially when we export to .texi (which does not involve calling makeinfo), not to .info. This customization might be set to 'auto by default, making ox-texinfo check makeinfo version. Parsing version is probably the easiest way. Another alternative is trying to run makeinfo on a small test file with math environment and checking if it gets exported as expected. Best, Ihor
Re: [PATCH worg 0/2] Cleanup of LoB file
Hi Tim, Tim Cross writes: > OK, thanks Bastien. Just out of interest, would you be able to send me a > copy of the nginx config for worg? I'm working on improving the build > process and I would like my local nginx to have a similar config. Also, > just in case there are changes which I think might improve the > experience from the server side, I would be good to know exactly what > the orgmode.org settings are. > > You can send that to me privately. Done, privately for now. Thanks for any suggestions on how to also improve this configuration. All best, -- Bastien
