Re: babel/noweb concatenation of equally-named code blocks fails?
Nicolas, thank you. wordsmithing opens up endless possibilities, so i don't know that the following is at all an improvement on your suggestion. but, it occurs to me to get the importance of =noweb-ref=, and its role in concatenation, brought out early on the "page". one paragraph currently reads: Org can replace the Noweb style reference with the source code---or concatenation thereof---, or even the results of an evaluation, as detailed below. The =noweb= header argument controls expansion of Noweb syntax references. Expansions occur when source code blocks are evaluated, tangled, or exported. an alternative: Depending on the setting of the =noweb= header argument, Org will either ignore a Noweb style reference, or will attempt to replace it. In the latter case, the replacement text will be either the source code from exactly *one* named source code block (using either a #+name: line, or a =noweb-ref= header argument), or a concatentation of one or more source code blocks, each with an identically named =noweb-ref= header argument. Expansions can only occur when source code blocks are evaluated, tangled, or exported. For more details, see below. again, thanks. cheers, Greg
Re: Public API change: How to handle function signature change gracefully
Thanks John and Nicolas. I sort of arrived at the same point with my over-engineered approach and change of public API. modified lisp/org.el @@ -5081,10 +5081,18 @@ This includes angle, plain, and bracket links." (link (org-element-property :raw-link link-object)) (type (org-element-property :type link-object)) (path (org-element-property :path link-object)) +(cbeg (org-element-property :contents-begin link-object)) +(cend (org-element-property :contents-end link-object)) +(contents (if (and cbeg cend) + (buffer-substring-no-properties cbeg cend))) (properties ;for link's visible part (list 'face (pcase (org-link-get-parameter type :face) - ((and (pred functionp) face) (funcall face path)) + ((and (pred functionp) face) (let* ((number-of-args (cdr (func-arity face))) + (kws (plist-put '() :contents contents))) + (if (equal number-of-args 1) + (funcall face path) + (funcall face path kws ((and (pred facep) face) face) ((and (pred consp) face) face) ;anonymous (_ 'org-link)) This in turn resulted in more complexity on the callee side as I had to resolve the keywords. So thanks for this simple fix I get rid of my over-engineered proposal: Having access to `org-element-context' is great for my usecase, because it means it will work on versions of Org that are already released. Yay! Best regards, Benny Apr 21, 2020, 22:07 by jkitc...@andrew.cmu.edu: > I think what Nicolas suggests is probably the easiest path. Here is one > example that does what I think you are looking for. I use a simple string > comparison on the contents, you could do something more sophisticated. > > #+BEGIN_SRC emacs-lisp > (defun fruit-link-face (path) > (let* ((ln (org-element-context)) > (start (org-element-property :contents-begin ln)) > (end (org-element-property :contents-end ln)) > (contents (if (and start end) > (buffer-substring start end) > nil))) > (if (and contents (stringp contents)) > (if (string> contents "j") > '(:foreground "red") > '(:foreground "blue")) > 'org-link))) > > > (org-link-set-parameters "fruit" > :face 'fruit-link-face) > #+END_SRC > > #+RESULTS: > | :face | fruit-link-face | > > [[fruit:mango ][test]]. # this will be red > > fruit:apple. # regular org link. > > [[fruit:apple][bera]]. # this will be blue > John > > --- > Professor John Kitchin > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu > > > On Tue, Apr 21, 2020 at 1:57 PM Nicolas Goaziou <> m...@nicolasgoaziou.fr> > > wrote: > >> Hello, >> >> Benjamin Andresen writes: >> > >> > I would like to change the public API of the :face part of >> `org-link-set-parameters': >> > >> > (org-link-set-parameters "file" :face 'org-link) >> > >> > My ultimate goal is to have org-links be able to be have their face >> changed based on the contents, not just the path of the link. >> > >> > I found the relevant code in org.el in the function `org-activate-links': >> > >> > 'face (pcase (org-link-get-parameter type :face) >> > ((and (pred functionp) face) (funcall face path)) >> > ((and (pred facep) face) face) >> > ((and (pred consp) face) face) ;anonymous >> > (_ 'org-link)) >> > >> > and would like to change this to >> > >> > 'face (pcase (org-link-get-parameter type :face) >> > ((and (pred functionp) face) (funcall face path contents)) ;; this is >> the change >> > ((and (pred facep) face) face) >> > ((and (pred consp) face) face) ;anonymous >> > (_ 'org-link)) >> > >> > Now that will introduce a host of call issues because the callees don't >> expect to the amount of arguments changed under their bottom. >> > >> > I would like some guidance how I could get what I think is neat: The >> > contents of the bracket-style links as an additional parameter to set >> > faces on and not breaking existing hookups. >> >> Isn't the function called with point on the link? You may just need to >> extract the contents from the environment. >> >> Otherwise, a solution is to catch `wrong-number-of-arguments' error and >> call again the function with the old calling convention. See, e.g., >> `org-link-open'. >> >> > To make this more palatable I would suggest it's changed so that the >> > 2nd argument will be a list of alists or keywords so to not have this >> > function signature problem if someone else comes up with a reason to >> > introduce yet more data. >> >>
Re: Public API change: How to handle function signature change gracefully
I think what Nicolas suggests is probably the easiest path. Here is one example that does what I think you are looking for. I use a simple string comparison on the contents, you could do something more sophisticated. #+BEGIN_SRC emacs-lisp (defun fruit-link-face (path) (let* ((ln (org-element-context)) (start (org-element-property :contents-begin ln)) (end (org-element-property :contents-end ln)) (contents (if (and start end) (buffer-substring start end) nil))) (if (and contents (stringp contents)) (if (string> contents "j") '(:foreground "red") '(:foreground "blue")) 'org-link))) (org-link-set-parameters "fruit" :face 'fruit-link-face) #+END_SRC #+RESULTS: | :face | fruit-link-face | [[fruit:mango ][test]]. # this will be red fruit:apple. # regular org link. [[fruit:apple][bera]]. # this will be blue John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Tue, Apr 21, 2020 at 1:57 PM Nicolas Goaziou wrote: > Hello, > > Benjamin Andresen writes: > > > > I would like to change the public API of the :face part of > `org-link-set-parameters': > > > > (org-link-set-parameters "file" :face 'org-link) > > > > My ultimate goal is to have org-links be able to be have their face > changed based on the contents, not just the path of the link. > > > > I found the relevant code in org.el in the function `org-activate-links': > > > >'face (pcase (org-link-get-parameter type :face) > >((and (pred functionp) face) (funcall face path)) > >((and (pred facep) face) face) > >((and (pred consp) face) face) ;anonymous > >(_ 'org-link)) > > > > and would like to change this to > > > >'face (pcase (org-link-get-parameter type :face) > >((and (pred functionp) face) (funcall face path contents)) ;; this is > the change > >((and (pred facep) face) face) > >((and (pred consp) face) face) ;anonymous > >(_ 'org-link)) > > > > Now that will introduce a host of call issues because the callees don't > expect to the amount of arguments changed under their bottom. > > > > I would like some guidance how I could get what I think is neat: The > > contents of the bracket-style links as an additional parameter to set > > faces on and not breaking existing hookups. > > Isn't the function called with point on the link? You may just need to > extract the contents from the environment. > > Otherwise, a solution is to catch `wrong-number-of-arguments' error and > call again the function with the old calling convention. See, e.g., > `org-link-open'. > > > To make this more palatable I would suggest it's changed so that the > > 2nd argument will be a list of alists or keywords so to not have this > > function signature problem if someone else comes up with a reason to > > introduce yet more data. > > Beware the over-engineering. At this point, someone motivated enough can > put an advice to the link fontification function. > > Regards, > > -- > Nicolas Goaziou > >
bug? org-lint issues warning when ;PROPERTIES: drawer before first headline
Org mode version 9.3.6 (release_9.3.6-528-gf874b6 @ /usr/local/share/org-mode/lisp/) GNU Emacs 28.0.50 (build 102, x86_64-pc-linux-gnu, GTK+ Version 3.24.18, cairo version 1.16.0) of 2020-04-21 AFAIU this is now allowed. Should org-lint be modified?
Re: Public API change: How to handle function signature change gracefully
Hello, Benjamin Andresen writes: > > I would like to change the public API of the :face part of > `org-link-set-parameters': > > (org-link-set-parameters "file" :face 'org-link) > > My ultimate goal is to have org-links be able to be have their face changed > based on the contents, not just the path of the link. > > I found the relevant code in org.el in the function `org-activate-links': > > 'face (pcase (org-link-get-parameter type :face) > ((and (pred functionp) face) (funcall face path)) > ((and (pred facep) face) face) > ((and (pred consp) face) face) ;anonymous > (_ 'org-link)) > > and would like to change this to > > 'face (pcase (org-link-get-parameter type :face) > ((and (pred functionp) face) (funcall face path contents)) ;; this is the > change > ((and (pred facep) face) face) > ((and (pred consp) face) face) ;anonymous > (_ 'org-link)) > > Now that will introduce a host of call issues because the callees don't > expect to the amount of arguments changed under their bottom. > > I would like some guidance how I could get what I think is neat: The > contents of the bracket-style links as an additional parameter to set > faces on and not breaking existing hookups. Isn't the function called with point on the link? You may just need to extract the contents from the environment. Otherwise, a solution is to catch `wrong-number-of-arguments' error and call again the function with the old calling convention. See, e.g., `org-link-open'. > To make this more palatable I would suggest it's changed so that the > 2nd argument will be a list of alists or keywords so to not have this > function signature problem if someone else comes up with a reason to > introduce yet more data. Beware the over-engineering. At this point, someone motivated enough can put an advice to the link fontification function. Regards, -- Nicolas Goaziou
Re: adding paragraph folding to visibility cycling?
Hello, "Bruce D'Arcus" writes: > Right now, I just keybindings for origami-toggle-all-nodes > origami-toggle-node. > > But I was thinking to have this folding as a step between disclosing > all headings, and disclosing everything. > > Does that make sense? There could be elements between headlines and paragraphs, e.g., a drawer or a block. Why would you fold the paragraphs without taking care of the intermediate levels. Moreover, it adds steps in TAB cycle, which makes it slower. I'm not sure this is a great idea to add that to the global cycling mechanism. Or maybe the global cycling should be configurable, e.g., as a list of symbols that can be expanded with TAB. It could be complicated to handle intermediate steps, as explained above. As a data point, I wouldn't like to have to hit TAB five times before returning to the original visibility state. Regards, -- Nicolas Goaziou
Re: [PATCH] Re: Inconsistent use of \ref and \eqref in ox-latex and ox-html
Hello, Brian Powell writes: > Thanks again. Please find attached patch addressing issues below. Perfect. Applied. Thank you! I forgot to add TINYCHANGE at the end of the commit message, but I added you to the list of contributors. Regards, -- Nicolas Goaziou
Re: Faces and spaces
Hello, Norman Tovey-Walsh writes: > I admit, up front, that this is of no practical consequence, but it’s > something that distracts me every single time I see it. (Which, I might > argue, is a practical consequence *for me*.) > > Consider the following todo: > > ** TODO Do something next week. >DEADLINE: <2020-04-28 Tue> >:PROPERTIES: >:CREATED: [2020-04-21 Tue 08:17] >:END: >This is the thing to do. > > DEADLINE: and :CREATED: are in the org-special-keyword face. > :PROPERTIES: and :END: are in the org-drawer face. > > Both of those faces are monospace and I would prefer them to remain that > way. > > The prose of my entry is fontified but not in any special face. I’m > using the Poet theme so that means it’s in some proportional face. > > Here’s the source of my irritation: the spaces preceding “DEADLINE” and > “:CREATED:” are, like the prose, simply fontified. The spaces preceding > “:PROPERTIES:” and “:END:” are in the org-drawer face. > > What this means is that the entry appears like this: > > ** TODO Do something next week. >DEADLINE: <2020-04-28 Tue> > :PROPERTIES: >:CREATED: [2020-04-21 Tue 08:17] > :END: >This is the thing to do. > > Is there any way to get the spaces preceding both sets of lines in the > same face? I don’t much care which, I’d just prefer if they were > aligned. Even getting just :CREATED: aligned would be an improvement. I pushed a fix on master for that. Please give it a try if you can. Regards, -- Nicolas Goaziou
Re: Adding Romanian translation for ox.el
On Tue, Apr 21, 2020 at 12:43 PM Claudiu Tănăselia wrote: > Yay! My first contribution to org-mode and Emacs! > > Thank you cleaning it up and making it part of the official branch! > > Regards, > Claudiu. > Congrats! Really glad you followed through the whole submission procession. :)
Re: Conditionally loading ob-sh or ob-shell
My workaround for dealing with different org versions on different machines: > (org-babel-do-load-languages > 'org-babel-load-languages > `((perl . t) > (ruby . t) > ,(if (version< org-version "9.0") > '(sh . t) >'(shell . t)) > (python . t) > (emacs-lisp . t) > (C . t) > (dot. t) > On Tue, Apr 21, 2020 at 9:59 AM Loris Bennett wrote: > Loris Bennett writes: > > > Hi, > > > > I want to use one init.el across multiple machines with different > > versions of Emacs and Org. Since 'ob-sh.el' changed to 'ob-shell', I > > need to do either > > > > (org-babel-do-load-languages > >'org-babel-load-languages > >'((org . t) > > (emacs-lisp . t) > > (shell . t) > > (perl . t) > > (R . t) > > (matlab . t) > > (gnuplot . t) > > (dot . t) > > (ditaa . t) > > (plantuml . t) > > (sqlite . t) > > (python . t) > > (latex . t))) > > or > > > > (org-babel-do-load-languages > >'org-babel-load-languages > >'((org . t) > > (emacs-lisp . t) > > (sh . t) > > (perl . t) > > (R . t) > > (matlab . t) > > (gnuplot . t) > > (dot . t) > > (ditaa . t) > > (plantuml . t) > > (sqlite . t) > > (python . t) > > (latex . t))) > > > > I can obviously use a conditional to test the Emacs or Org version and > > execute one block or the other. However, since the list of languages is > > quite long, I would like to avoid repeating it. > > > > I create init.el from an init.org, so I am open to tangling solutions > too. > > > > Cheers, > > > > Loris > > I discovered > > append org-babel-load-languages > > and solved the problem like this: > > (org-babel-do-load-languages > >'org-babel-load-languages > >'( > > (org . t) > > (emacs-lisp . t) > > (perl . t) > > (R . t) > > (matlab . t) > > (gnuplot . t) > > (dot . t) > > (ditaa . t) > > (plantuml . t) > > (sqlite . t) > > (python . t) > > (latex . t))) > > (if (string= org-version "8.2.10") > > (org-babel-do-load-languages > >'org-babel-load-languages > >(append org-babel-load-languages > >'((sh . t > > (org-babel-do-load-languages > > 'org-babel-load-languages > > (append org-babel-load-languages > > '((shell . t) > > The version test is a bit rigid, but > > org-version-check > > is deprecated in my newer, primary version of Org and I couldn't work > out how to use it anyway > > Cheers, > > Loris > > -- > This signature is currently under construction. > >
Re: Adding Romanian translation for ox.el
Yay! My first contribution to org-mode and Emacs! Thank you cleaning it up and making it part of the official branch! Regards, Claudiu. On Tue, Apr 21, 2020, at 19:40, Nicolas Goaziou wrote: > Hello, > > Claudiu Tănăselia writes: > > > I hope I'm doing this right, since it's my first time trying something > > like this, but I've added a Romanian translation for ox.el that > > I would like to share with you, hoping that it will make it into the > > main branch. Since I'm using a website generated from ox-hugo, that > > uses ox.el, this is useful for me and I hope others can find it > > helpful in the future. > > Thank you! I reworded the commit message, added a TINYCHANGE cookie at > its end and applied your patch. > > Regards, > > -- > Nicolas Goaziou >
Re: Adding Romanian translation for ox.el
Hello, Claudiu Tănăselia writes: > I hope I'm doing this right, since it's my first time trying something > like this, but I've added a Romanian translation for ox.el that > I would like to share with you, hoping that it will make it into the > main branch. Since I'm using a website generated from ox-hugo, that > uses ox.el, this is useful for me and I hope others can find it > helpful in the future. Thank you! I reworded the commit message, added a TINYCHANGE cookie at its end and applied your patch. Regards, -- Nicolas Goaziou
Re: Conditionally loading ob-sh or ob-shell
Loris Bennett writes: > Hi, > > I want to use one init.el across multiple machines with different > versions of Emacs and Org. Since 'ob-sh.el' changed to 'ob-shell', I > need to do either > > (org-babel-do-load-languages >'org-babel-load-languages >'((org . t) > (emacs-lisp . t) > (shell . t) > (perl . t) > (R . t) > (matlab . t) > (gnuplot . t) > (dot . t) > (ditaa . t) > (plantuml . t) > (sqlite . t) > (python . t) > (latex . t))) > or > > (org-babel-do-load-languages >'org-babel-load-languages >'((org . t) > (emacs-lisp . t) > (sh . t) > (perl . t) > (R . t) > (matlab . t) > (gnuplot . t) > (dot . t) > (ditaa . t) > (plantuml . t) > (sqlite . t) > (python . t) > (latex . t))) > > I can obviously use a conditional to test the Emacs or Org version and > execute one block or the other. However, since the list of languages is > quite long, I would like to avoid repeating it. > > I create init.el from an init.org, so I am open to tangling solutions too. > > Cheers, > > Loris I discovered append org-babel-load-languages and solved the problem like this: (org-babel-do-load-languages 'org-babel-load-languages '( (org . t) (emacs-lisp . t) (perl . t) (R . t) (matlab . t) (gnuplot . t) (dot . t) (ditaa . t) (plantuml . t) (sqlite . t) (python . t) (latex . t))) (if (string= org-version "8.2.10") (org-babel-do-load-languages 'org-babel-load-languages (append org-babel-load-languages '((sh . t (org-babel-do-load-languages 'org-babel-load-languages (append org-babel-load-languages '((shell . t) The version test is a bit rigid, but org-version-check is deprecated in my newer, primary version of Org and I couldn't work out how to use it anyway Cheers, Loris -- This signature is currently under construction.
Re: Failing tests
Kyle Meyer writes: > Marco Wahl writes: > >> When building with "make test" I get >> >> #v+ >> 2 unexpected results: >>FAILED ob-tangle/jump-to-org >>FAILED test-org-attach/dir >> #v- >> >> does this ring a bell for anybody? > > FWIW I don't see either failure on my end (Emacs 26.3). Do they fail > for you consistently? Good to know that the tests pass on your side. I'll check again and report in the case I find something interesting. Thanks! -- Marco
Conditionally loading ob-sh or ob-shell
Hi, I want to use one init.el across multiple machines with different versions of Emacs and Org. Since 'ob-sh.el' changed to 'ob-shell', I need to do either (org-babel-do-load-languages 'org-babel-load-languages '((org . t) (emacs-lisp . t) (shell . t) (perl . t) (R . t) (matlab . t) (gnuplot . t) (dot . t) (ditaa . t) (plantuml . t) (sqlite . t) (python . t) (latex . t))) or (org-babel-do-load-languages 'org-babel-load-languages '((org . t) (emacs-lisp . t) (sh . t) (perl . t) (R . t) (matlab . t) (gnuplot . t) (dot . t) (ditaa . t) (plantuml . t) (sqlite . t) (python . t) (latex . t))) I can obviously use a conditional to test the Emacs or Org version and execute one block or the other. However, since the list of languages is quite long, I would like to avoid repeating it. I create init.el from an init.org, so I am open to tangling solutions too. Cheers, Loris -- This signature is currently under construction.
Re: issue indent src block?
Hi Nicolas, On Mon, 20 Apr 2020 at 18:12, Nicolas Goaziou wrote: > I cannot reproduce it. You may want to check if something is setting > `org-edit-src-content-indentation' to 0, e.g., .dir-locals.el or some > such. Thanks! I have not found the culprit yet but hunt in progress... :-) All the best, simon
Adding Romanian translation for ox.el
Hello,
I hope I'm doing this right, since it's my first time trying something like
this, but I've added a Romanian translation for ox.el that I would like to
share with you, hoping that it will make it into the main branch. Since I'm
using a website generated from ox-hugo, that uses ox.el, this is useful for me
and I hope others can find it helpful in the future.
Best regards,
Claudiu.
From cc9f255ea388bcf6d37583a689acd14e6831ee4d Mon Sep 17 00:00:00 2001
From: Claudiu
Date: Mon, 20 Apr 2020 16:33:38 +0300
Subject: [PATCH] Update ox.el
Added Romanian translation.
---
lisp/ox.el | 21 +
1 file changed, 21 insertions(+)
diff --git a/lisp/ox.el b/lisp/ox.el
index 6f5e81af2..d5d0c9b41 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5817,6 +5817,7 @@ them."
("nn" :default "Forfattar")
("pl" :default "Autor")
("pt_BR" :default "Autor")
+ ("ro" :default "Autor")
("ru" :html "" :utf-8 "ÐвÑоÑ")
("sl" :default "Avtor")
("sv" :html "Frfattare")
@@ -5834,6 +5835,7 @@ them."
("nl" :default "Vervolg van vorige pagina")
("pt" :default "Continuação da página anterior")
("pt_BR" :html "Continuao da pgina anterior" :ascii "Continuacao da pagina anterior" :default "Continuação da página anterior")
+ ("ro" :default "Continuare de pe pagina precedentÄ")
("ru" :html "()"
:utf-8 "(ÐÑодолжение)")
("sl" :default "Nadaljevanje s prejšnje strani"))
@@ -5848,12 +5850,14 @@ them."
("nl" :default "Vervolg op volgende pagina")
("pt" :default "Continua na página seguinte")
("pt_BR" :html "Continua na prxima pgina" :ascii "Continua na proxima pagina" :default "Continua na próxima página")
+ ("ro" :default "Continuare pe pagina urmÄtoare")
("ru" :html "( )"
:utf-8 "(ÐÑодолжение ÑледÑеÑ)")
("sl" :default "Nadaljevanje na naslednji strani"))
("Created"
("cs" :default "VytvoÅeno")
("pt_BR" :default "Criado em")
+ ("ro" :default "Creat")
("sl" :default "Ustvarjeno"))
("Date"
("ar" :default "بتارÙØ®")
@@ -5874,6 +5878,7 @@ them."
("nb" :default "Dato")
("nn" :default "Dato")
("pl" :default "Data")
+ ("ro" :default "Data")
("pt_BR" :default "Data")
("ru" :html "" :utf-8 "ÐаÑа")
("sl" :default "Datum")
@@ -5895,6 +5900,7 @@ them."
("nb" :default "Ligning")
("nn" :default "Likning")
("pt_BR" :html "Equao" :default "Equação" :ascii "Equacao")
+ ("ro" :default "EcuaÈia")
("ru" :html ""
:utf-8 "УÑавнение")
("sl" :default "EnaÄba")
@@ -5914,6 +5920,7 @@ them."
("nb" :default "Illustrasjon")
("nn" :default "Illustrasjon")
("pt_BR" :default "Figura")
+ ("ro" :default "Imaginea")
("ru" :html "" :utf-8 "РиÑÑнок")
("sv" :default "Illustration")
("zh-CN" :html "" :utf-8 "å¾"))
@@ -5932,6 +5939,7 @@ them."
("nb" :default "Illustrasjon %d")
("nn" :default "Illustrasjon %d")
("pt_BR" :default "Figura %d:")
+ ("ro" :default "Imaginea %d:")
("ru" :html ". %d.:" :utf-8 "РиÑ. %d.:")
("sl" :default "Slika %d")
("sv" :default "Illustration %d")
@@ -5957,6 +5965,7 @@ them."
("nn" :default "Fotnotar")
("pl" :default "Przypis")
("pt_BR" :html "Notas de Rodap" :default "Notas de Rodapé" :ascii "Notas de Rodape")
+ ("ro" :default "Note de subsol")
("ru" :html "" :utf-8 "СноÑки")
("sl" :default "Opombe")
("sv" :default "Fotnoter")
@@ -5995,6 +6004,7 @@ them."
("nb" :default "Tabeller")
("nn" :default "Tabeller")
("pt_BR" :html "ndice de Tabelas" :default "Ãndice de Tabelas" :ascii "Indice de Tabelas")
+ ("ro" :default "Tabele")
("ru" :html " "
:utf-8 "СпиÑок ÑаблиÑ")
("sl" :default "Seznam tabel")
@@ -6013,6 +6023,7 @@ them."
("no" :default "Dataprogram")
("nb" :default "Dataprogram")
("pt_BR" :default "Listagem")
+ ("ro" :default "Lista")
("ru" :html ""
:utf-8 "РаÑпеÑаÑка")
("sl" :default "Izpis programa")
@@ -6029,6 +6040,7 @@ them."
("ja" :default "ã½ã¼ã¹ã³ã¼ã%d:")
("no" :default "Dataprogram %d")
("nb" :default "Dataprogram %d")
+ ("ro" :default "Lista %d")
("pt_BR" :default "Listagem %d:")
("ru" :html " %d.:"
:utf-8 "РаÑпеÑаÑка %d.:")
@@ -6042,6 +6054,7 @@ them."
("fr" :ascii "References" :default "Références")
("it" :default "Riferimenti")
("pt_BR" :html "Referncias" :default "Referências" :ascii "Referencias")
+ ("ro" :default "Bibliografie")
("sl" :default "Reference"))
("See figure %s"
("cs" :default "Viz obrázek %s")
@@ -6049,12 +6062,14 @@ them."
:html "cf.figure%s" :latex "cf.~figure~%s")
("it" :default "Vedi figura %s")
("pt_BR" :default "Veja a figura %s")
+ ("ro"
Faces and spaces
Hello, I admit, up front, that this is of no practical consequence, but it’s something that distracts me every single time I see it. (Which, I might argue, is a practical consequence *for me*.) Consider the following todo: ** TODO Do something next week. DEADLINE: <2020-04-28 Tue> :PROPERTIES: :CREATED: [2020-04-21 Tue 08:17] :END: This is the thing to do. DEADLINE: and :CREATED: are in the org-special-keyword face. :PROPERTIES: and :END: are in the org-drawer face. Both of those faces are monospace and I would prefer them to remain that way. The prose of my entry is fontified but not in any special face. I’m using the Poet theme so that means it’s in some proportional face. Here’s the source of my irritation: the spaces preceding “DEADLINE” and “:CREATED:” are, like the prose, simply fontified. The spaces preceding “:PROPERTIES:” and “:END:” are in the org-drawer face. What this means is that the entry appears like this: ** TODO Do something next week. DEADLINE: <2020-04-28 Tue> :PROPERTIES: :CREATED: [2020-04-21 Tue 08:17] :END: This is the thing to do. Is there any way to get the spaces preceding both sets of lines in the same face? I don’t much care which, I’d just prefer if they were aligned. Even getting just :CREATED: aligned would be an improvement. I think they’d align if I put the monospace ones in the proportional font, so I guess that’s an option, but I’d prefer to have them monospace. Be seeing you, norm -- Norman Tovey-Walsh https://nwalsh.com/ > Hanging is too good for a man who makes puns; he should be drawn and > quoted.--Fred Allen signature.asc Description: PGP signature
