Re: new org-contrib and straight.el
Hi, Greg. The recent changes to org-contrib's location/structure have been accounted for on straight's "develop" branch. Once on that branch you can rely on the default recipe: #+begin_src emacs-lisp (straight-use-package 'org-contrib) #+end_src You can see which version of straight you're currently using via `M-x straight-version`. If you're on the "master" branch (commit e1390a9 as of this writing), you can update to the "develop" branch by adding: #+begin_src emacs-lisp (setq straight-repository-branch "develop") #+end_src prior to straight's bootstrapping snippet in your in init file. I recommend using the develop branch and utilizing the lockfile system via `straight-freeze-versions` and `straight-thaw-versions` to define your own "stable releases". Hope that helps. If you have any other questions or run into problems feel free to reach out on our issue tracker: https://github.com/raxod502/straight.el/issues/new/choose Hope that helps, Nick
Cross referencing in Emacs Org mode
Dear All, Is it possible to have cross reference in LaTeX export for Org mode. To be specific: I have a org file segmented into sections, say as follows: *** example of Org file, excluding the headers** * Section 1 contains some text, a label [label:label1] and some citation [cite:cite1] * Section 2 contains some text, a label [label:label2] and a reference to label1 as [ref:label1], and a reference to a label in Section 3, [ref:label3] * Section 3 contains some text, and label [label:label3] \printbibliography I did not include the headers where the bibliography files are properly added. When I export the full buffer with C-c C-e l o everything runs fine. However, whenever I go to Section 2, say and try to export using C-c C-e C-s l o (for subtree export only), the bibliography does not appear, and the reference to label1 or label3 does not appear. Is it possible to have the labels properly referenced as well as the bibliography printed when subtrees are only exported to pdf? With my regards and all the very best wishes, partha
Re: Moving some lisp/ob-*.el files to org-contrib - your advice?
Eric S Fraga writes: > On Tuesday, 4 May 2021 at 01:49, Timothy wrote: >> For the future, I'd think Julia actually warrants 1st class inclusion in >> Org, and I've instigated an effort to write an ob-julia that works well. > > +1! Happy to help test if you wish. I use Julia as my programming > language these days. +1 from me as well, I think Julia passes the "well-established" test and is an important language for scientific computing. I like Julia, but only occasionally use it, and it seems to frequently cause troubles with my Org config whenever I update or move computers. So I appreciate this effort to support it better -- thank you Timothy.
Re: Manual on web site is not the latest version
On 17 May 2021, Nick Dokos wrote: The online manual is for 9.4 (the released version). What you see in org-manual.org is for 9.5 (which AFAIK has not been released yet). Well, that certainly explains that. I've been running Org from source for years now, and referring to the (older) online manual, but this is the first time I ever saw a difference, so it never occurred to me. Cheers, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator.
Re: Invalid duration format error with active timestamp
Hi Garjola, I had the same problem. I fixed it by downloading manually the last working version of Org from https://orgmode.org/elpa/, i.e. https://orgmode.org/elpa/org-20210503.tar and manually stored the extracted directory into my elpa directory, /home/garjola/.emacs.d/elpa/ in your case. After restarting Emacs Org agenda worked fine again. I hope that helps. Regards, Rainer Garjola Dindi writes: > On Mon 17-May-2021 at 16:01:25 +02, Nicolas Goaziou > wrote: >> Hello, >> >> Garjola Dindi writes: >> >>> I am using the most recent elpa version of org >>> 9.4.5 (9.4.5-93-gbc857b-elpa @ >>> /home/garjola/.emacs.d/elpa/org-20210510/) with emacs master branch. >>> >>> Since updating org yesterday, when I use a timestamp like >>> >>> , >>> | <2021-05-17 Mon 10:00-11:00> >>> ` >>> >>> >>> building the agenda fails with this backtrace: >>> >>> , >>> | Debugger entered--Lisp error: (error "Invalid duration format: >>> | #(\"10:00-11:00\" 0 5 (font...") >> >> This was fixed a few days ago. >> >> Since Org in ELPA is updated every Monday, you need to update it again >> (later?) today to get the fix. >> > > Hi, > > Thanks for your answer. I've been impatiently refreshing the packages > since yesterday, but I don't see any new version of org. > > I am using > > http://orgmode.org/elpa/ > > Is this still correct? Just wondering, since I understood that some > things are changing in org packaging and distribution. > > Thanks for your great work!
Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
On Tue, May 18, 2021, 11:45 AM Nicolas Goaziou wrote: > In a rebased "wip-cite-new" branch, I made an modest attempt to write > a `biblatex' citation processor ... Looks a bit more than "modest"! I don't use biblatex either; hopefully some folks that do can test this. I'm not sure on autocite, for example, either; that will require people who use biblatex to test it and see if it makes sense or not. But looks good in general; a natural extension of the natbib processor. Bruce
Re: Invalid duration format error with active timestamp
On Mon 17-May-2021 at 16:01:25 +02, Nicolas Goaziou wrote: > Hello, > > Garjola Dindi writes: > >> I am using the most recent elpa version of org >> 9.4.5 (9.4.5-93-gbc857b-elpa @ >> /home/garjola/.emacs.d/elpa/org-20210510/) with emacs master branch. >> >> Since updating org yesterday, when I use a timestamp like >> >> , >> | <2021-05-17 Mon 10:00-11:00> >> ` >> >> >> building the agenda fails with this backtrace: >> >> , >> | Debugger entered--Lisp error: (error "Invalid duration format: >> | #(\"10:00-11:00\" 0 5 (font...") > > This was fixed a few days ago. > > Since Org in ELPA is updated every Monday, you need to update it again > (later?) today to get the fix. > Hi, Thanks for your answer. I've been impatiently refreshing the packages since yesterday, but I don't see any new version of org. I am using http://orgmode.org/elpa/ Is this still correct? Just wondering, since I understood that some things are changing in org packaging and distribution. Thanks for your great work! --
Re: Global variables in Org mode document with source blocks
Lennart, John's idea seems good. also, you could generate a separate RESULT for each language, then :var each language's "failed" RESULT into your bash block and fail if any of them are set? cheers, Greg
Re: [PATCH] Async session eval (2nd attempt)
Sorry for the noise, replying to add the X-Woof-Patch:applied header.
Re: [PATCH] Async session eval (2nd attempt)
Hi ian,
ian martins writes:
> I gave this a try and it works for me. One thing I noticed is that if you
> run a call asynchronously, the final result ends up under the source block
> instead of the call. In the example below both RESULTS were written after
> I ran the call.
>
> #+name: test-call
> #+begin_src python :results output
> import time
> time.sleep(5)
> print("done")
> #+end_src
>
> #+RESULTS: test-call
> : done
>
> #+call: test-call() :session :async
>
> #+RESULTS:
> : 70e844920752b3411170716dc450c50f
Thank you for reporting. I'm adding the X-Woof-Bug header to this thread
so we can track it in updates.orgmode.org.
Re: [PATCH] Async session eval (2nd attempt)
Hi Bastien, Bastien writes: > Please feel free to commit this patch in master so that more people > can test it, we can test and fix oddities while preparing for 9.5. OK, I have incorporated the minor fixes from Kyle's review and pushed to master. Cheers, Jack
Re: [PATCH] Link handling for qutebrowser org-mac-link.el
Hi Bastien, you know what, I wanna do my part: https://sr.ht/~aimebertrand/org-mac-link/ Salut Aimé Bastien @ 2021-05-18 16:00 : Hello Aimé, Aimé Bertrand writes: I would love to, but don not now what that entails. Willing to try, but don't wanna break stuff for the community. Thanks for your consideration, appreciated. - Do I have to stick to sourcehut or can I use gitlab as well? You can do whatever forge you'd like: I'd recommend sourcehut but it can also also any other forge you want. - I would have to make sure the packages gets into elpa, melpa or others? If you want to, there is nothing mandatory about this. Thanks!
[wip-cite-new] Initial implementation of `biblatex' citation processor
Hello,
In a rebased "wip-cite-new" branch, I made an modest attempt to write
a `biblatex' citation processor, in the file "oc-biblatex.el".
Here is what is in there. Remarks follow.
--8<---cut here---start->8---
This library registers the `biblatex' citation processor, which provides
the "export" capability for citations. You may activate it globally with
(setq org-cite-export-processor '(biblatex))
or at the document level, with
#+cite_export: biblatex
The processor relies on "biblatex" LaTeX package. As such it ensures that
the package is properly required in the document's preamble. More
accurately, it will re-use any "\usepackage{biblatex}" already present in
the document (e.g., through `org-latex-packages-alist'), or insert one using
options defined in `org-cite-biblatex-options'.
In any case, the library will override style-related options with those
specified with the citation processor, in `org-cite-export-processor' or
"cite_export" keyword. If you need to use different styles for bibliography
and citations, you can separate them with "bibstyle/citestyle" syntax. E.g.,
#+cite_export: natbib authortitle/authortitle-ibid
The library supports the following citation styles:
- author(a), including caps(c), full(f) and caps-full(f) variants,
- locators(l), including bare(b), caps(c) bare-caps(bc) variants,
- nocite(n),
- note(fn), including bare(b) variant,
- smart(sm), including caps(c) variant,
- super(s),
- text(t), including caps(c) variant,
- title(ti), including full(f) variant,
- year(y), including full(f) variant,
- default style, including caps(c) variant.
The default style creates "autocite" commands.
When citation and style permit, the library automatically generates
"multicite" versions of the commands above.
Bibliography is printed using "\printbibliography" command. Additional
options may be passed to it through a property list attached to the
"print_bibliography" keyword. E.g.,
#+print_bibliography: :section 2 :heading subbibliography
Values including spaces must be surrounded with double quotes. If you need
to use a key multiple times, you can separate its values with commas, but
without any space in-between:
#+print_bibliography: :keyword abc,xyz :title "Primary Sources"
--8<---cut here---end--->8---
The first thing worth noticing is that I changed syntax for
"print_bibliography" keyword. Previously, it was
#+print_bibliography: style
but specifying a local style was not so useful. So, now, it accepts
a property list instead, as it was suggested in a related message about
filtering bibliography.
The library distinguishes two citation styles: one for the package
itself (e.g., when using "bibstyle/citestyle" syntax), and one for
generating the commands (when using #+cite_export: biblatex ... style).
Using "style" for both may be misleading. We may use "citation type" to
designate constructs like [cite/something:...] instead.
I don't use biblatex, but I'm not convinced by the default autocite
command. Wouldn't parencite be more predictable? Also, adding
#+cite_export biblatex ... auto
to trigger autocite by default seems easy enough. In any case, feel free
to suggest more styles/types to the list.
Is there any crucial feature missing?
I didn't test it much so it probably contains silly bugs. Sorry about
that.
Feedback is highly appreciated.
Regards,
--
Nicolas Goaziou
Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use
On 2021-05-18, 19:31 +0700, Maxim Nikulin wrote: > The question may be risen in emacs-devel but I am unsure if I will > participate in discussion. Why? >> Can you test this function: >> >> (defun org-table--comma-as-decimal-sep () >>"Return nil or 2 if separator is dot or comma respectively." >>(string-search "," (format "%f" 10))) > > No, it does not work. `format' always uses dot. It is reasonable when > e.g. during writing a config file or during data exchange when locales > must be ignored. > > I was too optimistic. I did not expect that support of locales are so > poor in Emcacs. I do not see any traces of localeconv(3) in sources that > would allow to get value of decimal_point directly. > > Numbers are forced to use "C" locale and I have not noticed any way to > override it. Initial settings: > > http://git.savannah.gnu.org/cgit/emacs.git/tree/src/emacs.c#n1490 > > http://git.savannah.gnu.org/cgit/emacs.git/tree/src/emacs.c#n2861 > > setlocale (LC_NUMERIC, "C"); > Hmm, so this means that Elisp cannot read something like this '10,1' as floating point number. >> To test I am using: $ LANG=de_DE.UTF-8 emacs -Q >> >> But I am getting this as warning: >> (process:1787): Gtk-WARNING **: 15:40:49.375: Locale not supported by C >> library. >> Using the fallback 'C' locale. > > You get this error due to you have not generated this locale. On debian > & ubuntu > > dpkg-reconfigure locales > > allows to select desired locales and performs all necessary actions. Thanks! I have fixed it now. -- Utkarsh Singh http://utkarshsingh.xyz
Re: Global variables in Org mode document with source blocks
Given all the different languages involved, I don't think there is a way to
use a common variable.
One way might be to have each block output some kind of string if it fails,
and then in the last block you could search for the buffer for that string.
Something like this:
* Section 1
#+BEGIN_SRC sh
false || echo "failed"-`date +'%s'`
#+END_SRC
#+RESULTS:
: failed-1621348872
#+BEGIN_SRC python
import time
if not False:
print(f'failed-{time.time()}')
#+END_SRC
#+RESULTS:
: failed-1621348926.125608
* Final section
#+BEGIN_SRC emacs-lisp
(format "There were %s failed blocks" (count-matches "failed-[0-9]"
(point-min) (point-max)))
#+END_SRC
#+RESULTS:
: There were 2 failed blocks
Some alternatives include writing/appending to a file on error, and then
counting the number of lines.
Another route is to use a :post header and search for the string there.
#+BEGIN_SRC emacs-lisp
(setq n-failures 0)
#+END_SRC
#+RESULTS:
: 0
#+name: fail-capture
#+BEGIN_SRC emacs-lisp :var data=""
(when (string-match "failed-[0-9]" data)
(incf n-failures)
(message "captured a failure in %s. n-failures=%s" data n-failures))
#+END_SRC
#+BEGIN_SRC sh :post fail-capture(*this*)
false || echo "failed"-`date +'%s'`
#+END_SRC
#+RESULTS:
: captured a failure in failed-1621349398. n-failures=1
#+BEGIN_SRC python :post fail-capture(*this*)
print('This did not fail')
#+END_SRC
#+RESULTS:
: nil
#+BEGIN_SRC python :post fail-capture(*this*)
print('This failed-9')
#+END_SRC
#+RESULTS:
: captured a failure in This failed-9
: . n-failures=2
All these approaches need you to handle and catch the errors. I think other
kinds of errors would stop the export process. e.g. if a block errors out
from division by zero or something.
I don't know how easy it would be to check if a src block succeeded or not.
If it was easy, you might use the org-babel-after-execute-hook variable to
update something when a failure is detected. Some blocks create an
*Org-Babel Error Output buffer somewhere, but i don't know if this is 100%
reliable across all blocks.
John
---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Tue, May 18, 2021 at 9:58 AM Lennart C. Karssen
wrote:
> Dear list,
>
> I am working on a dynamic report in Org mode, where I use source blocks
> in various languages to process data. Several blocks produce text or
> tables that become part of the PDF on export.
>
> The final chapter should state whether all checks passed, or whether one
> or more failed (it is not necessary to know which step failed).
>
> In a single language environment, I would use a variable (called e.g.
> nrChecksFailed) that would be incremented for each failing check. In a
> single language Org document this could probably be done with a
> :session, but given that I mix Awk, Bash, Emacs lisp and R that doesn't
> look like the way to go. Do Org documents/source blocks have some
> concept of a (global) variable that I can pass to my SRC blocks and
> increment inside them?
>
> E.g. after somehow initialising nrChecksFailed = 0, I would like to do:
>
> #+header :var nFailed=nrChecksFailed :var someData=someData
> #+begin_src R :results raw
> do_some_check_here_on_someData
>
> if (check_results_OK) {
> cat("check A passed\n")
> } else {
> cat("check A *failed*\n")
> nFailed <- nFailed + 1
> }
> #+end_src
>
> So that in my conclusion chapter I can do for example:
>
> #+header: :var nFailed=nrChecksFailed
> #+begin_src bash :results raw
> if [[ nFailed -eq 0 ]]; then
> echo "All checks passed
> else
> echo "One or more checks *failed!*"
> fi
> #+end_src
>
>
> Best regards,
>
> Lennart.
>
> --
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> L.C. Karssen
> The Netherlands
>
> lenn...@karssen.org
> http://blog.karssen.org
> GPG key ID: A88F554A
> -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
>
>
Re: [PATCH] Fontification for inline src blocks
Timothy writes:
In src blocks, you have the org-block-begin-line face applied. This (in
any sensible theme) has the same background as org-block.
I might be confused by my own config, but that doesn't seem to be the
case. Unless customized, the =org-block-begin-line= inherits from
org-meta-line, and the org-block documentation does specify that it
applies *inside* blocks.
I personaly dislike any inline change of background color. It makes
some sense for the python code, since it isn't org anymore (indeed,
the fontification is done in another buffer), but the src_lang, and
the result part are just org syntax.
Here's an example of a reasonable -- I hope -- use of those faces.
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?
Right at the end of ~org-src-font-lock-fontify-block~. The property
is =font-lock-multiline=.
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.
If results prettification were disabled by default, There would be much
less contention.
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.
I agree. But org-mode is ugly by default, so that is consistent.
So are you suggesting I do or don't create new faces for this?
You should create new faces yes. I do not know whether one or two faces is
best.
Regards,
--
Sébastien Miquel
Re: begin_src Indentation in org 9.4.4, 9.4.5
Hi Sébastien, Sébastien Miquel writes: > Here's such a patch. Applied, thanks a lot. >> Also, do you want to become the maintainer for org-src.el? We need >> more people taking charge of specific areas in Org's code. > I do intend to keep monitoring this list and help around for the > foreseeable future, and I would certainly agree to whatever sort of > maintainer position eventually, but I hold no particular interest (or > deep understanding) in this specific file. Sure, I understand. Thanks for your time in helping with this! Best, -- Bastien
Re: [PATCH] Link handling for qutebrowser org-mac-link.el
Hello Aimé, Aimé Bertrand writes: > I would love to, but don not now what that entails. > Willing to try, but don't wanna break stuff for the community. Thanks for your consideration, appreciated. > - Do I have to stick to sourcehut or can I use gitlab as well? You can do whatever forge you'd like: I'd recommend sourcehut but it can also also any other forge you want. > - I would have to make sure the packages gets into elpa, melpa or > others? If you want to, there is nothing mandatory about this. Thanks! -- Bastien
Global variables in Org mode document with source blocks
Dear list,
I am working on a dynamic report in Org mode, where I use source blocks
in various languages to process data. Several blocks produce text or
tables that become part of the PDF on export.
The final chapter should state whether all checks passed, or whether one
or more failed (it is not necessary to know which step failed).
In a single language environment, I would use a variable (called e.g.
nrChecksFailed) that would be incremented for each failing check. In a
single language Org document this could probably be done with a
:session, but given that I mix Awk, Bash, Emacs lisp and R that doesn't
look like the way to go. Do Org documents/source blocks have some
concept of a (global) variable that I can pass to my SRC blocks and
increment inside them?
E.g. after somehow initialising nrChecksFailed = 0, I would like to do:
#+header :var nFailed=nrChecksFailed :var someData=someData
#+begin_src R :results raw
do_some_check_here_on_someData
if (check_results_OK) {
cat("check A passed\n")
} else {
cat("check A *failed*\n")
nFailed <- nFailed + 1
}
#+end_src
So that in my conclusion chapter I can do for example:
#+header: :var nFailed=nrChecksFailed
#+begin_src bash :results raw
if [[ nFailed -eq 0 ]]; then
echo "All checks passed
else
echo "One or more checks *failed!*"
fi
#+end_src
Best regards,
Lennart.
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
The Netherlands
lenn...@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
OpenPGP_signature
Description: OpenPGP digital signature
Re: begin_src Indentation in org 9.4.4, 9.4.5
Hi Bastien, Bastien writes: Before I revert the commit and try your suggestion, can you share a patch that add both changes (the revert and your fix) manually so I can test it? If this fixes the original issue while preserving electric indentation, I'm okay with it. Here's such a patch. Also, do you want to become the maintainer for org-src.el? We need more people taking charge of specific areas in Org's code. I do intend to keep monitoring this list and help around for the foreseeable future, and I would certainly agree to whatever sort of maintainer position eventually, but I hold no particular interest (or deep understanding) in this specific file. Regards, -- Sébastien Miquel >From 1be7fa790e68d1fc2d198eee81c0d3bb72156d08 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Tue, 18 May 2021 14:39:33 +0200 Subject: [PATCH] org.el (org-src--contents-for-write-back): Indent blank lines * lisp/org.el (org-src--contents-for-write-back): Indent blank lines. * lisp/org-src.el (org-return): Revert part of commit bfda3cc7df. --- lisp/org-src.el | 9 - lisp/org.el | 6 +- 2 files changed, 5 insertions(+), 10 deletions(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index 5604e6568..79f002e56 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -453,15 +453,14 @@ Assume point is in the corresponding edit buffer." (insert (org-no-properties contents)) (goto-char (point-min)) (when (functionp write-back) (save-excursion (funcall write-back))) - ;; Add INDENTATION-OFFSET to every non-empty line in buffer, + ;; Add INDENTATION-OFFSET to every line in buffer, ;; unless indentation is meant to be preserved. (when (> indentation-offset 0) (while (not (eobp)) (skip-chars-forward " \t") - (unless (eolp) ;ignore blank lines - (let ((i (current-column))) - (delete-region (line-beginning-position) (point)) - (indent-to (+ i indentation-offset + (let ((i (current-column))) + (delete-region (line-beginning-position) (point)) + (indent-to (+ i indentation-offset))) (forward-line)) (defun org-src--edit-element diff --git a/lisp/org.el b/lisp/org.el index ae09f3e99..0add9bc2e 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -18018,10 +18018,6 @@ object (e.g., within a comment). In these case, you need to use (delete-and-extract-region (point) (line-end-position (org--newline indent arg interactive) (save-excursion (insert trailing-data - ;; FIXME: In a source block, don't try to indent as it may result - ;; in weird results due to `electric-indent-mode' being `t'. - ((eq element-type 'src-block) - (org--newline nil nil nil)) (t ;; Do not auto-fill when point is in an Org property drawer. (let ((auto-fill-function (and (not (org-at-property-p)) @@ -19167,7 +19163,7 @@ Also align node properties according to `org-property-format'." (line-beginning-position 2 nil) ((and (eq type 'src-block) - org-src-tab-acts-natively + org-src-tab-acts-natively (> (line-beginning-position) (org-element-property :post-affiliated element)) (< (line-beginning-position) -- 2.31.1
Re: [PATCH] Fontification for inline src blocks
Hi Sébastien, thanks for your comments.
Sébastien Miquel 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.
> 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
Re: [PATCH] Link handling for qutebrowser org-mac-link.el
Hi Bastien, I would love to, but don not now what that entails. Willing to try, but don't wanna break stuff for the community. - Do I have to stick to sourcehut or can I use gitlab as well? - I would have to make sure the packages gets into elpa, melpa or others? Salut Aimé Bertrand Do you want to take over maintainership of org-mac-link.el? If so, please set up a dedicated repository for it and we will advertize this new Homepage in org-mac-link.el, then remove it from the next stable release of org-contrib.
Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use
It seems, there is no reliable way to work with numbers in a locale-aware way in emacs. I am still against hard-coded list of locales. Requirement to customize a variable is rather inconvenient. Considering such properties as a part of translation is a little better but I prefer to avoid it. The question may be risen in emacs-devel but I am unsure if I will participate in discussion. On 18/05/2021 17:24, Utkarsh Singh wrote: On 2021-05-16, 23:24 +0700, Maxim Nikulin wrote: On 14/05/2021 21:54, Utkarsh Singh wrote: On 2021-05-13, 00:08 +0700, Maxim Nikulin wrote: Comma is decimal separator for es_ES, de_DE, ru_RU, etc. The point is that order in which separator candidates are tried should depend on active locale. I am willing to work on this problem but before this can you identify any other locale with similar problem or a resource from where I can information's about locale. I do not think list of locales should be hard coded. I am not familiar with elisp enough to tell you if locale properties such as decimal separator are exposed through some function. I expect, it is quite probable. As a last measure, some number, e.g. 0.5 or 1.5 could be formatted using a locale-aware function and result string could be checked if it contains ",". Can you test this function: (defun org-table--comma-as-decimal-sep () "Return nil or 2 if separator is dot or comma respectively." (string-search "," (format "%f" 10))) No, it does not work. `format' always uses dot. It is reasonable when e.g. during writing a config file or during data exchange when locales must be ignored. I was too optimistic. I did not expect that support of locales are so poor in Emcacs. I do not see any traces of localeconv(3) in sources that would allow to get value of decimal_point directly. Numbers are forced to use "C" locale and I have not noticed any way to override it. Initial settings: http://git.savannah.gnu.org/cgit/emacs.git/tree/src/emacs.c#n1490 http://git.savannah.gnu.org/cgit/emacs.git/tree/src/emacs.c#n2861 setlocale (LC_NUMERIC, "C"); To test I am using: $ LANG=de_DE.UTF-8 emacs -Q But I am getting this as warning: (process:1787): Gtk-WARNING **: 15:40:49.375: Locale not supported by C library. Using the fallback 'C' locale. You get this error due to you have not generated this locale. On debian & ubuntu dpkg-reconfigure locales allows to select desired locales and performs all necessary actions.
Re: [PATCH] Fontification for inline src blocks
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. 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 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~. 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. 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. 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. Regards, -- Sébastien Miquel
Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use
On 2021-05-16, 23:24 +0700, Maxim Nikulin wrote: > On 14/05/2021 21:54, Utkarsh Singh wrote: >> On 2021-05-13, 00:08 +0700, Maxim Nikulin wrote: >> >>> Comma is decimal separator for es_ES, de_DE, ru_RU, etc. The point is >>> that order in which separator candidates are tried should depend on >>> active locale. >>> >> I am willing to work on this problem but before this can you identify >> any other locale with similar problem or a resource from where I can >> information's about locale. > > I do not think list of locales should be hard coded. I am not familiar > with elisp enough to tell you if locale properties such as decimal > separator are exposed through some function. I expect, it is quite > probable. As a last measure, some number, e.g. 0.5 or 1.5 could be > formatted using a locale-aware function and result string could be > checked if it contains ",". Can you test this function: (defun org-table--comma-as-decimal-sep () "Return nil or 2 if separator is dot or comma respectively." (string-search "," (format "%f" 10))) To test I am using: $ LANG=de_DE.UTF-8 emacs -Q But I am getting this as warning: (process:1787): Gtk-WARNING **: 15:40:49.375: Locale not supported by C library. Using the fallback 'C' locale. -- Utkarsh Singh http://utkarshsingh.xyz
Re: begin_src Indentation in org 9.4.4, 9.4.5
Hi Sébastien, Sébastien Miquel writes: > The commit `bfda3cc7df31fa79222efb4c190618c3c85a3d04` breaks automatic > (electric) indentation in src blocks for all configurations. Yes, this was intentional: there are many variables interfering in this area, and preventing electric indentation for src code blocks seemed acceptable to me. Before I revert the commit and try your suggestion, can you share a patch that add both changes (the revert and your fix) manually so I can test it? If this fixes the original issue while preserving electric indentation, I'm okay with it. Also, do you want to become the maintainer for org-src.el? We need more people taking charge of specific areas in Org's code. Thanks, -- Bastien
Re: [PATCH] Link handling for qutebrowser org-mac-link.el
Bonjour Aimé, Aimé Bertrand Ntumwa-Nziza writes: > as per your wish and hint (thanx). Thanks, applied to https://git.sr.ht/~bzg/org-contrib Please see the README in https://git.sr.ht/~bzg/org-contrib Do you want to take over maintainership of org-mac-link.el? If so, please set up a dedicated repository for it and we will advertize this new Homepage in org-mac-link.el, then remove it from the next stable release of org-contrib. Thanks, -- Bastien
