strange table calculation

[Eric S Fraga]

Hello all,

I have an org table which is behaving strangely.  The column formula for
column 9 is:

   $9 = $-1+@-1$+1;ENf2

This should add up the entry in the column to the left, i.e. column 8,
with the entry one row up and to the right, i.e. column 10.  However,
when column 9 is calculated, any entry that is immediately after a
horizontal divider line causes the @-1$+1 to be replaced with the value
from the current row, not the one above.

Removing horizontal lines fixes this (although not entirely as I get a
different behaviour later down in the table...).

The behaviour of @-1$+1 seems fragile.

Has anybody had similar issues?

I cannot create a minimal example that replicates this unfortunately and
I cannot post the table that is exhibiting the problem.  However, I hope
somebody might have some idea of where to look...

Thank you,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-213-g49364f

Re: [Resolved]Re: OT: M-S-$ Not Working

[Robert Pluim]

> On Sat, 6 Feb 2021 22:52:17 +0700, Maxim Nikulin  
> said:

Maxim> P.S. Have you checked that it is possible to swap Ctrl and Caps in
Maxim> wayland session? If not it is likely worth filing a bug. It seems
Maxim> wayland will be default soon. Some Xkb stuff is already broken in
Maxim> gnome (rather intentionally). My first experience with wayland was
Maxim> that it took enough time to realize why I could not authenticate. Gdm
Maxim> was using wayland by default and in password fields (hidden input!)
Maxim> shift does not allow several capital letters in a row.

I donʼt know about swapping Ctrl and Caps, but I have Caps -> Meta,
Alt -> Ctrl, Ctrl -> Meta, Windows -> Super under Wayland, so I
suspect you'll be ok.

Robert

Re: Auto-activate new <<>>

[John Kitchin]

I guess the place to do it is with an advice on org-activate-links. Maybe a
simple after advice would do.

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 Sun, Feb 7, 2021 at 8:48 PM Kyle Meyer  wrote:

> Adam Sneller writes:
>
> > I want to call org-update-radio-target-regexp as soon as org-mode
> > recognises a new <<>> has been created (which seems to
> > happen as soon as the third ">" is typed).
> >
> > What hook can I use to get this done?
>
> I'm not spotting any hook that could be used for this.  The <<>>
> fontification happens through a simple 'regular expression => face'
> mapping in org-font-lock-keywords.
>
> You're probably aware of this and it's just not as automatic as you'd
> like, but just in case: pressing `C-c C-c' with point on <<>
> will call org-update-radio-target-regexp.
>
>

Re: Auto-activate new <<>>

[Adam Sneller]

Thanks John! It looks like there is also an org-activate-target-links which may 
narrow the field a bit. Here is what I have so far:

(defadvice org-activate-target-links (after ad-update-target-links ())
  "Activate radio target links as soon as a new target is created."
  (lambda ()
(interactive)
(when (and (org-in-regexp org-target-regexp)
   (not (org-in-regexp org-target-regexp nil t)))
  (org-update-radio-target-regexp
(ad-activate 'org-activate-target-links)

Unfortunately, this is not working for me...

Any ideas?

> On 8 Feb 2021, at 13:44, John Kitchin  wrote:
>
> I guess the place to do it is with an advice on org-activate-links. Maybe a 
> simple after advice would do.
>
> 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 Sun, Feb 7, 2021 at 8:48 PM Kyle Meyer  > wrote:
> Adam Sneller writes:
>
> > I want to call org-update-radio-target-regexp as soon as org-mode
> > recognises a new <<>> has been created (which seems to
> > happen as soon as the third ">" is typed).
> >
> > What hook can I use to get this done?
>
> I'm not spotting any hook that could be used for this.  The <<>>
> fontification happens through a simple 'regular expression => face'
> mapping in org-font-lock-keywords.
>
> You're probably aware of this and it's just not as automatic as you'd
> like, but just in case: pressing `C-c C-c' with point on <<>
> will call org-update-radio-target-regexp.
>

Problem with custom links

[Thomas S. Dye]

Aloha all,

Recently, custom links that I've used for years changed their 
behavior.  They used to behave like other org mode links, but now 
they are displayed in a different color face and are always fully 
displayed, unless I add two new keywords to 
org-link-set-parameters.


 (org-link-set-parameters
  "parencite"
  :follow 'org-ebib-open
  :export (lambda (path desc format)
(cond
 ((eq format 'html)
  (format "(%s)" path))
 ((eq format 'latex)
  (if (or (not desc) (equal 0 (search "parencite:" 
  desc)))

  (format "\\parencite{%s}" path)
(format "\\parencite[%s][%s]{%s}"
(cadr (split-string desc ";"))
(car (split-string desc ";")) path)
  :display 'org-link
  :face 'org-link)

I added the :display and :face keywords after I stumbled upon a 
list of defined links (which I wish I'd noted because I haven't 
found it since) that indicated that :display was set to 'full 
(which confused me because I'd read that the default was supposed 
to be 'org-link).  Adding these two keywords restores the original 
behavior for me.


I'm wondering why I have to set these keywords to get the default 
behavior?


I did search ORG-NEWS for a relevant entry, but didn't see 
anything that rang a bell.


I hope you and yours are well in the face of the pandemic.

Let me know if you have questions.

All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

ox-bibtex incorrectly renders bibtex entries with slashes.

[Vladimir Nikishkin]

Hello, everyone.

I have the following behaviour on org-plus-contrib-202011:

Entries that have alphanumberic keys, are rendered correctly, that is,
they appear as a number in the text, hyperlinked to the main body of the
bibliography.

However, keys which have slashes in them (that is mostly DBLP entries
fetched automatically, such as DBLP:books/mit/AbelsonS85), are rendered
having those keys as link texts, rather than numbers. Looks quite bad.

Example:
https://lockywolf.net/2021-02-08_Solving-SICP-Experience-Report-on-solving-sicp-from-icfp-scheme-2020-html-version-from-2020-08-29/Experience_Report.html
, search for "DBLP:"

Replacing those slashes with underscores makes them render as usual, but
this makes fetching entries from dblp a bit less convenient.

Does anybody have a workaround for this?

Vladimir

-- 
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: Typing latency

[Russell Adams]

On Mon, Feb 08, 2021 at 07:24:21PM +0100, Sébastien Miquel wrote:
> I often get some unpleasant latency when editing org-mode
> buffers. My use case combines a lot of special blocks and LaTeX
> fragments, and the fontification seems to slow things down.

My only suggestion is have you looked at disabling flyspell?


--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Typing latency

[Ihor Radchenko]

Sébastien Miquel  writes:

> AFAIU, the elisp profiler is useless in this case (fontification being
> slow). At least my runs don't seem to report anything relevant.

You can try font-lock-profiler package
(https://github.com/Lindydancer/font-lock-profiler)

Best,
Ihor

add org-ebib-open to ox-bibtex?

[Vladimir Nikishkin]

Dear all,

In ox-bibtex (contrib), line 169 there is the following code:

#+begin_src elisp
(let ((jump-fn (car (cl-remove-if-not #'fboundp '(ebib 
org-bibtex-goto-citation)
  (org-add-link-type "cite" jump-fn))
#+end-src

May I suggest that 'org-ebib-open be added as a follower instead of
'ebib?

Is is provided by org-ebib, shipped together with ebib, and is
semantically closer to what is needed. (ebib db key) opens a db file,
given as a first argument, whereas cite: expects a key (and the db is
usually in the #+bibliography). Unless every record has its own bib file,
this is not going to give an expected result.

Thank you.

-- 
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: Auto-activate new <<>>

[Kyle Meyer]

Adam Sneller writes:

> Thanks John! It looks like there is also an org-activate-target-links
> which may narrow the field a bit. Here is what I have so far:
>
> (defadvice org-activate-target-links (after ad-update-target-links ())
>   "Activate radio target links as soon as a new target is created."
>   (lambda ()
> (interactive)
> (when (and (org-in-regexp org-target-regexp)
>  (not (org-in-regexp org-target-regexp nil t)))
>   (org-update-radio-target-regexp
> (ad-activate 'org-activate-target-links)
>
> Unfortunately, this is not working for me...
>
> Any ideas?

org-activate-target-links _depends_ on org-update-radio-target-regexp
being called to update org-target-link-regexp, so I don't think it's a
candidate for a place to hook into if you want
org-update-radio-target-regexp to be triggered on typing <<>>.

Account for latex snippet width in fill paragraph

[Matt Huszagh]

Hello,

I make extensive use of inline latex image snippets in my Org
buffers. One thing that has annoyed me for a while is that
`org-fill-paragraph' (unsurprisingly) uses the width of the underlying
text when determining the characters which make up each line. Because
the characters which make up the source of an image are typically wider
than the image itself, this creates short lines when many snippets are
used. For example, the following text

```
This gives some degree of temperature-stability because although
\(V_{\mathrm{BE}}\) changes somewhat with temperature, the change is
small. If the quiescent output voltage is designed for say
\(10V_{\mathrm{BE}}\), and \(V_{\mathrm{BE}}\) varies \(\SI{0.1}{V}\)
over temperature changes, then the quiescent point will vary
\(\SI{1}{V}\) over temperature changes. This isn't great, but may
sometimes be good enough.
```

appears something like

```
This gives some degree of temperature-stability because although
VBE changes somewhat with temperature, the change is
small. If the quiescent output voltage is designed for say
10VBE, and VBE varies 0.1V
over temperature changes, then the quiescent point will vary
1V over temperature changes. This isn't great, but may
sometimes be good enough.
```

Before I take a crack at this, has anyone else attempted to remedy this?
I wasn't able to find anything on the mailing list. Would anyone else be
interested in this functionality? I figure a proper solution would
appear to the user as a configurable variable that could enable filling
based on image width (this behavior might be undesirable in some
cases). My currently uninformed view is that it should be possible to
query the overlay image width and perform a fill based on that. Any
thoughts, concerns, etc. are appreciated.

Matt