Re: what would cause failure in template for org capture?
On Tuesday, 27 Jul 2021 at 12:37, No Wayman wrote: > Resolved on Emacs master as of > 949dd41c31dab69f7a5067bba324c28bb2cfbf8e Excellent. Re-building now! Thank you (and Gregor) for bisecting and reporting. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-598-g604bfd : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: Multilingual quotes inside paragraphs
On 26/07/2021 16:25, Juan Manuel Macías wrote:
I'm experimenting with `org-link-set-parameters' to create multilingual
quotes (chunks of text) inside paragraphs. Although I focus mainly on
the export to LaTeX with babel and csquotes packages, I also want extend
support for HTML and odt output. I leave here some sketches.
Are you intentionally avoiding macros {{{lang(ru, текст)}}}? It seems,
you are abusing links a bit. Though it allows to hide "target" part and
thus to reduce "noise" in the text. On the other hand, links may be
broadly considered as customizable element ("interactive" property is
not necessary for such snippets) since there are no other similar
objects in Org syntax. One problem is support in 3rd party tools:
pandoc, various renderers, e.g. (ruby?) on github.
Another issue is that someone will almost immediately want to put such
quote inside link or vice versa to make some fragment of a quote a
regular link. A workaround is possible:
lang:de?href=https%3A%2F%2Forgmode.org%2F with some code for handling of
unescaped target. I expect complains that it is not user-friendly to
require splitting fragment at the borders of inner link. Org does not
support nested objects of the same type.
or explicitly preceded by
a "!": "!german" (the reason for the latter is that in babel we can
define new languages):
Unsure that ODT and HTML allows to define languages. I would consider
some lisp structures describing mapping of customizable languages codes
to some set of properties.
Re: org-cite-list-bibliography-files
Titus' second question got lost a bit, but does anyone have an answer? I have the same issue, but was thinking clicking should run org-open-at-point. I know some other people do get clickable links, so am wondering if it's a config issue? On Sun, Jul 25, 2021 at 10:47 AM Titus von der Malsburg wrote: > 2. The oc-basic processor makes citations look like clickable links (blue, > underlined, mouse pointer changes to finger), but when I click on them, > nothing happens. I can only follow a references via `org-open-at-point'. It > would be good to make citations clickable. I also suggest allowing users to > follow links via C-c C-c which currently doesn’t do anything on citations. > The other obvious action that C-c C-c could trigger would be > `org-cite-insert'. Not sure what’s better.
Re: Multilingual quotes inside paragraphs
Hi Maxim, thank you for your comments.
Maxim Nikulin writes:
> Are you intentionally avoiding macros {{{lang(ru, текст)}}}?
Yes. Precisely, these experiments are just an attempt to find an
alternative to macros (I use macros a lot). In scenarios like these
(chunks of text) is where the issue of the comma as a escape character
in macros becomes more evident (this comma issue has been discussed in a
past thread, and some interesting proposals were made). Links and
macros, of course, have their pros and cons.
> It seems, you are abusing links a bit.
I'm afraid it's true :-). Anyway I think the links have a great
potential. I have tried exploring other "eccentric" uses of links, for
example here (to export subfigures to LaTeX and HTML):
https://orgmode.org/list/87mty1an66@posteo.net/ or also in my
org-critical-edition package, to work on (philological) critical
editions from Org: https://gitlab.com/maciaschain/org-critical-edition
> [...]
> Another issue is that someone will almost immediately want to put such
> quote inside link or vice versa to make some fragment of a quote a
> regular link.
Yes, that issue you describe would be one of the biggest drawbacks for
the use of links in these contexts.
Links (or macros) are a good user-level solution to solve certain
specific cases, IMHO. At a native level (in case Org someday implement
consistent and native multilingual support), I don't know what would be
the best solution for multilingual chunks of text inside paragraphs.
Maybe some kind of inline `quote' block?
Best regards,
Juan Manuel
Re: org-cite-list-bibliography-files
Could it be related to the variable org-mouse-1-follows-link? Today I added mouse-1 to the keymap that org-ref-cite uses so that might also resolve it for you. 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 Wed, Jul 28, 2021 at 9:13 AM Bruce D'Arcus wrote: > Titus' second question got lost a bit, but does anyone have an answer? > > I have the same issue, but was thinking clicking should run > org-open-at-point. > > I know some other people do get clickable links, so am wondering if > it's a config issue? > > On Sun, Jul 25, 2021 at 10:47 AM Titus von der Malsburg > wrote: > > > 2. The oc-basic processor makes citations look like clickable links > (blue, underlined, mouse pointer changes to finger), but when I click on > them, nothing happens. I can only follow a references via > `org-open-at-point'. It would be good to make citations clickable. I also > suggest allowing users to follow links via C-c C-c which currently doesn’t > do anything on citations. The other obvious action that C-c C-c could > trigger would be `org-cite-insert'. Not sure what’s better. > >
Re: org-cite-list-bibliography-files
On 2021-07-28 Wed 15:12, Bruce D'Arcus wrote: > Titus' second question got lost a bit, but does anyone have an answer? > > I have the same issue, but was thinking clicking should run org-open-at-point. To avoid misunderstandings, I agree that a mouse click should run org-open-at-point. However, for C-c C-c it it would perhaps be more useful if it would run org-cite-insert. (On ordinary org links C-c C-c doesn’t appear to do anything.) Titus > > I know some other people do get clickable links, so am wondering if > it's a config issue? > > On Sun, Jul 25, 2021 at 10:47 AM Titus von der Malsburg > wrote: > >> 2. The oc-basic processor makes citations look like clickable links (blue, >> underlined, mouse pointer changes to finger), but when I click on them, >> nothing happens. I can only follow a references via `org-open-at-point'. >> It would be good to make citations clickable. I also suggest allowing users >> to follow links via C-c C-c which currently doesn’t do anything on >> citations. The other obvious action that C-c C-c could trigger would be >> `org-cite-insert'. Not sure what’s better.
Re: org-cite-list-bibliography-files
At least until org-mode supports it natively, here is how I added C-c C-c support to citations. It is easy to make it do what you want, I chose follow in this code, (you can insert from the follow menu). https://github.com/jkitchin/org-ref-cite/blob/main/org-ref-cite-follow.el#L305 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 Wed, Jul 28, 2021 at 10:20 AM Titus von der Malsburg wrote: > > On 2021-07-28 Wed 15:12, Bruce D'Arcus wrote: > > Titus' second question got lost a bit, but does anyone have an answer? > > > > I have the same issue, but was thinking clicking should run > org-open-at-point. > > To avoid misunderstandings, I agree that a mouse click should run > org-open-at-point. However, for C-c C-c it it would perhaps be more useful > if it would run org-cite-insert. (On ordinary org links C-c C-c doesn’t > appear to do anything.) > > Titus > > > > > I know some other people do get clickable links, so am wondering if > > it's a config issue? > > > > On Sun, Jul 25, 2021 at 10:47 AM Titus von der Malsburg > > wrote: > > > >> 2. The oc-basic processor makes citations look like clickable links > (blue, underlined, mouse pointer changes to finger), but when I click on > them, nothing happens. I can only follow a references via > `org-open-at-point'. It would be good to make citations clickable. I also > suggest allowing users to follow links via C-c C-c which currently doesn’t > do anything on citations. The other obvious action that C-c C-c could > trigger would be `org-cite-insert'. Not sure what’s better. > > >
org-timer-start at specified time stamp
Hello, frequently, when taking notes at a meeting with org-timer active, I happened to forget to start the timer at the beginning of the meeting: * Meeting Start: <2021-07-30 Fri 15:37> - 0:00:05 :: started the timer to late - 0:00:18 :: want to set zero to the time above 15:37 - 0:00:34 :: how do so? The documentation of org-timer-start says: > Set the starting time for the relative timer to now. > When called with prefix argument OFFSET, prompt the user for an offset time, > with the default taken from a timer stamp at point, if any. > If OFFSET is a string or an integer, it is directly taken to be the offset > without user interaction. This is about a timer stamp, not a timestamp. Of course, it's possible, but to get the offset, I need to compute the amount of time from timer start to meeting start. > When called with a double prefix arg, all timer strings in the active > region will be shifted by a specific amount. You will be prompted for > the amount, with the default to make the first timer string in > the region 0:00:00. My proposal is to enhance C-u org-timer-start to also determine if it is located at a timestamp and use that as zero time. Furthermore C-u C-u org-timer-start also can accept a timestamp and shift the region as if the timer was started at that time. All that requires to distinguish between a timestamp and a timestamp. For the first part, it is possible, as the timestamp includes a date, for the second part it's more hairy, as 15:37 could be a shift by 15m and 37s or the timestamp of 15:37 (3:37 pm). Alternatively, a new function can be introduced that manipulated the the running timer accordingly. What do you think about that proposal? I am happy to work on that myself, but probably need some assistance from you! Best, Florian
Re: org-cite-list-bibliography-files
On Wed, Jul 28, 2021 at 10:17 AM von der Malsburg, Titus wrote: > > > On 2021-07-28 Wed 15:56, John Kitchin wrote: > > Could it be related to the variable org-mouse-1-follows-link? > > This variable is non-nil for me and clicking on ordinary org links works fine > in my setup. Just confirming: same here. Bruce
Re: Dynamic block tables: adding prefix of "id:" to %ID
* Ihor Radchenko wrote:
> Karl Voit writes:
>> Thanks, this sounds clever and I think I understand the code.
>> Although I would have preferred not to overwrite a function. I
>> always have a fear that this leads to nasty side-effects with future
>> updates.
>
> That's not overwriting. org-columns-modify-value-for-display-function is
> not a function, but a custom variable defaulting to nil. You have all
> rights to set it to whatever you wish.
Oh, this is reassuring. Thank you!
>> Without deeper knowledge, I was astonished that C-h f
>> org-columns-modify-value-for-display-function did not lead to a
>> matching function and C-h v ... to a matching variable.
>
> Hmm. You are right. This should be a bug. It happens because
> org-colview.el is only loaded after you actually run column view or
> corresponding dblock. Before that, Emacs is not aware about this
> variable (unless you require org-colview manually in your config).
>
>> When I applied the new change to update a table in a file of 71k
>> lines of org, I had to cancel the process after over two hours
>> without a result. Before the change, updating this table took
>> roughly 20 minutes.
>
> That's probably because the function I provided tries to compute the
> description part of the link by querying the headline for each result.
> You may get much better performance using the following version:
>
> (defun yant/org-columns-custom-formatter (column-title value)
> "Format column values for columns with ID-LINK title as proper Org mode id:
> link."
> (pcase column-title
> ("ID-LINK"
> (format "[[id:%s]]" value))
> (_ nil)))
I can confirm that this version does not have any negative impact
compared to the version without your code.
If anybody is interested why this is taking roughly 20min to update
one table:
| - command-execute 553233 93%
| - call-interactively 553233 93%
| - funcall-interactively 553233 93%
|- org-ctrl-c-ctrl-c 553233 93%
| - org-update-dblock553228 93%
| - org-dblock-write:columnview 553228 93%
| - org-columns--capture-view 553212 93%
|- org-columns 540042 91%
| - org-columns--display-here536947 90%
| - face-remap-add-relative 527000 88%
| - face-remap-order 526004 88%
|- sort 521312 88%
| face-attrs-more-relative-p 458136 77%
| + org-columns--new-overlay 2008 0%
|face-attribute 205 0%
| + org-columns--overlay-text 44 0%
|org-get-level-face 4 0%
| + org-map-entries1506 0%
| + org-columns-compute-all1441 0%
| + org-columns--set-widths 8 0%
|+ org-map-entries12126 2%
|+ org-columns-quit 16 0%
| + org-table-align12 0%
| + org-columns--clean-item 4 0%
| + org-element-context 5 0%
| + ... 38956 6%
| + timer-event-handler 166 0%
| + redisplay_internal (C function) 28 0%
> Best,
> Ihor
Thank Ihor, you have improved yet another part of my Emacs life!
--
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
> get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/
bug processing non emacs-lisp blocks
org-babel-load-file will try to tangle any source block that contains the substring emacs-lisp or elisp in their language. For example, the following code block will be tangled: #+begin_src emacs-lispDONOT (use-package "org-sidebar") #+end_src the following patch fixes that problem. The Regular expression should be more stringent, so it does match exactly the string and not a substring. I think this is a regression. I used to comment out blocks from my .org init files by simply adding a XXX (as in emacs-lisp). In current org these blocks are tangled :( -- --dmg --- D M German http://turingmachine.org patch Description: Binary data
Re: bug processing non emacs-lisp blocks
dmg writes: > org-babel-load-file will try to tangle any source block that contains > the substring emacs-lisp or elisp in their language. > > For example, the following code block will be tangled: > > #+begin_src emacs-lispDONOT > (use-package "org-sidebar") > #+end_src > > the following patch fixes that problem. The Regular expression should > be more stringent, so it does match exactly the string and not a > substring. > > I think this is a regression. I used to comment out blocks from my > .org init files by simply adding a XXX (as in emacs-lisp). In > current org these blocks are tangled :( I think your right. The regexp should only match on complete string. BTW an easy way to comment out code blocks from tangling is to just add :tangle no to the header. This will work better because the code block will still work for editing etc and have correct syntax highlighting etc. Regards, Tim -- *Tim Cross* /For gor sake stop laughing, this is serious!/
