Re: Hyphen after LaTeX fragments
If it is deprecated in Org mode, maybe we can print a warning message in echo area? > but this question will keep coming over and > over and over until the end of times. Yet I tried searching Org manual, and also here the mailing list archive, before posting my latest lame message here. Maybe I did not use the correct keyword, maybe something else. > Clearly, there is a need for the dash, and given the quality and > syntactic stability of TeX, the problem is not going anywhere > ... ever. Absolutely. signature.asc Description: PGP signature
Hyphen after LaTeX fragments
Sometimes I encounter such texts: One of the useful features of a basis $B$ in an $n$-dimensional space When entered as-is in Org mode and exported to LaTeX, the string "$n$-dimensional" is exported as plain text, as One of the useful features of a basis \(B\) in an \$n\$-dimensional space However, in cases such as "$n$;" and "$n$.", they are correctly exported as "\(n\);" and "\(n\).". Are there any option to treat hypen the same as semicolon or full stop in LaTeX exports? -- Yuchen Guo yc_pubkey.gpg.asc Description: application/pgp-keys signature.asc Description: PGP signature
Hyphen after LaTeX fragments
Sometimes I encounter such texts: One of the useful features of a basis $B$ in an $n$-dimensional space When entered as-is in Org mode and exported to LaTeX, the string "$n$-dimensional" is exported as plain text, as One of the useful features of a basis \(B\) in an \$n\$-dimensional space However, in cases such as "$n$;" and "$n$.", they are correctly exported as "\(n\);" and "\(n\).". Are there any option to treat hypen the same as semicolon or full stop in LaTeX exports? -- Yuchen Guo
Hyphen after LaTeX fragments
Sometimes I encounter such texts: One of the useful features of a basis $B$ in an $n$-dimensional space When entered as-is in Org mode and exported to LaTeX, the string "$n$-dimensional" is exported as plain text, as One of the useful features of a basis \(B\) in an \$n\$-dimensional space In cases such as "$n$;" and "$n$.", they are correctly exported as "\(n\);" and "\(n\).". So, are there any option that can be tweaked to export "$MATH$-text" correctly? -- Yuchen Guo signature.asc Description: PGP signature
Re: [PATCH] Fixing refile cache use for org-goto in indirect buffers.
Thanks for the reply. On Mon 2022-09-19 22:48:34 +0700, Max Nikulin wrote: > On 19/09/2022 12:16, Yuchen Pei wrote: >> To reprod: >> - make sure the org-refile-targets generates a big enough list where >>the refile cache makes a difference >> - visit an org file in org-refile-targets >> - M-x clone-indirect-buffer-other-window >> - C-0 C-c C-w to clear cache >> - M-: (org-refile-get-targets) > > Have you tried to execute this command in the indirect buffer? Yes, and it would be instant (assuming (org-refile-get-targets) has been run in the original buffer). This is because the code path from org-goto has an overriding local binding of org-refile-targets to `((nil . (:maxlevel . ,org-goto-max-level)) before calling org-refile-get-location which calls org-refile-get-targets. > >> - org-goto in the original buffer takes no effort >> - but, org-goto in the indirect buffer takes time, which is unexpected. > >> diff --git a/lisp/org-refile.el b/lisp/org-refile.el >> index 16cff25bd..7189ef595 100644 >> --- a/lisp/org-refile.el >> +++ b/lisp/org-refile.el >> @@ -306,7 +306,10 @@ converted to a headline before refiling." >> (dolist (f files) >>(with-current-buffer (if (bufferp f) f (org-get-agenda-file-buffer f)) >> (or >> - (setq tgs (org-refile-cache-get (buffer-file-name) descre)) >> + (setq tgs (org-refile-cache-get >> +(buffer-file-name (when (bufferp f) >> +(buffer-base-buffer f))) >> +descre)) > > Thank you for the attempt to improve handling of indirect buffers. > > I am afraid, more serious refactoring is required to reuse result of > `buffer-base-buffer', for the previous attempt to avoid issues with > `buffer-file-name' see > satotake to emacs-orgmode… [PATCH] org-refile.el: Fix the case of > *scratch* buffer. Sat, 15 May 2021 19:38:39 > +0900. > https://list.orgmode.org/20210515103839.8574-2-doublequotat...@gmail.com > > There are several corner cases with `org-refile-cache', `org-goto', > and buffers. > - Perhaps buffer name, not file name should be used as the cache key > if some buffer is not associated with any file. Alternatively cache > should not be used at all. It seems there may be problem with this idea. If buffer name is the key, that will mean a buffer and its indirect clone will generate two caches, which duplicates the work, no? > - When an indirect buffer is narrowed down to some region > (e.g. created using `org-tree-to-indirect-buffer') jump targets > should be filtered to the displayed range. > > So the change is an improvement (I would prefer `and' instead of > `when' in such expression, but it does not really matter). Leaving > aside other issues and more serious refactoring, it seems, storing > results to the cache requires a similar fix, so perhaps it is possible > to move "(setq f ...)" code above of "(or ...)" and reuse f as the > cache key. Sure, I will update my patch when I get around to it again. > > Please, send patches produced by "git format-patch" command. > I guess you had some problem applying the patch? I did use (ma)git-format-patch, but had some difficulty of getting gnus to send the formatted patch (I basically visited the patch file and ran (message-mode), but it was missing a few header fields compared to composing a new mail from gnus, so I manually copied over these fields). This was why I sent two emails. The first one[1] had an odd extra bit of Message-ID at the bottom of the message. Is this the one you were referring to as not being "standard", or is the other one[2] also not quite right? [1] https://lists.gnu.org/archive/html/emacs-orgmode/2022-09/msg00322.html [2] https://lists.gnu.org/archive/html/emacs-orgmode/2022-09/msg00323.html Best, Yuchen -- PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 <https://ypei.org/assets/ypei-pubkey.txt>
[PATCH] Fixing refile cache use for org-goto in indirect buffers.
To reprod: - make sure the org-refile-targets generates a big enough list where the refile cache makes a difference - visit an org file in org-refile-targets - M-x clone-indirect-buffer-other-window - C-0 C-c C-w to clear cache - M-: (org-refile-get-targets) - org-goto in the original buffer takes no effort - but, org-goto in the indirect buffer takes time, which is unexpected. --- lisp/org-refile.el | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lisp/org-refile.el b/lisp/org-refile.el index 16cff25bd..7189ef595 100644 --- a/lisp/org-refile.el +++ b/lisp/org-refile.el @@ -306,7 +306,10 @@ converted to a headline before refiling." (dolist (f files) (with-current-buffer (if (bufferp f) f (org-get-agenda-file-buffer f)) (or -(setq tgs (org-refile-cache-get (buffer-file-name) descre)) +(setq tgs (org-refile-cache-get +(buffer-file-name (when (bufferp f) +(buffer-base-buffer f))) +descre)) (progn (when (bufferp f) (setq f (buffer-file-name (buffer-base-buffer f -- 2.37.3
[PATCH] Fixing refile cache use for org-goto in indirect buffers.
To reprod: - make sure the org-refile-targets generates a big enough list where the refile cache makes a difference - visit an org file in org-refile-targets - M-x clone-indirect-buffer-other-window - C-0 C-c C-w to clear cache - M-: (org-refile-get-targets) - org-goto in the original buffer takes no effort - but, org-goto in the indirect buffer takes time, which is unexpected. --- lisp/org-refile.el | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lisp/org-refile.el b/lisp/org-refile.el index 16cff25bd..7189ef595 100644 --- a/lisp/org-refile.el +++ b/lisp/org-refile.el @@ -306,7 +306,10 @@ converted to a headline before refiling." (dolist (f files) (with-current-buffer (if (bufferp f) f (org-get-agenda-file-buffer f)) (or -(setq tgs (org-refile-cache-get (buffer-file-name) descre)) +(setq tgs (org-refile-cache-get +(buffer-file-name (when (bufferp f) +(buffer-base-buffer f))) +descre)) (progn (when (bufferp f) (setq f (buffer-file-name (buffer-base-buffer f -- 2.37.3 Message-ID: <877d20vscj@ypei.org>
Re: An org backend to Haddock
On Tue 2022-07-19 21:58:26 +0800, Ihor Radchenko wrote: > Yuchen Pei writes: > >> Given this is not the official version of haddock and my changes are in >> haddock-api, I'm calling it haddorg-api, for lack of a better name / >> approach. I'll be happy to contribute my changes upstream if a >> different license covering my contribution (AGPLv3+) is accepted. >> >> Let me know what you think. > > I am pretty sure that you are asking the Haskell people for upstreaming > ;) Yes - I sent the email to both haskell-cafe and emacs-orgmode, but upstream here means haddock / haddock-api indeed, thanks for clarifying. > > From Org side, it is always welcome when other Free software projects > are making use of Org. > > Also, I looked into > https://g.ypei.me/haddock.git/tree/haddock-api/src/Haddock/Backends/Org/Types.hs > > Beware of possible edge cases with "*/~|" in formatting. I am not > sure if text containing such symbols is possible as an input for your > library, but if it is, things may get formatted wrongly. > > For example, text containing "|" anywhere inside a table field must have > "|" escaped using \vert entity. The markup can be escaped using > zero-width space. True. I have not addressed these edge cases in my code, except a quick hack to prepend a space whenever any line a src block / result block has a leading star. Tables on the other hand are extremely rare in Haskell package documentation strings, and having a | in them is even rarer. I do wonder what is the best way to handle cross-package links. Currently I'm using CUSTOM_ID in the format of package-name-x.y.z.Module.Name.IdentifierName, as well as Module.Name.IdentifierName. But this is a "one big org file" approach, and can make navigation slow when say the org file reaches 15+MB in size. Ideally one should be able to navigate the a hackage worth of documentations easily, with working cross-package links and low latency org-goto to jump to any identifier or module, but I don't see how to achieve that. To be further investigated. > > Best, > Ihor Best, Yuchen -- PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 <https://ypei.org/assets/ypei-pubkey.txt>
An org backend to Haddock
Hello, I decided to write an Org backend to Haddock[1], so that haskell library documentation can be generated in org mode markup. Compared to the existing backends (html, latex and hoogle), the org format allows utilising features like the infinite levels of heading hierarchy, flexible folding / unfolding, cross-package linking, jumping to any declaration with org-goto and the endless potentials of emacs customisation. It seems to me most information and haskell language features one can find on displayed on hackage are supported by the org backend and included in the output org files, though there are still some rough edges and unsupported language features (like infix declarations and linear types) which I aim to fix. Some example output can be found at [2] (I will need to rename the "assets" part of the url as it is not accurate), including base[4], ghc-prim[5] and ghc-lib-parser[6] (I use it for reference of the GHC API as it is easier to build than GHC). For more information, check out the README file[3]. Given this is not the official version of haddock and my changes are in haddock-api, I'm calling it haddorg-api, for lack of a better name / approach. I'll be happy to contribute my changes upstream if a different license covering my contribution (AGPLv3+) is accepted. Let me know what you think. [1] https://g.ypei.me/haddock.git/tree/haddock-api [2] https://ypei.org/assets/haddorg-output/ [3] https://g.ypei.me/haddock.git/tree/haddock-api/README.org [4] https://ypei.org/assets/haddorg-output/base-4.16.1.0.org.gz [5] https://ypei.org/assets/haddorg-output/ghc-prim-0.8.0.org.gz [6] https://ypei.org/assets/haddorg-output/ghc-lib-parser-9.2.2.20220307.org.gz Best, Yuchen -- PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 <https://ypei.org/assets/ypei-pubkey.txt>
Ethical problems with MathJax as default - Was: Faulty SVG width
Ihor Radchenko writes: > The license is declared in the script. You can see it by following the > script url. It is right on top. True. My fault. The problem is that the declaration is not machine-readable by LibreJS. On the other hand, I think it is more preferable and more privacy-conscious to forbid loading from Cloudflare and use a local copy of MathJax embedded in LibreJS instead: - One can not trust Cloudflare. - Even if it is trusted, Cloudflare would still (at least) log the IP address. > I am not sure what is the problem here. Apache licence does not restrict > modifications and you can use your modified MathJax source by > customising org-html-mathjax-options. Oh, I meant the freedom of the website visitor replacing MathJax with a modified version on-the-fly, not of the website authors. That is not trivial. Thanks for the tip! I will certainly use a local copy of MathJax when necessary. -- Yuchen Guo
Re: Faulty SVG width in default HTML export style
Ihor Radchenko writes: > 1. MathJax is not the default export option. See org-html-with-latex Maybe I'm getting confused here, but as of the latest commit (cbe3f2d697a973a41a412b826ab9435d5523f3d0): - in ox-html.el, `org-html-with-latex' is defined as `org-export-with-latex', with the comment that: `mathjax', t: Do MathJax preprocessing and arrange for MathJax.js to be loaded. - in ox.el, `org-export-with-latex' is defined as `t'. Therefore, MathJax is the default export option for math snippets in HTML exports. > 2. We use MathJax script from > https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js It is > licenced under Apache 2.0, which is GPL-compatible according to > https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses Yes. But it is still problematic because: - The license is not declared in the script and therefore not compatible with LibreJS. - It is not trivial to `control your computing', as in `modifying the script and run your modified copy instead.' Maybe LibreJS can provide us the facility to do so. -- Yuchen Guo
Re: Faulty SVG width in default HTML export style
Rudolf Adamkovič writes: > I now wonder if anyone knows how to fix the misaligned baselines of > inline LaTeX fragments (as shown in the second screenshot). I think we can solve this issue by looking at how Wikipedia does the alignment of text and LaTeX snippets. A cursory look at https://en.wikipedia.org/wiki/Normal_distribution ... shows that they use something like this: The alignment parameters are also dependent on the snippet itself. > If we could somehow fix that, MathJax-less export > could become usable in practice *and* it would also unlock full LaTeX > power, including TikZ and beyond! (It would also put Emacs ahead of the > pack in the world of LaTeX-capable editors because virtually every other > modern editor, including the proprietary ones, can just use MathJax.) For me, Emacs using MathJax as default came across as an unpleasant surprise: any person aware of the free/libre software movement knows that one should never allow Javascript to run in their browser: (ref https://www.gnu.org/philosophy/javascript-trap.html ). MathJax is not even compatible with LibreJS and loads script from a bunch of 3rd-party servers like Cloudflare. This enables those 3rd parties to track visitors to your website. Also, by loading external scripts, author of an website essentially puts the website and its visitors under the mercy of the script: the script, if malicious, can just sabotage the entire website. Sadly it seems that there aren't enough people using Orgmode with SVG: this CSS bug is at least present since 2020, according to git logs. Rendering SVG images is also painfully slow: I can export the document as PDF much faster than as HTML+SVG. Then there is the alignment issue. > @me.com Unrelated but I think its best to not use Apple dis-services: it has a record of kowtowing to government requests such as moving email account to surveillance-friendly regimes: https://en.wikipedia.org/wiki/ICloud#China Not to mention its utter contempt of Software Freedom such as forbidding GNU GPL on their program distribution platform. -- Yuchen Guo
Faulty SVG width in default HTML export style
Currently the style specified for SVG images
in `org-html-style-default' variable is the following:
.org-svg { width: 90%; }
This causes a single image (math formula) to occupy almost the width of
the entire page, rendering the page unreadable.
In my experiment removing this line fixed the issue.
Two PNG screenshots demostrating the issue is available under the
following links:
https://w.wiki/4uQd
https://w.wiki/4uQe
--
Yuchen Guo
Re: [BUG?] org-agenda not showing entries with diary sexp timestamps
Daniel Fleischer writes: Eric S Fraga [2021-09-10 Fri 11:57] wrote: What works for me, for diary sexp entries, is putting the time in the heading: * 09:00-10:00 Weekly meeting <%%(diary-cyclic 7 9 10 2021)> This is exactly how the feature is described in the manual: #+begin_example Diary-style expression entries For more complex date specifications, Org mode supports using the special expression diary entries implemented in the Emacs Calendar package(2). For example, with optional time: * 22:00-23:00 The nerd meeting on every 2nd Thursday of the month <%%(diary-float t 4 2)> #+end_example Thanks, my bad. I guess the reason for the time to be included in the headline is to be consistent with the diary format. -- Best, Yuchen PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 <https://ypei.me/assets/ypei-pubkey.txt> signature.asc Description: PGP signature
Re: [BUG?] org-agenda not showing entries with diary sexp timestamps
Daniel Fleischer writes: Yuchen Pei [2021-09-10 Fri 18:00] wrote: * Weekly meeting <%%(diary-cyclic 7 9 10 2021) 9:00-10:00> Invoking org-agenda with a (org-agenda-list) does not show the item, whereas scheduled diary sexp or plain timestamp works fine: * Weekly meeting SCHEDULED: <%%(diary-cyclic 7 9 10 2021) 9:00-10:00> I can reproduce; adding the hour makes the event not appear unless it has a DEADLINE or SCHEDULED. Thanks for confirming. The org-agenda code is not very readable for me with some very long functions, but I'll see if I can fix it. By the way is breaking functions into smaller ones desirable for the project? -- Best, Yuchen PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 <https://ypei.me/assets/ypei-pubkey.txt> signature.asc Description: PGP signature
[BUG?] org-agenda not showing entries with diary sexp timestamps
Hello, Can anyone reproduce this? Say I write the following in my agenda org file: * Weekly meeting <%%(diary-cyclic 7 9 10 2021) 9:00-10:00> Invoking org-agenda with a (org-agenda-list) does not show the item, whereas scheduled diary sexp or plain timestamp works fine: * Weekly meeting SCHEDULED: <%%(diary-cyclic 7 9 10 2021) 9:00-10:00> or * Weekly meeting <2021-09-10 9:00-10:00 +1w> emacs version: GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo version 1.17.4) of 2021-03-27 -- Best, Yuchen PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 <https://ypei.me/assets/ypei-pubkey.txt> signature.asc Description: PGP signature
pygments support
Hello, I was playing with my cgit setup when I noticed that pygments does not support org mode syntax highlighting[1]. Just wondering if anyone has worked on it, or if there's any "unofficial" org mode component (lexer?), before I go ahead and try to write my own. [1]: https://pygments.org/languages/ -- Best, Yuchen PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 <https://ypei.me/assets/ypei-pubkey.txt> signature.asc Description: PGP signature
bug#48199: 28.0.50; Org mode surprisingly usurps Calendar key binding
Lars Ingebrigtsen writes: Yuchen Pei writes: This bug seems to be still around, as it just happened to me. Steps to reproduce: - Build a recent version e.g. commit efaed29f3d with `make` - ./src/emacs - M-x calendar RET - i results in "command-execute: Wrong type argument: commandp, org-agenda-diary-entry". Can anyone else reproduce it? I can't reproduce this with "emacs -Q", or after visiting etc/ORG-NEWS, with the current Emacs trunk. You are right. I add `-Q` to the emacs invocation and the problem is gone. I'm gonna try to re-archive this bug. -- Best, Yuchen PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 <https://ypei.me/assets/ypei-pubkey.txt> signature.asc Description: PGP signature
bug#48199: 28.0.50; Org mode surprisingly usurps Calendar key binding
Looks like this email hadn't go through before I unarchived the bug. Apologies for any duplicate messages. Yuchen Pei writes: This bug seems to be still around, as it just happened to me. Steps to reproduce: - Build a recent version e.g. commit efaed29f3d with `make` - ./src/emacs - M-x calendar RET - i results in "command-execute: Wrong type argument: commandp, org-agenda-diary-entry". Can anyone else reproduce it? -- Best, Yuchen PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 <https://ypei.me/assets/ypei-pubkey.txt> signature.asc Description: PGP signature
Re: [O] clock consistency check doesn't work for today item
Bastien bzg at altern.org writes: If you clock in and ou using org-clock-in and org-clock-out (or equivalent commands from the agenda), then you should not have to worry abou whitespaces -- this must have been manually deleted/typed by error. So I'd say no, this is not a bug. Thanks for tell me this, I will be careful now. Sincerely, Yuchen
Re: [O] clock consistency check doesn't work for today item
Hi Bastien, Bastien bzg at altern.org wrote: Can you send a minimal .org file that we can use to reproduce the bug? Thanks for your attention to this matter. I'm sorry I post this mail twice by mistake.here is the test org file： * Task1 CLOCK:[2013-01-03 周四 23:24]--[2013-01-03 周四 23:42] = 0:18 * Task2 CLOCK: [2013-01-06 周日 12:31]--[2013-01-06 周日 12:39] = 0:08 CLOCK: [2013-01-06 周日 10:02]--[2013-01-06 周日 10:18] = 0:16 In fact, I find that this problem is caused by the absence of blank between CLOCK: and the timestamp.I forget to type it :P I don't know whether this is a bug... And thanks for telling me the basic etiquette while posting a question,here is the version info: Emacs: GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601) of 2012-08-29 on MARVIN Package: Org-mode version 7.8.11 Sincerely, Yuchen
[O] clock consistency check doesn't work for today item
Hello! I find that clock consistency check doesn't work for today item. For example, when I come into the log mode by C-c a l ,it looks like this: XXX (someday before today) Emacs: 12:56-16:09 Clocked: (3:13) STARTED The Org Manual 生活: 16:34-16:49 Clocked: (0:15) 杂务 生活: 17:08-17:22 Clocked: (0:14) 杂务 .. XXX (today) 物理: 16:46-16:56 Clocked: (0:10) 静电场 生活: 17:07-17:36 Clocked: (0:29) 休息 物理: 17:36-17:46 Clocked: (0:10) 静电场 goal: 19:10-22:41 Clocked: (3:31) 林肯 After v c to check the clock consistency,,it looks like this: XXX (someday before today) Emacs: 12:56-16:09 Clocked: (3:13) STARTED The Org Manual Clocking gap: 25 minutes 生活: 16:34-16:49 Clocked: (0:15) 杂务 Clocking gap: 19 minutes 生活: 17:08-17:22 Clocked: (0:14) 杂务 .. XXX (today) 物理: 16:46-16:56 Clocked: (0:10) 静电场 生活: 17:07-17:36 Clocked: (0:29) 休息 物理: 17:36-17:46 Clocked: (0:10) 静电场 goal: 19:10-22:41 Clocked: (3:31) 林肯 It seems only to loose its power on today...This really confused me when I want to summarize today's work. Regards, Yuchen
