Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
Hi all,
Here I am attaching a new version of the patch that includes a commit
message.
I put here an example for those who want to try it, a fragment of a
poem by W.H. Auden.
Best regards,
Juan Manuel
#+begin_src org
,#+LaTeX_Header: \usepackage{verse}
,#+ATTR_LATEX: :center t
,#+ATTR_LATEX: :versewidth Teach the free man how to praise.
,#+ATTR_LATEX: :lines 5 :latexcode \small
,#+begin_verse
Earth, receive an honoured guest:
William Yeats is laid to rest.
Let the Irish vessel lie
Emptied of its poetry.
In the nightmare of the dark
All the dogs of Europe bark,
And the living nations wait,
Each sequestered in its hate;
Intellectual disgrace
Stares from every human face,
And the seas of pity lie
Locked and frozen in each eye.
Follow, poet, follow right
To the bottom of the night,
With your unconstraining voice
Still persuade us to rejoice;
With the farming of a verse
Make a vineyard of the curse,
Sing of human unsuccess
In a rapture of distress;
In the deserts of the heart
Let the healing fountain start,
In the prison of his days
Teach the free man how to praise.
,#+end_verse
#+end_src
https://juanmanuelmacias.com/
>From 337014731e89f7f28873b8f5d9a917901e810c95 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Sat, 8 May 2021 09:03:10 +0200
Subject: [PATCH] Add LaTeX attributes for verse blocks
---
doc/org-manual.org | 48 ++
lisp/ox-latex.el | 20 +++
2 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index ab12fa70a..c752ce46d 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13861,6 +13861,54 @@ The LaTeX export back-end converts horizontal rules by the specified
-
#+end_example
+*** Verse blocks in LaTeX export
+:PROPERTIES:
+:DESCRIPTION: Attributes specific to special blocks.
+:END:
+
+#+cindex: verse blocks, in @LaTeX{} export
+#+cindex: @samp{ATTR_LATEX}, keyword
+
+The LaTeX export back-end accepts four attributes for verse blocks:
+=:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
+require the external LaTeX package =verse.sty=, wich is an extension
+of the standard LaTeX environment. The purpose of these attributes is
+explained below.
+
+- =:lines= :: To add marginal verse numbering. Its value is an
+ integer, the sequence in which the verses should be numbered.
+- =:center= :: With value =t= all the verses on the page are optically
+ centered (a typographic convention for poetry), taking as a
+ reference the longest verse, which must be indicated by the
+ attribute =:versewidth=.
+- =:versewidth= :: Its value is a literal text string with the longest
+ verse.
+- =:latexcode= :: It accepts any arbitrary LaTeX code that can be
+ included within a LaTeX =verse= environment.
+
+A complete example with Shakespeare's first sonnet:
+
+#+begin_src org
+,#+ATTR_LaTeX: :center t :latexcode \color{red} :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
+
** Markdown Export
:PROPERTIES:
:DESCRIPTION: Exporting to Markdown.
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index c3fc83b1b..0376dffd1 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3513,6 +3513,17 @@ 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))
+ (latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
+ (cent (org-export-read-attribute :attr_latex verse-block :center))
+ (attr (concat
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if latcode (format "\n%s" latcode) "")))
+ (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
+ (vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
+ (linreset (if lin "\n\\poemlines{0}" "")))
(concat
(org-latex--wrap-label
verse-block
@@ -3520,19 +3531,20 @@ 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
Re: [PATCH] Make org-load-hook obsolete
Hi Stefan, Stefan Kangas writes: > In Emacs, we have made all the `foo-load-hook' variables obsolete in > favor of `with-eval-after-load'. The attached patch does the same for > org-mode. Applied in master, thank you. -- Bastien
Re: Bug: Missing end parenthesis in JavaScript regarding HTML exports [9.4.5 (9.4.5-73-g4c7696-elpaplus @ /home/sebbe/.emacs.d/elpa/develop/org-plus-contrib-20210503/)]
Hi Sebastien, Sebastian Berntsson writes: > In lisp/ox-html.el in the function org-html-scripts, there's a missing > parenthesis in the JavaScript code which causes a syntax error. thanks for reporting this and sorry for this code typo, this is fixed in maint and master now. -- Bastien
Re: Please help by becoming a maintainer for an Org Babel file
Hi Tyler, Tyler Smith writes: > I can volunteer to maintain ob-awk.el. I've signed my assignment form > with FSF, and returned it to them this evening. I'll let you know when > I'm official. Thanks! I've added you as the maintainer on ob-awk.el. Please don't commit significant changes before the FSF papers are processed. > I have an account on code.orgmode.org already, but I think I only have > access to worg. You have now commit access to org-mode.git too. > I may also be able to maintain ob-shell.el. It is a bit more complex > than ob-awk.el, so I'd like to hold off until I understand a bit > better how ob works in general. Sure. > Is there any documentation for ob other than the source code? There is also https://orgmode.org/worg/org-contrib/babel/ and the manual but I cannot think of something else. Thanks again, -- Bastien
Re: Table alignment problem
Hello, thank you very much. This solves my problem. Kind Regards, Frank On 5/8/21 8:37 AM, Jeremie Juste wrote: Hello, You can have some success using [1] valign-mode. https://github.com/casouri/valign HTH, Jeremie
Re: bug#47088: org-w3m: handle w3m-image link information
Hi Nick, Nick Savage writes: > I haven't opened up the code yet to take a look, but I likely will > take a crack at some of these items in the future as low-hanging fruit > refactoring project. Please feel free to go ahead and enhance ol-w3m.el in Org's repo with the patches that Boruch kindly provided---and other enhancements that you would find useful. Thanks, -- Bastien
Re: Fold/Hide inline footnotes
Hi Denis, Denis Maier writes: > auctex has a nice feature to hide certain elements, > e.g. footnotes. Would it be possible to include something similar in > org-mode? There is no plan to include such feature, no. Probably you or someone else can hack something ad hoc, though. Best, -- Bastien
Re: Table alignment problem
Hello, thanks for the answer. I'm not familiar with github. Do you mean this program branch?: https://github.com/yantar92/org/tree/feature/org-fold%2Bpatches Kind regards, Frank On 5/7/21 4:50 PM, Ihor Radchenko wrote: Fr Ml writes: Hello, there is an old problem with table alignment. It's mentioned here: https://emacs.stackexchange.com/q/30495/11498 It occurs as far as I know only in 4 cases (last 4 rows): | 2 latin letters | ab | (2 glyphs) | | 2 arabic letters | من | ok (2 glyphs) | | same but with 2 diacritics | مِنْ | also ok (2 glyphs) | | the arabich letter ا and then ل isn't a problem | ال | also ok (2 glyphs) | | but ل and then ا is a problem (case1) | لا | not ok (it's 1 glyph) | | also ل and then أ (case2) | لأ | " (it's 1 glyph) | | also ل and then إ (case3) | لإ | " (it's 1 glyph) | | also ل and then آ (case4) | لآ | " (it's 1 glyph) | Can you try with org-fold branch [1]? It implements a new way to calculate string width. [1] https://github.com/yantar92/org Best, Ihor
Re: Table alignment problem
Fr Ml writes: > Hello, > > thanks for the answer. I'm not familiar with github. > Do you mean this program branch?: > https://github.com/yantar92/org/tree/feature/org-fold%2Bpatches Not really. I mean the main branch in the repo (which is feature/org-fold-universal-core). The installation instructions are in https://github.com/yantar92/org#installation Best, Ihor
Re:Re: [PATCH] Add 'simple option to org-fast-tag-selection-single-key.
At 2021-05-01 23:20:24, "Bastien" wrote: >Hi tumashu, > >tumashu writes: > >> This is v2 patch, use completing-read-multipul. > >Thanks for the patch. You can already do this: > >(setq org-use-fast-tag-selection nil) > >Then you'll be able to select tags the way you implemented it >with this simple mode. I think (setq org-use-fast-tag-selection nil) do not work well with ivy, selectrum or vertico. I like the below idea, but seem to no progress. https://lists.gnu.org/archive/html/emacs-orgmode/2020-07/msg00222.html > >-- > Bastien
Re: CSL-JSON support for =parsebib=
Dear All,
this is just to +1 this on my part as well. Although unadvertised,
citeproc-org basically already supports CSL-JSON bibliographies, and
it would be fantastic if other components of the Emacs
citation/bibliography infrastructure also did. BTW, would CSL-JSON
support in =parsebib= mean that there is hope for having CSL-support
in Ebib too?
best regards,
András
On Fri, 7 May 2021 at 18:23, Titus von der Malsburg wrote:
>
>
> On 2021-05-07 Fri 16:47, Joost Kremers wrote:
> > On Fri, May 07 2021, Titus von der Malsburg wrote:
> >>> Apparently, =json-parse-{buffer|string}= then gives you a symbol with a
> >>> space
> >>> in it...
> >>
> >> I now see that symbol names “can contain any characters whatever” [1]. But
> >> many
> >> characters need to be escaped (like spaces) which isn’t pretty.
> >
> > Agreed. But if you pass such a symbol to =symbol-name= or to =(format
> > "%s")=,
> > the escape character is removed, so when it comes to displaying those
> > symbols to
> > users, it shouldn't matter much.
> >
> > Note, though, that the keys in CSL-JSON don't seem to contain any spaces or
> > other weird characters. There are just lower case a-z and dash, that's all.
>
> I agree that weird characters are unlikely going to be an issue.
> Nonetheless, strings seem slightly more future-proof. Funky unicode stuff is
> now appearing everywhere (I’ve seen emoji being used for variable names) and
> the situation could be different a couple of years down the line.
>
> >>> This works for the Elisp library =json.el=, but Emacs 27 can be compiled
> >>> with
> >>> native JSON support, which, however, doesn't provide this option,
> >>> unfortunately.
> >>
> >> I see. In this case it might make sense to propose string keys as a
> >> feature for
> >> json.c. The key is a string anyway at some point during parsing, so
> >> avoiding the
> >> conversion to symbol may actually be the best way to speed things up.
> >
> > True. I'll ask on emacs-devel. Personally, I'd prefer strings, too, but I'm
> > a
> > bit hesitant about doing the conversion myself, esp. given that in Ebib,
> > all the
> > keys would need to be converted back before I can save a file.
>
> Sure, converting all keys in parsebib is not attractive.
>
> >>> That would be easy to support, but IMHO is better handled in
> >>> bibtex-completion:
> >>> just parse the buffer and then call =gethash= on the resulting hash
> >>> table. Or
> >>> what use-case do you have in mind?
> >>
> >> One use case: bibtex-completion drops fields that aren’t needed early on
> >> to save
> >> memory and CPU cycles. (Some people work with truly enormous
> >> bibliographies,
> >> like crypto.bib with ~60K entries.) But this means that we sometimes have
> >> to
> >> read an individual entry again if we need more fields that were dropped
> >> earlier.
> >> In this case I’d like to be able to read just one entry without having to
> >> reparse the complete bibliography.
> >
> > Makes sense. For .bib sources, this should be fairly easy to do. For .json,
> > I
> > can't really say how easy it would be. It's not difficult to find the entry
> > key
> > in the buffer, but from there you'd have to be able to find the start of the
> > entry in order to parse it. Currently, I don't know how to do that.
>
> Not a big deal. Since it’s just about individual entries and the code isn’t
> super central, we can easily hack something.
>
> - Functions for resolving strings and cross-references.
> > [...]
> >>> parsebib has a lower-level API and a higher-level API, and the latter does
> >>> essentially what you suggest here. I thought bibtex-completion was already
> >>> using it...
> >>
> >> Nope. I think the high-level API didn’t exist when I wrote my code in 2014.
> >
> > No, it didn't. I seem to remember, though, that you gave me the idea for the
> > higher-level API, which is probably why I assumed you were using it.
> >
> > So that part of =parsebib= hasn't been tested much... (Ebib doesn't use it,
> > either). If you do decide to start using it, please test it and report any
> > issues you find. And let me know if I can help with testing.
>
> The organically grown parsing code in the Bibtex completion has been bugging
> me for a while. So I'm keen on rewriting this. But I may not get to it
> until the summer. I'll keep you posted when I start working on it.
>
> Titus
>
>
Re:Re:Re: [PATCH] Add 'simple option to org-fast-tag-selection-single-key.
>I think (setq org-use-fast-tag-selection nil) do not work well with ivy, >selectrum or vertico. > >I like the below idea, but seem to no progress. > https://lists.gnu.org/archive/html/emacs-orgmode/2020-07/msg00222.html If this patch is hard to merge, I think my patch is a conside way, for it nearly doesn't affect other places
Re: [PATCH] Use cache in org-up-heading-safe
On 07/05/2021 09:08, Ihor Radchenko wrote:
Maxim Nikulin writes:
Did you just replace gethash by avl-tree?
Yes
Likely my idea is based on a
wrong assumption. I hoped that having positions of headers it is
possible to avoid jumps (goto-char ...) preceded or followed by regexp
matching almost completely. Previous header for arbitrary initial
position can be found using binary search through structure obtained
during scan.
Sorry, I cannot follow what you mean. The call to goto-char in
org-up-heading-safe is required by function docstring - we need to move
point to the parent heading.
I am trying to minimize number of regexp searches. Mostly it is applied
when information concerning multiple headings is required (agenda,
refile targets). It unlikely will get some benefits during interactive
calls related to single heading.
For a file having 3000 headings, scanning though it takes ~0.1sec to get
the following properties: position, level, list of parents (with same
properties). Note that no expensive operations are performed like
cleaning up of heading title.
Having list of headings (and its length), it is possible to build a tree
for binary search in linear time. It takes ~0.01sec.
Having the tree, it is possible to instantly find heading for
*arbitrary* position in the buffer. Likely the next operation is goto to
the heading or to it parent and parsing the line for more detailed
properties. The latter is cacheable, structure for heading properties
can be expanded.
Hash works only for fixed set of positions, to use hash it is necessary
to find position of the heading at first. On the other hand, to take
advantage of binary tree, more substantial modification of code is required.
Since there is no operations as insertion or deletion of nodes from
tree, no complex code is required to implement balancing rotations. That
is why I think that avl-tree is an overkill.
See the attachment for experimental (thus almost untested) code. Likely
you will find code style quite ugly. I am not happy with 0.1 sec for a
moderately large file. It is close to the limit for comfortable
interactive operations.
+ (re-search-backward
+ (format "^\\*\\{1,%d\\} " level-up) nil t)
+ (funcall outline-level
Unsure concerning the following optimization from the point of
readability and reliability in respect to future modifications. Outline
level can be derived from the length of matched string without the
funcall requiring extra regexp.
I am not sure here. outline-level also consults outline-heading-alist,
though I found no references to that variable in Org mode code.
Otherwise, outline-level already reuses match-data. There is no regexp
matching there.
Sorry. You are right. The function does what I proposed to write
explicitly. For some reason I believed that outline-level calls
something like looking-at. Maybe I checked it earlier and completely forgot.
#+begin_src elisp :results none
;; Heading properties
(defun nm-heading-properties-new (position level parents)
"Heading properties: (position . (level . parent))"
(cons position (cons level parents)))
(defun nm-heading-properties-level (props)
(cadr props))
(defun nm-heading-properties-pos (props)
(car props))
(defun nm-heading-properties-parents (props)
(cddr props))
(defun nm-heading-pos-lessp (value props)
(< value (nm-heading-properties-pos props)))
(defun nm-buffer-headings-reversed (buffer)
(with-current-buffer buffer
(save-restriction
(save-excursion
(widen)
(goto-char (point-min))
(let ((count 0)
(headings ())
(parents ()))
(while (re-search-forward org-outline-regexp-bol nil t)
(let* ((pos (match-beginning 0))
(level (- (match-end 0) pos 1)))
(while (and parents (>= (nm-heading-properties-level (car
parents)) level))
(pop parents))
(setq count (1+ count))
(let ((props (nm-heading-properties-new pos level parents)))
(push props headings)
(push props parents
(and headings (cons headings count)))
;; binary search tree
(defun nm-btree-new-node ()
"((left right) . properties"
(cons (cons nil nil) nil))
(defun nm-btree-node-left (node)
(caar node))
(defun nm-btree-node-set-left (node child)
(setcar (car node) child))
(defun nm-btree-node-set-right (node child)
(setcdr (car node) child))
(defun nm-btree-node-right (node)
(cdar node))
(defun nm-btree-node-properties (node)
(cdr node))
(defun nm-btree-node-set-properties (node properties)
(setcdr node properties))
(defun nm-btree-from-reversed (scan-result)
(and
scan-result
(let* ((key-properties-list (car scan-result))
(length (
Re: bug#47088: org-w3m: handle w3m-image link information
I have applied it now as commit 5d2ccdae7f in master. Thank you, Boruch! On Sat, May 8, 2021, at 03:44, Bastien wrote: > Hi Nick, > > Nick Savage writes: > > > I haven't opened up the code yet to take a look, but I likely will > > take a crack at some of these items in the future as low-hanging fruit > > refactoring project. > > Please feel free to go ahead and enhance ol-w3m.el in Org's repo with > the patches that Boruch kindly provided---and other enhancements that > you would find useful. > > Thanks, > > -- > Bastien >
Re: CSL-JSON support for =parsebib=
Hi,well, this is what I asked Joost in the first place. Adjusting parsebib is part of the efforts to make that possible.Denis
Re: [wip-cite-new] New natbib processor
On Fri, May 7, 2021 at 7:37 AM Bruce D'Arcus wrote: > Maybe it's fine to drop them (sub-styles_. ... > Also not sure if additional are needed for the other styles; a "caps" default? I can't figure this bit out though. '[cite:/Text@doe]' is obvious and elegant enough, but how do you do the same thing for default? But with some kind of sub-style, you can do: [cite//c:@doe] Bruce
Re: CSL-JSON support for =parsebib=
On Sat, May 08 2021, András Simonyi wrote: > this is just to +1 this on my part as well. Although unadvertised, > citeproc-org basically already supports CSL-JSON bibliographies, and > it would be fantastic if other components of the Emacs > citation/bibliography infrastructure also did. BTW, would CSL-JSON > support in =parsebib= mean that there is hope for having CSL-support > in Ebib too? Yes, that is the plan. No promises on an ETA, but it's high on my to-do list. -- Joost Kremers Life has its moments
[PATCH] org-agenda: Skip formatting if format string is ""
Hi! This is my first patch. The patch skips formatting TODO item in org-agenda when the format string is "". When the format string was "" the extra space would still be inserted which was not needed when there is no TODO keyword. Thanks, Samim From dc3ba301219622bc7d324901a5f277024f8b55cc Mon Sep 17 00:00:00 2001 From: Samim Pezeshki Date: Sat, 8 May 2021 20:09:16 +0430 Subject: [PATCH] org-agenda: Skip formatting if format string is "" When the format string was "" the extra space would still be inserted which was not needed when there is no TODO keyword. --- lisp/org-agenda.el | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 85e201086..32ed19afc 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -7147,12 +7147,13 @@ The optional argument TYPE tells the agenda type." (setq x (concat (substring x 0 (match-end 1)) - (format org-agenda-todo-keyword-format - (match-string 2 x)) - ;; Remove `display' property as the icon could leak - ;; on the white space. - (org-add-props " " (org-plist-delete (text-properties-at 0 x) - 'display)) + (when (not (eq org-agenda-todo-keyword-format "")) + (format org-agenda-todo-keyword-format + (match-string 2 x)) + ;; Remove `display' property as the icon could leak + ;; on the white space. + (org-add-props " " (org-plist-delete (text-properties-at 0 x) + 'display))) (substring x (match-end 3))) x))) -- 2.31.1
Re: [PATCH] org-protocol: Fix missing '+' in js snippet
> Thank you. However on linux there is another degree of freedom: various
> desktop environments can be different in respect to treatment of URLs before
> passing them to protocol handlers. I have tried KDE and a kind of
> minimalistic setup inside container (xdg-utils) so far. Anyway it is good to
> receive confirmation that it could work for other people.
Perhaps the following helps provide more context:
- OS: NixOS 20.09
- WM: Xmonad 0.15
> In the meanwhile I have realized that bug report I mentioned was for Windows
> with emacs running in WSL
> https://orgmode.org/list/87zhbq7zin@pie.tf/
I have no access to Windows setups at the moment to test that -- just
NixOS and macOS.
> P.S. Since your response was private, I am unsure if Cc:
> emacs-orgmode@gnu.org should be added.
I'm definitely new with this workflow of `git send-email` so I totally
missed that I didn't reply to the group -- I didn't reply-to-group in
mutt so that was on me.
Not sure what the policy is on keeping the signal-to-noise manageably
low on the mailing groups as I'm very much of a noob here 🤣 so I'll
just add the CC address and I trust that I'll hear when I'm contributing
to more noise than signal. 😉
On Tue, May 04, 2021 at 11:44:34PM +0700, Maxim Nikulin wrote:
> On 03/05/2021 22:25, David Asabina wrote:
> > > I have a question that is a bit off-topic in this thread however. Since
> > > you
> > > are setting up org-protocol, you may notice other issues. There were
> > > reports
> > > that two slashes after "org-protocol:" cause some problems. My guess is
> > > that
> > > capture is recognized as hostname, so another slash is inserted after it.
> > > There was a patch allowing "/" before "?" to get things work (perhaps on
> > > Windows). Could you try, please, if one or three slashes in org-protocol
> > > URIs ("org-protocol:/capture?url=..." and
> > > "org-protocol:///capture?url=...")
> > > works properly in your environment? Maybe code examples in docs would
> > > benefit from one more correction.
> >
> > I've tried:
> > - org-protocol:/capture?template=t&url=emacs.org and
> > - org-protocol:///capture?template=t&url=emacs.org
> > and both worked like a charm on my setup (Firefox on NixOS).
>
> Thank you. However on linux there is another degree of freedom: various
> desktop environments can be different in respect to treatment of URLs before
> passing them to protocol handlers. I have tried KDE and a kind of
> minimalistic setup inside container (xdg-utils) so far. Anyway it is good to
> receive confirmation that it could work for other people.
>
> In the meanwhile I have realized that bug report I mentioned was for Windows
> with emacs running in WSL
> https://orgmode.org/list/87zhbq7zin@pie.tf/
>
> P.S. Since your response was private, I am unsure if Cc:
> emacs-orgmode@gnu.org should be added.
--
David Asabina
@vidbina on GitHub, Twitter, Instagram, etc.
+49 1768 7062 719
signature.asc
Description: PGP signature
bug#47088: org-w3m: handle w3m-image link information
I'm closing this report as the patch has been applied upstream. -- Bastien
