* [PATCH] Improve documentation of #+startup keyword
@ 2021-03-19 12:03 77% Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-03-19 12:03 UTC (permalink / raw)
To: org-mode-email
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
Hello all,
I was talking to someone who was finding the behaviour of `#+startup'
confusing, and they managed to work out a table summarising the
behaviour.
I think that this would be a good addition to the manual, and help
clarify the behaviour --- so I've prepared a little patch to the manual.
I notice that there are some `#+cindex' lines lying around but I'm not
quite sure what they do. Please let me know if I should add anything
like that etc.
All the best,
*Timothy*
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-doc-org-manual.org-clarify-startup-behaviour.patch --]
[-- Type: text/x-patch, Size: 1720 bytes --]
From 8ff32dfbf2e14419eb542d58ee39c1545f34354b Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Fri, 19 Mar 2021 20:01:03 +0800
Subject: [PATCH] doc/org-manual.org: clarify #+startup behaviour
* doc/org-manual.org: clarify the behaviour that each #+startup option
implies.
---
doc/org-manual.org | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index e8763ff17..a005cce52 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -598,6 +598,19 @@ *** Initial visibility
is requested by startup options and =VISIBILITY= properties in
individual entries.
+A summary of each keyword's behaviour may be seen in the table below.
+| #+startup: | org-startup-folded | VISIBILITY | shows headings | shows body |
+|---------------------+--------------------+------------+----------------+------------|
+| overview (or fold) | t | x | lvl1 | |
+| content | 'content | x | all | |
+| show2levels | 'show2levels | x | lvl1-2 | |
+| ... | 'showNlevels | x | lvl1-N | |
+| show5levels | 'show5levels | x | lvl1-5 | |
+| showall (or nofold) | nil | x | all | x |
+| showeverything | 'showeverything | | all | x |
+| <DEFAULT> | 'showeverything | | all | x |
+
+
*** Catching invisible edits
:PROPERTIES:
:DESCRIPTION: Preventing mistakes when editing invisible parts.
--
2.30.1
^ permalink raw reply related [relevance 77%]
* Re: [PATCH] Treat :tangle-mode as an octal value not integer
@ 2021-09-29 14:58 78% ` Timothy
1 sibling, 1 reply; 200+ results
From: Timothy @ 2021-09-29 14:58 UTC (permalink / raw)
To: tomas; +Cc: emacs-orgmode
<tomas@tuxteam.de> writes:
> So you favour going the "full custom special parser". You're much more
> involved in Org, so I think your gut feeling counts more than mine here :)
Well, I'm not sure that my feeling is representative of experienced Org users,
my opinion basically boils down to:
>> I think as long as it’s clear what’s intended, and it’s not some home-baked
>> non-standard format, or terribly annoying to support — why not?
Rephrased: I think there are a few arguably "sensible" formats that a user could
reasonably assume, and if we can support most of them without introducing
ambiguity in parsing or interpretation (and I think we can), can't we make
everyone happy?
> `755' is the funniest one, since, strictly speaking it doesn't correspond
> to anything "out there" (note that the shell command `chmod' wants the
> leading zero, or, well, it will do surprising things if you don't
> provide it ;-)
Consider my suggestion amended to 0755 etc. :)
Anyway, as an example here's a code snippet that implements everything I've
mentioned.
#+begin_src emacs-lisp
(defvar org-tangle-default-mode #o544
"The default mode for tangled files, as an integer.")
(defun org-interpret-file-mode (mode)
(cond
((integerp mode) mode)
((not (stringp mode))
(user-error "File mode %S not recognised as a valid format." mode))
((string-match-p "^0[0-7][0-7][0-7]$" mode)
(string-to-number mode 8))
((string-match-p "^#o[0-7][0-7][0-7]$" mode)
(string-to-number (substring mode 2) 8))
((string-match-p "^[ugoa]*\\(?:[+-=][rwxXstugo]*\\)+\\(,[ugoa]*\\(?:[+-=][rwxXstugo]*\\)+\\)*$" mode)
(file-modes-symbolic-to-number mode 0))
((string-match-p "^[rwx-]\\{3\\}$" mode)
(file-modes-symbolic-to-number (concat "u=" mode) org-tangle-default-mode))
((string-match-p "^[rwx-]\\{9\\}$" mode)
(file-modes-symbolic-to-number (concat "u=" (substring mode 0 3)
",g=" (substring mode 3 6)
",a=" (substring mode 6 9))
org-tangle-default-mode))
(t (user-error "File mode %S not recognised as a valid format." mode))))
#+end_src
--
Timothy
^ permalink raw reply [relevance 78%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
@ 2021-01-03 13:08 79% ` TEC
0 siblings, 1 reply; 200+ results
From: TEC @ 2021-01-03 13:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Thank you very much for your response and your comments.
Seriously, thanks for the patch. I think the ML is usually a bit more
responsive, but it seems to be a bit quiet at the moment.
> I agree to name "Insert, include, etc." the attribute to include
> arbitrary LaTeX code, better than "options".
Glad my feedback seems to have gone down well :). If the only likely use
of this is adjusting the font, perhaps for the sake of consistency we
can match the behaviour of tables, which take a :font LaTeX attribute?
> Of course, I can add the necessary documentation to the files you tell
> me. As I am new to submitting patches, I don't really know how to
> proceed: do I have to send you the new version of the patch, with the
> documentation? Should I send a new email with all of it to this list?
Thanks for asking. Sometimes it seems the maintainers take the trouble of
adding an ORG-NEWS entry or minor touching ups to the patch, but I think
it's nice to leave as little for them to do as possible :)
Announce changes in: etc/ORG-NEWS
Document new/different behaviour in: doc/org-manual.org
I think Markup for /Rich Contents > Paragraphs/ may be the right place
to add a description of this functionality --- verse blocks are
discussed around line 10750.
Regarding how patches on this ML work, this is what I've observed:
- Initial version of patch submitted, with justification/explanation
- Feedback may be given
- Revisions of the patch are attached in replies to feedback
- Process repeats until everyone's happy
- Patch is merged
i.e. it all tends to happen in the same thread.
Hope this helps,
Timothy.
^ permalink raw reply [relevance 79%]
* [PATCH] Add font-lock rule for inline export snippets
@ 2021-03-31 15:57 80% Timothy
2021-04-28 7:23 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-03-31 15:57 UTC (permalink / raw)
To: org-mode-email
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
Hello,
The latest in my visually-oriented (mostly) short patch series, adding
basic fontification to inline export snippets --- @@comment:these things@@.
I think fontification for stuff like this is nice because it visually
indicates to the user that they've written out an Org construct, and
haven't just mis-remembered / imagined some syntax.
In future this could be extended to use native fontification for
recognised export formats (like src blocks do), but I think this is a
nice improvement over nothing.
--
Timothy
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-Add-font-lock-rule-for-inline-export-snippets.patch --]
[-- Type: text/x-patch, Size: 942 bytes --]
From 3584602f88381ab9624c767a83c18cfd93ffeaf0 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Wed, 31 Mar 2021 23:47:58 +0800
Subject: [PATCH] org: Add font-lock rule for inline export snippets
* lisp/org.el (org-set-font-lock-defaults): Add font-lock rule for
inline export snippets.
---
lisp/org.el | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/lisp/org.el b/lisp/org.el
index f4d069504..240f745c7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5719,6 +5719,11 @@ (defun org-set-font-lock-defaults ()
;; Description list items
'("^[ \t]*[-+*][ \t]+\\(.*?[ \t]+::\\)\\([ \t]+\\|$\\)"
1 'org-list-dt prepend)
+ ;; Inline export snippets
+ '("\\(@@\\)\\([a-z-]+:\\).*?\\(@@\\)"
+ (1 'font-lock-comment-face t)
+ (2 'org-tag t)
+ (3 'font-lock-comment-face t))
;; ARCHIVEd headings
(list (concat
org-outline-regexp-bol
--
2.30.1
^ permalink raw reply related [relevance 80%]
* Re: [PATCH] Fontification for inline src blocks
@ 2021-05-18 13:34 80% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-05-18 13:34 UTC (permalink / raw)
To: sebastien.miquel; +Cc: org-mode-email
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
Hi Sébastien, thanks for your comments.
Sébastien Miquel <sebastien.miquel@posteo.eu> writes:
> Hi Timothy,
>
> Thanks for your work. I hope this can be merged.
:)
> Here are a few comments.
>
> Doesn't this line in ~org-toggle-inline-results-display~ throw the
> configured delimiters away when called twice ?
> : (setq org-inline-src-prettify-results (not org-inline-src-prettify-results))
>
> I think the =org-block= face should only be applied to the actual
> code, note the =src_lang= part, nor the result. For normal src blocks,
> it is only used inside the block.
In src blocks, you have the org-block-begin-line face applied. This (in
any sensible theme) has the same background as org-block. For the sake
of visual consistency, I think we want to have this applied to the
src_lang and result parts too. However, the org-block-begin-line face
overly fades the text, and so I've combined the org-block face with
other faces.
[-- Attachment #2: inline-src-back.png --]
[-- Type: image/png, Size: 9480 bytes --]
[-- Attachment #3: Type: text/plain, Size: 2642 bytes --]
> The ~org-src-font-lock-fontify-block~ function could be modified to
> take an optional =inline= argument. When =t=, it should not set the
> =multiline= font property. Although this is very minor, it would allow
> one to easily advice this function to behave differently in inline src
> blocks. For example, to not use the =org-block= face in this case.
I don't see where the multiline property is currently set, would you mind
pointing it out to me?
> I think the default parenthesis pair around results are bad. I much
> preferred your original brackets. Yes, as Tom said, they look alien,
> but alien is appropriate for use of ~prettify-symbols~.
I'm going to be using the original symbols in my configuration anyway
because I think they're nicer, but clearly this is contentious. I'd want
to hear from more people on this.
> Since ~prettify-symbols~ seems to be raising some usability concerns,
> perhaps ~org-inline-src-prettify-results~ should default to ~nil~.
> It'd be unlike org to hide things from the user in the default
> configuration.
This seems somewhat sensible to me, but I must say that {{{results()}}}
is /ugly/ and I suspect that many users would like the effect, but a
minority will be aware of this option. Perhaps this is worth doing
anyway.
> As Tom points out, the two faces used (for the =src_= and bracket and
> the language part) should be customizable. The default value you chose
> are fine IMO. Perhaps the language one could also be used to highlight
> the language of normal src blocks, though It might be easier to use a
> single face.
So are you suggesting I do or don't create new faces for this?
> Timothy writes:
>>> P.S. Nitpick: You do not need to run fontification in while loops. Just
>>> fontifying next match before limit should be enough. Font-lock will call
>>> the function again if needed.
>> I'm guessing for this to work I'd need to return the final char
>> fortified? Or is the moving of point enough?
>>
>> Maybe related - I've noticed this doesn't seem to work with multiple
>> src_ blocks per line, might you have any insight here?
>
> You need only return =t= if some fontification has been done (and set
> point after the fontified part). If your function returns =t=, it will
> be called again.
>
> A case can be made for keeping the loop though. It works fine and is
> clearer since the aforementioned fontlock behaviour is poorly
> documented. Really, the only downside is the loss of consistency, since
> the function ~org-fontify-meta-lines-and-blocks-1~ doesn't loop.
Returning t works nicely, and now we can highlight more than one inline
src per line :)
--
Timothy
^ permalink raw reply [relevance 80%]
* Re: [PATCH] (v2) New LaTeX code export option: engraved
@ 2022-05-09 12:57 80% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-05-09 12:57 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Daniel Fleischer, emacs-orgmode, Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 5007 bytes --]
Hi Ihor,
> Before merging, could you also try to implement tests at least for
> engraved feature? If I recall correctly, we do not currently have
> backend-specific tests. But it would certainly help if we did. You might
> as well write a small “nucleus” test for ox-latex.
Probably not a bad idea, I’m just not sure what/how I’d go about this.
> Also, unless I miss something, there is no support for coderefs in the
> patchset. Is it intentional?
I think you’ve missed something. It has the same coderefs support as minted.
> It appears that the code for caption-str is duplicated. It could be
> also factored out.
It could, but I’m not sure this is actually a good idea as the duplication is
more the result of chance than a common dependency.
>> + (format-spec custom-env
>> + `((?s . ,formatted-src)
>> + (?c . ,caption)
>> + (?f . ,float)
>> + (?l . ,(org-latex–label src-block info))
>> + (?o . ,(or (plist-get attributes :options) “”)))))))
>
> I do not see a definition of `format-spec’ function. There is only
> `spec’ above in the code. Can you double check? Either I am missing
> something or something fishy is going on.
This code isn’t introduced by my patches, just relocated. FWIW `format-spec' is
provided by Emacs, and I don’t think is new.
>> + (let ((code (org-element-property :value inline-src-block))
>> + (lang (org-element-property :language inline-src-block)))
>> + (pcase (plist-get info :latex-listings)
>> + (’nil (org-latex–text-markup code ’code info))
>> + (’minted (org-latex-inline-src-block–minted info code lang))
>> + (_ (org-latex-inline-src-block–listings info code lang)))))
>
> Please use `nil and `minted. Using ’ may create issues in older Emacs.
Done.
>> +% In case engrave-faces-latex-gen-preamble has not been run.
>> +\
>> +\
>
> What is the difference between EfD and EFD? EfD is also not documented.
Documentation added. EfD is the background colour.
>> +FVEXTRA-SETUP sets fvextra’s defaults according to
>> +`org-latex-engraved-options’, and LISTINGS-SETUP creates the
>> +listings environment and defines \.“
>
> It is unclear what listings environment does given that we use engraved
> package. Can you provide a bit more details in the docstring on what the
> user will get if [LISTINGS-SETUP] is present.
> It may catch users by surprise that deleting this will make captions
> disappear.
It does the same thing as minted’s `listings' environment, hence the choice of
name. Documentation added.
> Why not just
> (org-element-map (plist-get info :parse-tree)
> ’(src-block inline-src-block example-block fixed-width) #’identity
> info t)
Ah, in my config I’m also using some engraved info for example/fixed-width
blocks. I’ll leave this out for now.
>> (pcase (plist-get info :latex-listings)
>> (’nil (org-latex–text-markup code ’code info))
>> …
> Same comment about ` in pcase.
Done.
> What will happen if there is no [LISTINGS-SETUP]?
Captioned/Floating code blocks won’t work.
>> +(defcustom org-latex-engraved-theme nil
> Docstring does not explain what happens when set to nil.
> Also, does :type ’symbol allow t and nil?
I think so, `symbolp' says they’re symbols if nothing else.
> Will it work when engraved-theme is t?
Yes.
> What about example-block and fixed-width? I may be missing something,
> but earlier in the patchset you had conditionals of the type
> (or src-p fixedw-p). So, does engrave-faces do anything with fixedw-type
> elements?
Resolved earlier.
>> + (gen-theme-spec
>> + (lambda (theme) …
>
> This appears to be not guarded by (require ’engrave-faces-latex nil t).
It is before it’s actually called.
>> -(defun org-latex-src–engrave-code (content lang)
>> - “Engrave CONTENT to LaTeX in a LANG-mode buffer, and give the result.”
>> +(defun org-latex-src–engrave-code (content lang &optional theme options inline)
>> + “Engrave CONTENT to LaTeX in a LANG-mode buffer, and give the result.
>> +When THEME is non-nil, it will be used.”
>
> You did not document the remaining two arguments. (this makes me ask a
> question whether you checked compile warnings). Also, consider running
> M-x checkdoc on ox-latex.el.
Now documented.
I have checked compile warnings (there are none), but checkdoc is currently a
bit dodgy on the Emacs commit I’m on.
>> - (insert content)
>> + (insert (string-trim-right content “”))
>
> As a theoretical possibility, what will happen if content has something
> like “%”?
Discussed in DMs. It just gets rid of trailing newlines, and it’s fine with
escaping.
All the best,
Timothy
^ permalink raw reply [relevance 80%]
* Re: [PATCH] Fix regex for determining image width from attribute
@ 2021-11-21 19:20 81% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-21 19:20 UTC (permalink / raw)
To: Matt Huszagh; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]
Hi Matt,
> A recent patch started computing the inline image width from any attr_
> line. This is incorrect, as it matches settings like attr_latex, or
> attr_html. We only want to look for settings specifically for the org
> buffer. This patch fixes that.
Once again, thank you for the patch. The fact that the current regexp matches
`#+attr_latex' and `#+attr_html' is in fact by design though*. This is because I
consider it safe to assume that a `#+attr_*' which gives non-integer width between
0 and 2 can be safely assumed to be that proportion of the page width. e.g.
`#+attr_latex: :width 0.7\linewidth' or `#+attr_html: :width 70%'.
This way, a good guess can be made without having do have both an
`#+attr_latex/html' /and/ an `#+attr_org' line for the width. Should this assumption
be incorrect, a subsequent `#+attr_org' line will override the other `#+attr_*'.
Should there be edge-cases where this assumption doesn’t hold, I’d be interested
in patches that improves the logic here. As long as this holds more often than
not though, this should be a net positive for user experience as I see it.
Do please let me know if there are any good examples of unintended /
counter-intuitive behaviour you’re aware of.
All the best,
Timothy
* Well, it’s worked this way for a while, and I made a deliberate choice to keep
this behaviour when expanding the width to recognise proportional values.
^ permalink raw reply [relevance 81%]
* Re: [PATCH] Accept more :tangle-mode specification forms
@ 2021-10-01 18:14 81% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-10-01 18:14 UTC (permalink / raw)
To: Tom Gillespie; +Cc: tomas, emacs-orgmode, mail
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
Hi Tom,
Thanks for going through the replies so far and refining your thoughts.
> *snip a whole bunch of comments*
I think I’m of the same mind as you that if we try to mentally separate Org the
markup format and Org the emacs mode, the format should not specify the
interpretation of the :tangle-mode value.
I think the best way to have it would be,
⁃ Org the format, :tangle-mode takes a value representing the file permissions
the tangled file should have. Optional: here are some common examples that
might be recognised
⁃ Org the emacs mode, :tangle-mode’s value is interpreted like so (…)
> That said, reducing the number of forms as Eric suggests would
> be a happy medium.
Indeed, I’ve basically supported every form I could think of. I’m currently
inclined to cut it down to:
• 755
• “rwxrw-r–” (`ls -l' style)
• chmod style with `org-babel-tangle-default-mode' and `file-modes-symbolic-to-number'
Maybe with (if anybody says they would like this)
• #o755 (elisp octal)
• 0755 (C octal)
• “rwx” = user perm, bit-or’d with `org-babel-tangle-default-mode' for the rest
(i.e. `org-babel-tangle-default-mode', but not exceeding the user perm)
All the best,
Timothy
^ permalink raw reply [relevance 81%]
* Re: [PATCH] Fontification for inline src blocks
@ 2021-05-12 16:39 81% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-05-12 16:39 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Tom Gillespie, org-mode-email
Thank you for the detailed feedback :)
Ihor Radchenko <yantar92@gmail.com> writes:
> Timothy <tecosaur@gmail.com> writes:
>
>>> I do not like abusing prettify-symbols-mode. What if it is not enabled?
If you know of another way of accomplishing text-replacement which
changes back when the cursor enters the region, please let me know.
>> Ah, it does it anyway at the moment.
>
> Hmm. You are right. You are calling compose-region directly. Note, that
> you do not add 'decompose-region function for automatic region
> destruction (see help:pretty-symbol-pattern-to-keyword).
Isn't the same effect achieved by the remove-list-of-text-properties call?
> If I understand correctly (I did not really install your patch), if you have
> composed region, disable font-lock, and try to edit the region, edits
> will be invisible. Or imagine setting org-inline-src-prettify-results to
> nil in already fontified buffer.
I just tried "setting org-inline-src-prettify-results to nil in already
fontified buffer." and the region just decomposed and stayed that way.
> Also, you may find help:font-lock-extra-managed-props useful. That way,
> you will not have to manually remove composition and other non-standard
> properties during fontification
Hmmm, from a look I can't tell exactly how these are "managed". Are they
just removed when a region is processed?
> why are you even removing 'face? It should be already done by font-lock).
I tried removing such calls, and everything still worked, so this is no
longer done.
>>> What will happen if user toggles prettify-symbols-mode in Org buffer?
>>
>> This seems to be toggled nicely by prettify-symbols-mode too.
>
> I would not expect it to. Why would prettify-symbols-mode interfere with
> Org mode native fontification if it is not strictly necessary?
Well, I guess this is a by-product of using prettify-symbols-start/end,
see my note at the start of this email about not being aware of anything else.
> P.S. Nitpick: You do not need to run fontification in while loops. Just
> fontifying next match before limit should be enough. Font-lock will call
> the function again if needed.
I'm guessing for this to work I'd need to return the final char
fortified? Or is the moving of point enough?
Maybe related - I've noticed this doesn't seem to work with multiple
src_ blocks per line, might you have any insight here?
Thanks,
Timothy
^ permalink raw reply [relevance 81%]
* [PATCH] Apply emacs manual css to org pages
@ 2020-12-23 2:35 82% TEC
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: TEC @ 2020-12-23 2:35 UTC (permalink / raw)
To: org-mode-email
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
Hi all,
This is a quick patch to use the Emacs manual CSS with our generated Org
manual.
You can see what the single-page version of this looks like here:
https://tecosaur.com/resources/org/doc/manual.html and the multi-page
here: https://tecosaur.com/resources/org/doc/manual/
This should be an easy upgrade to our online documentation :)
--
Timothy
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-mk-default.mk-use-same-html-doc-style-as-emacs.patch --]
[-- Type: text/x-patch, Size: 826 bytes --]
From fc57ea88432ea119d063906cc29cc51ee591031d Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Wed, 23 Dec 2020 10:30:09 +0800
Subject: [PATCH] mk/default.mk: use same html doc style as emacs
* mk/default.mk: Add CSS stylesheet ref to HTML generated by TEXI2HTML,
specifically the stylesheet used with the online Emacs manual.
---
mk/default.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mk/default.mk b/mk/default.mk
index fbfdaf5..e92d58c 100644
--- a/mk/default.mk
+++ b/mk/default.mk
@@ -139,7 +139,7 @@ MKDIR = install -m 755 -d
MAKEINFO = makeinfo
# How to create the HTML file
-TEXI2HTML = makeinfo --html --number-sections
+TEXI2HTML = makeinfo --html --number-sections --css-ref "https://www.gnu.org/software/emacs/manual.css"
# How to find files
FIND = find
--
2.29.2
^ permalink raw reply related [relevance 82%]
* Re: [PATCH] Fontification for inline src blocks
@ 2021-10-03 9:22 83% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-10-03 9:22 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Protesilaos Stavrou, org-mode-email
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
Hi Ihor,
> What about separating the src_{nil} fontification into separate patch? I
> think that part raised no objections.
That sounds like a good idea to me. We may as well get that in.
> As for the results prettifications, I look at this and similar ideas as
> at Emacs themes. It looks nice on your screenshot with your fonts and
> colours, but may not be good for other people. Similar to org-bullets
> and co.
The behaviour makes me think of link prettification more than what Emacs themes
do. Hiding the text {{{results( with an overlay seems like something a
major/minor mode should be responsible for, not a theme.
> I can see how some people (I am among those people) want to reduce the
> markup noise beyond hiding emphasis markers. However, some people
> prefer not to hide text in buffer under “bells and whistles”.
Indeed, and it’s good to have this option. This is why I also introduced a new
setting, `org-inline-src-prettify-results' (similarly named to
`org-pretty-entities').
> Maybe we can create some kind of “prettify-symbol themes” replacing different
> markup elements in bulk with nice symbols/svg (e.g. inline results, block
> headers/footers, uninteresting property drawers aka org-custom-properties,
> bullets, etc)? WDYT? Also, CCing Prot as it might be of interest for him.
> Best, Ihor
I think it could make sense for some prettification capabilities to be built
into Org well. Currently there are a few little things we have, but it seems to
be handled inconsistently and I think it could be nice to provide a more unified
approach. There are also things like
<https://github.com/awth13/org-appear/blob/master/org-appear.el> which I feel just
make a lot of sense with Org (you never have to guess if `point' is before or
after a markup character).
All the best,
Timothy
^ permalink raw reply [relevance 83%]
* Re: [PATCH] Don't fill displayed equations
@ 2021-10-02 10:18 83% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-10-02 10:18 UTC (permalink / raw)
To: Eric S Fraga; +Cc: emacs-orgmode, Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]
Hi Eric,
>> text
>> 1+1=3
>> text
>>
>> is a single paragraph in LaTeX.
> This is true and probably the most convincing argument in this debate.
I can’t help but think that this line of thinking is a bit of a trap, because
what LaTeX’s idea of a paragraph does not line up with Org’s. I think the more
pertinent consideration is that `\[ ... \]' changes LaTeX into vertical mode,
which does not allow for any other content on the ’line’ — which is far
closer to Org’s concept of a block element than an inline element.
Frankly, I think the issue is that the semantics of `\[ ... \]' simply don’t play
well with Org. Unfortunately, due to the Org/LaTeX difference I don’t see any
ideologically “pure” way we can have it in Org. The most idiomatic solution
would be to just remove support for `\[ ... \]' *. Otherwise, we have to treat
`\[ ... \]' specially in if we want ’sensible’ behaviour — as I mention in my
reply to Nicolas, we’re already parsing it differently to other inline markup…
All the best,
Timothy
* However, I am not advocating for this: There’s both the obvious comparability
issue, but I also rather like using `\[ ... \]' myself.
^ permalink raw reply [relevance 83%]
* Re: [PATCH] Don't fill displayed equations
@ 2021-10-04 6:05 83% ` Timothy
1 sibling, 1 reply; 200+ results
From: Timothy @ 2021-10-04 6:05 UTC (permalink / raw)
To: Org Mode List
Hi All,
Given the way the conversation has evolved I think it may be worth revisiting
another viewpoint to see if anybody has any nice ideas.
As things are, regardless of the complexities of parsing and inline vs.
block elements etc., just considering the user experience when running
org-fill on an example like the one below, the behaviour isn't /nice/.
Might there be some way we could allow for people who are used to LaTeX
and/or like \[ ... \] to have fill behaviour that leaves \[ ... \]
blocks alone? My original idea was changing how org-fill works for
everyone, the discussion has gone on to changing \[ ... \] to a block
element -- both of these seem to have rather significant issues.
Ihor came up with the idea of making org-fill something more
customisable by the user, so that someone could have this behaviour
without making Org behave un-idiomatically for everyone. I proposed
maybe just having a setting could be a halfway house between my original
patch and his idea.
Does anybody have any other thoughts?
> If you’re wondering why I’m so opposed to the current behaviour, that is probably
> best explained by a more realistic demo that what I have in the commit message.
>
> ┌────
> │ Since \(\cos\) is an even function, we can negate the numerator of the argument
> │ without changing the result, giving
> │ \[
> │ \cos \left( \pi \frac{C_1-x}{2C_1+D} \right) \ , \quad C_1 = \frac{D}{2}.
> │ \]
> │ this will be positive over \(x \in (0,D)\), and so we can rewrite \(\tilde{y}\) as,
> │ \[
> │ \tilde{y}(x) = \frac{2D}{\pi} \log \cos \left( \pi \frac{\frac{D}{2}-x}{2D} \right) + C_2.
> │ \]
> │ Once again considering that \(y(0)=y(D)=0\), it is clear that
> │ \[
> │ C_2 = - \frac{2D}{\pi} \log \cos \left( \frac{\pi}{4} \right) = - \frac{2D}{\pi} \log 2^{-\frac{1}{2}} = \frac{D}{\pi} \log 2.
> │ \]
> │ The complete solution for \(\tilde{y}\) is hence,
> │ \[
> │ \tilde{y} = \frac{2D}{\pi} \log \cos \left( \pi \frac{D-2x}{4D} \right) + \frac{D}{\pi} \log 2.
> │ \]
> └────
> is currently filled to
> ┌────
> │ Since \(\cos\) is an even function, we can negate the numerator of the argument
> │ without changing the result, giving \[ \cos \left( \pi \frac{C_1-x}{2C_1+D}
> │ \right) \ , \quad C_1 = \frac{D}{2}. \] this will be positive over \(x \in (0,D)\),
> │ and so we can rewrite \(\tilde{y}\) as, \[ \tilde{y}(x) = \frac{2D}{\pi} \log \cos \left( \pi
> │ \frac{\frac{D}{2}-x}{2D} \right) + C_2. \] Once again considering that
> │ \(y(0)=y(D)=0\), it is clear that \[ C_2 = - \frac{2D}{\pi} \log \cos \left(
> │ \frac{\pi}{4} \right) = - \frac{2D}{\pi} \log 2^{-\frac{1}{2}} = \frac{D}{\pi} \log 2.
> │ \] The complete solution for \(\tilde{y}\) is hence, \[ \tilde{y} = \frac{2D}{\pi} \log \cos
> │ \left( \pi \frac{D-2x}{4D} \right) + \frac{D}{\pi} \log 2. \]
> └────
--
Timothy
^ permalink raw reply [relevance 83%]
* Re: [PATCH] avoid loading major modes when exporting to file
@ 2021-05-01 17:26 84% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-05-01 17:26 UTC (permalink / raw)
To: Bastien; +Cc: org-mode-email
Bastien <bzg@gnu.org> writes:
> This even be "auto-mode-alist" instead of "(auto-mode-alist nil)".
Ah, it can indeed.
> I'm still unsure the patch is correct: what if people *need* major
> mode initialization before any contents is exported to a file?
I haven't responded to this concern, because I haven't been able to
conceive of a single situation where loading the normal-mode for the
exported file could be desirable.
>> I think the commit description is pretty thorough, so give that a look.
>> TLDR; it makes `org-export-to-file' behave a bit more nicely.
>
> I find it useful to have a small description of the change and why it
> is needed in the body of the email, when a patch is attached.
I think I may have been become overly used to how convenient mu4e is for
showing patches inline 😅.
For the sake of anyone just looking at the Email body, here's what I
considered to be an informative commit message, subtly reworded:
Currently, when `org-export-to-file' is called it activated the major
mode for that file type based on `auto-mode-alist'. This can be mildly
annoying in various ways as loading the major mode:
1. makes the export take longer
2. can produce unwanted "noise" while initialising, namely warnings and
errors related to the mode itself
3. can produce spurious files like an .auctex-auto folder
By locally binding `auctex-auto' to nil all of these undesirable
behaviours can be avoided.
--
Timothy
^ permalink raw reply [relevance 84%]
* Re: [PATCH] New remote resource download policy
@ 2022-06-22 10:01 84% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2022-06-22 10:01 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 3028 bytes --]
Hi Max,
>> — a/lisp/org-attach.el
>> +++ b/lisp/org-attach.el
>> @@ -525,7 +525,11 @@ (defun org-attach-attach (file &optional visit-dir method)
>> [snip]
>> + (if (or (not noninteractive) (org–should-fetch-remote-resource-p file))
>
> I am confused by (not noninteractive). Does it mean that interactive call is
> enough to bypass protection? It may have sense it at this step there is no
> ambiguity what resources is fetched. On the other hand I am unsure concerning a
> case when `org-attach-attach’ is a part of a larger command.
The idea here is that when this is done interactively the user will be aware of
the URL this is being applied to, and so it isn’t a risk. Let me know if this
assumption doesn’t hold.
>> +(defcustom org-download-remote-resources ’prompt
>
> The name sounds like some function.
Mmm. I could add `-policy' to that variable name perhaps.
>> +(defun org–confirm-resource-safe (uri)
>> + “Ask the user if URI should be considered safe, returning non-nil if so.”
>> + (unless noninteractive
>> + (let ((buf (get-buffer-create “*Org Remote Resource*”)))
>
> I see your intention to add something fancy to the dialog. May `org-mks’ be
> reused instead to avoid proliferation variants of rather similar UI code?
Well, the thing here is that I’m explicitly trying to mimic the
file-local-variable dialog, and since a general form isn’t exposed by Emacs, a
little bit of proliferation seems like the best option to me.
>> + ;; Set up the contents of the *Local Variables* buffer.
>
> I am in doubts concerning “once”. I tried “y” in a file having to “#+include:”
> of the same file. I did not get question for second include. I did not get
> prompt for this file anymore at all, even during next export. I modified the
> remote file, but stale content appeared during export. So the file was really
> downloaded once, but it is hardly in agreement with my expectations. Behavior is
> unrelated to this patch, concerning wording I am not sure, but I have no a
> better variant.
Ok, that is not the intended behaviour. I’ll see if I can work out what’s going
on here. Oh, and I should change that comment to “Set up the contents of the *Org
Remote Resource* buffer.”.
>> + (propertize “n” ’face ’error)
>> + “ to skip this resource.”)
>
> From “skip” I do not expect aborting of export.
Hmm, the “skip” action isn’t determined by the “is it safe” functions, but some
wording that doesn’t sound completely safe at least would be good.
> I have an idea but unsure if it should be implemented. Consider
> `org-remote-resources-policy’ custom variable that is a list of pairs
> (url-regexp . policy) for fine grain tuning instead of 2 variables. The price is
> more complicated structure, so higher chance of user error.
My initial reaction is that this feels like overkill.
All the best,
Timothy
^ permalink raw reply [relevance 84%]
* Re: [PATCH] Customizify org-babel-fortran-compiler
@ 2021-07-01 14:40 84% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-07-01 14:40 UTC (permalink / raw)
To: Nico Sonack; +Cc: emacs-orgmode
Hi Nico,
Thanks for sending in the patch. Seeing it pointed out, this seems like
a pretty obvious omission. This looks like it should be pretty easy to
merge :)
Four minor niggles with your commit message:
+ Since `defvar' and `defcustom' are elisp symbols, they should be
quoted as such.
+ It's probably better to avoid shorthand like "X -> Y", and write out
"Change X to Y" instead.
+ You have included "lisp/" in the commit subject, which isn't needed.
Just "ob-fortran.el" or even "ob-fortran" is enough here.
+ Your commit subject goes over 50 chars, which is undesirable.
Here's what I'd recommend:
#+begin_example
ob-fortran: Use a defcustom for fortran compiler
* lisp/ob-fortran.el (org-babel-fortran-compiler): Change `defvar' to `defcustom'
so that the fortran compiler is customizable like almost all other org-babel
compilers.
#+end_example
This is rather minor though, I mention this mostly as a note for the
future :)
--
Timothy
Nico Sonack <nsonack@outlook.com> writes:
> Hey there,
>
> I've been using org-mode for quite a while already and am pretty
> happy with it!
>
> Today I noticed a minor oddity, that occured when I tried to run some
> Fortran code with org-babel: it failed with the compiler not being
> found. Looking at the custom variables of the org-babel group, I was
> unable to find a compiler option for Fortran. Thus, I quickly patched
> the ob-fortran.el and turned the defvar of
> `org-babel-fortran-compiler' into a defcustom such that it is a little
> more consistent with the rest of the org-babel languages.
>
> The patch is attached to this mail. Please let me know if I should
> correct anything.
>
> Nico
^ permalink raw reply [relevance 84%]
* Re: [PATCH] Re: [BUG] Creating sparse tree with regexp property matches
@ 2021-09-17 10:17 85% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-17 10:17 UTC (permalink / raw)
To: Daniel Fleischer; +Cc: emacs-orgmode, Cassio Koshikumo
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
Hi Daniel,
Thanks for bumping your patch, unfortunately many of us (people who can push to
Org) seem to be stretched a bit thin as of late. I’ve just gone over it, it
reads well IMO and I think looking at the non-trivial changes in your patch it’s
possible to charitably interpret this as <=15 non-trivial lines changed. I’ve
applied this as 6600dc09 on Org master with a tweaked commit message 🙂.
Documentation is vital to communicating what Org offers to users, so thanks
again for going to the effort to clear up a possible point of confusion. Should
you wish to make any further contributions (which would be great!) it would be
very helpful if you could get FSF assignment (see
<https://orgmode.org/contribute.html>), as we can’t accept more than 15 lines of
non-trivial lines as an FSF project.
All the best,
Timothy
^ permalink raw reply [relevance 85%]
* Re: fontsets (was: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful..."))
@ 2022-07-11 17:45 85% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-07-11 17:45 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Maxim Nikulin, Ihor Radchenko, orgmode
[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]
Hi Juan,
> When you talk about fontset, I understand that you mean lists of
> families with their options that you have previously defined, is that
> right?
Yep, so in my config’s implementation I have an alist of fontset names and
individual fonts. For something part of org-mode itself, we’d probably want to
add a format level to this, something like:
┌────
│ ((fontset-name .
│ ((serif .
│ ((pdflatex . "\\usepackage{myserif}")
│ (lualatex . "etc.")
│ (html . "and so on")))
│ (sans ...) ... ))
│ (another-fontset ...) ...)
└────
Actually, now that I think of it maybe it would be better to seperate out the
fontsets and fots, e.g.
┌────
│ ;; Fonts
│ ((myfonta . ((pdflatex . "etc.") (lualatex ...) (html ...) ...))
│ (myfontb ...)
│ ...)
│ ;; Fontsets
│ ((myfontset .
│ ((sans . myfonta)
│ (serif . myfontb)
│ (mono . myfontc)
│ ...))
│ ...)
└────
> In any case, I think it would also be nice if the user could add only
> one family for roman, sans, mono or math, if he/she prefers it that way.
> Something like:
>
> #+options: rmfont:Minion Pro
Sure. There’s another bit of functionality in my config which I think is worth
noting, you can add a -sans/-serif/-mono suffix to the fontset name to override
the default body text font.
All the best,
Timothy
^ permalink raw reply [relevance 85%]
* Re: [PATCH] New LaTeX code export option: engraved
@ 2022-05-06 11:23 86% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-05-06 11:23 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Daniel Fleischer, emacs-orgmode, Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]
Hi Ihor,
>> Sure. If it’s any help, here’s a comparison example I whipped up:
>> <https://0x0.st/oAdn.png>
>
> Timothy, could you please not use 0x0 to share not-so-large images? 0x0
> deletes uploaded files within ~1year time and this link will no longer
> be valid if someone tries to read this discussion years later.
I forget if org-msg handles image links well (I recall some issue in the past).
Let’s do a little test:
<file:/tmp/ox-latex-src-fontification-comparison.png>
> Also, this illustration makes me wonder if engrave-faces can provide a
> color scheme that is mimicking minted.
One could certainly create `engrave-faces-preset-styles' presets which mimic
certain minted colour schemes.
> Generally, easy customisation of highlight schemes could be useful.
I agree. Is this not already the case though? Manually modifying
`engrave-faces-preset-styles' or calling `engrave-faces-generate-preset' seems
pretty easy to me, the only thing missing is the ability to generate a preset
from a theme not loaded, which I suspect won’t be easy to do.
> On per-src-block basis or even on per-language basis if document contains
> course blocks with different programming languages.
I can’t say I really see the point in this myself. It would certainly be
non-trivial to add, but could be added latter if there’s demand for it.
All the best,
Timothy
[-- Attachment #2: ox-latex-src-fontification-comparison.png --]
[-- Type: image/png, Size: 476505 bytes --]
^ permalink raw reply [relevance 86%]
* Re: [PATCH] Enhance org-html--build-meta-info
@ 2020-12-16 7:22 86% ` TEC
0 siblings, 1 reply; 200+ results
From: TEC @ 2020-12-16 7:22 UTC (permalink / raw)
To: Jens Lechtenboerger; +Cc: Bastien, org-mode-email
Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:
> I like this!
:)
>> Maybe it should be applied to the rest (in ~org-html--build-meta-info~)?
>> I'm not sure.
>
> I’m not sure either. Maybe people expect their typed characters,
> maybe not. This might call for a new variable.
I'm tempted to leave the current behaviour as-is, and then we can
introduce a new variable if we want later :)
> I like the new variant much better. However, I still do not
> understand why you pass the title into org-html-meta-tags-default
> just to ignore it. The title is already dealt with elsewhere, isn’t
> it?
For people who want to customise this to add metadata, the page title is
something they're probably interested in. If so, I think it's work
giving the title processed by org-html--build-meta-info as it's not so
simple as (plist-get info :title). Worst case, the argument just sits
there and is ignored :P
> Some comments raise complaints by checkdoc (lines too long, no
> sentence in fist line). (Actually, the file has more problems in
> that regard.)
Ooops, I thought I took care of that. Looks like I'll be taking another
look...
Would be nice my issues weren't one of dozens throughout the file, it
makes it a bit harder to notice errors coming from /my/ section.
> Many thanks for your continued work!
Thanks for your testing and feedback!
--
Timothy
^ permalink raw reply [relevance 86%]
* Re: [PATCH] Treat :tangle-mode as an octal value not integer
@ 2021-09-29 13:48 86% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-09-29 13:48 UTC (permalink / raw)
To: Jeremy Cowgar; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]
Hi Jeremy,
> As an org user I would expect :tangle-mode 0660 to produce a file that
> has user rw, group rw, other nothing. Instead, what really happens
> currently is 0660 is treated as an integer which is actually
> 3140. This produces unexpected file permissions.
I agree that :tangle-mode could be more user-friendly. However, I think we can
go further. Currently, only (identity #o755 / 493) works, however I think it would be
good if it worked like chmod and accepted most of the following forms:
⁃ `#o755'
⁃ `755' (because people are used to this, as technically misleading as it may be,
as long as we can tell “:tangle-mode 356” from “:tangle-mode (identity #o544)”)
⁃ `rw' (equivalent to a=rw, and so #o555)
⁃ `a=rw,u+x' (equivalent to #o755) [hardest to support, so maybe?]
And then I’d also be in favour of accepting
⁃ `rw-r--r--' (equivalent to #o544)
I think as long as it’s clear what’s intended, and it’s not some home-baked
non-standard format, or terribly annoying to support — why not?
All the best,
Timothy
^ permalink raw reply [relevance 86%]
* Re: [PATCH] Fontification for inline src blocks
@ 2021-05-02 21:03 87% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2021-05-02 21:03 UTC (permalink / raw)
To: Tom Gillespie; +Cc: org-mode-email
Thanks for trying this!
Tom Gillespie <tgbugs@gmail.com> writes:
> Hi Timothy,
> It seems to work more or less as expected. A few comments below. Best,
> Tom
>
> 1. I think there needs to be a function to toggle
> org-inline-src-prettify-results as there is e.g. for hyperlinks. I was
> quite confused by the prettified results.
I see. I imagine the expected behaviour of such a function would be to
toggle org-inline-src-prettify-results and redisplay?
> 2. I'm also not sure that this approach to prettify is a good idea.
> There are issues with unexpected killing/yanking and basic navigation
> behavior of the prettified text which seem worse than the already
> troublesome issues with hyperlinks. I'm not sure we can do anything
> about this though?
If there is something that can be done, I'd love to hear about it. I'm
no aware of anything though.
> 3. I'm not sure about the default choice for prettified delimiters. I
> see there is already a way to customize the delimiters by providing a
> cons. I think a default value of '("" . "") might be a better choice
> since ⟨ and ⟩ being hardcoded seems like it introduces completely
> alien characters. Going with empty strings also seems consistent with
> the behavior for hyperlinks.
Hmmm, yes. Perhaps something else would make for a better default.
I'm open to suggestions on this, I just didn't personally like any of
the ASCII chars I tried when writing this.
> 4. There is an interaction with rainbow delimiters that there isn't an
> easy solution for. I wish there was a syntax type that was "this is a
> paren for electric pair mode but not for font locking."
This sounds like something worth being aware of, that nothing can really
(currently) be done about.
> 5. I'm not sure that the faces selected for src_ and lang are the
> right ones. Is there any issue with adding new faces specifically for
> those rather than reusing existing faces? I thought that matching the
> font locking of #+begin_src lines might make sense, but then I
> realized that that doesn't make sense because that is for blocks more
> generally.
I don't know if adding faces is a big deal or not, so I tried to pick
"sensible choices" from the current set. Further input on this would be
appreciated (particularly more people's thoughts).
--
Timothy
^ permalink raw reply [relevance 87%]
* Re: [PATCH] Accept more :tangle-mode specification forms
2021-11-18 10:20 93% ` Timothy
@ 2021-11-18 17:22 87% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-18 17:22 UTC (permalink / raw)
To: Org Mode List
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]
Hi All,
I thought I’d checked for this, but I’ve just noticed that :tangle-mode 755
doesn’t actually work as expected. I assumed 755 would be passed as a string but
org-babel-parse-header-arguments actually turns it into an integer, just like
(identity #o755). Obviously 755 != #o755 and so this causes issues.
As it stands “755” works, but that isn’t great (most importantly, it’s easy to
confuse). Since it’s easier to add than remove things like this, we could just
get rid of this for now, but a convenient octal notation was a large chunk of
the motivation here IIRC.
We could also change the implementation to handle :tangle-mode o755, which will
make org-babel-parse-header-arguments parse the argument as a string.
I’m be keen to hear other people’s thoughts on this.
All the best,
Timothy
^ permalink raw reply [relevance 87%]
* Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export
@ 2021-05-03 18:03 87% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-05-03 18:03 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: org-mode-email
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> This sounds reasonable.
I'm glad to hear that!
>> +(defun org-md-latex-environment [...]
> Nitpick: I would use `format', also the final newline character is
> useless, since it will be removed later during the export process.
Actually, since writing this patch I'm not sure that $$-surrounding
\begin{}...\end{} environments is also a good idea. I'm inclined to
leave this out of the patch.
>> +;;;; Latex Fragment
>> +
>> +(defun org-md-latex-fragment (latex-fragment contents info)
>> + "Transcode a LATEX-FRAGMENT object from Org to Markdown.
>> +CONTENTS is nil. INFO is a plist holding contextual information."
>> + (when (plist-get info :with-latex)
>> + (let ((frag (org-html-latex-fragment contents info)))
>> + (cond
>> + ((string-match-p "^\\\\(" frag)
>> + (concat "$" (substring frag 2 -2) "$"))
>> + ((string-match-p "^\\\\\\[" frag)
>> + (concat "$$" (substring frag 2 -2) "$$"))
>> + (t (message "unrecognised fragment: %s" frag)
>> + frag)))))
>
> Nitpick: I suggest to use `rx' macro. It really makes the code base
> a better place.
I do rather like the `rx' macro, however I'm not sure that
(rx bol "\\(") is really an improvement over "^\\\\(" in this particular
case.
> You are missing some cases. The fragment could be $...$ or $$...$$
> already, so you can return it as-is without sending the message.
Ah yep, after getting your thoughts on this message I'll send a revised
patch with fixes this (along with any other changes).
> Otherwise, it is a macro. We can assume it lives outside math mode. So
> maybe the "Unrecognized fragment: %S" is in order in that situation. We
> could also let HTML export back-end deal with it. I don't know what is
> better.
I'm not sure what to do here either. Perhaps nothing/HTML backend?
Finally, I think if this case (lone macro) is handled, there aren't any
possible "Unrecognized fragment"s that could be passed, and so that
condition would no longer be necessary?
--
Timothy.
^ permalink raw reply [relevance 87%]
* Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export
@ 2021-05-04 13:31 87% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-05-04 13:31 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: org-mode-email
Hello,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>> Should one want to convert LaTeX images say to an SVG for HTML export, I
>> do not think one would want this behaviour to also apply to LaTeX being
>> exported to markdown.
>
> Why do you think so? This is consistent with everything else not
> supported by vanilla Markdown.
To speak personally, at the moment I use mathjax for HTML. I'm quite
content with the markdown output from this patch without what's
discussed below.
However, if/when I can get the SVG baseline to work with dvisvgm I plan
on switching to that for HTML files. However, I'd consider this
behaviour undesirable for markdown.
The main reason why I'm hesitant about including <img>s in Markdown, is
because unlike <table> etc. the output now relies on external files.
>> As such I see two 'sensible' paths forward: (1) just include LaTeX
>> verbatim when :with-latex is non-nil, or (2) introduce
>> `org-markdown-with-latex' which can be set to t/'verbatim or 'html.
>>
> Obeying to :with-latex property means "ox-md" is somehow actively
> handling LaTeX fragments, which was not the initial intent, IIUC. The
> first idea was to provide a sensible default for such objects, because
> we're outside the specification anyway. I'd rather not overdo it.
I'm happy to strip this out of the patch (there's always advice for my
own config...), I just thought there may be people who like me are
interested in <img>s for LaTeX in HTML, but not in Markdown.
--
Timothy
^ permalink raw reply [relevance 87%]
* Re: [PATCH] LaTeX export: arbitrary float environments
@ 2021-05-01 17:31 88% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-05-01 17:31 UTC (permalink / raw)
To: Thomas S. Dye; +Cc: emacs-orgmode
Thomas S. Dye <tsd@tsdye.online> writes:
> Aloha Timothy,
:waves:
> Sorry for the clumsy patch, which I guess would also benefit from an addition to
> the manual, as well?
No problem, we all start somewhere :) (and I know I'm still making mistakes)
An update to the manual to describe the changed behaviour would be good.
If you'd like you could wait till a core maintainer says this looks good
before going to that effort, or you could add it in now so it's all in a
single patch --- as long as something happens.
> Larger question: do we really want to tinker with ob-latex in this way? Or,
> should changes like this patch follow a path indicated by Tim Cross and into
> their own package, say ob-latex-ex, which might someday replace ob-latex if it
> proved useful and stable?
I don't think LaTeX support is likely to leave Org any time soon, so at
least until a core maintainer tells you otherwise I'd be inclined to
proceed with your current patch.
If this was a huge/transformational change I may be more uncertain, but
this looks fairly simple to me at least.
--
Timothy
> All the best,
> Tom
>
> Timothy <tecosaur@gmail.com> writes:
>
>> Hi Thomas,
>>
>> On the surface, this looks reasonable to me :)
>>
>> Just commenting on some technicalities with the patch itself:
>> - In ORG-NEWS it would be good to wrap the content over multiple lines
>> instead of having a single 270 char line :)
>> - You seem to have an anomalous change to the ob-python :return entry
>> - I don't think your patch subject follows the convention for Org, it
>> should be:
>> "main file/feature: overall change summary"
>> so, something like
>> "ox-latex: allow for arbitrary float environments"
>> rather than
>> "LaTeX export: arbitrary float environments"
>>
>> Thanks for the patch :)
>>
>> Timothy
^ permalink raw reply [relevance 88%]
* Re: [PATCH] tweaks to ox-html style
@ 2021-02-12 18:16 88% ` Timothy
2 siblings, 0 replies; 200+ results
From: Timothy @ 2021-02-12 18:16 UTC (permalink / raw)
To: Jens Lechtenboerger; +Cc: Kyle Meyer, org-mode-email
Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:
> I do not know why the CDATA lines exist. I don’t see a reason to
> keep them (patch 0001), but that might be a lack of understanding on
> my part.
I'll cover this in my reply to your follow-up.
> Patch 0003 is about whitespace fixes.
>
> Patches 0002, 0004, 0005 change defconst styling. I don’t have a
> strong opinion here. However, if they are changed now, what about
> turning them into defcustoms? Then each of us would be entitled to
> their own opinion ;)
>
> The docstring for org-html-head-include-default-style says that
> org-html-style-default (a defconst proposed to be changed here)
> should not be changed. Why not?
The defconst is left a defsconst because I don't really know why it is
one, and when I don't know why something is the way it is, I try to leave
it alone. In my own config I actually overwrite it, but oh well.
I'm guessing this is just a case of "User beware, this contains
important stuff to have Org look reasonable. Don't remove that."
Perhaps this should be a defcustom? It would be good to hear from
someone else on this. If this ends up being a hold up though I'd rather
resolve this separately.
--
Timothy.
^ permalink raw reply [relevance 88%]
* Re: [PATCH] Fontification for inline src blocks
@ 2021-04-28 7:14 88% ` Timothy
2021-05-02 20:17 93% ` Timothy
2 siblings, 1 reply; 200+ results
From: Timothy @ 2021-04-28 7:14 UTC (permalink / raw)
To: org-mode-email
Timothy <tecosaur@gmail.com> writes:
> Hi All,
>
> I've been using inline src blocks a fair bit more recently, and I've
> thought it's a pity how bad they look as they are currently without
> fontification. A little digging into Org internals and font-lock later
> and we have this patch. I could speak about what's been done, but I
> think a screenshot does a much better comparison.
>
> For more details, see the attached patch.
Since this affects font-lock, display performance is obviously a key
concern, and so I have two things to note on that front:
1. I have been using this patch for over a month at this point,
frequently in a ~10k line Org file (my Emacs config), and there has
been no noticeable performance degradation
2. The most expensive part of this is the native syntax highlighting,
which is only used when `org-src-fontify-natively' is t, and the
second most expensive part (results formatting) is only performed
when `org-inline-src-prettify-results' (a new variable) is t.
In brief: I don't anticipate any significant performance implications of
this patch, though of course second opinions would be great :)
--
Timothy
^ permalink raw reply [relevance 88%]
* Re: [PATCH] ob-shell-test, test-ob-shell and introduction
@ 2021-11-22 18:43 88% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-22 18:43 UTC (permalink / raw)
To: Matt; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]
Hi Matt,
> I’m interested in getting async into ob-shell.el. Since I’ve never contributed
>before, I figure it’d be good to start with a few easy tasks.
Fantastic! Great to hear from you, and I hope it goes well. Feel free to send
further emails for if you get stuck. If you intend to do more than just one or
two small tweaks (it sounds like you have bigger plans than that), you’ll need
what’s known as [FSF copyright assignment]. Have you done that yet?
> It looks to me like the stdin and cmdline header args aren’t documented anywhere
> (at least I couldn’t find anything). To make sure I’m using them correctly
> before making a patch for the manual, here are some tests.
Great! I’m not overly familiar with these, so I’ll leave other people to take a
look at the tests you’ve written, but your approach sounds good. 👍
> Please let me know if things look okay. It wasn’t clear to me how to send along
> a message with git send-email, so I formatted these patches and included them as
> an attachment. Is that fine?
Patches attached to an email are perfectly fine here.
Thanks for getting in touch, and I hope to see you around 🙂.
All the best,
Timothy
[FSF copyright assignment] <https://orgmode.org/contribute.html#copyright>
^ permalink raw reply [relevance 88%]
* Re: [PATCH] Fix caption format for custom latex src block
@ 2022-06-29 15:26 88% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2022-06-29 15:26 UTC (permalink / raw)
To: Matt Huszagh; +Cc: Ihor Radchenko, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
Hi Matt,
As mentioned by Ihor, you’ll want to take a look at the curent version of
ox-latex, specifically `org-latex-src-block--custom' which now contains `(?c .
,caption)'. You may want to consider modifying `org-latex--caption/label-string' to
accept the form `(element info &optional content-only)' or reimplementing just the
bits needed for this purpose — which ever works out nicer. Looking at
`org-latex--caption/label-string' a substring approach looks quite fragile, though
you might be able to get away with an application of `replace-regexp-in-string',
though I’d personally consider this a bit of a last resort.
Matt Huszagh <huszaghmatt@gmail.com> writes:
> Ihor Radchenko <yantar92@gmail.com> 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
>
> {Perform inter-sample interpolation.
> }
>
> I could use substring to remove the leading { and trailing
> }. What do you think?
All the best,
Timothy
^ permalink raw reply [relevance 88%]
* Re: [PATCH] ob-svgbob: New babel backend for SVGBob
@ 2021-09-26 20:35 88% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-26 20:35 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode, Steven vanZyl
[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]
Hi Bastien,
> Not later than a few hours ago, I removed several ob-* files:
> <https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=db67c7e9>
>
> (ob-svgbob.el should not go in org-contrib, though, because the
> org-contrib repo is for unmaintained libraries.)
>
> I suggest you maintain ob-svgbob.el as a contributed library to
> GNU ELPA (<https://elpa.gnu.org>) to help people find it. See the
> instructions here:
>
> <https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README>
Thanks for taking a look at this. In light of your response I’m wondering about
the ob-* inclusion criteria. I recall when removal was being discussed the
concerns being with ob-* libraries that were some combination of:
⁃ Too niche
⁃ Being actively maintained
Which is why I thought SVGBob could be a good fit, as it’s a small useful
general-purpose tool that only takes ~50 lines of code for a library (and so I’d
be quite happy to maintain) and IMO fits in nicely with Org.
Would you mind elaborating a bit more on your thoughts on what makes an ob-*
library a good fit for Org or not?
All the best,
Timothy
^ permalink raw reply [relevance 88%]
* Re: [PATCH] Rename headline to heading
@ 2021-09-19 11:06 89% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2021-09-19 11:06 UTC (permalink / raw)
To: André A. Gomes; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
Hi André,
Sorry that you haven’t heard anything in a while. I’ve been hoping that Bastien
or Nicolas might have been able to take a look at this and give their thoughts,
but unfortunately judging from their recent activity they both seem to be quite
busy as of late. I dream of the day when Org could actually employ a full-time
maintainer via opencollective (or similar).
In the meantime, I’ve flagged this message in my own mail client, and it appears
on <https://updates.orgmode.org/> so you can at least be sure that this won’t be
forgotten about.
> I’m still waiting for the FSF to send me back my form signed. I’ve sent
> it on the 31st of July.
Could you let us know if the FSF have got back to you on this?
All the best,
Timothy
^ permalink raw reply [relevance 89%]
* Re: [PATCH] Async session eval (2nd attempt)
@ 2021-04-25 6:26 89% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 6:26 UTC (permalink / raw)
To: Kyle Meyer; +Cc: Jack Kamm, emacs-orgmode
Hi Jack, Kyle,
This is moving at a glacial pace, but I'd love to see this merged ---
there's clearly a lot of interest in this from the community if not
within this mailing list (ob-async which is more limited has 250 stars
on GitHub).
Jack, do you think you might be able to make these tweaks so I can
implore the maintainers to "just merge this"? :P
Kyle, if Jack doesn't get back to us do you think we could just make
those changes and merge the patch as-is at some point? Or merge it and
then add a commit making these fixes?
--
Timothy.
Kyle Meyer <kyle@kyleam.com> writes:
> Jack Kamm writes:
>
>> I also have an async implementation for ob-R that's ready after this is
>> merged :)
>
> It's a bit disappointing that only one babel user has tested this out
> and provided feedback, but please feel free to merge this whenever you
> think it's ready.
>
> I'm very happy to leave the babel details to you, but here are minor
> comments from a quick read-through looking for things that will likely
> be changed/cleaned up (either in the Org repo or the Emacs repo) if left
> as is.
>
>> Subject: [PATCH] ob-comint.el, ob-python.el: Async session evaluation
> [...]
>> +;; Async evaluation
>
> For a heading comment, please use at least three semicolons.
>
> (info "(elisp)Comment Tips")
>
>> +
>> +(defvar-local org-babel-comint-async-indicator nil
>> + "Regular expression that `org-babel-comint-async-filter' scans for.
>> +It should have 2 parenthesized expressions,
>> +e.g. \"org_babel_async_\\(start\\|end\\|file\\)_\\(.*\\)\". The
>> +first parenthesized expression determines whether the token is
>> +delimiting a result block, or whether the result is in a file. If
>> +delimiting a block, the second expression gives a UUID for the
>> +location to insert the result. Otherwise, the result is in a tmp
>> +file, and the second expression gives the file name.")
>> +
>> +(defvar-local org-babel-comint-async-buffers nil
>> + "List of org-mode buffers to check for Babel async output results.")
>
> s/org-mode/Org mode/ here and other spots, following
> doc/Documentation_Standards.org and tree-wide cleanups like de24694f0
> (Turn org-mode into Org or Org mode, 2016-08-23).
>
> Also, you're missing two spaces between some sentences.
>
>> +(defmacro org-babel-comint-async-delete-dangling-and-eval
>> + (session-buffer &rest body)
>> + "Remove dangling text in SESSION-BUFFER and evaluate BODY.
>> +This is analogous to `org-babel-comint-with-output', but meant
>> +for asynchronous output, and much shorter because inserting the
>> +result is delegated to `org-babel-comint-async-filter'."
>> + (declare (indent 1))
>> + `(org-babel-comint-in-buffer ,session-buffer
>> + (goto-char (process-mark (get-buffer-process (current-buffer))))
>> + (delete-region (point) (point-max))
>> + ,@body))
>> +(def-edebug-spec org-babel-comint-async-with-output (sexp body))
>
> Please move this edebug spec to the `declare' form (see 7dd1cfb6c,
> 2021-02-12).
>
>> diff --git a/testing/lisp/test-ob-python.el b/testing/lisp/test-ob-python.el
>> index a2cc7b79c..0267678cd 100644
>> --- a/testing/lisp/test-ob-python.el
>> +++ b/testing/lisp/test-ob-python.el
>> @@ -207,6 +207,67 @@ (ert-deftest test-ob-python/session-value-sleep ()
>> #+end_src"
>> (org-babel-execute-src-block)))))
>>
>> +(ert-deftest test-ob-python/async-simple-session-output ()
>> + (let ((org-babel-temporary-directory "/tmp")
>
> Prefer `temporary-file-directory' to hard coding "/tmp".
>
> Thanks.
^ permalink raw reply [relevance 89%]
* Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil
2021-09-19 13:13 92% ` Timothy
@ 2021-08-31 11:59 89% ` Timothy
1 sibling, 1 reply; 200+ results
From: Timothy @ 2021-08-31 11:59 UTC (permalink / raw)
To: Morgan Willcock; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
Hi Morgan,
> I’ve attached a patch to fix an issue where tab characters are generated by
> the ASCII exporter when `indent-tabs-mode’ has its default value of t.
Thanks for finding this bug, fixing it, and sending us it 🙂. I was able to
reproduce your test case with “emacs -Q” (thanks for that, by the way).
As you suspected, with the small number of changed lines, this would be fine to
accept without FSF assignment.
However, your “patch” seems to consist of a diff at the bottom of your email and
a commit message at the top?? It would be preferable if you could provide a
“proper” patch, that way you can get attribution for your help instead of just
someone committing it on your behalf.
All the best,
Timothy
^ permalink raw reply [relevance 89%]
* Re: [PATCH] Add support for $…$ latex fragments followed by a dash
@ 2022-01-28 16:37 89% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-01-28 16:37 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]
Hi Max,
> There is no point to discuss deprecation of $…$ and ... while usage of
> such constructs is not discouraged by the org manual
Isn’t the point of discussing depreciation now that we’d change the manual etc.
to discourage it? 😛
FWIW, I have an extra 2c to add: I think that there’s a danger in having $…$
/almost/ behave like LaTeX, as the closer it is the more surprising the edge cases
are, and due to the nature of Org there will /always/ be a collection of edge
cases with $…$. By comparison, \(…\) has much less ’surprising’ behaviour.
>> If we do deprecate support for $…$, it might also be a good idea to
>> see if we can add a utility function which would make it easier for
>> people to migrate existing documents to the new/alternative syntax. For
>> the same reason it is hard to reliably parse $…$ syntax, we probably
>> can’t automate that transition, but we should be able to reduce the effort
>> required to update existing documents.
Tim, as mentioned before I’m strongly in favour of a ~half decade transition
including utility functions to shift existing TeX constructs to LaTeX, and
adding warnings, well before dropping support.
All the best,
Timothy
^ permalink raw reply [relevance 89%]
* Re: Subject: [PATCH] Fix DISPLAY error on exporting org with plantuml to html
@ 2021-11-30 4:18 90% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-30 4:18 UTC (permalink / raw)
To: Sun Lin; +Cc: Bastien Guerry, marcowahlsoft@gmail.com, emacs-orgmode@gnu.org
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
Hi Sun,
> Can any help merge the patch? Or should I request Bastien to merge the patch?
Thanks for not forgetting about this. As I commented before, I this looks
sensible enough to apply, and so I’ve just pushed it as f9dcc3d with a tweaked
commit message.
You’ve also been added to the list of TINYCHANGE contributors on
<https://orgmode.org/worg/contributors.html>. If you submit more than 20
cumulative lines of non-trivial code, you’ll need to get FSF assignment.
Thanks for sharing the issue and making a patch for it 🙂 hopefully we’ll see
you around in the future.
All the best,
Timothy
^ permalink raw reply [relevance 90%]
* Re: [PATCH] Enhance org-html--build-meta-info
@ 2020-12-14 7:27 90% ` TEC
0 siblings, 0 replies; 200+ results
From: TEC @ 2020-12-14 7:27 UTC (permalink / raw)
To: Bastien; +Cc: Jens Lechtenboerger, org-mode-email
Bastien <bzg@gnu.org> writes:
> Can we approach this with two patches, one with the refactoring and
> one with the added functionality?
Sure :) I'll take care of this when I get home in a few hours.
> This sounds useful.
Glad to hear!
> I think "Org Export" as the default is counter-intuitive, let's stick
> to the empty string. (Also, this kind of "small" changes should be
> made with consideration of all exporters.)
In case of confusion, this isn't replacing the #+title in the document,
just the <title>...</title> which is used as the tab content.
I just find blank tabs to be quite unhelpful, particularly when nestled
among others.
I'm not really aware of anything analogous in other exporters. Maybe the
metadata in exported PDFs ... but that doesn't exactly show up in
browser tabs :P
> Nope, the first line of a docstring should be a sentence. You'll have
> to reformulate the beginning of the docstring...
I'll take care of this with the patch separation.
Thanks for the feedback!
Timothy.
^ permalink raw reply [relevance 90%]
* Supported Emacs version (was: [PATCH] Fix window width when line numbers present)
@ 2021-11-22 5:51 90% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-22 5:51 UTC (permalink / raw)
To: Bastien; +Cc: Matt Huszagh, emacs-orgmode, Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 817 bytes --]
Hi Bastien,
> Our commitment is that the latest Org version is compatible with the
> last three stable versions of Emacs.
>
> So when Emacs 28 and Org 9.6 are both out, we guarantee that Org is
> compatible with Emacs 28, 27 and 26.
>
> Does that explain it better?
Thanks for clarifying. That’s perfectly clear, and re-reading the content of
<https://orgmode.org/worg/org-maintenance.html#emacs-compatibility> I think that
is too and I just must have read it strangely the first time??
On the topic of Emacs version compatibility, I’ve just taken a peek at
org-compat.el and notice that we still have code for Emacs < 24.4 compatibility.
I’m tempted to make some patches to remove all the Emacs < 26 compatibility code
if we no longer need it. What do you think?
All the best,
Timothy
^ permalink raw reply [relevance 90%]
* Re: [PATCH] Allow LaTeX reference command (\ref) to be customised
@ 2021-06-09 13:36 90% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-06-09 13:36 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: org-mode-email
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> I agree there is no good reason to hard-code "\ref", but, off the top of
> my head, there may be a couple of things to consider:
>
> 1. There is still a dangling \ref in `org-latex-footnote-defined-format';
I noticed this, but looking at the usage I think the user would be
surprised if changing \ref for sections, figures etc. also changed how
footnotes looked.
> 2. This change is already somewhat trivial using a link filter:
>
> (defun my-ref-link-filter (s &rest _)
> (replace-regexp-in-string (rx string-start "\\ref") "\\foo" s nil t))
>
> (add-to-list 'org-export-filter-link-functions #'my-ref-link-filter)
As are many things :P but I think it's worth making some more obvious to
users, and IMO this is worth it.
> 3. \hyperref is still hard-coded in `org-latex-link'; your patch could
> look like a partial solution.
A reference with a named description does use hyperref, but I think
that would still be expected --- let me know if you think otherwise
though.
> Those are not strong objections, so if you think none of them is worth
> considering, then I'm fine with your patch.
If what I've said above makes sense, I think it would be good to merge 👍.
All the best,
Timothy.
^ permalink raw reply [relevance 90%]
* Re: [PATCH] Have C-c C-c recognise #+plot lines
@ 2021-04-30 12:16 90% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-30 12:16 UTC (permalink / raw)
To: Eric S Fraga; +Cc: Bastien, emacs-orgmode@gnu.org
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> I have updated org. Problem persists.
>
> Attached is a full backtrace after hitting C-u C-c C-c on a table. The
> document itself has 2 headings and a small table.
>
> I unfortunately cannot spend more time on this at the moment as I have a
> presentation to make this afternoon and it's not quite ready...
Thank you for taking the time to check this in what sounds like a busy
day, and the backtrace. It's much appreciated :)
It seems like for you (org-element-property :post-affiliated context)
was unexpectedly nil. (or 0 ...) would be a quick-fix, but I find it odd
that this is a issue, and am yet to be able to reproduce this myself.
Is anybody else willing to try this and weigh in?
--
Timothy
p.s. Good luck with the presentation!
^ permalink raw reply [relevance 90%]
* Re: [PATCH] Accept more :tangle-mode specification forms
@ 2021-11-29 18:57 91% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-29 18:57 UTC (permalink / raw)
To: Tim Cross; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
Hi Tim,
> I’ll let you (/the ML) know when I’ve taken a look at stiky bits, and whether I
> think I’m able to create something that works. My intuition is that if ls -l can
> properly represent sticky bits (and my rudimentary understanding is that it can)
> it should be fine for specifying them too. We’ll see.
I’ve gone away and had a look, then come back and had a think. This has resulted
in 9ce7802. Since we just have to worry about suid/sgid (as :tangle-mode is only
applied to the file produced [with the sticky bit being dir-specific]), not much
is required — we just allow the `s' in place of `x' for the user/group executable
flag.
This is pretty trivial as we’re still relying on `file-modes-symbolic-to-number'
for this, and in a very straight-forward way. So, I think we should be fine now 🙂.
All the best,
Timothy
^ permalink raw reply [relevance 91%]
* Re: [PATCH] org-cite: Use citeproc-el to create CSL processor itemgetters
@ 2021-09-20 12:29 91% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-20 12:29 UTC (permalink / raw)
To: András Simonyi; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
Hi András,
Great to see this patch from you 🙂.
> this is the first item in a series of oc-csl patches which I’ve
> accumulated and am planning to send this week. (My first attempt to
> send a patch, so please be patient and forgiving :-) )
This may be your first attempt sending a patch, but it all looks good to me.
Simply attaching a `.patch' file is all that’s needed, and you seem to be
following our commit message guidelines, which is good to see.
Regarding the content of this patch and the few you have planned that follow —
would it be fair to say that overall you’re trying to update `oc-csl' based on
changes you’ve made to `citeproc-el' since `oc-csl' was written?
All the best,
Timothy
^ permalink raw reply [relevance 91%]
* Faces for inline src blocks (was: [PATCH] Fontification for inline src blocks)
@ 2021-12-02 13:57 91% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-12-02 13:57 UTC (permalink / raw)
To: Eric S Fraga; +Cc: org-mode-email
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
Hi Eric,
> However, I am finding the result not very pleasing unfortunately.
> Specifically, I am not happy with the use of other pre-existing faces
> (shadow and org-meta-line) for this purpose. These other faces have
> their specific uses and the resulting combination for inline src blocks,
> for me, is ugly. I do not wish to modify those faces for this use case
> as it will affect their use everywhere else.
Yep, I’ve been quite open to the prospect of adding faces, just not entirely
sure how much / what I should do. Since I didn’t want that block this feature
we’ve currently got the one-face version.
The various elements that could have a face are:
⁃ the src_ prefix
⁃ the lang component
⁃ headers
⁃ the square brackets delimiting the headers / curly brackets delimiting the content
⁃ the content
⁃ the whole block (this is what currently has a dedicated face)
Let me know what your thoughts are.
All the best,
Timothy
^ permalink raw reply [relevance 91%]
* Re: [PATCH] Support #+include-ing URLs
@ 2022-06-07 11:27 91% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-06-07 11:27 UTC (permalink / raw)
To: Fraga, Eric; +Cc: Max Nikulin, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
Hi Eric,
>> Is it possible to disable fetching remote files by some setting?
>
> I would not want automatic retrieval of URLs without confirmation.
This already occurs with #+setupfile.
I think this is a good point to raise, but a slightly separate one as it
concerns the pre-existing behaviour of org-file-contents.
A new patch set introducing a defcustom with three values (t, prompt, nil) and
accompanying modification to org-file-contents (it’s the only use of
`url-retrieve-synchronously' other than org-feed I see) would probably be a decent
idea. If nobody makes such a patch in the next week or so I’ll take a punt at
this.
All the best,
Timothy
^ permalink raw reply [relevance 91%]
* Re: [PATCH] Fix regex for determining image width from attribute
@ 2021-11-22 8:29 91% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-22 8:29 UTC (permalink / raw)
To: Matt Huszagh; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
Hi Matt,
> Unfortunately, I think this makes a valid use case
> impossible. Specifically, I like to be able to set an image width
> explicitly with #+attr_org (or some other attr_ for the corresponding
> export) and fall back to the actual image width when this isn’t
> specified. This includes the ability to use the actual image width in an
> org buffer, but an explicitly-set image width for export. For example,
> for my blog I often have attr_html set, but I want the image to use its
> actual width when displayed in org.
Thanks for explaining a use case! That’s most helpful.
> I don’t see how this is possible with the current implementation.But, it
> works naturally with the implementation I have in mind
Actually, it’s almost possible with the current implementation. Consider this
example:
┌────
│ #+attr_org: :width t
│ #+attr_html: :width 20%
│ [[file:image.png]]
└────
At the moment Org tries to interpret `t' as a number (and obviously fails),
however with a small tweak that I think would be very reasonable to make, this
would cause the behaviour you describe.
What do you think?
> (IIRC this is how it previously worked, but I could be mistaken).
You are mistaken. The previous implementation looked for `#+attr_*' too, but
didn’t recognise proportional values.
> Maybe a solution to accomplish all goals would be to add an #+attr_fallback
> (or attr_default, attr_any, attr_all, etc.) that is used for any backend
> unless a specific setting is made for that backend.
Hmmm, I’m not sure this is called for.
All the best,
Timothy
^ permalink raw reply [relevance 91%]
* Re: [PATCH] Add org-meta*-final-hook
@ 2021-04-25 6:31 91% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 6:31 UTC (permalink / raw)
To: Jay Bosamiya; +Cc: emacs-orgmode
Hi Jay,
Apologies for how incredibly long it's taken for someone to reply to
your email. It looks like this is your first contribution, so please
don't think this is the norm 😅, you just seemed to slip through the
cracks.
Jay Bosamiya <jaybosamiya@gmail.com> writes:
> Similar to org-shiftup-final-hook, org-shiftdown-final-hook, etc, I have
> added org-metaup-final-hook, org-metadown-final-hook, etc. Please see
> attached patch.
This seems consistent with what we already have, and so a good addition 👍.
> Please do let me know if any changes are required.
It looks like you have >15 lines changed here, so this is not eligible
to be a TINYCHANGE, i.e. we require FSF assignment
(see: https://orgmode.org/contribute.html#copyright) if you haven't got
this already.
--
Timothy
^ permalink raw reply [relevance 91%]
* Re: [PATCH] LaTeX export: arbitrary float environments
@ 2021-05-01 11:08 91% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-05-01 11:08 UTC (permalink / raw)
To: Thomas S. Dye; +Cc: emacs-orgmode
Hi Thomas,
On the surface, this looks reasonable to me :)
Just commenting on some technicalities with the patch itself:
- In ORG-NEWS it would be good to wrap the content over multiple lines
instead of having a single 270 char line :)
- You seem to have an anomalous change to the ob-python :return entry
- I don't think your patch subject follows the convention for Org, it
should be:
"main file/feature: overall change summary"
so, something like
"ox-latex: allow for arbitrary float environments"
rather than
"LaTeX export: arbitrary float environments"
Thanks for the patch :)
Timothy
^ permalink raw reply [relevance 91%]
* Re: [PATCH]
@ 2021-04-28 3:53 91% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-28 3:53 UTC (permalink / raw)
To: Bastien; +Cc: org-mode-email
Bastien <bzg@gnu.org> writes:
> Feel free to install changes when they have reached consensus,
> or to ask for decisions when not.
Thanks for the reply Bastien, would you mind elaborating on this a bit
more? I'm comfortable with the idea of what I can do with org-plot.el as
the maintainer (directly push, but field patches to the ML for
non-trivial changes), but as a non-core-contributor I didn't think I
could push my own patches for other things.
Also, with the batch of patches I sent a plea about recently, how would
you recommend I proceed with that? There doesn't seem to be any
consensus or decision despite prompting.
Thanks,
Timothy
^ permalink raw reply [relevance 91%]
* Re: [PATCH] New remote resource download policy
@ 2022-07-16 9:47 91% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-07-16 9:47 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]
Hi Max,
I’ve just made a few more tweaks, tested it, and pushed this as 0583a0c. We may
want to tweak this further before the next Org release, but I think this is a
good enough starting point.
> An idea: a menu entry that displays location in the org file that caused the
> prompt. However it may require enough work to pass context data to the function
> rendering menu.
This could be added in future.
> I see you point concerning blocking modal prompt and I do not like it as well.
> Have you seen the following thread:
>
> Arthur Miller. Proposal: ’executable’ org-capture-templaes. Wed, 22 Jun 2022
> 14:13:51 +0200.
> <https://list.orgmode.org/AM9PR09MB49771CF015DAECBF3E5F955E96B29@AM9PR09MB4977.eurprd09.prod.outlook.com>
>
> If it were merged already, would it be enough for you to implement the dialog or
> the proposal lacks some features necessary for smooth user experience?
I have not read much of this thread, but from a brief glance — possibly.
> The reason why I asked about `org-mks’ is expectation of UI consistency withing
> Org. It might help users having customized `display-buffer-alist’
Here I was more thinking of UI consistency within Emacs.
> I still do not like code adding a menu close enough to existing one, but I will
> not object any more.
Since this is separate to the functionality, I’m going to push this for now, and
we can update the UI side of things later.
All the best,
Timothy
^ permalink raw reply [relevance 91%]
* Re: [PATCH] Async session eval (2nd attempt)
@ 2021-03-01 6:22 91% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2021-03-01 6:22 UTC (permalink / raw)
To: Jack Kamm; +Cc: emacs-orgmode
Jack Kamm <jackkamm@gmail.com> writes:
> I'm attaching an updated patch rebased on master.
Fantastic. Thanks for doing this.
> ob-python session blocks don't use "return", so this should just be:
Ah, oops 😛
> The non-session case is substantially different, and I think it would
> probably require a separate implementation.
I see, fair enough. I haven't looked at the internals myself.
> One possible approach would be to modify ob-eval.el, so that
> org-babel--shell-command-on-region uses make-process instead of
> process-file.
>
> I agree it would be nice to have, but it would take a bit of work to
> figure it all out, and there is already ob-async.el [1] that implements
> non-session async for all languages. (I wish it could be brought into
> org-mode, but it probably can't, because it depends on the external
> async.el.)
Interesting that you use a different async method.
>> p.s. After this is merged, it would be great to see support for other
>> languages grow :)
>
> I also have an async implementation for ob-R that's ready after this is
> merged :)
Brilliant! I can't wait.
I know Bastien has found himself unfortunately busy as of late (which I
think is why he's looking to have someone else take over as project
lead), but please don't be disheartened by the slow progress with
getting this merged! I can assure you that quite a few people are
watching this with keen interest :)
All the best,
Timothy.
^ permalink raw reply [relevance 91%]
* Re: [PATCH] ox-md.el export code blocks using grave accents.
@ 2021-04-27 10:18 91% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-27 10:18 UTC (permalink / raw)
To: Bruce D'Arcus; +Cc: Tim Cross, emacs-orgmode
Bruce D'Arcus <bdarcus@gmail.com> writes:
> On Sat, Jan 30, 2021, 6:29 PM Tim Cross <theophilusx@gmail.com> wrote:
>
>> There are no precise standards for markdown, but org states in the
>> manual that the version of markdown it supports is that defined at
>> http://daringfireball.net/projects/markdown
>
> Perhaps at some point it would make sense to change to this, which is
> much more precisely specified:
>
> https://commonmark.org/
The only change I'd think would be worthwhile, is to complicate ox-md by
introducing the concept of styles/presets.
Even just commonmark has multiple ways you can do things (backticks and
spaces for code), and I'd think supporting a set like: Gruber's
original, commonmark, and GFM would make sense.
Alternatively, we can leave that to other backends like ox-gfm.
Basically: markdown is a mess and I'm not sure what would be a good
course of action.
--
Timothy
^ permalink raw reply [relevance 91%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
@ 2021-01-03 10:25 92% ` TEC
0 siblings, 1 reply; 200+ results
From: TEC @ 2021-01-03 10:25 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Hi Juan,
Thanks for your patch.
This looks like a fairly sensible addition. Two comments from me:
1. I'm not sure that "options" is a good name for arbitrary LaTeX which
is included inside the verse block. Perhaps something like "insert"
or "include", etc. may be a better fit.
2. It's considered generally nice to document features like this :) The
two documents which I'd think to note this in are ORG-NEWS and the
manual (docs/manual.org).
All the best,
Timothy.
Juan Manuel Macías <maciaschain@posteo.net> writes:
> (Sorry, due to a mistake, the text of my message did not appear in my previous email)
>
> Hi,
>
> I would like to propose this patch to add some LaTeX attributes to the verse block,
> especially to be able to apply certain features from the verse.sty package, which is an
> extension (widely used in Humanities) of the standard LaTeX 'verse' environment.
>
> These attributes would be:
>
> - `:lines' to add verse numbers, according to any numbering sequence
> - `:center' to apply the optical centering of the poem, which is a typographic convention
> whereby a poem or a group of verses is centered on the page, taking the width of the
> longest verse as a reference. In fact, optical centering is the correct arrangement of
> verses in a document.
> - `:versewidth' which expects a text string that is the longest verse of the poem,
> required when applying the `:center' attribute.
>
> As I said, these three attributes require the LateX package verse.sty. A fourth `:options'
> attribute would be used to add arbitrary code within the verse environment.
>
> Consider this complete example with Shakespeare's first sonnet:
>
> #+begin_src org
> ,#+ATTR_LaTeX: :center t :options \small :lines 5
> ,#+ATTR_LaTeX: :versewidth Feed’st thy light’st flame with self-substantial fuel,
> ,#+begin_verse
> From fairest creatures we desire increase,
> That thereby beauty’s rose might never die,
> But as the riper should by time decrease,
> His tender heir mught bear his memeory:
> But thou, contracted to thine own bright eyes,
> Feed’st thy light’st flame with self-substantial fuel,
> Making a famine where abundance lies,
> Thyself thy foe, to thy sweet self too cruel.
> Thou that art now the world’s fresh ornament
> And only herald to the gaudy spring,
> Within thine own bud buriest thy content
> And, tender churl, makest waste in niggarding.
> Pity the world, or else this glutton be,
> To eat the world’s due, by the grave and thee.
> ,#+end_verse
> #+end_src
>
> when exporting to LaTeX we get:
>
> #+begin_src latex
> \settowidth{\versewidth}{Feed’st thy light’st flame with self-substantial fuel,}
> \begin{verse}[\versewidth]
> \poemlines{5}
> \small
> From fairest creatures we desire increase,\\
> That thereby beauty’s rose might never die,\\
> But as the riper should by time decrease,\\
> His tender heir mught bear his memeory:\\
> But thou, contracted to thine own bright eyes,\\
> Feed’st thy light’st flame with self-substantial fuel,\\
> Making a famine where abundance lies,\\
> Thyself thy foe, to thy sweet self too cruel.\\
> Thou that art now the world’s fresh ornament\\
> And only herald to the gaudy spring,\\
> Within thine own bud buriest thy content\\
> And, tender churl, makest waste in niggarding.\\
> Pity the world, or else this glutton be,\\
> To eat the world’s due, by the grave and thee.\\
> \end{verse}
> #+end_src
>
> In an attached image I send a screenshot with the typographic result
>
> And finally, this is the patch I would propose
>
> #+begin_src diff
> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index 2a14b25d5..bc6b64e78 100644
> --- a/lisp/ox-latex.el
> +++ b/lisp/ox-latex.el
> @@ -3506,6 +3506,16 @@ channel."
> "Transcode a VERSE-BLOCK element from Org to LaTeX.
> CONTENTS is verse block contents. INFO is a plist holding
> contextual information."
> +(let*
> + ((lin (org-export-read-attribute :attr_latex verse-block :lines))
> + (opt (org-export-read-attribute :attr_latex verse-block :options))
> + (cent (org-export-read-attribute :attr_latex verse-block :center))
> + (attr (concat
> + (if cent "[\\versewidth]" "")
> + (if lin (format "\n\\poemlines{%s}" lin) "")
> + (if opt (format "\n%s" opt) "")))
> + (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
> + (vwidth-attr (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")))
> (concat
> (org-latex--wrap-label
> verse-block
> @@ -3513,7 +3523,9 @@ contextual information."
> ;; character and change each white space at beginning of a line
> ;; into a space of 1 em. Also change each blank line with
> ;; a vertical space of 1 em.
> - (format "\\begin{verse}\n%s\\end{verse}"
> + (format "%s\\begin{verse}%s\n%s\\end{verse}"
> + vwidth-attr
> + attr
> (replace-regexp-in-string
> "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
> (replace-regexp-in-string
> @@ -3524,7 +3536,7 @@ contextual information."
> info)
> ;; Insert footnote definitions, if any, after the environment, so
> ;; the special formatting above is not applied to them.
> - (org-latex--delayed-footnotes-definitions verse-block info)))
> + (org-latex--delayed-footnotes-definitions verse-block info))))
> #+end_src
>
> Regards,
>
> Juan Manuel
^ permalink raw reply [relevance 92%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
[not found] ` <87tunlxws3.fsf@ucl.ac.uk>
@ 2021-05-02 11:31 92% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-05-02 11:31 UTC (permalink / raw)
To: Eric S Fraga; +Cc: Bastien, Juan Manuel Macías, emacs-orgmode
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> Is the verse package loaded automatically already? I did not see any
> change in the patch to that aspect and when I export a simple test, the
> package is not loaded.
Wouldn't it be nice if there was something in-between loading the
kitchen sink and manually adding packages*... [ foreshadowing ;) ]
--
Timothy
* My prototype is now rather stable and I like the interface, I'm just
wondering if I should generalise it for arbitrary backends or keep it
as LaTeX-only, but don't let me take this thread on a tangent over
this. I just thought it was worth mentioning.
^ permalink raw reply [relevance 92%]
* Re: [PATCH] tweaks to ox-html style
@ 2021-02-12 18:22 92% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-02-12 18:22 UTC (permalink / raw)
To: Jens Lechtenboerger; +Cc: Kyle Meyer, org-mode-email
Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:
> On 2021-02-12, Jens Lechtenboerger wrote:
>
>> I do not know why the CDATA lines exist. I don’t see a reason to
>> keep them (patch 0001), but that might be a lack of understanding on
>> my part.
>
> OK, that is probably for XHTML, where < and & are only allowed
> inside CDATA sections.
>
> Timothy, did you try to validate XHTML output?
If you look at the commit message for 001, you can see the following:
> remove CDATA strings, as they are now
> considered obsolete --- see
> https://developer.mozilla.org/en-US/docs/Web/API/CDATASection#specifications
Does that page clear things up for you?
I did a bit more googling and found
https://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5
which mentions CDATA:
> The CDATA code is then seen as text by the HTML parser (and can thus
> interfere with the scripting or styling language!), while the XML
> parser sees the content as text without markup semantics.
In other words, CDATA allows you to keep XML comparability, but now
breaks strict HTML comparability. IMO the latter is much more important
for an org-html export.
--
Timothy
^ permalink raw reply [relevance 92%]
* Re: [PATCH] ob-R output file with graphics parameter
@ 2021-07-03 4:52 92% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-07-03 4:52 UTC (permalink / raw)
To: Jack Kamm; +Cc: Colin Baxter, Berry, Charles, emacs-orgmode
Jack Kamm <jackkamm@gmail.com> writes:
> I think it would still make sense though, and would be beneficial beyond
> ob-R. According to [1], the "graphics" and "link" arguments don't do
> anything unless used with "file", so it would make sense for them to
> automatically add the "file" argument.
Mmmm, I think it would be good if we could make it so it's generally
less effort to create plots.
Would it be strange if running the code block with just
:output graphics
Automatically added "link" if *only* graphics is set, and generated a
file name if no :file is set?
I think it would be nice if I could declare a "figures directory"
(default to "/tmp" or "."?) for exactly this.
--
Timothy
^ permalink raw reply [relevance 92%]
* Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil
@ 2021-09-19 13:13 92% ` Timothy
2021-08-31 11:59 89% ` Timothy
1 sibling, 1 reply; 200+ results
From: Timothy @ 2021-09-19 13:13 UTC (permalink / raw)
To: Morgan Willcock; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 646 bytes --]
Hi Morgan,
I’ve just taken a look at your patch (it `git am's just fine), since nobody else
seems to have had the time to look at your patch as of late. There’s one thing
which I now realise completely slipped by me last time — why are tabs bad?
Maybe I’m missing something obvious, but exporting with tabs and viewing/`cat'ing
the file everything looks fine to me in terms of alignment.
Morgan Willcock <mwillcock@precedence.co.uk> writes:
> I’ve attached a patch to fix an issue where tab characters are generated by
> the ASCII exporter when `indent-tabs-mode’ has its default value of t.
All the best,
Timothy
^ permalink raw reply [relevance 92%]
* Re: [PATCH] Babel: remove LaTeX environment -type #+results
@ 2021-04-25 18:09 92% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 18:09 UTC (permalink / raw)
To: Greg Minshall; +Cc: org-mode-email
Greg Minshall <minshall@umich.edu> writes:
> Timothy,
>
> interesting. would this show up in #+RESULTS blocks? in (heaven
> forbid!) #+BEGIN_SRC blocks?
>
> cheers, Greg
The screenshot where it shows up is from the following Org buffer
(manually constructed for the example):
#+begin_src julia
[1 2; 3 4]
#+end_src
#+RESULTS:
\begin{equation}
\left[
\begin{array}{cc}
1 & 2 \\
3 & 4 \\
\end{array}
\right]
\end{equation}
#+begin_src julia
using Symbolics
@variables t
2^sin(t) + cos(t)/t
#+end_src
#+RESULTS:
\begin{equation}
\frac{\cos\left( t \right)}{t} + 2^{\sin\left( t \right)}
\end{equation}
The rendering is just done by `org-latex-preview'.
Hope that clears things up.
--
Timothy
^ permalink raw reply [relevance 92%]
* Re: Subject: [PATCH] Fix DISPLAY error on exporting org with plantuml to html
@ 2021-11-18 7:38 92% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-18 7:38 UTC (permalink / raw)
To: Sun Lin; +Cc: emacs-orgmode
Hi Sun,
> [snipped patch description]
> Please help review the patch. Thanks.
> [2. text/x-patch; 0001-Fix-DISPLAY-error-on-exporting-org-with-plantuml-to-.patch]...
Thanks for your patience. This looks quite straight-forward. I don't use
or have plantuml so I'm in a poor position to test.
However, I can use google, and it seems that -Djava.awt.headless=true
just uses Java for some graphics operations which are normally delegated
to the system graphics stack.
This seems rather safe to me, and so I'd be inclined to take your word
that this is a beneficial change and merge the patch.
All the best,
Timothy
^ permalink raw reply [relevance 92%]
* Re: [PATCH] Fix window width when line numbers present
2021-11-21 19:19 93% ` Timothy
@ 2021-11-21 19:14 92% ` Timothy
1 sibling, 1 reply; 200+ results
From: Timothy @ 2021-11-21 19:14 UTC (permalink / raw)
To: Matt Huszagh; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 916 bytes --]
Hi Matt,
> This is a very small patch that I believe fixes a previous, incorrect
> fix for computing the window text area when line numbers are
> present. The previous fix seemed to assume that
> display-line-numbers-width being nil meant that this means line numbers
> are not present. However, it can also mean (as described in the
> variable documentation) that the line number width is computed
> dynamically.
Thanks for this patch. I wasn’t aware of `line-number-display-width' when I wrote
that, but it looks like a better fit than my `(or ... 0)' statement. As such, I’ve
just applied your patch as cd3e138, tweaking the commit message to no longer go
over the maximum length :)
Looking at the docstring for `line-number-display-width', it seems that the
pixelwise mode may be more useful for our purposes, but that improvement can be
in a subsequent patch.
All the best,
Timothy
^ permalink raw reply [relevance 92%]
* Re: [PATCH] Include support for evaluating julia code
@ 2021-09-24 20:04 92% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-09-24 20:04 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 522 bytes --]
Hi Pedro,
Thanks for your patch, it’s great to see the interest in Julia support and it’s
something that I absolutely think should be in org-core 🙂. However, ob-julia.el
was moved into org-contrib because it was not well maintained, and very buggy.
I’m actually currently working on a successor with Nicolò (see the linked repo)
in my free time, and intend to submit that to Org when I feel it is mature
enough. See <https://github.com/nico202/ob-julia/> for more information.
All the best,
Timothy
[-- Attachment #1.2: Type: text/html, Size: 4044 bytes --]
^ permalink raw reply [relevance 92%]
* Re: [PATCH] Don't fill displayed equations
@ 2021-10-02 11:24 92% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-10-02 11:24 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
Hi Nicolas,
> *snip lots of text*
Thanks for going through my points in detail. I think I understand your
perspective much better now. At this point though, I’m not really sure what to
make of `\[ ... \]', I now feel like it’s sitting in some sort of markup limbo
where it can’t be either fully LaTeX-y or fully Org-y. I still think it would be
good to improve this, but I no longer have such a firm idea that “modifying fill
is the way”.
All the best,
Timothy
^ permalink raw reply [relevance 92%]
* Re: [PATCH] Fix match/maxlevel conflict in colview dynblock
@ 2021-08-31 14:33 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-08-31 14:33 UTC (permalink / raw)
To: Nick Dokos; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]
Hi Nick,
Thanks for reporting this issue here, and providing a patch. Unfortunately the
“main maintainers” seem to be rather busy as of late, leaving you hanging for
quite a while. I’ve had a look at the issue and your patch, and it the issue
seems clear, and your patch small and straightforward enough that I feel
confident pushing it should be fine :) it’s now on master with a small tweak to
the commit message.
Thanks for your efforts.
> Specifying both `maxlevel’ and `match’ in a columnview dynamic block
> was broken: the `match’ argument is ignored in that case. See the link
> below for a (not so minimal) ECM.
>
> Reported-by: Pablo A Perez-Fernandez
> Link: <https://emacs.stackexchange.com/questions/66658/filter-columnview-dblock-on-properties-or-tags>
>
> –
> Nick
>
> “There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors.” -Martin Fowler
>
> From 8bcff482e59c24758f87b9b5cdef3bc123dc12f8 Mon Sep 17 00:00:00 2001
> From: Nick Dokos <ndokos@gmail.com>
> Date: Sun, 11 Jul 2021 22:30:22 -0400
> Subject: [PATCH] Fix match/maxlevel conflict in colview dynblock
>
> * lisp/org-coplview.el (org-columns–capture-view): Combine the match
> and maxlevel arguments properly to construct the MATCH argument of
> `org-map-entries’.
>
> Specifying both `maxlevel’ and `match’ in a columnview dynamic block
> does not work: the `match’ argument is ignored in that case. See the
> link below for a (not so minimal) ECM.
>
> Reported-by: Pablo A Perez-Fernandez
> Link: <https://emacs.stackexchange.com/questions/66658/filter-columnview-dblock-on-properties-or-tags>
> —
> lisp/org-colview.el | 5 +++–
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff –git a/lisp/org-colview.el b/lisp/org-colview.el
> index 2e1c29a99..7144308ff 100644
> — a/lisp/org-colview.el
> +++ b/lisp/org-colview.el
> @@ -1398,8 +1398,9 @@ other rows. Each row is a list of fields, as strings, or
> (org-get-tags))))
> (push (cons (org-reduced-level (org-current-level)) (nreverse row))
> table)))))
> - (or (and maxlevel (format “LEVEL<=%d” maxlevel))
> - (and match match))
> + (if match
> + (concat match (and maxlevel (format “+LEVEL<=%d” maxlevel)))
> + (and maxlevel (format “LEVEL<=%d” maxlevel)))
> (and local ’tree)
> ’archive ’comment)
> (org-columns-quit)
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Ready to merge! Re: [PATCH] Enhance org-html--build-meta-info
@ 2021-01-14 16:02 93% ` TEC
0 siblings, 0 replies; 200+ results
From: TEC @ 2021-01-14 16:02 UTC (permalink / raw)
To: Jens Lechtenboerger; +Cc: Bastien, org-mode-email
This thread has dragged on ages, and if no-one else is following this
chain I wouldn't blame them in the slightest.
To help indicate that this is actually ready (at last) now, I'm just
going to add that info the the subject line in the hope it helps Bastien
or any others notice that this is actually good to go now :)
--
Timothy
Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:
> This looks fine to me. Many thanks!
>
> Best wishes
> Jens
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ob-core: tangle check library of babel after current buffer
@ 2021-07-24 19:41 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-07-24 19:41 UTC (permalink / raw)
To: Tom Gillespie; +Cc: emacs-orgmode
Hi Tom,
Sorry that it's taken so long for someone to get to this. I've just
applied your patch to my local Org instance, and then tested the
described behaviour before and afterwards. I can confirm that the issue
reported exists, and that your patch fixes this.
In light of this and the two other positive reviews here, I feel it's
pretty safe, and so have applied this patch as f052acee5 :)
--
Timothy
Tom Gillespie <tgbugs@gmail.com> writes:
> Pinging on this to see if anyone can test it so that it can be merged.
> Tom
>
> On Wed, Jun 16, 2021 at 4:29 PM Tom Gillespie <tgbugs@gmail.com> wrote:
>>
>> Hi,
>> This is a patch that fixes tangling behavior when a block has been
>> ingested into the library of babel and then modified. Best!
>> Tom
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Accept more :tangle-mode specification forms
@ 2021-11-20 14:50 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-20 14:50 UTC (permalink / raw)
To: tomas; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
Hi Thomas (& co.),
>> […] I’m thinking either “o555” or “#o555” would be a good improvement over
>> “(identity #o555), but am open to other suggestions.
>
> That’s reasonable. I’d even tend to disallow decimal. In usage, it’s too
> exotic and the potential for someone entering “just a number” expecting
> for it to be read as octal is too high. Is it worth the risk?
I’ve just pushed three commits that
1. Add “o555” as an octal shorthand
2. Perform a simple check that integer modes are valid*
3. Make the ls-style regex stricter
> Timothy, I really admire your patience, and your incredibly friendly way
> of doing things :)
Thanks. It helps that this list is fairly friendly to begin with :)
All the best,
Timothy
* For example, “:tangle-mode 755” will now produce the warning:
“1363 is not a valid file mode octal. Did you give the decimal value 755 by
mistake?”. Maybe it would be worth adding “if so try o755” or similar?
^ permalink raw reply [relevance 93%]
* Re: [PATCH] New remote resource download policy
@ 2022-06-29 15:27 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2022-06-29 15:27 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]
Hi Max,
Max Nikulin <manikulin@gmail.com> writes:
>>> I see your intention to add something fancy to the dialog. May `org-mks’ be
>>> reused instead to avoid proliferation variants of rather similar UI code?
>> Well, the thing here is that I’m explicitly trying to mimic the
>> file-local-variable dialog, and since a general form isn’t exposed by Emacs, a
>> little bit of proliferation seems like the best option to me.
>
> From my point of view the result is rather close (prompt should be adjusted):
>
> (let ((uri “<https://orgmode.org>”))
> (org-mks
> nil
> (format “An org-mode document would like to download %s, which is not
> considered safe.
>
> Do you want to download this?”
> (propertize uri ’face ’(:inherit org-link :weight normal)))
> nil ; prompt
> `((,(propertize “!” ’face ’success)
> “download this resource, and permanantly mark it as safe.”)
> (,(propertize “y” ’face ’warning)
> “to download this resource, just this once.”)
> (,(propertize “n” ’face ’error)
> “skip this resource.”))))
I just tried this snippet and it looked quite different to me, that said I have
tweaked `org-mks' a bit in my config… (I initially found org-capture quite
ugly).
I also really don’t like how `org-mks' so forcefully grabs all keyboard input. I
can see it being nice to jump back to the buffer and see where the resource is
being used, which isn’t really possible using `org-mks'.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [patch] priorities range reversed
@ 2021-08-31 15:14 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-08-31 15:14 UTC (permalink / raw)
To: Joe Corneli; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]
Hi Joe,
Thanks for looking into this and figuring out a patch. I’ve just taken a peek at
your patches, and I have two minor comments:
⁃ Why use saved-position instead of save-excursion
⁃ I’m think ascii versions of ② et. al would be preferable
Also, I notice that your patches are just diffs and don’t have a commit message.
Are you planning on writing them later?
Joe Corneli via “General discussions about Org-mode.” <emacs-orgmode@gnu.org> writes:
> Actually, there some bigger problems with the function as well…
>
> — It didn’t update the priority cookie properly when one had been set before
>
> * [#1] Exercise: update to [#2]
>
> — After fixing that, I noticed that the included save-excursion doesn’t work
> (<https://emacs.stackexchange.com/questions/7574/why-save-excursion-doesnt-save-point-position>)
>
> So, here’s a more comprehensive patch, including the previous changes
> (in order to support numeric priorities) and then adjusting the
> update/insert logic so that it makes more sense.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* [PATCH] Enhance org-html--build-meta-info
@ 2020-09-17 13:50 93% TEC
0 siblings, 1 reply; 200+ results
From: TEC @ 2020-09-17 13:50 UTC (permalink / raw)
To: org-mode-email
[-- Attachment #1.1: Type: text/plain, Size: 374 bytes --]
Hi All,
This just replaces the current `org-html--build-meta-info' with a
cleaner, more
extensible (I also added a new variable) version. Please give it a look
and let
me know what you think!
Timothy.
<#part type="text/x-patch"
filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0001-lisp-ox-html.el-make-html-meta-func-nicer.patch"
disposition=inline>
<#/part>
[-- Attachment #1.2: Type: text/html, Size: 2250 bytes --]
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-plot abstractions and extension
@ 2020-09-25 17:51 93% ` TEC
2020-10-17 2:12 93% ` TEC
0 siblings, 1 reply; 200+ results
From: TEC @ 2020-09-25 17:51 UTC (permalink / raw)
To: org-mode-email
Hello everyone. Just in case this has slipped through the cracks /
fallen under the radar --- here's a little bump.
Timothy.
TEC <tecosaur@gmail.com> writes:
> Oooops, I've just noticed my patch attachment re-send was only addressed
> to Bastien (maybe this is why I haven't heard anything?).
> This is what I get for mixing mail clients and not paying attention
> I guess 😅.
>
> If someone would be willing to have a look through my work, and comment
> - that would be fantastic.
>
> I'd love to get my code into shape to be merged :)
>
> All the best,
>
> Timothy.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Enhance org-html--build-meta-info
@ 2020-09-27 18:35 93% ` TEC
0 siblings, 1 reply; 200+ results
From: TEC @ 2020-09-27 18:35 UTC (permalink / raw)
To: Jens Lechtenboerger; +Cc: org-mode-email
Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:
> On 2020-09-28, TEC wrote:
>
>> Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:
>>> Also, in org-html--build-meta-info you call
>>> org-html-encode-plain-text with two arguments, but it just
>>> accepts
>>> one.
>>
>> ? No I don't.
>
> Your patch contains this:
>
> + (let* ((title (org-html-encode-plain-text (plist-get info
> :title)
> info))
Ohhhh, that's the bit you were referring to. That's just copied
from the
current state (iirc). Anyway, I dropped the second argument.
Thanks,
Timothy.
^ permalink raw reply [relevance 93%]
* Re: PATCH: Display point of code block point when confirming evaluation
@ 2020-09-30 4:57 93% ` TEC
0 siblings, 0 replies; 200+ results
From: TEC @ 2020-09-30 4:57 UTC (permalink / raw)
To: Kyle Meyer; +Cc: Jarmo Hurri, emacs-orgmode
Kyle Meyer <kyle@kyleam.com> writes:
> That sounds reasonable to me, and the change looks fine to me.
> My only
> thought is that perhaps the line number would be friendlier to
> report,
> but I don't feel strongly about that.
+1 for line numbers
Assuming the current format is something like:
"Do you want to eval <lang> block at <pos> y/n:"
I'd be in favour of:
"Do you want to eval <lang> block at <pos> (line <line>) y/n:"
or similar.
All the best,
Timothy.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-plot abstractions and extension
2020-09-25 17:51 93% ` TEC
@ 2020-10-17 2:12 93% ` TEC
0 siblings, 1 reply; 200+ results
From: TEC @ 2020-10-17 2:12 UTC (permalink / raw)
To: org-mode-email
Hello all,
I'm still hoping that someone might get back to me ... eventually,
so here's another bump.
Timothy.
TEC <tecosaur@gmail.com> writes:
> Hello everyone. Just in case this has slipped through the cracks
> /
> fallen under the radar --- here's a little bump.
>
> Timothy.
>
> TEC <tecosaur@gmail.com> writes:
>
>> Oooops, I've just noticed my patch attachment re-send was only
>> addressed
>> to Bastien (maybe this is why I haven't heard anything?).
>> This is what I get for mixing mail clients and not paying
>> attention
>> I guess 😅.
>>
>> If someone would be willing to have a look through my work, and
>> comment
>> - that would be fantastic.
>>
>> I'd love to get my code into shape to be merged :)
>>
>> All the best,
>>
>> Timothy.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-plot abstractions and extension
@ 2020-12-09 2:58 93% ` TEC
1 sibling, 0 replies; 200+ results
From: TEC @ 2020-12-09 2:58 UTC (permalink / raw)
To: Bastien; +Cc: org-mode-email
It's now been 1.5 months, so I'm going to bump this thread.
--
Timothy
TEC <tecosaur@gmail.com> writes:
> Bastien <bzg@gnu.org> writes:
>
>> I'm not an org-plot.el user so I cannot test, but by reading the
>> patches, they look okay.
>>
>> Let's go in "optimistic merging" mode and commit your patches?
>
> Sounds good then. I don't expect the changes to compromise any
> existing
> functionality.
>
>> Is https://orgmode.org/list/87lfhbhfhe.fsf@gmail.com/ the latest
>> version I should use?
>
> I've smoothed a rough edge or two, and added a documentation
> entry.
>
> I'll attach all the patches to this email, so there's no
> ambiguity.
> (crosses fingers for attachments working as expected)
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-plot abstractions and extension
@ 2020-12-14 6:30 93% ` TEC
1 sibling, 0 replies; 200+ results
From: TEC @ 2020-12-14 6:30 UTC (permalink / raw)
To: Bastien; +Cc: org-mode-email
Bastien <bzg@gnu.org> writes:
> Applied, with minor modifications of the changelog entries:
>
> - You need to add an entry when creating a new custom variable.
>
> - I suggest saying "option" instead of "custom variable".
>
> - Sentences should be separated by two spaces and start with an
> uppercase letter.
>
> Also, the convention in Emacs is to avoid whitespaces-only commits,
> you need to fix whitespaces within other non-whitespaces changes in
> a commit.
Thanks for the feedback on the patches! I tried to get it right after my
previous (and first) attempt, but it looks like there are a few things I
still need to take note of. Big improvement though, nonetheless,
hopefully next time they'll be nothing to change :)
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Enhance org-html--build-meta-info
2020-12-20 5:08 93% ` TEC
@ 2020-12-20 5:08 93% ` TEC
1 sibling, 0 replies; 200+ results
From: TEC @ 2020-12-20 5:08 UTC (permalink / raw)
To: Jens Lechtenboerger; +Cc: Bastien, org-mode-email
Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:
>> For people who want to customise this to add metadata, the page title is
>> something they're probably interested in.
>
> What metadata would you derive from the title?
In my earlier example, I use the "og:title" property.
>> If so, I think it's work giving the title processed by
>> org-html--build-meta-info as it's not so simple as
>> (plist-get info :title).
>
> Extracting it from ~info~ might be more flexible as it would not be
> tied to the current implementation.
My thoughts are just that its seems like title/author may be handy, and
we've already worked those out, so why not just pass them along?
Could probably reduce to just info, not sure what's best though.
Other than this, is there anything else you think might be worth
considering before merging?
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Enhance org-html--build-meta-info
@ 2020-12-20 5:08 93% ` TEC
2020-12-20 5:08 93% ` TEC
1 sibling, 1 reply; 200+ results
From: TEC @ 2020-12-20 5:08 UTC (permalink / raw)
To: Jens Lechtenboerger; +Cc: Bastien, org-mode-email
Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:
>> For people who want to customise this to add metadata, the page title is
>> something they're probably interested in.
>
> What metadata would you derive from the title?
In my earlier example, I use the "og:title" property.
>> If so, I think it's work giving the title processed by
>> org-html--build-meta-info as it's not so simple as
>> (plist-get info :title).
>
> Extracting it from ~info~ might be more flexible as it would not be
> tied to the current implementation.
My thoughts are just that its seems like title/author may be handy, and
we've already worked those out, so why not just pass them along?
Could probably reduce to just info, not sure what's best though.
Other than this, is there anything else you think might be worth
considering before merging?
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-plot abstractions and extension
@ 2020-12-23 5:10 93% ` TEC
0 siblings, 0 replies; 200+ results
From: TEC @ 2020-12-23 5:10 UTC (permalink / raw)
To: Kyle Meyer; +Cc: Bastien, org-mode-email
Kyle Meyer <kyle@kyleam.com> writes:
> This series introduced some compiler warnings.
>
> Timothy, could you please submit a follow-up patch to address these?
Absolutely. Thanks for raising this, I'll take a look shortly.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Apply emacs manual css to org pages
@ 2020-12-28 4:04 93% ` TEC
0 siblings, 0 replies; 200+ results
From: TEC @ 2020-12-28 4:04 UTC (permalink / raw)
To: Samuel Wales; +Cc: org-mode-email
Hi Samuel,
We could add some of our own CSS, but that would have us deviate from
the Emacs manual. It's worth asking if we want to do that IMO.
--
Timothy
Samuel Wales <samologist@gmail.com> writes:
> i wonder if css makes it possible to have wider margins /except/ for
> tables and stuch. or perhaps that is consiedered bad style. but it
> would be accessible/functional. but i am just glad that it is only
> tables that need horizontal scrolling.
>
> On 12/27/20, Samuel Wales <samologist@gmail.com> wrote:
>> if i were to make any /tiny nit-level/ suggestions from my pov it
>> would be somewhat wider margins, not pure white but slightly [so still
>> /very/ high contrast] warmer for fg, and some less-blue for links [but
>> i realize blue is common].
>>
>> i would also do [ha ha, as if i knew what to do or even whether it is
>> possible] wrapping for left columns that go under text rather than
>> bullet for e.g this line: "• Extracting Agenda Information
>> Post-processing agenda information." set fonts large.
>>
>> these are without regard for emacs manual as i have not seen that
>> online recently. great job. thank you.
>>
>>
>> On 12/27/20, Samuel Wales <samologist@gmail.com> wrote:
>>> i like the black bg, the no issues with paragraph width.
>>>
>>>
>>> On 12/22/20, TEC <tecosaur@gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> This is a quick patch to use the Emacs manual CSS with our generated Org
>>>> manual.
>>>>
>>>> You can see what the single-page version of this looks like here:
>>>> https://tecosaur.com/resources/org/doc/manual.html and the multi-page
>>>> here: https://tecosaur.com/resources/org/doc/manual/
>>>>
>>>> This should be an easy upgrade to our online documentation :)
>>>>
>>>> --
>>>> Timothy
>>>>
>>>>
>>>
>>>
>>> --
>>> The Kafka Pandemic
>>>
>>> Please learn what misopathy is.
>>> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>>>
>>
>>
>> --
>> The Kafka Pandemic
>>
>> Please learn what misopathy is.
>> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>>
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ox-md.el/markdown-hyperlink
@ 2021-01-03 10:06 93% ` TEC
0 siblings, 0 replies; 200+ results
From: TEC @ 2021-01-03 10:06 UTC (permalink / raw)
To: turbo.cafe@clovermail.net; +Cc: emacs-orgmode
Thanks for the patch turbo.
I was able to test this with a simple Org file, and both observed the
issue with radio targets in generated markdown files, and observed the
patch fixing it, as intended.
--
Timothy
turbo.cafe@clovermail.net <turbo.cafe@clovermail.net> writes:
> exporting to markdown loses radio target hyperlinks.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ox-md.el/preserve radio target hyperlink
@ 2021-01-03 10:11 93% ` TEC
0 siblings, 0 replies; 200+ results
From: TEC @ 2021-01-03 10:11 UTC (permalink / raw)
To: nazar.stasiv@atk.sk; +Cc: emacs-orgmode
Hi turbo.
As this appears to be an exact duplicate of your other email, I'm going
to mark this as closed and hope that any/all conversation on your patch
happens there.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [patch] A proposal to add LaTeX attributes to verse blocks
@ 2021-01-03 10:22 93% ` TEC
0 siblings, 0 replies; 200+ results
From: TEC @ 2021-01-03 10:22 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Hi Juan,
Since you've resent this in a second email, let's discuss this patch
there.
As such, I'm marking this patch as closed.
--
Timothy.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Enhance org-html--build-meta-info
@ 2021-01-10 20:36 93% ` TEC
0 siblings, 1 reply; 200+ results
From: TEC @ 2021-01-10 20:36 UTC (permalink / raw)
To: Jens Lechtenboerger; +Cc: Bastien, org-mode-email
Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:
> Sorry, I still see the flycheck warning and "&amp;" for "&".
Maybe I accidently sent you the old patches? I'll check tomorrow.
--
Timothy.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] tweaks to ox-html style
@ 2021-01-20 11:00 93% ` TEC
2 siblings, 0 replies; 200+ results
From: TEC @ 2021-01-20 11:00 UTC (permalink / raw)
To: org-mode-email
Gah! I left the subject as a placeholder [shame emoji].
Apologies for that.
Why do I always seem to notice these things as the Email is sending...
--
Timothy
TEC <tecosaur@gmail.com> writes:
> Hi All,
>
> This is just some tweaks to the styling in ox-html that I think may
> appeal (and prevent ridiculously long lines on non-small displays, which
> are an issue for legibility).
>
> I also took the opportunity to remove the (obsolete) CDATA strings and
> make the CSS more consistently formatted. If you don't want this to
> get its own commit, please just squash it.
>
> Style changes:
> - Restrict max content width, and centre
> - tweak styling of source code blocks
>
> I took some screenshots (1440p monitor, 120% zoom, Firefox).
> Current: https://0x0.st/-iW9.png
> This patch: https://0x0.st/-iWp.png
>
> All the best,
>
> Timothy.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Enhance org-html--build-meta-info
@ 2021-01-21 5:55 93% ` TEC
0 siblings, 0 replies; 200+ results
From: TEC @ 2021-01-21 5:55 UTC (permalink / raw)
To: Kyle Meyer; +Cc: org-mode-email
Kyle Meyer <kyle@kyleam.com> writes:
> I've applied this (a8df7670c) with two minor changes (shown in the diff
> at end): s/with with/with/ in a docstring and move an element to its own
> line to avoid the warning from lisp-mode's lisp--match-hidden-arg.
Thanks :)
> This thread has gone on long enough that I'll avoid requesting changes
> for convention/style nits, but some things to keep in mind for future
> patches:
I'll try to keep these in mind in future. Might there be a Worg page or
something listing all of these little things so I don't keep on being
told of them a few at a time as I violate them?
> Also, it'd be good for this to be accompanied by a NEWS entry. I'd
> appreciated if that were sent in a separate thread, though. For some
> reason I haven't debugged, my usual MUA can't load this thread.
Will do 👍.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] document org-html-meta-tags
@ 2021-02-09 19:51 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-02-09 19:51 UTC (permalink / raw)
To: Kyle Meyer; +Cc: org-mode-email
Kyle Meyer <kyle@kyleam.com> writes:
> Thanks. Pushed (5b0eb9aad) with the tweaks mentioned below.
Great!
>> Oh, by the way --- [...]
>
> Sorry, I don't have the bandwidth at the moment for that discussion.
No problem, I mainly wanted to put the thought /somewhere/ --- which I
have now done :)
--
Timothy.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] tweaks to ox-html style
@ 2021-02-14 4:36 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-02-14 4:36 UTC (permalink / raw)
To: Christian Moe; +Cc: Tim Cross, emacs-orgmode
Regarding any use case which would benefit from turning
org-html-style-default into a defcustom, IMO there are two:
+ When you don't want to have to add a #+HTML_HEAD to every file you
export
+ When you want to include a long inline style (my use case)
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Use <img> tags for SVGs
@ 2021-04-07 11:29 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-07 11:29 UTC (permalink / raw)
To: org-mode-email
Timothy <tecosaur@gmail.com> writes:
> It's worth nothing that the current approach isn't just "not great", but
> actually causes some issues.
Oh, and for reference the W3C violation this fixes is:
"Attribute alt not allowed on element object"
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ob-tangle.el: Speed up tangling
@ 2021-04-21 8:02 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-21 8:02 UTC (permalink / raw)
To: sebastien.miquel; +Cc: Tom Gillespie, emacs-orgmode
Sébastien Miquel <sebastien.miquel@posteo.eu> writes:
> On second thought, I'm uneasy about my approach. If tangling fails,
> the user might miss the error message since it is quickly replaced by
> the tangling info. Ideally we should backup all the tangled files and
> restore them all if a single one fails to ensure we're back to a
> consistent state.
>
> I'm unsure what would be best practices here. In case of a remote
> tangled files, I don't know if temporary files should be remote or
> not, and what guarantees do emacs primitives such as ~rename-file~
> offer.
Just 2c from me on how I'd like this to work as a user, when tangling
fails:
+ Every file that could be tangled is tangled, or there's a variable
which controls what to do on an error
+ Loud message at the end that lists all files which files failed to
tangle
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-capture.el: Add new capture template option :refile-to
@ 2021-04-25 3:16 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:16 UTC (permalink / raw)
To: emacs-orgmode
Marking this patch as cancelled for updates.orgmode.org.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] New "project" option for org-link-file-path-type
@ 2021-04-25 3:29 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:29 UTC (permalink / raw)
To: Jack Kamm; +Cc: Kyle Meyer, emacs-orgmode
This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.
Jack Kamm <jackkamm@gmail.com> writes:
> Thanks, I've fixed the remaining issues you pointed out and pushed this
> in 5371b30fe.
>
> Cheers,
> Jack
^ permalink raw reply [relevance 93%]
* Re: [final patch] Re: add new link type "contact:" for org-contacts.el
@ 2021-04-25 3:31 93% ` Timothy
2021-04-25 3:59 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-04-25 3:31 UTC (permalink / raw)
To: emacs-orgmode
This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.
Bastien <bzg@gnu.org> writes:
> Of course, done (c822c80ef).
>
> Sorry I forgot about this patch, and thanks for your reply.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Apply emacs manual css to org pages
@ 2021-04-25 3:34 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:34 UTC (permalink / raw)
To: org-mode-email
This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.
Bastien <bzg@gnu.org> writes:
> I made this change and tested it online, the HTML Org manual now looks
> like the Emacs manual: https://orgmode.org/manual/
>
> Thanks for the suggestion!
> In any cas, the Emacs manual css is better than my attempt and using
> it for Org makes sense IMO.
>
> Best,
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Apply emacs manual css to org pages
@ 2021-04-25 3:36 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:36 UTC (permalink / raw)
To: org-mode-email
For some reason updates.orgmode.org registered this as a new patch??
Marking as closed via X-Woof-Patch header.
Greg Minshall <minshall@umich.edu> writes:
> Timothy,
>
>> This is a quick patch to use the Emacs manual CSS with our generated Org
>> manual.
>
> that's certainly visually pleasing. nice!
>
> Greg
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ol: Avoid initial input when completing function for storing link
@ 2021-04-25 3:38 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:38 UTC (permalink / raw)
To: emacs-orgmode
This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.
Kyle Meyer <kyle@kyleam.com> writes:
> Pushed (00b4de329).
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-contacts.el: Use `bound-and-true-p' to check (unbound) var
@ 2021-04-25 3:41 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:41 UTC (permalink / raw)
To: emacs-orgmode
This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.
miles christopher <numbchild@gmail.com> writes:
> Applied, I think this should be the final version.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ob-java, a proposal on import improvement
@ 2021-04-25 3:42 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:42 UTC (permalink / raw)
To: emacs-orgmode
This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.
ian martins <ianxm@jhu.edu> writes:
> It's no problem. Didn't mean to rush you. Thanks again for the patch. Applied.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ob-java: Allow import to end with asterisk
@ 2021-04-25 3:43 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:43 UTC (permalink / raw)
To: emacs-orgmode
This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.
ian martins <ianxm@jhu.edu> writes:
> Thanks. And thanks for taking the time to fix issues that you find. It
> continues to improve because of your contributions.
> The patch looks good. Applied.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
@ 2021-04-25 3:46 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:46 UTC (permalink / raw)
To: emacs-orgmode
As you have said you'll start a new thread for your revised proposal,
I'll mark this as closed on updates.orgmode.org via the X-Woof-Patch
header.
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ok, I agree. Next week I will start a new thread for submit this new
> proposal.
>
> Best regards,
>
> Juan Manuel
^ permalink raw reply [relevance 93%]
* Re: [PATCH 0/1] Add option to delay fontification of source blocks
@ 2021-04-25 3:48 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:48 UTC (permalink / raw)
To: emacs-orgmode
Marking as closed on updates.orgmode.org via the X-Woof-Patch header.
Leo Okawa Ericson <leo@relevant-information.com> writes:
> I can't think of a reason either (now that I know that jit-lock exists)
> so I will retract my patch.
^ permalink raw reply [relevance 93%]
* Re: [PATCH 0/1] Add option to delay fontification of source blocks
@ 2021-04-25 3:48 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:48 UTC (permalink / raw)
To: emacs-orgmode
Marking as closed on updates.orgmode.org via the X-Woof-Patch header.
Leo Okawa Ericson <leo@relevant-information.com> writes:
> I can't think of a reason either (now that I know that jit-lock exists)
> so I will retract my patch.
^ permalink raw reply [relevance 93%]
* Re: [PATCH 0/1] Add option to delay fontification of source blocks
@ 2021-04-25 3:49 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:49 UTC (permalink / raw)
To: emacs-orgmode
Marking as closed on updates.orgmode.org via the X-Woof-Patch header.
Leo Okawa Ericson <leo@relevant-information.com> writes:
> I can't think of a reason either (now that I know that jit-lock exists)
> so I will retract my patch.
^ permalink raw reply [relevance 93%]
* Re: [final patch] Re: add new link type "contact:" for org-contacts.el
2021-04-25 3:31 93% ` Timothy
@ 2021-04-25 3:59 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:59 UTC (permalink / raw)
To: emacs-orgmode
I'm afraid it looks like I either made a typo while doing this, or
something odd happened. Regardless it didn't work correctly.
Take 2, sorry for the noise --- but at least the patch section on
updates.orgmode.org should be more useful now as it only shows pending
patches again.
Timothy <tecosaur@gmail.com> writes:
> This was not marked as applied on updates.orgmode.org.
> Doing so with the X-Woof-Patch header.
>
> Bastien <bzg@gnu.org> writes:
>
>> Of course, done (c822c80ef).
>>
>> Sorry I forgot about this patch, and thanks for your reply.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Refresh inline plotted images
@ 2021-04-26 14:54 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-26 14:54 UTC (permalink / raw)
To: org-mode-email
Applied in dadbd025f.*
Timothy <tecosaur@gmail.com> writes:
> Hi All,
>
> This patch improves the result of running org-plot in the following
> situation
>
> #+plot: ... file:"somefile.png"
>
> [[file:somefile.png]]
>
> Previously, when somefile.png is re-plotted the [[file:]] inline image
> did not refresh. With this patch, after plotting, overlays of the
> replotted image are refreshed.
* As Bastien pointed out to me, I /am/ the org-plot maintainer...
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Add font-lock rule for inline export snippets
2021-03-31 15:57 80% [PATCH] Add font-lock rule for inline export snippets Timothy
@ 2021-04-28 7:23 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-28 7:23 UTC (permalink / raw)
To: org-mode-email
Timothy <tecosaur@gmail.com> writes:
> Hello,
>
> The latest in my visually-oriented (mostly) short patch series, adding
> basic fontification to inline export snippets --- @@comment:these things@@.
>
> I think fontification for stuff like this is nice because it visually
> indicates to the user that they've written out an Org construct, and
> haven't just mis-remembered / imagined some syntax.
>
> In future this could be extended to use native fontification for
> recognised export formats (like src blocks do), but I think this is a
> nice improvement over nothing.
This addition to the font-lock regexps is quite simple, and doesn't
contain anything fancy/expensive (like backtracking), so I don't expect
there to be any performance concerns --- but it would be good to hear
from others :)
I considered limiting this to no-newlines, but
https://orgmode.org/worg/dev/org-syntax.html says anything other than @@
is allowed.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Have C-c C-c recognise #+plot lines
2021-04-30 7:06 93% ` Timothy
@ 2021-04-28 18:04 93% ` Timothy
1 sibling, 1 reply; 200+ results
From: Timothy @ 2021-04-28 18:04 UTC (permalink / raw)
To: Eric S Fraga; +Cc: emacs-orgmode@gnu.org
Hi Eric,
Have you had a chance to test this out?
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Have C-c C-c recognise #+plot lines
@ 2021-04-30 7:06 93% ` Timothy
2021-04-28 18:04 93% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2021-04-30 7:06 UTC (permalink / raw)
To: Eric S Fraga; +Cc: emacs-orgmode@gnu.org
Now that Eric and I have both tested this, and Nicolas' comments have
been taken into account, it would be great if a core maintainer could
consider applying this patch :)
--
Timothy
p.s. I'm specifically making a new reply to the version of the patch
that should be looked at, in the hope that this might help with clarity
when there are 4 different patches in this thread.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Have C-c C-c recognise #+plot lines
@ 2021-04-30 8:52 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-04-30 8:52 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode@gnu.org, Eric S Fraga
Bastien <bzg@gnu.org> writes:
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> Further on this, I don't have time to debug right now but the patch
>> seems to have broken org table recalculation, specifically C-u C-c C-c
>> on a table.
>
> Thanks for reporting - Tim can you double-check this?
I checked the docs for `org-table-recalculate' and based on manually
calling it compared the behaviour to C-u C-c C-c on a table and noticed
no difference, but I'm not familiar with the intended functionality so
an example from Eric (or someone else) of what should happen would be
very helpful.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-src.el Do not ask to revert unmodified buffers
@ 2021-05-01 10:55 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-05-01 10:55 UTC (permalink / raw)
To: pillule; +Cc: Kyle Meyer, emacs-orgmode
Hi pillule, should we consider this patch cancelled?
pillule <pillule@riseup.net> writes:
> You are right I clearly missed org-src-ask-before-returning-to-edit-buffer
> Don't know how . . .
>
> Sorry for the noise.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
@ 2021-05-01 10:58 93% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2021-05-01 10:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
Sorry it's still taking a while for your patch to be looked at.
Assuming it does get merged, it would be good to check if you'd be
willing to write a manual entry to accompany this (in a separate patch
works).
Thanks again for the patch,
Timothy.
Juan Manuel Macías <maciaschain@posteo.net> writes:
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Babel: remove LaTeX environment -type #+results
@ 2021-05-01 11:44 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-05-01 11:44 UTC (permalink / raw)
To: Bastien; +Cc: org-mode-email
Bastien <bzg@gnu.org> writes:
> Applied in master as commit b90b850ae.
>
> Can you add a etc/ORG-NEWS entry for this?
Great! News entry added.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fontification for inline src blocks
2021-04-28 7:14 88% ` Timothy
@ 2021-05-02 20:17 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-05-02 20:17 UTC (permalink / raw)
To: org-mode-email
It would be good to hear if anyone has been able to test this, and if so
what your experience has been :)
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export
@ 2021-05-02 20:20 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-05-02 20:20 UTC (permalink / raw)
To: Berry, Charles; +Cc: org-mode-email
> Will this handle LaTeX macros[1] gracefully and other things intended as raw LaTeX?
> [1] https://pandoc.org/MANUAL.html#latex-macros
This only affects LaTeX fragments, and then it's just changing \(\) /
\[\] for $ / $$. I don't think this has any effect on your concerns.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export
@ 2021-05-02 20:23 93% ` Timothy
2 siblings, 0 replies; 200+ results
From: Timothy @ 2021-05-02 20:23 UTC (permalink / raw)
To: Nicolas Goaziou, org-mode-email
Hello Nicolas,
In my plea for patch feedback email, Bastien said he'd like to leave
this patch to your discretion.
As such, it would be fantastic if you might be able to provide your
thoughts on this.
All the best,
Timothy.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export
@ 2021-05-09 20:12 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-05-09 20:12 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: org-mode-email
Hi,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>> I just thought there may be people who like me are interested in
>> <img>s for LaTeX in HTML, but not in Markdown.
>
> Fair enough. Let's push your last patch, then.
Going off this, I've taken this as assent and just pushed my patch in
its current form as 981f25031.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fontification for inline src blocks
@ 2021-05-12 11:15 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-05-12 11:15 UTC (permalink / raw)
To: Tom Gillespie; +Cc: org-mode-email
If anyone else is interested in this, it would be great to get your
thoughts.
I'd also appreciate it if a core maintainer might be able to find the
time to review the patch and let me know if it looks good.
Thanks,
Timothy.
--
> Tom Gillespie <tgbugs@gmail.com> writes:
>
>> 1. I think there needs to be a function to toggle
>> org-inline-src-prettify-results as there is e.g. for hyperlinks. I was
>> quite confused by the prettified results.
>
> Added org-toggle-inline-results-display.
>
>> 3. I'm not sure about the default choice for prettified delimiters. I
>> see there is already a way to customize the delimiters by providing a
>> cons. I think a default value of '("" . "") might be a better choice
>> since ⟨ and ⟩ being hardcoded seems like it introduces completely
>> alien characters. Going with empty strings also seems consistent with
>> the behavior for hyperlinks.
>
> Changed to your suggestion.
>
> Awaiting others' thoughts on 2. and 5.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fontification for inline src blocks
@ 2021-05-12 14:47 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-05-12 14:47 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Tom Gillespie, org-mode-email
Thanks for your response.
Ihor Radchenko <yantar92@gmail.com> writes:
> I do not like abusing prettify-symbols-mode. What if it is not enabled?
Ah, it does it anyway at the moment.
> What will happen if user toggles prettify-symbols-mode in Org buffer?
This seems to be toggled nicely by prettify-symbols-mode too.
> Maybe better use something like org-entities?
I'm not sure if that would work, perhaps someone else knows otherwise.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Allow LaTeX reference command (\ref) to be customised
@ 2021-06-09 2:11 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-06-09 2:11 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: org-mode-email
Hi Nicolas,
Since this is a fairly small thing and ox-latex seems to be your domain,
I'm wondering if you've had a chance to take a look yet? (just making
sure this hasn't slipped by, given your recent replies in other threads).
> Hi All,
>
> I've started doing some more cross-referencing in documents exported to
> LaTeX, and a hardcoded use of \ref has begun to stand out to me as a
> rather annoying thing. Hypperef provides \autoref for adding helpful
> prefixes (section, figure, etc.), and there are other packages which one
> may want to use to generate 'clever' references (like cleveref with
> \cref).
>
> As such, I think that the hardcoded \ref should actually be turned into
> a customisable format string, which is what the attached patch does.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Allow LaTeX reference command (\ref) to be customised
@ 2021-06-09 17:38 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-06-09 17:38 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: org-mode-email
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Sure, LGTM!
Cool :) Merged.
Now the only other LaTeX PR I may poke you about in the future is the
latexmk one :P
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix erroneous tangling of blocks
@ 2021-07-01 13:38 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-07-01 13:38 UTC (permalink / raw)
To: Jacopo De Simoi; +Cc: emacs-orgmode
HI Jacopo,
I've just taken a look at your patch and it looks good :) glad to see
you've also followed the commit message format. I hope this gets merged
soon.
--
Timothy
p.s. Just a little note for the future: it's good if you have full
sentences in the description of the changes.
Jacopo De Simoi <jacopods@protonmail.com> writes:
> Dear All,
>
> Please find attached a patch (against master) which takes care of the
> following issue. Assume I have a block like this
>
> #+begin_src sh :tangle no
> This should not be tangled
> #+end_src
>
> Then the block is correctly ignored when tangling the whole file, but
> erroneously tangled (to a file named "no") when tangling is run with the
> universal argument (so that only the current block should be tangled)
>
> This happens because the check for the "no" option is not performed when
> tangling a single block. In the proposed patch I address this issue by
> checking for the "no" option in the function org-babel-effective-tangled-
> filename
^ permalink raw reply [relevance 93%]
* Re: [patch] add :url and :doi optional entries for export to BiBTeX
@ 2021-07-01 14:23 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-07-01 14:23 UTC (permalink / raw)
To: Eric S Fraga; +Cc: emacs-orgmode
Hi Eric,
I've not used Org for exporting to BibTeX, so I don't really know what
I'm on about, but is there any particular reason why only some entries
have :url ? Other than that, this seems like a fairly straightforward
patch.
--
Timothy
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> I introduced an error in the previous patch. Please use this one.
> Thank you,
> eric
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Customizify org-babel-fortran-compiler
@ 2021-07-01 14:45 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-07-01 14:45 UTC (permalink / raw)
To: emacs-orgmode
Marking as closed in favour of 2nd email.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Change default latex compiler to latexmk
@ 2021-07-09 14:25 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-07-09 14:25 UTC (permalink / raw)
To: Bastien; +Cc: org-mode-email, Bruce D'Arcus
Bastien <bzg@gnu.org> writes:
> I let Timothy decide.
I consider this patch fit to merge. I'm just under the impression that
this I should only push files I'm listed as a maintainer for without
explicit approval.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Change default latex compiler to latexmk
@ 2021-07-09 16:41 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-07-09 16:41 UTC (permalink / raw)
To: Bastien; +Cc: org-mode-email, Bruce D'Arcus
Bastien <bzg@gnu.org> writes:
> You can consider this an explicit approval :) Even if we do something
> wrong, we can always discuss and revert it.
>
> Thanks!
Pushed :) For future reference, should I be less wary of pushing commits
I'm confident in and haven't had any negative feedback on?
--
Timothy
p.s. updates.orgmode.org is returning a 502 error again
^ permalink raw reply [relevance 93%]
* Re: [PATCH] be more cautious when setting csl etc dir location
@ 2021-07-14 19:39 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-07-14 19:39 UTC (permalink / raw)
To: org-mode-email
Applied.
This seems quite simple, so I've taken the liberty of applying the
patch. Please don't hesitate to revert it if something seems off.
--
Timothy <tecosaur@gmail.com> writes:
> Hello,
>
> It's come to my attention that the current value of
> org-cite-ctl--etc-dir is problematic for anyone managing Org with
> package.el or straight. This patch adds a check to see if the initial
> location actually exists, if it doesn't we try the expected location
> when using package.el/straight.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] bad table formula recorded in some cases
@ 2021-07-21 10:50 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-07-21 10:50 UTC (permalink / raw)
To: tbanelwebmin; +Cc: emacs-orgmode
Hi Thierry,
Thanks for this! Looking at the change you suggest, do you know why the
(match-string 2) bit might have been added in the first place? I'm just
wondering if there might be some edge-case adversely affected by this ---
hence trading one bug for another :P
--
Timothy
tbanelwebmin <tbanelwebmin@free.fr> writes:
> Small bug, small fix.
>
> Suppose we have a table embedded in a begin-end block.
>
> #+begin: aaa :param value
> | a | b |
> | a | b |
> #+end:
>
> Suppose we want to add a formula, with C-c =
> We end up with an incorrect result:
>
> #+begin: aaa :param value
> | a | 33 |
> | a | b |
> :param value $2=33
> #+end:
>
> The fix: in org-table.el, line 2177, change
> (insert (or (match-string 2) "#+TBLFM:")))
> to
> (insert "#+TBLFM:"))
>
> Then we get the correct result:
>
> #+begin: aaa :param value
> | a | 33 |
> | a | b |
> #+TBLFM: $2=33
> #+end:
>
> Why? Because (match-string 2) is supposed to refer to the (looking-at)
> instruction 7 lines above. But (match-string 2) is in the else branch,
> which means that (looking-at) failed. Therefore (match-string 2) returns
> garbage.
>
> Thanks to Uwe Brauer for pointing to this bug.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] bad table formula recorded in some cases
@ 2021-07-21 15:07 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-07-21 15:07 UTC (permalink / raw)
To: tbanelwebmin; +Cc: emacs-orgmode
Hi Thierry,
tbanelwebmin <tbanelwebmin@free.fr> writes:
> I don't know the intention. But the answer may lie in the comment 4
> lines above:
> ;; Don't overwrite TBLFM, we might use text properties to
> ;; store stuff.
>
> In this case, the intention would be to keep the original "#+TBLFM:"
> instead of inserting a fresh new one.
>
> But we are in the else branch of (if (looking-at ...)), which means
> there was no "#+TBLFM:". And no text properties to save. Therefore we
> may safely remove this (match-string 2).
Thank you for looking into this, I'm reassured by your inference that
this change is safe to make. I'm not really one of the main
contribution-acceptors/pushers though, so I'd rather leave this for
someone like Nicolas to sign off on.
Would you mind bumping this thread in a few weeks if nothing happens?
Hope that's not too much of an inconvenience,
Timothy.
> Le 21/07/2021 à 12:50, Timothy a écrit :
>> Hi Thierry,
>>
>> Thanks for this! Looking at the change you suggest, do you know why the
>> (match-string 2) bit might have been added in the first place? I'm just
>> wondering if there might be some edge-case adversely affected by this ---
>> hence trading one bug for another :P
>>
>> --
>> Timothy
>>
>> tbanelwebmin <tbanelwebmin@free.fr> writes:
>>
>>> Small bug, small fix.
>>>
>>> Suppose we have a table embedded in a begin-end block.
>>>
>>> #+begin: aaa :param value
>>> | a | b |
>>> | a | b |
>>> #+end:
>>>
>>> Suppose we want to add a formula, with C-c =
>>> We end up with an incorrect result:
>>>
>>> #+begin: aaa :param value
>>> | a | 33 |
>>> | a | b |
>>> :param value $2=33
>>> #+end:
>>>
>>> The fix: in org-table.el, line 2177, change
>>> (insert (or (match-string 2) "#+TBLFM:")))
>>> to
>>> (insert "#+TBLFM:"))
>>>
>>> Then we get the correct result:
>>>
>>> #+begin: aaa :param value
>>> | a | 33 |
>>> | a | b |
>>> #+TBLFM: $2=33
>>> #+end:
>>>
>>> Why? Because (match-string 2) is supposed to refer to the (looking-at)
>>> instruction 7 lines above. But (match-string 2) is in the else branch,
>>> which means that (looking-at) failed. Therefore (match-string 2) returns
>>> garbage.
>>>
>>> Thanks to Uwe Brauer for pointing to this bug.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix regression in org-get-time-of-day introduced in aba1f2066
@ 2021-07-24 19:48 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-07-24 19:48 UTC (permalink / raw)
To: emacs-orgmode
Marking as applied for updates.orgmode.org.
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Thanks. I applied a slightly different fix.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-agenda.el: Avoid dependency on subr-x
@ 2021-08-06 20:30 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-08-06 20:30 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
Hi Maxim,
> Timothy, I have seen that discussion. For me it does not matter in which way
> org-agenda.el will be fixed: by adding (require ’subr-x) or by using string=
> instead of string-empty-p. Both variants work with Emacs-26.3. The point is that
> “make single” should work without warnings and in the case of mixed install
> users should not get confusing errors that resemble real issues.
>
> The only reason why I suggested namely to avoid string-empty-p is that
> compatibility with Emacs-24.3 is still declared in Org sources.
Ah, cool. I took your original email to indicate that this change was solely for
Emacs 24.3 comparability, but I now see you simply used that as a reason to
choose between two different fixes.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-cite: define \citeprocitem for LaTeX export
@ 2021-08-26 8:18 93% ` Timothy
2021-09-19 13:19 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-08-26 8:18 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 276 bytes --]
Heyo,
As it’s been a few days, given the prior consultation with citeproc-el, and that
this is a very small change, I’m pushing this as 818bec57eb. We can always
revert/patch over in case I’m walking on someone’s (nickolas’?) toes :)
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-cite: prevent ' from being an active char in LaTeX export
@ 2021-08-26 8:24 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-08-26 8:24 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 263 bytes --]
Heyo,
> This is a band-aid over the issue raised in
> <https://lists.gnu.org/archive/html/emacs-orgmode/2021-08/msg00342.html>.
As this actually fixes a real annoyance, and is a trivial change, I’m pushing
this as a3ba79cd3a.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Update some changed export keybindings [worg]
@ 2021-08-31 11:37 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-08-31 11:37 UTC (permalink / raw)
To: Stefan Kangas; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 501 bytes --]
Hi Stefan,
Thanks for the patch. I’ve just applied it. I haven’t had a look at the other
“C-c C-e” keybindings, but I’m glad that you brought it up. Hopefully someone
else will take a look at some point.
> The attached patch fixes some incorrect keybindings in worg.
>
> I’d recommend that someone takes a look at all the “C-c C-e …”
> keybindings, as there are some that I was unsure about, and may still
> be incorrect even after this patch.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil
@ 2021-08-31 12:54 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-08-31 12:54 UTC (permalink / raw)
To: Morgan Willcock; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
Hi Morgan,
> Great! Thank you for taking a look.
No problem, thanks for making the patch :)
> I used `git send-email` which is listed as being OK on the website:
Huh, I guess it should be fine then. I’ve just never seen the commit message at
the top like that so I assumed you’d done it by hand. :shrug:
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix bug assuming canonical duration units in org-agenda-format-items
@ 2021-08-31 13:55 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-08-31 13:55 UTC (permalink / raw)
To: Anders Johansson; +Cc: emacs-orgmode, Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 688 bytes --]
Hi Anders,
Did you have any thoughts on Nicolas’ comments?
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> Anders Johansson <mejlaandersj@gmail.com> writes:
>
>> org-duration-from-minutes was called with canonical = t, but without
>> providing a corresponding format only using the canonical units. This
>> broke if the user’s org-duration-format used other than the canonical
>> units.
>
> I think a proper fix would be to change `org-duration-from-minutes’ so
> it removes any unknown unit from what is provided from fmt or
> `org-duration-format’, and defaults to (special . h:mm) if nothing is
> left.
>
> WDYT?
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ox-latex: Allow percent sign in 'src-block' caption
@ 2021-09-07 13:17 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-07 13:17 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
Hi Maxim,
> I have decided that it is better to provide a partial fix than to leave
> the problem as is. This patch covers only plain verbatim environment,
> more advanced formatting using listings or minted should be addressed
> by another change (Anybody?). Do not close the bug after applying
> this patch.
>
> [2. text/x-patch; 0001-ox-latex-Allow-percent-sign-in-src-block-caption.patch]…
Thanks for the patch. At a glance it looks good, and it’s great to see you’ve
gone to the effort of writing some tests for it too! That’s something we should
probably do more of 😅. Hopefully someone else will get around to giving your
work a closer look and maybe merge it soon-ish :)
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Re: New source block results option for attaching file to node
@ 2021-09-10 6:26 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-10 6:26 UTC (permalink / raw)
To: Ryan Scott; +Cc: Greg Minshall, emacs-orgmode, Ihor Radchenko
[-- Attachment #1.1: Type: text/plain, Size: 234 bytes --]
Hi Ryan,
I’ve just had a glance, but this looks much better to me than what was proposed
earlier 👍. Hopefully we’ll be able to get some feedback on this from others,
and then see it merged 🙂.
All the best,
Timothy
[-- Attachment #1.2: Type: text/html, Size: 7242 bytes --]
^ permalink raw reply [relevance 93%]
* Re: [BUG?][PATCH] Should the `lexical-binding' variable be bound during src block with :lexical t? [9.4.6 (9.4.6-ga451f9 @ /home/n/.emacs.d/straight/build/org/)]
@ 2021-09-10 6:32 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-10 6:32 UTC (permalink / raw)
To: No Wayman; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 363 bytes --]
Hi NoWayman,
> I ran into this with some code I’m writing which checks against
> `lexical-binding’.
> Should the following result in “lexical binding enabled” or
> “lexical binding disabled”?:
Can you think of any examples where this results in different behaviour (without
explicitly checking `lexical-binding')?
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix some typos
@ 2021-09-17 9:03 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-17 9:03 UTC (permalink / raw)
To: Stefan Kangas; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 161 bytes --]
Hi Stefan,
Thanks again for going through our documentation and picking up these mistakes.
I’ve just applied this as 215d80d :)
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] minor typo fix in org-tutorials/org-protocol-custom-handler.org
@ 2021-09-19 12:42 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-19 12:42 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 43 bytes --]
Marking as applied on updates.orgmode.org.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ob-tangle.el: Fix error in org-tangle from org-src edit buffer
@ 2021-09-19 12:57 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-19 12:57 UTC (permalink / raw)
To: markgdawson; +Cc: emacs-orgmode
Hi Mark,
Many thanks for not only tracking down this problem but making a fix and
submitting it 🙂. I've just pushed this as 986341b with minor tweaks to the
commit message.
Mark Dawson <markgdawson@gmail.com> writes:
> [PATCH] ob-tangle.el: Fix error in org-tangle from org-src edit
> buffer
>
> (org-babel-tangle) : Fix stringp error which happens when confirming
> successful tangle when `org-babel-tangle` is called from an org-src edit
> buffer.
>
> TINYCHANGE
> ---
> lisp/ob-tangle.el | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
> index 2f60ef9a4..0768c8588 100644
> --- a/lisp/ob-tangle.el
> +++ b/lisp/ob-tangle.el
> @@ -281,7 +281,10 @@ matching a regular expression."
> (if (= block-counter 1) "" "s")
> (file-name-nondirectory
> (buffer-file-name
> - (or (buffer-base-buffer) (current-buffer)))))
> + (or (buffer-base-buffer)
> + (current-buffer)
> + (and (org-src-edit-buffer-p)
> + (org-src-source-buffer))))))
> ;; run `org-babel-post-tangle-hook' in all tangled files
> (when org-babel-post-tangle-hook
> (mapc
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Various minor docfixes found by checkdoc
@ 2021-09-19 13:00 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-19 13:00 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 66 bytes --]
Just marking as applied for <https://updates.orgmode.org/> 🙂.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fixed lstset where language= wipes out previous definitions
@ 2021-09-19 13:02 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-19 13:02 UTC (permalink / raw)
To: Karl Stump; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]
Hi Karl,
Thanks for sending in this patch, and sorry it’s taken so long for someone to
get back to you. Would you mind explaining the issue here a bit more? I can’t
see at a glance how preceding definitions are wiped in the current
code.
Karl Stump <karlstump@gmail.com> writes:
> * ox-latex.el (org-latex-src-block): moved ((“language” ,lst-lang)) to the head of the list.
> This fixes wiping out preceding definitions given in `org-latex-listings-options’.
> TINYCHANGE
> —
> lisp/ox-latex.el | 4 ++–
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff –git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index b9ecf070a..f956c851e 100644
> — a/lisp/ox-latex.el
> +++ b/lisp/ox-latex.el
> @@ -3075,13 +3075,13 @@ contextual information.“
> (concat
> (org-latex–make-option-string
> (append
> - lst-opt
> + `((”language“ ,lst-lang))
> + lst-opt
> (cond
> ((and (not float) (plist-member attributes :float)) nil)
> ((string= ”multicolumn“ float) ’((”float“ ”*“)))
> ((and float (not (assoc ”float“ lst-opt)))
> `((”float“ ,(plist-get info :latex-default-figure-position)))))
> - `((”language“ ,lst-lang))
> (if label
> `((”label“ ,(org-latex–label src-block info)))
> ’((”label“ ” “)))
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-cite: define \citeprocitem for LaTeX export
2021-08-26 8:18 93% ` Timothy
@ 2021-09-19 13:19 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-19 13:19 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 109 bytes --]
Looks like I forgot to mark this patch as applied on updates.orgmode.org.
Let’s just quickly fix that…
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Add faces to improve contextuality of agenda views
@ 2021-09-19 13:23 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-19 13:23 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: emacs-orgmode, Gustavo Barros
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
Hi Protesilaos,
Thanks for sending this patch in, and sorry it’s taken a while for you to hear
anything back. I see the utility of org-imminent-deadline, but am fairly
indifferent about the rest.
Hopefully bumping this might prompt some others to give their thoughts on your
patch.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] manual: How to refer to tables in other files
@ 2021-09-19 13:36 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-19 13:36 UTC (permalink / raw)
To: William Denton; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hi William,
Thanks for sending in this patch. Documentation improvements are always great to
see. I’ve just applied your patch with minor tweaks to the commit message, and
the “Nu HTML” bit removed as d700c03 🙂.
William Denton <wtd@pobox.com> writes:
> Attached is a very small update to the docs about how to refer to tables in
> other files. Probably there’s something wrong with the formatting, but git
> send-email didn’t work, and I hope the Changelog entry gets through.
>
> Bill
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil
@ 2021-09-19 17:02 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-19 17:02 UTC (permalink / raw)
To: Morgan Willcock; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
Hi Morgan,
Thanks for clarifying this. That makes sense to me, and so I’ve just pushed your
patch as 3a77e59 🙂, with a slightly tweaked commit message. Thanks for going to
the effort of pinpointing and fixing this issue, and your patience in seeing
this accepted.
Morgan Willcock <mwillcock@precedence.co.uk> writes:
> It seems to default to spaces everywhere else. If you export an actual
> document through the ascii exporter instead of just a document header
> you will get a mix of tabs and spaces. This is how it was brought to my
> attention, I was distributing a file that was batch exported and someone
> pointed out that the indentation was inconsistent.
>
> If it is handled as an export preference or defaults to the global
> indentation preference then that would be fine but I don’t believe
> either of those are the case.
>
> Thanks for continuing to look,
> Morgan
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
@ 2021-09-21 13:32 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-21 13:32 UTC (permalink / raw)
To: Bastien
Cc: Karl Voit, Ihor Radchenko, emacs-orgmode, Nicolas Goaziou,
Christian Heinrich, Kyle Meyer
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
I’m suspect it too short notice for such a large change to make its way into Org
9.5, but Bastien’s release email is certainly a good prompt to bump this.
Bastien <bzg@gnu.org> writes:
> Thank you *very much* for this work and sorry for the slow reply.
>
> I urge everyone to test this change, as I’d like to include it in
> Org 9.5 if it’s ready.
>
> I will test this myself this week and report.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-manual.org: Augment TODO keywords example
@ 2021-09-24 4:39 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-24 4:39 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 45 bytes --]
Marking as cancelled for updates.orgmode.org
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-manual.org: Augment TODO keywords example
@ 2021-09-24 4:41 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-24 4:41 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 45 bytes --]
Marking as cancelled for updates.orgmode.org
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Include support for evaluating julia code
@ 2021-09-25 14:13 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-25 14:13 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
Hi Bastien,
> We had previous discussions with Pedro on his contribution regarding
> ob-julia.el¹, I agreed he could be the maintainer once he signed the
> FSF copyright assignment, so I feel an obligation to apply his patch
> right now, but I’m sure Pedro, you and Nicolò can work together on
> the improved version.
As far as I’m concerned, the more the merrier 😀.
> I don’t know if Nicolò has signed the FSF copyright assignment but
> once he does, he can join the party too.
I’ve talked to Nicolò about this, and I don’t think he has yet, but he’s said he
knows what’s needed and it won’t be a problem.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH]
@ 2021-09-26 12:01 93% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2021-09-26 12:01 UTC (permalink / raw)
To: Org Mode List
How on earth did I remember to start writing the subject, then switch to the
message, and forget to finish it... (sigh). Ooops.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH]
@ 2021-09-27 12:20 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-09-27 12:20 UTC (permalink / raw)
To: Bastien; +Cc: Org Mode List
[-- Attachment #1: Type: text/plain, Size: 306 bytes --]
Bastien <bzg@gnu.org> writes:
> It looks better, Thanks. The two patches don’t apply on main here.
> Can you apply the change yourself and add an entry in etc/ORG-NEWS?
I’ve written an ORG-NEWS entry, verified it works (and fixed a trivial
oversight), and pushed :)
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH]
@ 2021-09-27 15:36 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-09-27 15:36 UTC (permalink / raw)
To: Bastien; +Cc: Org Mode List
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
Bastien <bzg@gnu.org> writes:
> This triggers a compiler warning about `visual-fill-column-width’ not
> being declared.
>
> This variable comes from
> <https://github.com/joostkremers/visual-fill-column>
>
> Why relying on this package? Any chance to avoid this dependency?
>
> If not, can you please add the needed declaration?
Here I’m not relying on the package, but trying to make it so that this will
still function as intended if the package is used, as it can modify the area
used for text in a buffer (hence the bound-and-true-p). I think this is worth
having, but obviously byte-compile errors aren’t nice. Would adding a
declare-function statement be the best thing to do here?
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH]
@ 2021-09-27 17:52 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-09-27 17:52 UTC (permalink / raw)
To: Bastien; +Cc: Org Mode List
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
Bastien <bzg@gnu.org> writes:
> Since this is a variable, a simple (defvar visual-fill-column-width)
> will silent the compiler.
I’ve just had another thought which wouldn’t add visual-fill-column-width to the
namespace (if that’s worth worrying about). Not sure if this is better or worse
though.
┌────
│ (/ (or (and (bound-and-true-p visual-fill-column-mode)
│ (or (bound-and-true-p visual-fill-column-mode) auto-fill-function))
└────
Might you have an opinion on this?
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH]
@ 2021-09-28 15:50 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-28 15:50 UTC (permalink / raw)
To: Bastien Guerry; +Cc: Org Mode List
[-- Attachment #1: Type: text/plain, Size: 198 bytes --]
Bastien Guerry <bzg@gnu.org> writes:
>> It seems to me that the defvar declaration is good enough.
>
> I just pushed this.
Ah, cool. Thanks for taking care of this Bastien.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Treat :tangle-mode as an octal value not integer
@ 2021-09-30 18:13 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-09-30 18:13 UTC (permalink / raw)
To: Jeremy Cowgar; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 185 bytes --]
Hi Jeremy,
> I love it! Much better than my proposed patch.
I’m about to send a patch based on my snippet, so I’m marking this patch as cancelled.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Don't fill displayed equations
@ 2021-09-30 18:54 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-09-30 18:54 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> I strongly disagree with this. \[...\] is an inline element, not a block
> element. As such, it can be filled, and filling function should obey to
> the inner structure of the document.
>
> You can use a real block element here, e.g.,
> \begin{equation*}...\end{equation*}, which will not be filled.
Given that \[ ... \] is an alias for \begin{equation*} ...
\end{equation*} I don't see why it should be treated any differently
when filling.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Don't fill displayed equations
@ 2021-09-30 19:28 93% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2021-09-30 19:28 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>> Given that \[ ... \] is an alias for \begin{equation*} ...
>> \end{equation*}
>
> This is true in LaTeX, not in Org, obviously.
Isn't the whole point of the \[ ... \], \( ... \), $ ... $, $$ ... $$,
and \begin{env} ... \end{env} and constructs in Org to be consistent
with LaTeX?
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Don't fill displayed equations
@ 2021-10-02 18:28 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-10-02 18:28 UTC (permalink / raw)
To: Tom Gillespie; +Cc: Max Nikulin, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
Hi Tom,
> The answer is that can only occur inside paragraphs. The issues
> here are exactly the same as the issues for inline footnotes. Org gives
> us a bit more power, but not the full power because Org is Org, not
> Latex. Making available outside of a paragraph would be a massive
> breaking change.
>
> In Timothy’s original example he is narrowly skirting the syntax to
> allow that all to remain a single paragraph, but stick in a newline
> anywhere and boom, no more paragraph, no more equation.
I don’t understand what you’re talking about here. You can already use `\[ ... \]'
outside a paragraph, e.g.
┌────
│ blah blah blah
│
│ \[
│ not part of a paragraph
│ \]
│
│ blah blah blah
└────
I also don’t see how footnotes are analogous, as footnotes are placed in the
middle of a line of text.
If you could explain your thoughts here a bit more, that would be appreciated.
> I guess one thing I’m missing/not understanding is when/why people
> want to use instead of full #+begin_export latex block?
org-latex-preview :)
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Prevent displayed images from being re-scaled
@ 2021-10-02 20:30 93% ` Timothy
2021-10-25 13:49 93% ` Timothy
1 sibling, 1 reply; 200+ results
From: Timothy @ 2021-10-02 20:30 UTC (permalink / raw)
To: Org-Mode Mailing List
[-- Attachment #1: Type: text/plain, Size: 119 bytes --]
Hi All,
I intend to push this in the next few days, assuming I don’t get any feedback.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Prevent displayed images from being re-scaled
@ 2021-10-03 5:45 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-10-03 5:45 UTC (permalink / raw)
To: Bastien; +Cc: Org-Mode Mailing List
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
Bastien <bzg@gnu.org> writes:
> Nitpick: I suggest shortening the ChangeLog part like this:
> *snip*
> The ChangeLog part should not be too verbose, you can add explanations
> after it.
Thanks Bastien, I’ll use that message when I push the commit 👍.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fontification for inline src blocks
@ 2021-10-03 7:16 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-10-03 7:16 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: org-mode-email
Ihor Radchenko <yantar92@gmail.com> writes:
> Let me bump this thread again and mark it as a patch ;)
Thanks for the bump. I'd like to get this working, but I don't know how best to
deal with the "prettification" of {{{results(=value=)}}}, which is the major blocker as I
see it.
Other than that, this all works fantastically as far as I can tell from a few
months of usage of my branch of Org 🙂.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Don't fill displayed equations
@ 2021-10-03 8:50 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-10-03 8:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Org Mode List, Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
Hi Ihor,
> What about making org-fill-element modular? We may define separate fill
> functions for different elements and let the user override them
> individually if the user prefer so. It may be implemented similar to
> export functionality with customisable formatters for different
> elements.
Thanks for that idea. Perhaps something along those lines may be the best
solution here. If we don’t want to make the whole function modular, perhaps we
could make a setting for this?
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Don't fill displayed equations
@ 2021-10-03 9:14 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-10-03 9:14 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Org Mode List, Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 568 bytes --]
Ihor Radchenko <yantar92@gmail.com> writes:
> I personally would prefer modular function as a whole. For my taste,
> Org code has too much of (case (variant 1) (variant 2) …)-style
> functions (i.e. org-todo, org-cycle, org-ctrl-c-ctrl-c, org-store-link,
> etc) and they are a pain to debug and advice for users.
Mmmm, I’m with you on this in general. I also think the code base has far too
many monolithic “200 line” functions which are crying out to be split up.
Now if I could just clone myself once or twice… 😛
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Don't fill displayed equations
@ 2021-10-03 9:42 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-10-03 9:42 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Org Mode List, Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 304 bytes --]
Hi Ihor,
> Then would you mind proposing a patch for org-fill-element in
> particular? At least, you seem to have a motivation for this particular
> function ;)
Perhaps in a few weeks, for now I’m a bit to busy for anything other than
“accidental” 😛 patches.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Don't fill displayed equations
@ 2021-10-04 7:15 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-10-04 7:15 UTC (permalink / raw)
To: Tom Gillespie; +Cc: Org Mode List
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
Hi Tom,
> From time to time I encounter random patterns that I don’t want to be
> reformatted during a fill operation. Maybe a custom variable like
> org-fill-paragraph-skip-regexp or similar that could be set by the user?
> For Timothy’s use case he would set it to the regexp provided in the
> original patch? Not sure how much of the implementation in the patch
> is dependent on that particular regexp, but a general solution that
> could even be set per org file might be a very useful new feature.
Hmmm, that’s an interesting idea. I suppose you could have something like a list
of cons cells where the car is a regexp matching the start of the “don’t touch”
region and the cdr a regexp matching the end.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Accept more :tangle-mode specification forms
@ 2021-10-05 14:45 93% ` Timothy
2021-11-18 10:20 93% ` Timothy
1 sibling, 2 replies; 200+ results
From: Timothy @ 2021-10-05 14:45 UTC (permalink / raw)
To: Org Mode List
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
Hi Everyone,
It feels like we’re near a patch that would be good to merge. I would very much
like to get feedback on what I proposed in my reply to Tom though (see below).
>> That said, reducing the number of forms as Eric suggests would
>> be a happy medium.
>
> Indeed, I’ve basically supported every form I could think of. I’m currently
> inclined to cut it down to:
> • 755
> • “rwxrw-r–” (`ls -l’ style)
> • chmod style with `org-babel-tangle-default-mode’ and `file-modes-symbolic-to-number’
>
> Maybe with (if anybody says they would like this)
> • #o755 (elisp octal)
> • 0755 (C octal)
> • “rwx” = user perm, bit-or’d with `org-babel-tangle-default-mode’ for the rest
> (i.e. `org-babel-tangle-default-mode’, but not exceeding the user perm)
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Accept more :tangle-mode specification forms
@ 2021-10-05 16:13 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-10-05 16:13 UTC (permalink / raw)
To: unknown@email.com; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]
Hi Jeremy,
> I think this is a good idea and don’t see any problems (or other
> suggestions) with the proposed formats.
>
> The existing (identity #o0755) will still function, correct?
> i.e. backward compatibility.
It should yes. I’ll double check before I actually push the commit.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Rename headline to heading
@ 2021-10-15 9:56 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-10-15 9:56 UTC (permalink / raw)
To: André A. Gomes; +Cc: Bastien, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
Hi André,
I haven’t gone through the patches you’ve sent, but it looks like you’ve put a
tremendous amount of effort into this! It’s fantastic to see. I think I can
speak for the Org community when I say thank you.
André A. Gomes <andremegafone@gmail.com> writes:
> Hi Bastien and All,
>
> This is a first attempt towards the goal.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Prevent displayed images from being re-scaled
2021-10-02 20:30 93% ` Timothy
@ 2021-10-25 13:49 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-10-25 13:49 UTC (permalink / raw)
To: Org-Mode Mailing List
[-- Attachment #1: Type: text/plain, Size: 70 bytes --]
It’s been quite a few days, so I’ve just pushed this as 9dc08c9.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-manual.org: org-cite additions
@ 2021-11-18 8:08 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-18 8:08 UTC (permalink / raw)
To: Bruce D'Arcus; +Cc: emacs-orgmode
Hi Bruce,
Thanks for this patch. I've had a read through and it all looks good to
me. I've just applied this with minor tweaks as 30dbfc6.
> This is a minor patch to address the most obvious missing pieces that
> have confused people.
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Accept more :tangle-mode specification forms
2021-10-05 14:45 93% ` Timothy
@ 2021-11-18 10:20 93% ` Timothy
2021-11-18 17:22 87% ` Timothy
1 sibling, 1 reply; 200+ results
From: Timothy @ 2021-11-18 10:20 UTC (permalink / raw)
To: Org Mode List
Hi All,
This has just been pushed as described in fa97f9a39.
See some tests I performed before pushing below.
#+begin_src text :tangle-mode (identity #o345) :tangle t1.txt
this works
#+end_src
#+begin_src text :tangle-mode 433 :tangle t2.txt
this works
#+end_src
#+begin_src text :tangle-mode u+x :tangle t3.txt
this works
#+end_src
#+begin_src text :tangle-mode rw-r--r-- :tangle t4.txt
this works
#+end_src
#+begin_src text :tangle-mode hey :tangle t5.txt
invalid, error message given
#+end_src
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ob-R async evaluation
@ 2021-11-18 10:36 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-18 10:36 UTC (permalink / raw)
To: Jeremie Juste; +Cc: emacs-orgmode
Hi Jeremie,
Sorry it's taken a while to get to this. I've just gone through your
patch and it looks quite reasonable. I also took the liberty of
fixing the indentation in a few spots and tweaking your commit message.
This has just been pushed as 58db28d.
> I'm attaching a patch that clean up a bit of non conventional coding
> practices (mainly because of my ignorance), in ob-R. These were
> initially generating warning during the compilation of org-mode.
By the way, just letting you know that your mail client declared your
.patch to be a PDF file 😛.
> [2. application/pdf; 0001-ob-R.el-Patch-4-async-evaluation.patch]...
--
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Treat :tangle-mode as an octal value not integer
@ 2021-11-18 12:04 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-18 12:04 UTC (permalink / raw)
To: emacs-orgmode
Just removing this from updates.orgmode.org.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org.el (org-display-inline-image--width): Small fix
@ 2021-11-18 12:06 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-18 12:06 UTC (permalink / raw)
To: emacs-orgmode
Just marking this patch as applied for updates.orgmode.org.
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> Sébastien Miquel <sebastien.miquel@posteo.eu> writes:
>
>> Subject: [PATCH] org.el (org-display-inline-image--width): Small fix
>
> I expounded the commit message and applied your patch. Thank you.
>
> Regards,
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Accept more :tangle-mode specification forms
@ 2021-11-21 4:27 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-21 4:27 UTC (permalink / raw)
To: Greg Minshall; +Cc: tomas, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
Hi Greg,
> i’d push back, even here, on allowing decimal. file modes are bit
> masks. to me, offering a way to set a bit mask via a *decimal* value
> seems a mistake.
Just a quick note (see my long recent reply to Tim where I expand on this more),
but this isn’t new behaviour (isn’t actually affected by my recent changes) and
my concerns are with the viability of the necessary changes rather than whether
this would be good (we are of the same mind I think).
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] org-src: Reset buffer-modified-p after fontifying
@ 2021-11-21 6:58 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-21 6:58 UTC (permalink / raw)
To: Clément Pit-Claudel; +Cc: emacs-orgmode
Hi Clément,
I've just had a look at your patch, and it seems very reasonable to me.
Hence, I've just pushed it as ebd06c1 :)
> Hi all,
>
> * lisp/org-src.el (org-src-font-lock-fontify-block): Reset the
> modification flag of the temporary fontification buffer after
> fontifying.
>
> Without this some modes cause Emacs to prompt about unsaved buffers
> when exiting: `Save buffer *org-src-fontification:...-mode*?'
>
> (I'm seeing this with Proof General's coq-mode, specifically.)
>
> Clément.
>
> [2. text/x-patch; 0001-org-src-Reset-buffer-modified-p-after-fontifying.patch]...
--
Timothy
^ permalink raw reply [relevance 93%]
* Dodgy Worg publishing? (was: [patch] Fix link to Library of Babel)
@ 2021-11-21 7:04 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-21 7:04 UTC (permalink / raw)
To: Thomas S. Dye; +Cc: Bastien, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
Hi Thomas,
Thanks for catching this problem. To me this looks more like a problem with the
worg publishing than an outdated link. I’ve cc’d Bastien as he’s much more
familiar with the Worg publish process than I am.
“Thomas S. Dye” <tsd@tsdye.online> writes:
> The attached patch changes a 404 link to the working link used on Worg.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix window width when line numbers present
@ 2021-11-21 19:19 93% ` Timothy
2021-11-21 19:14 92% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2021-11-21 19:19 UTC (permalink / raw)
To: Matt Huszagh; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 92 bytes --]
Oops, I forgot to mark this patch as applied for updates.orgmode.org.
Done in this message.
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix window width when line numbers present
@ 2021-11-22 3:16 93% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2021-11-22 3:16 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Matt Huszagh, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> `line-number-display-width’ is Emacs 26+. So I guess it is unfortunately
> not acceptable on main branch.
Ooops, thanks for picking that up Nicolas. I see we actually have
┌────
│ (if (fboundp 'line-number-display-width)
│ (defalias 'org-line-number-display-width 'line-number-display-width)
│ (defun org-line-number-display-width (&rest _) 0))
└────
in org-compat.el, but I think that fallback definition could be improved — even
just `(or display-line-numbers-width 0)' would be better.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix window width when line numbers present
@ 2021-11-22 5:31 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-22 5:31 UTC (permalink / raw)
To: Bastien; +Cc: Matt Huszagh, emacs-orgmode, Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
Hi Bastien,
> We can safely assume that Org 9.6 will be released after Emacs 28, so
> let’s use `line-number-display-width’ on main.
So I take this to mean that we will now assume that Org 9.6+ will target Emacs
29? This seems reasonable to me, but doesn’t quite accord with how I read
<https://orgmode.org/worg/org-maintenance.html#emacs-compatibility>.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fontification for inline src blocks
@ 2021-11-22 14:37 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-22 14:37 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: org-mode-email
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]
Hi Ihor,
>>>> org-inline-src-fontify-max-length
>> The description may need updating, as that’s a tad inaccurate. That value
>> actually limits how far forwards a paired paren is searched for. There’s no
>> spurious fontification.
>
> I can see the purpose. However, it still looks like overcomplication.
> org-element-context takes care about this issue simply by narrowing to
> current element (inline src block is an object and hence must end within
> current element).
Well, one simple change we could do is just replace
org-inline-src-fontify-max-length with the addition of `(save-excursion
(search-forward "\n" limit nil) (point))' to the restriction.
>>> It looks like you are repeating the job of org-element-context here. Why
>>> don’t you just get the proper object?
>>
>> IIRC `org-element-context’ doesn’t separate out the `src_’, `lang’, `[options]’, and
>> `{content}’ of an inline source code block (which we want).
>
> Sounds like an omission in org-element-context. At least, the parser
> could return :contents-begin and :contents-end. Then, you would also not
> need to re-implement the parser.
Perhaps. However frankly I don’t think it would do that much to reduce the
complexity, and what’s in this patch seems to work fairly nicely.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix regex for determining image width from attribute
@ 2021-11-22 17:54 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-22 17:54 UTC (permalink / raw)
To: Matt Huszagh; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
Hi Matt,
I’ve just pushed the change I described in 4514a32. This improves the
interpretation of :width attributes and makes a value of “t” work as discussed.
I have not prioritised #+attr_org for now, but that sounds like a change we
could make in the future.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix regex for determining image width from attribute
@ 2021-11-23 5:14 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-23 5:14 UTC (permalink / raw)
To: Matt Huszagh; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 158 bytes --]
Hi Matt,
This issue and Kyle’s change were resolved in another thread, just FYI this is
fixed now. Thanks for mentioning it.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix regex for determining image width from attribute
@ 2021-11-23 5:39 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-23 5:39 UTC (permalink / raw)
To: Matt Huszagh; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 100 bytes --]
Hi Matt,
(sigh) well that’s silly. Thanks, I’ve just pushed that.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix regex for determining image width from attribute
@ 2021-11-29 5:13 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-29 5:13 UTC (permalink / raw)
To: Matt Huszagh; +Cc: Max Nikulin, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 497 bytes --]
Hi Matt,
> I also still don’t really like the behavior
> here. I don’t think it makes sense to interpret a width as 120% if we
> have something like
>
> #+attr_latex: :width 1.2
What would be a more sensible interpretation in your mind? The “true” value
depends on the number of columns, and fetching that information seems a bit
unreasonable. Since this isn’t just used if nothing else if given, I see a 120%
interpretation as fairly reasonable.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [patch] fix ox-latex async export bug
@ 2021-11-29 5:15 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-29 5:15 UTC (permalink / raw)
To: Tim Cross; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
Hi Tim,
> I’m wondering if this could be a problem when exporting to latex if the
>underlying latex process encounters errors and is waiting for user input before
>it can continue (which happens if there are problems in the tex source latex is
>trying to process)?
>
> It might be worth checking next time you encounter an error if you can
> run latex on the generated *.tex file and see if it waits for user
> input?
If you look at the default value of `org-latex-pdf-process', it has the flag
`-interaction=nonstopmode' which should mean the process never pauses and waits
for user input.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fontification for inline src blocks
@ 2021-11-30 11:44 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2021-11-30 11:44 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: org-mode-email
[-- Attachment #1: Type: text/plain, Size: 40 bytes --]
Pushed 🙂.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fontification for inline src blocks
@ 2021-11-30 12:46 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-11-30 12:46 UTC (permalink / raw)
To: sebastien.miquel; +Cc: org-mode-email
[-- Attachment #1: Type: text/plain, Size: 252 bytes --]
Hi Sebastien,
> Sorry for the late reply, but isn’t there a `message' call leftover from
> debugging ?
Ooops! Time for a clean-up patch to fix the things you and Ihor’s just noticed.
Thanks for mentioning this.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] ob-shell-test, test-ob-shell and introduction
@ 2021-12-02 9:39 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-12-02 9:39 UTC (permalink / raw)
To: Matt; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 713 bytes --]
Hi Matt,
> > [FSF copyright assignment]. Have you done that yet?
>
> I just verified with my employer that my contract grants an exception for this
> project. Just emailed the request to assign@gnu.org. Also, got access from
> Bastien for worg. I figure it’s probably best to reserve any more changes ’til
> the paper work is done?
Great to hear that won’t get in the way of things 🙂. Feel free to develop and
share patches before the assignment is complete, we’ll just wait till it’s gone
through before merging (the process should just be a quick email or two and take
no more than a few days, just let us know if it’s dragging out).
Hope that helps.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix ob-plantuml over TRAMP
@ 2021-12-02 9:43 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-12-02 9:43 UTC (permalink / raw)
To: Guillaume Buisson (gbuisson); +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
Hi Guillaume,
Thanks for picking this up and submitting a patch.
Have you considered using `tramp-handle-file-exists-p'? I’m not overly familiar
with tramp or this sort of issue, but it looks like it could be exactly what we want.
> My Emacs Workflow involves connecting to a dev server over SSH so I can use my
> machines as thin clients and avoid synchronizing files, for that I do pretty
> much everything over TRAMP as I don’t want to lose the benefits of GUI Emacs.
> While everything mostly works impressively fine, I noticed writing my
> specifications that ob-plantuml fails to generate diagrams.
>
> It seems to me that there is a redundant check which uses `file-exists-p` even
> if using TRAMP, the plantuml jar is located on the remote server, so it fails
> with an error even though the command to actually render the diagrams works
> fine.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Remote link localisation, i.e. exporting remote images
@ 2022-01-31 11:40 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-01-31 11:40 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 39 bytes --]
I’ve just pushed this as 6ee4551 :)
^ permalink raw reply [relevance 93%]
* Re: [PATCH] New LaTeX code export option: engraved
@ 2022-05-05 16:09 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2022-05-05 16:09 UTC (permalink / raw)
To: Daniel Fleischer; +Cc: emacs-orgmode, Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 336 bytes --]
Hi Daniel,
> Hi Timothy, thank you very much for your work!
Thanks for the kind words 🙂
> Let me learn a bit about the different code highlighting options in
> order to understand what you offer.
Sure. If it’s any help, here’s a comparison example I whipped up:
<https://0x0.st/oAdn.png>
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] New LaTeX code export option: engraved
@ 2022-05-10 1:13 93% ` Timothy
2022-05-10 16:10 93% ` Timothy
0 siblings, 1 reply; 200+ results
From: Timothy @ 2022-05-10 1:13 UTC (permalink / raw)
To: sebastien.miquel; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]
Hi Sebastien,
> I’m quite exited and impressed to see this alternative to minted,
> thank you.
That’s great to hear!
> I haven’t been able to test your patches to org, but I have tried
> engrave-faces.el. Here’s a couple issues I’ve run into.
Still helpful, thanks.
> 1. engrave-faces-generate-preset generates emacs colors such as
> `:foreground “grey70”` which are not supported by
> engrave-faces-latex-gen-preamble-line and co.
Ah. I’ve just found this snippet from `list-colors-print'
┌────
│ (apply 'format "#%02x%02x%02x"
│ (mapcar (lambda (c) (ash c -8))
│ (color-values (car color))))
└────
I’ll see if I can incorporate this into engrave-faces v0.3.1.
> 2. `minted` supports a `mathescape` option to render math content
> inside code. `fvextra` supports the same option, but maths
> characters are escaped by engrave-faces-latex-face-mapper.
I’l also take a look at this :)
Thanks for the comments Sebastien.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] New LaTeX code export option: engraved
2022-05-10 1:13 93% ` Timothy
@ 2022-05-10 16:10 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-05-10 16:10 UTC (permalink / raw)
To: sebastien.miquel; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
Hi Sebastien,
>> 1. engrave-faces-generate-preset generates emacs colors such as
>> `:foreground “grey70”` which are not supported by
>> engrave-faces-latex-gen-preamble-line and co.
>
> I’ll see if I can incorporate this into engrave-faces v0.3.1.
Done.
>> 2. `minted` supports a `mathescape` option to render math content
>> inside code. `fvextra` supports the same option, but maths
>> characters are escaped by engrave-faces-latex-face-mapper.
>
> I’l also take a look at this :)
Implemented in engrave-faces-latex, but not worked into ox-html yet. If you
could check it out on the engrave-faces-latex side and check it’s behaving
sanely, that would be helpful.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] (v3) New LaTeX code export option: engraved
@ 2022-05-12 16:44 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-05-12 16:44 UTC (permalink / raw)
To: Daniel Fleischer; +Cc: Ihor Radchenko, emacs-orgmode, Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
Hi Daniel,
> Looks good. I had to update `engrave-faces’ to 0.3 because of new
> variables/functions and it works now. It does what it says on the box so
> let’s move forward introducing these changes and be open to feedback.
>
> Thank you very much for introducing this feature!
That’s great to hear! I’ve just tagged and pushed 0.3.1 of engrave-faces, so
HEAD is no longer required, along with my patch of ox-latex commits.
Thanks for helping with the process of getting this in, this has been over a
year in the works and so it feels fantastic to have this feature in-tree at last!
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Support #+include-ing URLs
@ 2022-06-12 9:52 93% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2022-06-12 9:52 UTC (permalink / raw)
To: Org Mode
Hi All,
> This is just a little patchset to treat #+include: URL the same way as
> #+setupfile: URL. All the usual #+include: bells and whistles
> (::*Heading, :lines, etc.) work as normal.
Since it's been a week and nobody has raised any objections to this
functionality (though it has provoked a proposed change to
org-file-contents), I'm going to tentatively merge this and prepare a
patch for org-file-contents to add download settings.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] New remote resource download policy
@ 2022-06-22 9:58 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-06-22 9:58 UTC (permalink / raw)
To: Robert Pluim; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
Hi Robert,
> Timothy> +(defcustom org-download-remote-resources ’prompt
>
> ’prompted when downloading unsafe resources’
>
> maybe?
>
> Does this need a ’prompt-always option? I guess thatʼs what you get
> with the default value of `org-safe-remote-resources’, but maybe it
> makes sense to be explicit?
That isn’t the behaviour. `prompt' doesn’t /always/ prompt, just when the resource
in question is not considered safe according to `org--safe-remote-resource-p'.
So, `prompt-always' would be something else, but one can easily make prompt behave
that way by setting `org-safe-remote-resources' to nil, so I don’t think it
warrants an extra option.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [STYLE] :version tags in defcustom definitions (was: [PATCH] Improve look of agenda on graphical displays)
@ 2022-06-29 14:07 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-06-29 14:07 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Ihor Radchenko, Daniel Mendler, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 451 bytes --]
Hi Ihor and Stefan,
>> Sure. Just trying to clarify my confusion. The inconsistency with some
>> defcustoms using :version and some not is bugging me.
>
> Agreed. It would be better to be consistent with this.
Given that org-mode is distributed separately to Emacs, and I get the impression
having a newer org-mode version that Emacs version is not uncommon, I think it
would make sense to have /just/ org-mode version tags.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] Fix caption format for custom latex src block
@ 2022-06-29 15:20 93% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2022-06-29 15:20 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Matt Huszagh, Emacs-Orgmode
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
Hi Ihor,
> Timothy, looking at the new implementation of org-latex-src-block, I do
> not see custom-env being passed as an argument of
> org-latex-src-block–custom. This is likely a bug.
Ah yes, this was an oversight. Corrected in 30953bd7b701c870152cd60f52f2d484970caeb9.
All the best,
Timothy
^ permalink raw reply [relevance 93%]
* Re: [PATCH] I updated patch by deleteing duplicate tags
@ 2021-04-25 3:25 99% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:25 UTC (permalink / raw)
To: emacs-orgmode
This was not marked as applied. Doing so with the X-Woof-Patch header.
Kyle Meyer <kyle@kyleam.com> writes:
> Christopher Miles writes:
>
>> Subject: [PATCH] org.el: Complete tags from both global and buffer local
>
> Thanks. Applied (86ad8d279)...
^ permalink raw reply [relevance 99%]
Results 1-200 of ~300 next [<= 77%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2020-09-17 13:50 93% [PATCH] Enhance org-html--build-meta-info TEC
2020-09-17 15:53 ` Jens Lechtenboerger
2020-09-17 16:14 ` TEC
2020-09-18 8:11 ` Jens Lechtenboerger
2020-09-25 17:48 ` TEC
2020-09-27 15:17 ` Jens Lechtenboerger
2020-09-27 17:39 ` TEC
2020-09-27 18:00 ` Jens Lechtenboerger
2020-09-27 18:35 93% ` TEC
2020-09-28 8:17 ` Jens Lechtenboerger
2020-12-13 16:12 ` TEC
2020-12-14 6:04 ` Bastien
2020-12-14 9:49 ` Jens Lechtenboerger
2020-12-15 11:39 ` TEC
2020-12-16 6:55 ` Jens Lechtenboerger
2020-12-16 7:22 86% ` TEC
2020-12-16 8:37 ` Jens Lechtenboerger
2020-12-20 5:08 93% ` TEC
2020-12-20 17:59 ` Jens Lechtenboerger
2021-01-02 18:51 ` TEC
2021-01-03 13:26 ` Jens Lechtenboerger
2021-01-03 14:48 ` TEC
2021-01-03 15:41 ` Jens Lechtenboerger
2021-01-03 17:17 ` TEC
2021-01-04 7:11 ` Jens Lechtenboerger
2021-01-10 15:52 ` TEC
2021-01-10 17:02 ` Jens Lechtenboerger
2021-01-10 20:36 93% ` TEC
2021-01-14 10:36 ` TEC
2021-01-21 4:05 ` Kyle Meyer
2021-01-21 5:55 93% ` TEC
2021-01-14 15:59 ` Jens Lechtenboerger
2021-01-14 16:02 93% ` Ready to merge! " TEC
2020-12-20 5:08 93% ` TEC
2020-12-14 6:34 ` TEC
2020-12-14 7:20 ` Bastien
2020-12-14 7:27 90% ` TEC
[not found] <388850760.3644614.1634354740816.ref@mail.yahoo.com>
2021-10-16 3:25 ` Subject: [PATCH] Fix DISPLAY error on exporting org with plantuml to html Sun Lin
2021-11-18 7:38 92% ` Timothy
2021-11-18 7:47 ` Sun Lin
2021-11-30 1:41 ` Sun Lin
2021-11-30 4:18 90% ` Timothy
2020-12-23 2:35 82% [PATCH] Apply emacs manual css to org pages TEC
2020-12-29 6:07 ` Kyle Meyer
2021-03-24 8:08 ` Bastien
2021-04-25 3:34 93% ` Timothy
2020-12-27 21:29 ` Samuel Wales
2020-12-27 21:39 ` Samuel Wales
2020-12-27 21:45 ` Samuel Wales
2020-12-28 4:04 93% ` TEC
2020-12-23 3:42 ` Greg Minshall
2021-04-25 3:36 93% ` Timothy
2021-03-31 15:57 80% [PATCH] Add font-lock rule for inline export snippets Timothy
2021-04-28 7:23 93% ` Timothy
2021-03-19 12:03 77% [PATCH] Improve documentation of #+startup keyword Timothy
2021-09-24 0:03 [PATCH] org-manual.org: Augment TODO keywords example Thomas S. Dye
2021-09-24 4:39 93% ` Timothy
2021-08-09 13:06 [patch] priorities range reversed Joe Corneli via General discussions about Org-mode.
2021-08-09 13:51 ` Joe Corneli via General discussions about Org-mode.
2021-08-31 15:14 93% ` Timothy
2021-09-02 13:44 [PATCH] Re: New source block results option for attaching file to node Greg Minshall
2021-09-03 3:10 ` Ihor Radchenko
2021-09-03 3:28 ` Ryan Scott
2021-09-05 13:22 ` Ihor Radchenko
2021-09-05 13:56 ` Ryan Scott
2021-09-10 1:04 ` Ryan Scott
2021-09-10 6:26 93% ` Timothy
2020-10-30 7:35 [PATCH] add new link type "contact:" for org-contacts.el stardiviner
2020-10-30 7:44 ` stardiviner
2020-11-09 0:24 ` stardiviner
2020-11-09 6:14 ` Jean Louis
2020-11-10 1:15 ` [UPDATED PATCH] " stardiviner
2020-11-11 8:37 ` Bastien
2020-11-11 12:04 ` stardiviner
2020-11-11 13:57 ` More on design of org-contacts.el - " Jean Louis
2020-11-16 9:26 ` stardiviner
2020-12-14 6:06 ` Bastien
2020-12-15 8:53 ` [final patch] " stardiviner
2020-12-15 9:56 ` Bastien
2020-12-15 14:13 ` stardiviner
2020-12-15 14:27 ` Bastien
2021-04-25 3:31 93% ` Timothy
2021-04-25 3:59 93% ` Timothy
2021-09-24 0:06 [PATCH] org-manual.org: Augment TODO keywords example Thomas S. Dye
2021-09-24 4:41 93% ` Timothy
2021-04-24 4:59 [PATCH] Refresh inline plotted images Timothy
2021-04-26 14:54 93% ` Timothy
2021-08-09 14:41 [PATCH] Fix bug assuming canonical duration units in org-agenda-format-items Anders Johansson
2021-08-11 9:39 ` Nicolas Goaziou
2021-08-31 13:55 93% ` Timothy
2021-02-18 16:33 [PATCH] Startup option to separate macros arguments with an alternative string Juan Manuel Macías
2021-04-19 9:19 ` Nicolas Goaziou
2021-04-21 16:01 ` Juan Manuel Macías
2021-04-22 12:55 ` Nicolas Goaziou
2021-04-22 13:46 ` Juan Manuel Macías
2021-04-25 3:46 93% ` Timothy
2021-08-17 23:07 [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil Morgan Willcock
2021-09-19 13:13 92% ` Timothy
2021-09-19 15:30 ` Morgan Willcock
2021-09-19 17:02 93% ` Timothy
2021-08-31 11:59 89% ` Timothy
2021-08-31 12:42 ` Morgan Willcock
2021-08-31 12:54 93% ` Timothy
2021-06-28 9:34 [PATCH] Customizify org-babel-fortran-compiler Nico Sonack
2021-07-01 14:45 93% ` Timothy
2021-09-11 7:05 [PATCH] ob-tangle.el: Fix error in org-tangle from org-src edit buffer Mark Dawson
2021-09-19 12:57 93% ` Timothy
2021-07-30 15:00 Bug: Percentage in caption (even escaped) does not work in LaTeX export Charest, Luc
2021-09-03 12:17 ` Maxim Nikulin
2021-09-07 12:21 ` [PATCH] ox-latex: Allow percent sign in 'src-block' caption Maxim Nikulin
2021-09-07 13:17 93% ` Timothy
2021-04-24 22:02 [PATCH] org-capture.el: Add new capture template option :refile-to Richard Garner
2021-04-25 3:16 93% ` Timothy
2021-06-16 23:29 [PATCH] ob-core: tangle check library of babel after current buffer Tom Gillespie
2021-07-17 17:42 ` Tom Gillespie
2021-07-24 19:41 93% ` Timothy
2021-09-24 19:56 [PATCH] Include support for evaluating julia code Pedro Bruel
2021-09-24 20:04 92% ` Timothy
2021-09-25 14:06 ` Bastien
2021-09-25 14:13 93% ` Timothy
2021-08-05 12:12 [PATCH] Rename headline to heading André A. Gomes
2021-09-19 11:06 89% ` Timothy
2021-09-26 9:27 ` Bastien
2021-09-30 12:21 ` André A. Gomes
2021-10-01 8:38 ` Bastien
2021-10-15 8:52 ` André A. Gomes
2021-10-15 9:56 93% ` Timothy
2021-01-26 7:53 [PATCH] ob-java: Allow import to end with asterisk John Herrlin
2021-01-27 3:21 ` ian martins
2021-01-28 20:03 ` John Herrlin
2021-01-30 10:50 ` ian martins
2021-04-25 3:43 93% ` Timothy
2021-10-05 22:37 [PATCH] ob-R async evaluation Jeremie Juste
2021-11-18 10:36 93% ` Timothy
2020-12-17 17:11 [patch] A proposal to add LaTeX attributes to verse blocks Juan Manuel Macías
2021-01-03 10:22 93% ` TEC
2021-12-30 4:05 [PATCH] Fix caption format for custom latex src block Matt Huszagh
2022-06-14 3:51 ` Ihor Radchenko
2022-06-28 4:07 ` Matt Huszagh
2022-06-29 15:26 88% ` Timothy
2022-06-29 2:24 ` Ihor Radchenko
2022-06-29 15:20 93% ` Timothy
2020-11-03 20:40 [PATCH] ox-md.el/preserve radio target hyperlink nazar.stasiv
2021-01-03 10:11 93% ` TEC
2021-06-23 22:50 [PATCH] ob-R output file with graphics parameter Jeremie Juste
2021-06-24 9:21 ` Colin Baxter
2021-06-27 17:12 ` Jack Kamm
2021-06-28 21:54 ` Jeremie Juste
2021-07-03 4:21 ` Jack Kamm
2021-07-03 4:52 92% ` Timothy
2021-09-29 13:33 [PATCH] Prevent displayed images from being re-scaled Timothy
2021-10-02 20:30 93% ` Timothy
2021-10-25 13:49 93% ` Timothy
2021-10-03 4:57 ` Bastien
2021-10-03 5:45 93% ` Timothy
2020-12-02 9:30 [PATCH] [C-c C-q] completing tags from both buffer-local and global alist of tags stardiviner
2020-12-03 2:40 ` [PATCH] I updated patch by deleteing duplicate tags stardiviner
2021-01-10 22:10 ` Kyle Meyer
2021-01-11 2:24 ` Christopher Miles
2021-01-13 3:26 ` Kyle Meyer
2021-01-13 9:30 ` Christopher Miles
2021-01-14 5:24 ` Kyle Meyer
2021-04-25 3:25 99% ` Timothy
2021-01-08 16:28 [PATCH] ob-java, a proposal on import improvement John Herrlin
2021-01-09 15:51 ` ian martins
2021-01-10 20:55 ` John Herrlin
2021-01-12 12:00 ` ian martins
2021-01-16 12:56 ` ian martins
2021-01-16 15:32 ` John Herrlin
2021-01-16 20:49 ` ian martins
2021-04-25 3:42 93% ` Timothy
2021-11-24 16:11 [PATCH] Fix ob-plantuml over TRAMP Guillaume Buisson (gbuisson)
2021-12-02 9:43 93% ` Timothy
2020-11-04 6:40 [PATCH] ox-md.el/markdown-hyperlink turbo.cafe
2021-01-03 10:06 93% ` TEC
2021-09-28 14:54 [PATCH] Treat :tangle-mode as an octal value not integer Jeremy Cowgar
2021-09-29 13:48 86% ` Timothy
2021-09-29 14:26 ` tomas
2021-09-29 14:58 78% ` Timothy
2021-09-29 15:13 ` Jeremy Cowgar
2021-09-30 18:13 93% ` Timothy
2021-09-29 17:18 ` Greg Minshall
2021-11-18 12:04 93% ` Timothy
2021-09-30 18:14 [PATCH] Accept more :tangle-mode specification forms Timothy
2021-10-05 14:45 93% ` Timothy
2021-11-18 10:20 93% ` Timothy
2021-11-18 17:22 87% ` Timothy
2021-11-19 16:31 ` Tim Cross
2021-11-20 8:08 ` Timothy
2021-11-20 12:25 ` tomas
2021-11-20 14:50 93% ` Timothy
2021-11-21 4:08 ` Greg Minshall
2021-11-21 4:27 93% ` Timothy
2021-11-20 19:49 ` Tim Cross
2021-11-21 4:02 ` Timothy
2021-11-21 13:51 ` Tim Cross
2021-11-21 14:33 ` Timothy
2021-11-29 18:57 91% ` Timothy
2021-10-05 15:54 ` unknown@email.com
2021-10-05 16:13 93% ` Timothy
2021-10-01 1:24 ` Tom Gillespie
2021-10-01 6:59 ` Timothy
2021-10-01 8:00 ` Stefan Nobis
2021-10-01 10:05 ` Eric S Fraga
2021-10-01 10:29 ` tomas
2021-10-01 18:04 ` Tom Gillespie
2021-10-01 18:14 81% ` Timothy
2021-05-28 22:40 [PATCH] Fixed lstset where language= wipes out previous definitions Karl Stump
2021-09-19 13:02 93% ` Timothy
2021-03-25 17:43 [PATCH 0/1] Add option to delay fontification of source blocks Leo Okawa Ericson
2021-04-25 3:48 93% ` Timothy
2021-10-24 17:20 [patch] Fix link to Library of Babel Thomas S. Dye
2021-11-21 7:04 93% ` Dodgy Worg publishing? (was: [patch] Fix link to Library of Babel) Timothy
2021-10-28 15:24 [PATCH] org-src: Reset buffer-modified-p after fontifying Clément Pit-Claudel
2021-11-21 6:58 93% ` Timothy
2021-01-20 10:46 [PATCH] TEC
2021-01-20 11:00 93% ` [PATCH] tweaks to ox-html style TEC
2021-02-12 6:16 ` Kyle Meyer
2021-02-12 16:57 ` Jens Lechtenboerger
2021-02-12 18:16 88% ` Timothy
2021-02-12 21:46 ` Tim Cross
2021-02-13 13:32 ` Christian Moe
2021-02-14 4:36 93% ` Timothy
2021-02-12 17:08 ` Jens Lechtenboerger
2021-02-12 18:22 92% ` Timothy
2021-04-28 3:38 ` [PATCH] Bastien
2021-04-28 3:53 91% ` [PATCH] Timothy
2021-01-05 3:56 [PATCH v2] org-contacts.el: Only use org-id-store-link if org-id is loaded Kyle Meyer
2021-01-05 4:20 ` [PATCH] org-contacts.el: Use `bound-and-true-p' to check (unbound) var David Florness
2021-01-05 11:33 ` miles christopher
2021-04-25 3:41 93% ` Timothy
2021-08-02 15:45 [PATCH] minor typo fix in org-tutorials/org-protocol-custom-handler.org Atlas Cove
2021-08-14 23:25 ` Tim Cross
2021-08-15 2:24 ` Eric Abrahamsen
2021-09-19 12:42 93% ` Timothy
2021-09-09 22:58 [BUG?][PATCH] Should the `lexical-binding' variable be bound during src block with :lexical t? [9.4.6 (9.4.6-ga451f9 @ /home/n/.emacs.d/straight/build/org/)] No Wayman
2021-09-10 6:32 93% ` Timothy
2021-07-12 18:07 [PATCH] be more cautious when setting csl etc dir location Timothy
2021-07-14 19:39 93% ` Timothy
2021-07-15 2:33 [PATCH] manual: How to refer to tables in other files William Denton
2021-09-19 13:36 93% ` Timothy
2021-06-03 21:58 [PATCH] Add faces to improve contextuality of agenda views Protesilaos Stavrou
2021-09-19 13:23 93% ` Timothy
2021-03-08 22:57 [PATCH] org-src.el Do not ask to revert unmodified buffers pillule
2021-03-21 20:33 ` Kyle Meyer
2021-03-26 3:10 ` pillule
2021-05-01 10:55 93% ` Timothy
2021-04-04 18:46 [PATCH] LaTeX export: arbitrary float environments Thomas S. Dye
2021-05-01 11:08 91% ` Timothy
2021-05-01 17:20 ` Thomas S. Dye
2021-05-01 17:31 88% ` Timothy
2020-09-28 22:37 [PATCH] Add org-meta*-final-hook Jay Bosamiya
2021-04-25 6:31 91% ` Timothy
2020-04-24 6:55 [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers Ihor Radchenko
2020-05-17 15:00 ` Ihor Radchenko
2020-05-17 15:40 ` Ihor Radchenko
2020-05-18 14:35 ` Nicolas Goaziou
2020-05-18 16:52 ` Ihor Radchenko
2020-05-19 13:07 ` Nicolas Goaziou
2020-05-23 13:52 ` Ihor Radchenko
2020-05-26 8:33 ` Nicolas Goaziou
2020-06-02 9:21 ` Ihor Radchenko
2020-06-05 7:26 ` Nicolas Goaziou
2020-06-05 8:18 ` Ihor Radchenko
2020-06-05 13:50 ` Nicolas Goaziou
2020-06-08 5:05 ` Ihor Radchenko
2020-06-10 17:14 ` Nicolas Goaziou
2020-08-11 6:45 ` Ihor Radchenko
2020-08-11 23:07 ` Kyle Meyer
2020-08-12 6:29 ` Ihor Radchenko
2020-09-20 5:53 ` Ihor Radchenko
2020-12-04 5:58 ` Ihor Radchenko
2021-03-21 9:09 ` Ihor Radchenko
2021-05-03 17:28 ` Bastien
2021-09-21 13:32 93% ` Timothy
2021-04-18 7:22 [PATCH] ob-tangle.el: Speed up tangling Sébastien Miquel
2021-04-18 18:47 ` Tom Gillespie
2021-04-19 8:05 ` Sébastien Miquel
2021-04-20 8:33 ` Tom Gillespie
2021-04-21 6:33 ` Sébastien Miquel
2021-04-21 8:02 93% ` Timothy
2020-12-17 17:23 [PATCH] A proposal to add LaTeX attributes to verse blocks Juan Manuel Macías
2021-01-03 10:25 92% ` TEC
2021-01-03 13:07 ` Juan Manuel Macías
2021-01-03 13:08 79% ` TEC
2021-01-07 18:52 ` Juan Manuel Macías
2021-05-01 10:58 93% ` Timothy
2021-05-01 10:58 ` Bastien
[not found] ` <87tunlxws3.fsf@ucl.ac.uk>
2021-05-02 11:31 92% ` Timothy
2022-05-04 15:59 [PATCH] New LaTeX code export option: engraved Timothy
2022-05-09 19:19 ` Sébastien Miquel
2022-05-10 1:13 93% ` Timothy
2022-05-10 16:10 93% ` Timothy
2022-05-05 8:48 ` Ihor Radchenko
2022-05-05 15:17 ` Timothy
2022-05-05 16:13 ` Timothy
2022-05-07 5:16 ` Ihor Radchenko
2022-05-07 6:57 ` Timothy
2022-05-07 10:40 ` Timothy
2022-05-07 11:33 ` Daniel Fleischer
2022-05-08 14:30 ` [PATCH] (v2) " Timothy
2022-05-09 6:20 ` Ihor Radchenko
2022-05-09 12:57 80% ` Timothy
2022-05-11 16:05 ` [PATCH] (v3) " Timothy
2022-05-12 16:40 ` Daniel Fleischer
2022-05-12 16:44 93% ` Timothy
2022-05-05 7:52 ` [PATCH] " Daniel Fleischer
2022-05-05 16:09 93% ` Timothy
2022-05-06 2:35 ` Ihor Radchenko
2022-05-06 11:23 86% ` Timothy
2021-03-25 18:25 [PATCH 0/1] Add option to delay fontification of source blocks leo
2021-04-25 3:49 93% ` Timothy
2021-04-25 9:06 [PATCH] Babel: remove LaTeX environment -type #+results Timothy
2021-05-01 11:03 ` Bastien
2021-05-01 11:44 93% ` Timothy
2021-04-25 13:44 ` Greg Minshall
2021-04-25 18:09 92% ` Timothy
2022-06-27 12:08 [PATCH] Improve look of agenda on graphical displays Stefan Kangas
2022-06-29 9:19 ` Ihor Radchenko
2022-06-29 10:20 ` Stefan Kangas
2022-06-29 12:46 ` [STYLE] :version tags in defcustom definitions (was: [PATCH] Improve look of agenda on graphical displays) Ihor Radchenko
2022-06-29 12:55 ` Stefan Kangas
2022-06-29 14:07 93% ` Timothy
2020-10-29 0:46 [PATCH] New "project" option for org-link-file-path-type Jack Kamm
2020-11-02 5:41 ` Kyle Meyer
2020-11-04 18:11 ` Jack Kamm
2020-11-06 3:33 ` Kyle Meyer
2020-11-12 1:05 ` Jack Kamm
2021-04-25 3:29 93% ` Timothy
2021-09-26 11:51 [PATCH] Timothy
2021-09-26 12:01 93% ` [PATCH] Timothy
2021-09-26 12:14 ` [PATCH] Timothy
2021-09-27 8:19 ` [PATCH] Bastien
2021-09-27 10:35 ` [PATCH] Timothy
2021-09-27 11:45 ` [PATCH] Bastien
2021-09-27 12:20 93% ` [PATCH] Timothy
2021-09-27 15:26 ` [PATCH] Bastien
2021-09-27 15:36 93% ` [PATCH] Timothy
2021-09-27 17:44 ` [PATCH] Bastien
2021-09-27 17:52 93% ` [PATCH] Timothy
2021-09-27 19:45 ` [PATCH] Bastien
2021-09-28 15:31 ` [PATCH] Bastien Guerry
2021-09-28 15:50 93% ` [PATCH] Timothy
2019-12-07 7:26 PATCH: Display point of code block point when confirming evaluation Jarmo Hurri
2020-09-30 4:04 ` Kyle Meyer
2020-09-30 4:57 93% ` TEC
2021-11-21 18:41 [PATCH] Fix window width when line numbers present Matt Huszagh
2021-11-21 19:19 93% ` Timothy
2021-11-21 19:14 92% ` Timothy
2021-11-21 21:08 ` Nicolas Goaziou
2021-11-22 3:16 93% ` Timothy
2021-11-21 21:14 ` Matt Huszagh
2021-11-21 21:16 ` Bastien
2021-11-21 21:22 ` Matt Huszagh
2021-11-22 5:14 ` Bastien
2021-11-22 5:31 93% ` Timothy
2021-11-22 5:44 ` Bastien
2021-11-22 5:51 90% ` Supported Emacs version (was: [PATCH] Fix window width when line numbers present) Timothy
2021-08-25 20:12 [BUG] Creating sparse tree with regexp property matches Cassio Koshikumo
2021-08-25 21:03 ` Daniel Fleischer
2021-08-25 22:30 ` Cassio Koshikumo
2021-08-31 11:27 ` Timothy
2021-08-31 12:28 ` Daniel Fleischer
2021-08-31 12:56 ` Timothy
2021-08-31 20:31 ` Daniel Fleischer
2021-09-01 10:28 ` Timothy
2021-09-01 11:32 ` Daniel Fleischer
2021-09-02 6:35 ` [PATCH] " Daniel Fleischer
2021-09-16 15:01 ` Daniel Fleischer
2021-09-17 10:17 85% ` Timothy
2021-04-07 11:24 [PATCH] Use <img> tags for SVGs Timothy
2021-04-07 11:29 93% ` Timothy
2022-06-05 14:32 [PATCH] Support #+include-ing URLs Timothy
2022-06-12 9:52 93% ` Timothy
2022-06-05 15:01 ` Max Nikulin
2022-06-07 10:09 ` Fraga, Eric
2022-06-07 11:27 91% ` Timothy
2021-09-16 21:40 [PATCH] Fix some typos Stefan Kangas
2021-09-17 9:03 93% ` Timothy
2021-10-13 22:14 [PATCH] org-manual.org: org-cite additions Bruce D'Arcus
2021-11-18 8:08 93% ` Timothy
2021-03-25 11:58 org-plot/gnuplot: question and feature suggestions Eric S Fraga
[not found] ` <88f6c54a01f345d785492c4d5b3b82d3@VI1PR0102MB3327.eurprd01.prod.exchangelabs.com>
2021-04-26 17:05 ` [PATCH] Have C-c C-c recognise #+plot lines Eric S Fraga
2021-04-26 17:11 ` Timothy
2021-04-26 17:13 ` Timothy
2021-04-26 17:17 ` Timothy
2021-04-30 7:06 93% ` Timothy
2021-04-28 18:04 93% ` Timothy
2021-04-30 8:17 ` Eric S Fraga
2021-04-30 8:22 ` Bastien
2021-04-30 8:52 93% ` Timothy
2021-04-30 10:59 ` Eric S Fraga
2021-04-30 12:16 90% ` Timothy
2021-01-31 19:04 [PATCH] document org-html-meta-tags TEC
2021-02-08 0:50 ` Kyle Meyer
2021-02-09 19:51 93% ` Timothy
2022-01-24 16:42 [PATCH] Add support for $…$ latex fragments followed by a dash Sébastien Miquel
2022-01-25 7:56 ` Eric S Fraga
2022-01-26 17:15 ` Rudolf Adamkovič
2022-01-27 8:28 ` Ihor Radchenko
2022-01-27 19:15 ` Tim Cross
2022-01-28 14:37 ` Max Nikulin
2022-01-28 16:37 89% ` Timothy
2020-09-06 5:50 [PATCH] org-plot abstractions and extension TEC
[not found] ` <87blijmnv9.fsf@gnu.org>
[not found] ` <CAHNg_jM8sE4a6XvL5D8Gks4dQXfWhZvRBR33BDLkRgEgZ++ZGg@mail.gmail.com>
2020-09-15 3:43 ` TEC
2020-09-25 17:51 93% ` TEC
2020-10-17 2:12 93% ` TEC
2020-10-24 11:31 ` Bastien
2020-10-24 18:16 ` TEC
2020-12-09 2:58 93% ` TEC
2020-12-14 5:41 ` Bastien
2020-12-14 6:30 93% ` TEC
2020-12-23 5:09 ` Kyle Meyer
2020-12-23 5:10 93% ` TEC
2020-10-25 18:54 [PATCH] Async session eval (2nd attempt) Jack Kamm
2021-01-03 8:51 ` TEC
2021-02-28 22:23 ` Jack Kamm
2021-03-01 6:22 91% ` Timothy
2021-03-04 5:13 ` Kyle Meyer
2021-04-25 6:26 89% ` Timothy
2021-09-26 15:03 [PATCH] ob-svgbob: New babel backend for SVGBob Steven vanZyl
2021-09-26 20:33 ` Bastien
2021-09-26 20:35 88% ` Timothy
2021-11-28 15:59 [patch] fix ox-latex async export bug Rasmus
2021-11-28 19:52 ` Nicolas Goaziou
2021-11-28 22:54 ` Tim Cross
2021-11-29 5:15 93% ` Timothy
2021-08-23 10:23 [PATCH] org-cite: define \citeprocitem for LaTeX export Timothy
2021-08-26 8:18 93% ` Timothy
2021-09-19 13:19 93% ` Timothy
2021-01-30 21:57 [PATCH] ox-md.el export code blocks using grave accents Rodrigo Morales
2021-01-30 22:51 ` Tim Cross
2021-04-27 10:03 ` Bruce D'Arcus
2021-04-27 10:18 91% ` Timothy
2021-06-28 12:42 [patch] add :url and :doi optional entries for export to BiBTeX Eric S Fraga
2021-06-28 12:59 ` Eric S Fraga
2021-07-01 14:23 93% ` Timothy
2021-07-30 15:24 Bug: org-agenda-highlight-todo: Symbol’s function definition is void: string-empty-p [9.4.6 (9.4.6-11-g1ee52c-elpa @ /home/vmg/.emacs.d/elpa/org-20210726/)] Вячеслав Гришин
2021-08-04 15:20 ` [PATCH] org-agenda.el: Avoid dependency on subr-x Maxim Nikulin
2021-08-05 12:59 ` Timothy
2021-08-06 17:10 ` Maxim Nikulin
2021-08-06 20:30 93% ` Timothy
2021-03-31 15:25 [PATCH] avoid loading major modes when exporting to file Timothy
2021-05-01 16:52 ` Bastien
2021-05-01 17:26 84% ` Timothy
2021-07-12 3:51 [PATCH] Fix match/maxlevel conflict in colview dynblock Nick Dokos
2021-08-31 14:33 93% ` Timothy
2021-08-24 11:02 [PATCH] Update some changed export keybindings [worg] Stefan Kangas
2021-08-31 11:37 93% ` Timothy
2021-01-02 22:13 [PATCH] ol: Avoid initial input when completing function for storing link Kyle Meyer
2021-01-05 5:16 ` Kyle Meyer
2021-04-25 3:38 93% ` Timothy
2021-11-22 18:37 [PATCH] ob-shell-test, test-ob-shell and introduction Matt
2021-11-22 18:43 88% ` Timothy
2021-11-24 18:48 ` Matt
2021-12-02 9:39 93% ` Timothy
2021-06-20 9:17 [PATCH] Fix regression in org-get-time-of-day introduced in aba1f2066 Ihor Radchenko
2021-06-20 16:09 ` Nicolas Goaziou
2021-07-24 19:48 93% ` Timothy
2021-07-08 16:04 [PATCH] bad table formula recorded in some cases tbanelwebmin
2021-07-21 10:50 93% ` Timothy
2021-07-21 14:25 ` tbanelwebmin
2021-07-21 15:07 93% ` Timothy
2021-03-31 15:00 [PATCH] Fontification for inline src blocks Timothy
2021-04-28 7:14 88% ` Timothy
2021-05-02 20:17 93% ` Timothy
2021-05-02 20:57 ` Tom Gillespie
2021-05-02 21:03 87% ` Timothy
2021-05-03 3:29 ` Timothy
2021-05-12 11:15 93% ` Timothy
2021-05-12 14:24 ` Ihor Radchenko
2021-05-12 14:47 93% ` Timothy
2021-05-12 15:53 ` Ihor Radchenko
2021-05-12 16:39 81% ` Timothy
2021-05-18 12:06 ` Sébastien Miquel
2021-05-18 13:34 80% ` Timothy
2021-11-21 14:09 ` Timothy
2021-11-22 11:52 ` Timothy
2021-12-02 12:53 ` Eric S Fraga
2021-12-02 13:57 91% ` Faces for inline src blocks (was: [PATCH] Fontification for inline src blocks) Timothy
2021-11-22 12:23 ` [PATCH] Fontification for inline src blocks Ihor Radchenko
2021-11-22 13:43 ` Timothy
2021-11-22 14:35 ` Ihor Radchenko
2021-11-22 14:37 93% ` Timothy
2021-11-23 13:30 ` Ihor Radchenko
2021-11-29 19:21 ` Timothy
2021-11-30 11:44 93% ` Timothy
2021-11-30 12:45 ` Sébastien Miquel
2021-11-30 12:46 93% ` Timothy
2021-10-03 7:14 ` Ihor Radchenko
2021-10-03 7:16 93% ` Timothy
2021-10-03 9:09 ` Ihor Radchenko
2021-10-03 9:22 83% ` Timothy
2021-06-28 10:21 [PATCH] Customizify org-babel-fortran-compiler Nico Sonack
2021-07-01 14:40 84% ` Timothy
2021-06-06 16:55 [PATCH] Change default latex compiler to latexmk Timothy
2021-06-29 14:32 ` Bruce D'Arcus
2021-06-30 10:48 ` Bastien
2021-06-30 11:14 ` Bruce D'Arcus
2021-07-09 12:30 ` Bruce D'Arcus
2021-07-09 14:17 ` Bastien
2021-07-09 14:25 93% ` Timothy
2021-07-09 15:03 ` Bastien
2021-07-09 16:41 93% ` Timothy
2022-06-12 14:43 [PATCH] New remote resource download policy Timothy
2022-06-14 9:40 ` Robert Pluim
2022-06-22 9:58 93% ` Timothy
2022-06-15 12:35 ` Max Nikulin
2022-06-22 10:01 84% ` Timothy
2022-06-22 16:55 ` Max Nikulin
2022-06-29 15:27 93% ` Timothy
2022-06-30 16:57 ` Max Nikulin
2022-07-16 9:47 91% ` Timothy
2021-06-06 18:19 [PATCH] Allow LaTeX reference command (\ref) to be customised Timothy
2021-06-09 2:11 93% ` Timothy
2021-06-09 11:52 ` Nicolas Goaziou
2021-06-09 13:36 90% ` Timothy
2021-06-09 15:08 ` Nicolas Goaziou
2021-06-09 17:38 93% ` Timothy
2021-03-25 17:19 [PATCH 0/1] Add option to delay fontification of source blocks Leo Okawa Ericson
2021-03-29 5:03 ` Kyle Meyer
2021-04-02 12:44 ` Leo Okawa Ericson
2021-04-25 3:48 93% ` Timothy
2021-11-21 19:08 [PATCH] Fix regex for determining image width from attribute Matt Huszagh
2021-11-21 19:20 81% ` Timothy
2021-11-21 19:51 ` Matt Huszagh
2021-11-22 8:29 91% ` Timothy
2021-11-22 16:11 ` Matt Huszagh
2021-11-22 17:54 93% ` Timothy
2021-11-22 20:53 ` Matt Huszagh
2021-11-23 5:14 93% ` Timothy
2021-11-23 5:38 ` Matt Huszagh
2021-11-23 5:39 93% ` Timothy
2021-11-23 7:46 ` Matt Huszagh
2021-11-23 16:44 ` Max Nikulin
2021-11-24 1:57 ` Matt Huszagh
2021-11-24 14:48 ` Max Nikulin
2021-11-24 15:59 ` Matt Huszagh
2021-11-24 17:00 ` Max Nikulin
2021-11-25 16:43 ` Max Nikulin
2021-11-29 0:23 ` Matt Huszagh
2021-11-29 5:13 93% ` Timothy
2021-10-23 12:18 [PATCH] org.el (org-display-inline-image--width): Small fix Sébastien Miquel
2021-11-03 16:25 ` Nicolas Goaziou
2021-11-18 12:06 93% ` Timothy
2021-09-30 17:20 [PATCH] Don't fill displayed equations Timothy
2021-09-30 18:51 ` Nicolas Goaziou
2021-09-30 18:54 93% ` Timothy
2021-09-30 19:02 ` Nicolas Goaziou
2021-09-30 19:28 93% ` Timothy
2021-09-30 20:45 ` Timothy
2021-10-04 6:05 83% ` Timothy
2021-10-04 7:11 ` Tom Gillespie
2021-10-04 7:15 93% ` Timothy
2021-09-30 22:55 ` Nicolas Goaziou
2021-10-01 7:43 ` Timothy
2021-10-02 11:06 ` Nicolas Goaziou
2021-10-02 11:24 92% ` Timothy
2021-10-03 8:49 ` Ihor Radchenko
2021-10-03 8:50 93% ` Timothy
2021-10-03 9:13 ` Ihor Radchenko
2021-10-03 9:14 93% ` Timothy
2021-10-03 9:41 ` Ihor Radchenko
2021-10-03 9:42 93% ` Timothy
2021-10-01 7:38 ` Stefan Nobis
2021-10-01 20:41 ` Nicolas Goaziou
2021-10-02 10:04 ` Eric S Fraga
2021-10-02 10:18 83% ` Timothy
2021-10-02 11:24 ` Eric S Fraga
2021-10-02 14:21 ` Max Nikulin
2021-10-02 17:51 ` Tom Gillespie
2021-10-02 18:28 93% ` Timothy
2021-03-31 16:41 [PATCH] Wrap LaTeX snippets in $$ with markdown export Timothy
2021-05-02 20:23 93% ` Timothy
2021-05-03 16:13 ` Nicolas Goaziou
2021-05-03 18:03 87% ` Timothy
2021-05-03 22:54 ` Nicolas Goaziou
2021-05-04 3:35 ` Timothy
2021-05-04 13:03 ` Nicolas Goaziou
2021-05-04 13:31 87% ` Timothy
2021-05-06 21:56 ` Nicolas Goaziou
2021-05-09 20:12 93% ` Timothy
2021-03-31 20:59 ` Berry, Charles via General discussions about Org-mode.
2021-05-02 20:20 93% ` Timothy
2022-07-08 12:17 LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Juan Manuel Macías
2022-07-08 18:49 ` Thomas S. Dye
2022-07-09 2:23 ` Max Nikulin
2022-07-09 10:42 ` Juan Manuel Macías
2022-07-09 12:15 ` Max Nikulin
2022-07-09 14:58 ` Juan Manuel Macías
[not found] ` <b58ee3cc-c58c-b627-9cc5-51993020db2c@gmail.com>
2022-07-09 20:22 ` Juan Manuel Macías
2022-07-10 20:23 ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Juan Manuel Macías
2022-07-11 2:19 ` Ihor Radchenko
2022-07-11 14:19 ` Timothy
2022-07-11 15:00 ` Juan Manuel Macías
2022-07-11 17:45 85% ` fontsets (was: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")) Timothy
2021-07-01 3:50 [PATCH] Fix erroneous tangling of blocks Jacopo De Simoi
2021-07-01 13:38 93% ` Timothy
2021-09-16 10:34 [PATCH] Various minor docfixes found by checkdoc Stefan Kangas
2021-09-16 19:30 ` Marco Wahl
2021-09-19 13:00 93% ` Timothy
2022-01-29 16:00 [PATCH] Remote link localisation, i.e. exporting remote images Timothy
2022-01-31 11:40 93% ` Timothy
2021-09-20 11:56 [PATCH] org-cite: Use citeproc-el to create CSL processor itemgetters András Simonyi
2021-09-20 12:29 91% ` Timothy
2021-08-23 10:27 [PATCH] org-cite: prevent ' from being an active char in LaTeX export Timothy
2021-08-26 8:24 93% ` Timothy
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).