Re: [O] Displaying inline svg images

[Eric S Fraga]

On Wednesday,  9 Jan 2019 at 00:25, Kaushal Modi wrote:
> Hello,
>
> I am unable to display inline SVG images.

Your example works fine for me but I am using a slightly old version of
org so maybe something has changed?

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.14-1035-gfeb442

[O] Displaying inline svg images

[Kaushal Modi]

Hello,

I am unable to display inline SVG images.

Here is the minimum reproducible example:

1. I have org-image-actual-width defcustom at its default value of t.
2. Here is the Org file:

=
#+startup: inlineimages

[[file:red-blue-squares.svg]]
=

3. Here is the example SVG file. Put it in the same dir as the Org file as
red-blue-squares.svg.

=

http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;>

http://www.w3.org/2000/svg;
 width="467" height="462">
  

  

=

Upon saving the .svg file and then opening the .org file, I do not see the
image inlined.

Is anyone able to reproduce this?

Upon investigating the org-display-inline-images function in org.el, I
found that this happens because the internal variable width is evaluated as
nil and `:width nil' gets passed to the `create-image' function ..
resulting in a zero-width SVG.

Though, this is not a problem with PNG and JPG images.

As a quick workaround, I did this:

=
diff --git a/lisp/org.el b/lisp/org.el
index ea1607d85..54e8d0142 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18618,7 +18618,8 @@ boundaries."
  (let ((image (create-image file
 (and width 'imagemagick)
 nil
-:width width)))
+;; :width width
+)))
(when image
  (let ((ov (make-overlay
 (org-element-property :begin link)
=

i.e. I stopped passing the :width property to create-image altogether and
after that the SVG image showed inline just fine.

So, is there any point passing `:width width' if width is nil? If not, I
can work on a patch that prevents passing that property only in that case.



Org version: Org mode version 9.2 (release_9.2-151-g8a5d8f ..) | master
branch
Emacs version: GNU Emacs 27.0.50 (build 5, x86_64-pc-linux-gnu, GTK+
Version 2.24.23)
 of 2019-01-08, built using commit 55c5e26307a1e8f1fff74415fc560aa172a421cf
| master branch


--
Kaushal Modi

Re: [O] exporting code blocks with continued line numbers?

[stardiviner]

This solved a problem in my todo list. Thanks for sharing. John.

-- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  

[O] recently header argument :file does not respect :dir anymore

[stardiviner]

For example, like this source block:

#+begin_src sh :mkdirp yes :results file link :dir "data/code" :file 
"awesome-cl-software/README.md" :async
if [ -d awesome-cl-software ]; then
  cd awesome-cl-software ; git pull
else
  git clone --recursive https://github.com/azzamsa/awesome-cl-software.git 
awesome-cl-software
fi
#+end_src

It will report no directory or file "awesome-cl-software/README.md".

A few days ago, it works. But now, I have to specify dir in ~:file~ too, like 
this:

#+begin_src sh :mkdirp yes :results file link :dir "data/code" :file 
"data/code/awesome-cl-software/README.md" :async
if [ -d awesome-cl-software ]; then
  cd awesome-cl-software ; git pull
else
  git clone --recursive https://github.com/azzamsa/awesome-cl-software.git 
awesome-cl-software
fi
#+end_src

#+RESULTS[<2019-01-09 09:20:17> 1cce5f5d251b5bf7b32b1db410185ee6b9a80fde]:
[[file:data/code/awesome-cl-software/README.md]]

I checked out recently Git commits, but have not found any commits
related to ~:dir~. Only found one change on ~:file~ and ~:file-ext~
related with ~:results file~. I checked, it's hasn't changed ~:dir~
neither.


And also, I hope ~:tangle~ can respect ~:dir~ header argument too.

Like this example:

#+begin_src clojure :dir "data/code/clj-crawler-demo" :tangle 
"src/clj_crawler_demo/core.clj"
(ns clj-crawler-demo.core
  (:require [clj-http.client :as http])
  (:require [net.cgrand.enlive-html :as html]))

(html/select
 (-> (http/get "https://www.baidu.com;)
 :body
 html/html-snippet)
 [:div])
#+end_src

Why need this? If ~:tangle~ respect ~:dir~, it will don't need the complete 
path to
tangled file. And when the source block has other header argument need dir like
~:file~, this will make ~:tangle~ and other related header arguments shorter.

WDYT?

--
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

Re: [O] keybinding change in org 9.2?

[Tim Cross]

Forget that the only other issue I ran into was a problem with mu4e. I
was still running 0.9.x (default for my Linux distro version). Found I
had issues with org and mu4e integration. Updated mu4e to current
version and all was OK.

John Kitchin  writes:

> Did anything change in org 9.2 that would affect how key-bindings are
> loaded? I installed org-plus-20181230 from MELPA and suddenly many
> keybindings that used to work didn't, e.g. all the org-ref bindings, and
> other customizations I had made. If I manually run those files, the
> bindings come back, but they don't seem to get run or loaded on my startup.
> If I go back to the older version I was using (9.1.14) everything works as
> expected (i.e. the way it used to).  Just curious if anyone else
> experienced anything like that.
>
>
> 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


-- 
Tim Cross

Re: [O] keybinding change in org 9.2?

[Tim Cross]

The only key binding issue I ran into was not being able to use C-c C-,
for the new block expansion code. Problem turned out to be a key binding
conflict with hydra-ox, which I don't use, but which was being loaded by
another package I do use.

Apart from that, I've not run into any binding issues. Your description
sounds suspiciously like a 'dirty' install. I find, when updating org
from ELPA, it is very important to do it in a fresh Emacs instance where
org has not yet been used/loaded to avoid 'mixed' versions being
built. While often not an issue with minor version changes, definitely
important for major version changes.

In fact, I find it useful to completely remove my ELPA directory, remove
the selected packages line from Emacs custom and do a fresh install from
time to time. However, as I use use-package, this is really easy - just
restart emacs after removing elpa directory and selected packages entry
from custom block.

Tim

John Kitchin  writes:

> Did anything change in org 9.2 that would affect how key-bindings are
> loaded? I installed org-plus-20181230 from MELPA and suddenly many
> keybindings that used to work didn't, e.g. all the org-ref bindings, and
> other customizations I had made. If I manually run those files, the
> bindings come back, but they don't seem to get run or loaded on my startup.
> If I go back to the older version I was using (9.1.14) everything works as
> expected (i.e. the way it used to).  Just curious if anyone else
> experienced anything like that.
>
>
> 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


-- 
Tim Cross

[O] keybinding change in org 9.2?

[John Kitchin]

Did anything change in org 9.2 that would affect how key-bindings are
loaded? I installed org-plus-20181230 from MELPA and suddenly many
keybindings that used to work didn't, e.g. all the org-ref bindings, and
other customizations I had made. If I manually run those files, the
bindings come back, but they don't seem to get run or loaded on my startup.
If I go back to the older version I was using (9.1.14) everything works as
expected (i.e. the way it used to).  Just curious if anyone else
experienced anything like that.


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

Re: [O] org-copy-subtree: Invalid function: org-preserve-local-variables

[Nicolas Goaziou]

Hello,

Britt Anderson  writes:

> Using org version 9.2 and emacs version 26.1 I received the error in the
> subject line when trying to move or archive subtrees. It seems to me
> that this is related to the
>
> (eval-and-compile (require 'org-macs))
>
> line in org.el as replacing it with (require 'org-macs) solved that
> problem.
>
> Can someone tell me whether this is actually related to something else
> that I may have set up faulty or whether there is a more correct fix.

This was introduced recently by Aaron Ecay in commit
581fd9064535bef40c620bbd8f8d1fa0b28feb66. I'm Cc'ing him as he may know
if we can safely remove that.

Regards,

-- 
Nicolas Goaziou

Re: [O] please read: bug when marking tasks done

[cesar mena]

hello nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> cesar mena  writes:
>
>> as per the documentation for "org-auto-repeat-maybe" only the base date
>> of repeating deadline/scheduled time stamps should change. AFAICT the
>> patch changes every occurrence of an inactive repeating timestamp that is
>> not a comment.
>
> The base date of a time stamp is the part before the repeater. IOW,
> every time stamp with a repeater has a base date, therefore
> `org-auto-repeat-maybe' changes them all. I see no problem with the
> docstring.

the _base date_ is not the pertinent part; the _deadline/scheduled_ aspect
is.  moreover this should only happen on the headline.

from the docstring:

  |--- org-auto-repeat-maybe 
  |  Check if the *current headline* contains a repeated time-stamp.
  |
  |  If yes, set TODO state back to what it was and change the base date
  |  of repeating *deadline/scheduled time stamps to new date*
  |
  |  ...
  |-

thus we should not programmatically modify an arbitrary date in a
document just because it has a repeater. specially not one buried 300
lines deep in a :LOGBOOK: drawer.

commit af81211fdc contradicts the established documentation. 

see bernt hansen's email in this thread for another unintended
consequence. he can't mark a task that is no longer scheduled as DONE
because there is an inactive timestamp in a :LOGBOOK: entry.

> I don't think we agree about the immutable part.

see below for clarification.

> At least, the user who reported the bug solved in
> af81211fdc01b64449179bcdb77fb1c8ecb3fb94 didn't agree.

but the solution overreaches. again, only repeating deadline/scheduled
time stamps should change if they are in the current headline.

> Inactive time stamps are not immutable.

apologies if i wasn't clear. what should be immutable is a logged,
state-change entry. an existing entry should not change because one
marks a task as DONE.

regards,
-cm

Re: [O] exporting code blocks with continued line numbers?

[John Kitchin]

Answering my own question:

(add-to-list 'org-latex-minted-options '("firstnumber" "last")) seems to do
it.

For per block continuation you can use:

#+attr_latex: :options firstnumber=last


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, Jan 8, 2019 at 11:40 AM John Kitchin 
wrote:

> Hi all,
>
> In the following example document:
>
> #+BEGIN_SRC python -r +n
> #!/bin/env python (ref:bang)
> print()  (ref:print)
> #+END_SRC
>
> Next, you need to modify line [[(filename)]] to point to the Excel sheet
> you have saved the data in, line [[(sheet)]] with an integer for the sheet
> number for the data (index starts at 1), and line [[(range)]] with the
> range for the data.
>
> #+BEGIN_SRC python -r +n
> filename = 'Copper_Samples' (ref:filename)
> sheet = 6 (ref:sheet)
> Tstar1 = xlsread(filename, sheet, 'A2:E29')  (ref:range)
> #+END_SRC
>
> When I export this to LaTeX, the line numbers to the coderefs in the text
> are correct, but the line numbers in each code block start at 1.  I am
> using minted for the export. Is there an option that will tell minted to
> continue the line numbers from the previous block?
>
> Thanks,
>
> 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
>
>

Re: [O] Change in order of tag collation from #+filetags plus heading tags [Regression 9.1 -> 9.2]

[Kaushal Modi]

On Fri, Jan 4, 2019 at 4:43 PM Kaushal Modi  wrote:

> I am also copying Matt Lundin as I believe that this commit[1] caused this
> regression.
>
> If above looks good, I will go ahead the commit this patch with test,
> proper commit log, etc.
>

I went ahead and committed this fix to maint (and merged to master) as it
did not fail any existing test:
https://code.orgmode.org/bzg/org-mode/commit/34e5dcfb06800802a5e06f13340d646b6d829f04
.

[O] exporting code blocks with continued line numbers?

[John Kitchin]

Hi all,

In the following example document:

#+BEGIN_SRC python -r +n
#!/bin/env python (ref:bang)
print()  (ref:print)
#+END_SRC

Next, you need to modify line [[(filename)]] to point to the Excel sheet
you have saved the data in, line [[(sheet)]] with an integer for the sheet
number for the data (index starts at 1), and line [[(range)]] with the
range for the data.

#+BEGIN_SRC python -r +n
filename = 'Copper_Samples' (ref:filename)
sheet = 6 (ref:sheet)
Tstar1 = xlsread(filename, sheet, 'A2:E29')  (ref:range)
#+END_SRC

When I export this to LaTeX, the line numbers to the coderefs in the text
are correct, but the line numbers in each code block start at 1.  I am
using minted for the export. Is there an option that will tell minted to
continue the line numbers from the previous block?

Thanks,

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

Re: [O] please read: bug when marking tasks done

[Bernt Hansen]

Nicolas Goaziou  writes:

> Anyway, I don't really have any other idea besides dropping the repeater
> part from automatically inserted inactive time stamps. 

When I unschedule (and log) a habit I don't want to lose the detail
about the repeat interval.  My workaround for this is to break the
timestamp by adding a ',' after the '[' in the timestamp so marking it
DONE actually works.

** DONE Weekly Review 2018 [0/16]
 CLOSED: [2019-01-08 Tue 09:19]
:PROPERTIES:...
:LOGBOOK:
- State "DONE"   from "TODO"   [2019-01-08 Tue 09:19]
- Not scheduled, was "[,2019-01-07 Mon ++7d/14d]" on [2019-01-08 Tue
09:18]

Marking this task done is also pretty slow - taking 25 seconds.
The task has 233 lines, 2549 words, and 12993 characters.

partial elp-results for this task below

org-todo   1   25.33 25.33
org-self-insert-command1   25.33 25.33
org-checklist  1   25.12425.124
org-reset-checkbox-state-subtree   1   25.12425.124
org-reset-checkbox-state-maybe 1   25.12425.124
org-update-checkbox-count  1   24.94524.945
org-update-checkbox-count-maybe1   24.94524.945
org-element-at-point   154824.87099  0.0160665374
org-element-context154124.86899  0.0161382219
org-element--parse-to  154424.71899  0.0160097150
org-element--current-element   310922.07099  0.0070990672
org-element-example-block-parser   153719.66499  0.0127944046
org-unescape-code-in-string153713.60400  0.0088510084
org-element-paragraph-parser   15441.77  0.0011528497
org-fast-todo-selection1   0.201 0.201
...

Regards,
Bernt

Re: [O] batch failure of first org-num test

[Kaushal Modi]

On Mon, Jan 7, 2019, 2:56 PM Kyle Meyer  Sorry, I just now spotted an earlier message from Kaushal that reports
> the same test failure:
> https://lists.gnu.org/archive/html/emacs-orgmode/2019-01/msg00112.html


No need to be sorry. You did the debugging and even found a fix for this. :)

Re: [O] Failing org-num-mode test

[Nicolas Goaziou]

Hello,

Kaushal Modi  writes:

> While recently working on few Org tag fixes in org.el, I was running make
> test, and saw 1 test related to the recently added org-num-mode fail.
>
> The failure can be quickly recreated with:
>
>  make test BTEST_RE=test-org-num

As pointed out by Kyle Meyer (Cc'ed), I forgot to (require 'org-num).
This is now fixed.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] please read: bug when marking tasks done

[Nicolas Goaziou]

Hello,

cesar mena  writes:

> as per the documentation for "org-auto-repeat-maybe" only the base date
> of repeating deadline/scheduled time stamps should change. AFAICT the
> patch changes every occurrence of an inactive repeating timestamp that is
> not a comment.

The base date of a time stamp is the part before the repeater. IOW,
every time stamp with a repeater has a base date, therefore
`org-auto-repeat-maybe' changes them all. I see no problem with the
docstring.

>> I think a solution would be to remove the repeater from timestamps
>> inserted upon logging a state change or a re-scheduling.
>
> but that is useful and correct information. it lets me know the state of
> the scheduled timestamp at the time i rescheduled; you are proposing to
> change this to avoid a re-computation for data that i am sure we agree
> should be treated as immutable.

I don't think we agree about the immutable part. At least, the user who
reported the bug solved in af81211fdc01b64449179bcdb77fb1c8ecb3fb94
didn't agree. Inactive time stamps are not immutable.

But the main issue is that I don't understand what useful and correct
information we loose if we drop the repeater part, i.e.:

  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-29 Sat 18:50]

to

  - Rescheduled from "[2019-02-05 Tue]" on [2018-09-29 Sat 18:50]

> note that the from dates in the "Rescheduled" line is also in quotes
> indicating that it is textual information. no longer in play. changing
> such dates is akin to changing dates in a comment.
>
> what do you think?

I think quotes are not comment syntax in Org, so it means nothing
programatically.

Anyway, I don't really have any other idea besides dropping the repeater
part from automatically inserted inactive time stamps. 

You may want to read the thread in the commit message referenced above
and possibly discuss with the bug reporter to find an acceptable middle
ground.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Secondary smart quotes are exported as apostrophes. [9.1.14 (9.1.14-1-g4931fc-elpa @ /home/coleman/.emacs.d/elpa/org-9.1.14/)]

[Nicolas Goaziou]

Hello,

Coleman Gariety  writes:

> I agree. However, in specialized fields (linguistics and philosophy, for
> example), single quotation marks are commonly used to refer to technical
> terms or specialized uses of words
> :
> "Single
> quotes are easier on the eyes when reading material that uses quotes
> frequently, which is why academic publishers adopted this format for works
> in these areas."

As you put it: "in specialized fields", which is exactly my point. Smart
quotes, as implemented in Org, are not up to the requirements of
specialized fields. This is no LaTeX.

>> You can use entities directly to obtain the desired result, e.g. \rsquo,
> \lsquo...
>
> I think that this is rather tedious. Do you agree?

It depends on the number of occurrences. With completion, it can be
quick to insert.

> If so, it seems reasonable to me that there should be some option to
> export text such as...
>
> 'foo'
>
>
> ...in the form of...
>
>  foo

You may write an export filter for that.

> It occurs to me that an academic who works in the field of linguistics or
> philosophy should be able to properly export his or her writing without
> using cryptic glyphs ("...") or commenting out line `5545` of `ox.el`. Do
> you agree?

I think cryptic (?) double quotes are perfectly fine since you can
export them as single quotes in the end. And I do not understand your
reference to line 5545 in "ox.el".

Despite its lacks, current implementation of smart quotes does its —
limited — job. I understand that it does not fulfill anyone's needs.

Now, if you think you have a better design for them, please share it
here. If it is sound and you are willing to implement it, I'm sure Org
users will appreciate it.

However, please make sure you explain the design from the ground up, not
as a modification of the current system, even if the implementation
ultimately is a slight modification of the latter. This is important to
avoid introducing a misunderstanding of the current system in the
process. 

In particular, you may note that current system does not use "double
quotes" and "single quotes", but "primary quotes" and "secondary
quotes". This is an important distinction, as it is more general: some
languages do not use, e.g., single quotes at all. It just happens that
Org uses double quotes as primary quotes, but only as a class of
characters, not as a literal symbol. As a consequence, as odd as it may
sound, I would consider it a regression if Org exported " as double
quotes and ' as single quotes exclusively.

Regards,

-- 
Nicolas Goaziou