Re: How to get shell source blocks to read my profile?

2021-03-14 Thread Tim Cross


comments in-line ...

George Mauer  writes:

> Hey Tim, thanks for helping out. I commented inline to your response below 
> but I'll sum up and ask the outstanding questions more directly here as well.
>
> I think you might have misread what I was doing - I had 3 different variables 
> set in 3 different places precisely because I want to dissect things and 
> figure
> out which profile/rc scripts were run.
>
> Yes, this is emacs running in GUI mode so yes, it doesn't have a shell as a 
> parent. But that only explains why these environment variables aren't in
> emacs itself, not the spawned bash or zsh processes
>

To clarify, the GUI mode is unrelated. You can run in GUI mode from a
terminal and the emacs process will inherit the environment in the
terminal. If that terminal is a login terminal (i.e. terminal shell was
run as a login shell), the 'profile' file will be sourced and the 'rc'
file will have been sourced. If not a login shell, only the rc file will
have been sourced.

If on the other hand, Emacs is started from the dock, it is started in a
completely different process chain and is not a child of a login
process. This is why, if you want your emacs to have /usr/local/bin in
the path, you have to add it to /etc/paths or /etc/path.d whereas if you
start emacs from within a terminal (GUI or text mode), you only need to
add /usr/local/bin to your PATH setting in .profile (just an example to
highlight the difference between running from in a terminal and running
from the dock).

> So to sum up the specific questions. My ~shell-file-name~ is ~/bin/zsh~ which 
> seems to be what ~ob-shell~ is passing down to be run. So why on earth
> does my ~GIM_ZSHRC~ variable not show up here?
>
>   #+begin_src shell
> env
>   #+end_src
>
> When I actually directly call bash
>
>  #+begin_src shell
> bash -c env
>   #+end_src
>

Have a closer look on the section in the bash manual on the difference
between interactive and non-interactive shells. (also holds for zsh).
Basically, the 'rc' files are not sourced for non-interactive shells.

> Why would the output not include ~GIM_BASHRC~ - it should have been run, 
> right?
>

No. Adding the -c means it is a non-interactive shell, so no .bashrc
sourcing.


> What about when I call this? Even with explicitly selecting the rc file to 
> run, it seems to not
>
>   #+begin_src shell
> bash --rcfile ~/.bashrc -c env
>   #+end_src
>

Same issue here. --rcfile only has effect in interactive shells.

> Finally, the outstanding question about ~ob-shell~ is if there is any way to 
> force it to run the shell processes' rc-script? I really would have expected 
> it to
> be run in the above situations already...
>

You could try sourcing it e.g.

#+begin_src shell
source ~/.bashrc
env
#+end_src

or use 'shorthand' dot

#+begin_src shell
. ~/.bashrc
env
#+end_src

there are also some options you can add at the 'shebang' line i.e.

#!/bin/bash -l

or

#!/bin/bash -i

which will change the behaviour.

There is a lot of 'meat' in the bash man page and there is a lot of
additional information in the bash info pages. However, both can be a
bit terse and because the info is very 'dense', it is very easy to miss
key points.

In order to have environment variables available inside your org source
blocks, you really need to

- have them in the environment inherited by emacs when it starts. This
  will depend how you start Emacs (i.e from within an interactive shell
  vs from the dock). Note that you typically don't see this issue under
  Linux because in most Linux setups, the X environment is started
  inside a login shell. So everything started as part of the X session,
  like a dock, is a child of the login process and therefore inherits
  the login environment. On a mac, the dock is not part of the login
  shell, so it only inherits what is in the system wide bash profile
  file.

- Ensure your source block run as interactive and/or login shells using
  shebang options like -i or -l

- explicitly source the .profile or .bashrc file using a source call

- pass the environment variable in on the command line e.g.

#+begin_src shell
FRED=barney env
#+end_src

will result in

FRED=barney

being in the output from 'env'.


> ---
>
>  Is this perhaps on a Mac where Emacs is started from the dock?
>
> Yup like I said, its in GUI mode so I understand why those environment 
> variables aren't within emads itself
>

It is actually a little more subtle. It isn't because your running in
GUI mode those variables are not there. It is because your running from
the dock. Run it in GUI mode from within a login terminal and all those
variables will be 'in' emacs.



> It is certainly confusing but I think I got a handle on it mostly. If it's a 
> login shell you'll run a profile, if it's not you'll run the default rc file 
> unless one of the
> options were specified. I think each is named specific to each shell name but 
> oftentimes you chain them together in practice.
>

There 

Re: [PATCH] org-compat.el (org-mode-flyspell-verify): Do not spell check code in headline

2021-03-14 Thread Kyle Meyer
Sébastien Miquel writes:

> Subject: [PATCH] org-compat.el (org-mode-flyspell-verify): Do not check code
>  in headline
>
> * lisp/org-compat.el (org-mode-flyspell-verify): Do not spell check
> code, verbatim and LaTeX fragments in headline title.

Makes sense.  Hopefully the cost of the org-element-at-point call isn't
too noticeable.

Applied to master (7c4d057cd), adding a TINYCHANGE cookie to the commit
message.  You're bumping up against the cumulative number of changes
allowed without assigning copyright, so please consider completing the
copyright paperwork (or, if you've already done so, please let me know
I'll update your status listed at
).

Thanks.



Re: How to get shell source blocks to read my profile?

2021-03-14 Thread George Mauer
Hey Tim, thanks for helping out. I commented inline to your response below
but I'll sum up and ask the outstanding questions more directly here as
well.

I think you might have misread what I was doing - I had 3 different
variables set in 3 different places precisely because I want to dissect
things and figure out which profile/rc scripts were run.

Yes, this is emacs running in GUI mode so yes, it doesn't have a shell as a
parent. But that only explains why these environment variables aren't in
emacs itself, not the spawned bash or zsh processes

So to sum up the specific questions. My ~shell-file-name~ is ~/bin/zsh~
which seems to be what ~ob-shell~ is passing down to be run. So why on
earth does my ~GIM_ZSHRC~ variable not show up here?

  #+begin_src shell
env
  #+end_src

When I actually directly call bash

 #+begin_src shell
bash -c env
  #+end_src

Why would the output not include ~GIM_BASHRC~ - it should have been run,
right?

What about when I call this? Even with explicitly selecting the rc file to
run, it seems to not

  #+begin_src shell
bash --rcfile ~/.bashrc -c env
  #+end_src

Finally, the outstanding question about ~ob-shell~ is if there is any way
to force it to run the shell processes' rc-script? I really would have
expected it to be run in the above situations already...

---

>
> Is this perhaps on a Mac where Emacs is started from the dock?


Yup like I said, its in GUI mode so I understand why those environment
variables aren't within emads itself


> If so, it
> could be because on the mac, applications started from the dock are not
> executed inside a login shell. Do you get different results if you start
> emacs from within a terminal?


Yup I do, but thats why I move on to the test where I run `bash` directly


> I am also a little confused by your examples. Some of them are
> attempting to source .bash_profile, others .bashrc and others .zshrc.
>

I created the three environment variables I indicated and placed one in
each file so that I could test which profile file ran


> Which shell are you using and which files do you have? I get the feeling
> that in your frustration, you have taken a 'shotgun' approach and added
> the variable everywhere.


That's exactly what I'm trying to avoid here. I *did* add variables
everywhere, but I added *different* variables everywhere so that I can see
exactly which profile ran.


> For some reason, there seems to be some confusion these days about the
> difference between .profile, .bash_profile, .bashrc, .zsh_profile and
> .zshrc. In particular, I frequently see incorrect/wrong advice regarding
> the use of 'profile' and 'rc' files. Most of it can
> be blamed on wrong advice in forums like stack overflow!
>

It is certainly confusing but I think I got a handle on it mostly. If
it's a login shell you'll run a profile, if it's not you'll run the default
rc file unless one of the options were specified. I think each is named
specific to each shell name but oftentimes you chain them together in
practice.


> I would also experiment with just dumping out the output of 'env' and
> not run it through grep so that you can see what is being defined.


I did, that just isn't conducive to posting on an email list ;)

iI also think it is a good dea to be explicit about the shell so that you
> have more
> control/understanding over what is being run e.g. put the line
>

Yeah, I suppose I could do a prologue with a hashbang, but I debugged into
the source and it's just ~shell-file-name~ which in my case is ~/bin/zsh~

In very broad terms (glossing over some of the subtleties, which is
> likely the cause of some of your issues), the 'profile' files are only
> sourced for login shells and the 'rc' files are sourced whenever a new
> shell process is run. Note that these processes run in a hierarchy i.e.
> shell processes have a parent process. Some things have to be set in
> your 'profile' (or are better set there) while other things must be set
> in your 'rc' file. For example, setting PATH in your 'profile' is normal
> because you typically just want that set once and then 'exported' to all
> child processes. Setting a dynamic prompt which changes depending on the
> directory your in (or because it has some other dynamic data, like the
> time) need to be set in your 'rc' file because these are sourced before
> each shell process is executed. I the 'old days' it was important to get
> these distinctions correct because sourcing the files could have a
> performance impact - not as big an issue these days.
>

Great history, thanks, that's mostly what I was thinking but gives me
useful background

These days, things seem to have become even more confusing in an attempt
> to make things easier. I often see people with a .profile, a
> .bash_profile, a .bashrc, a .zsh_profile and a .zshrc with variables set
> and exported mixed in across all these files.


Don't forget that many tools from homebrew to pyenv install scripts to
ansible will 

[PATCH] Improve code readability in org-set-font-lock-defaults

2021-03-14 Thread Nick Savage
I'm not sure what the appetite is for small changes like this, but I 
have attached a small patch to improve readability in 
org-set-font-lock-defaults. I was trying to understand how org-emphasize 
worked and came across some code that I thought could be simplified.


If small refactoring patches like this aren't recommended or if I should 
wait until I have larger patches put together first before sending them 
to the list, please let me know.





>From a7d5e226dd3b377edcc9c97dd83a8445ae67d952 Mon Sep 17 00:00:00 2001
From: Nicholas Savage 
Date: Sun, 14 Mar 2021 21:47:57 -0400
Subject: [PATCH] Refactor org-set-font-lock-defaults to improve code
 readability

* org.el (org-set-font-lock-defaults): Reduce number of local
variables to improve code readability.
---
 lisp/org.el | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 28596558b..d3c043a0c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5614,9 +5614,7 @@ needs to be inserted at a specific position in the font-lock sequence.")
 
 (defun org-set-font-lock-defaults ()
   "Set font lock defaults for the current buffer."
-  (let* ((em org-fontify-emphasized-text)
-	 (lk org-highlight-links)
-	 (org-font-lock-extra-keywords
+  (let ((org-font-lock-extra-keywords
 	  (list
 	   ;; Call the hook
 	   '(org-font-lock-hook)
@@ -5643,10 +5641,10 @@ needs to be inserted at a specific position in the font-lock sequence.")
 	   '(org-fontify-drawers)
 	   ;; Link related fontification.
 	   '(org-activate-links)
-	   (when (memq 'tag lk) '(org-activate-tags (1 'org-tag prepend)))
-	   (when (memq 'radio lk) '(org-activate-target-links (1 'org-link t)))
-	   (when (memq 'date lk) '(org-activate-dates (0 'org-date t)))
-	   (when (memq 'footnote lk) '(org-activate-footnote-links))
+	   (when (memq 'tag org-highlight-links) '(org-activate-tags (1 'org-tag prepend)))
+	   (when (memq 'radio org-highlight-links) '(org-activate-target-links (1 'org-link t)))
+	   (when (memq 'date org-highlight-links) '(org-activate-dates (0 'org-date t)))
+	   (when (memq 'footnote org-highlight-links) '(org-activate-footnote-links))
;; Targets.
(list org-radio-target-regexp '(0 'org-target t))
 	   (list org-target-regexp '(0 'org-target t))
@@ -5690,7 +5688,7 @@ needs to be inserted at a specific position in the font-lock sequence.")
 	   (list (concat "\\<" org-closed-string) '(0 'org-special-keyword t))
 	   (list (concat "\\<" org-clock-string) '(0 'org-special-keyword t))
 	   ;; Emphasis
-	   (when em '(org-do-emphasis-faces))
+	   (when org-fontify-emphasized-text '(org-do-emphasis-faces))
 	   ;; Checkboxes
 	   '("^[ \t]*\\(?:[-+*]\\|[0-9]+[.)]\\)[ \t]+\\(?:\\[@\\(?:start:\\)?[0-9]+\\][ \t]*\\)?\\(\\[[- X]\\]\\)"
 	 1 'org-checkbox prepend)
-- 
2.20.1



Re: References?? (feature idea)

2021-03-14 Thread David Masterson
John Kitchin  writes:

> You could define a new org link with this behavior. You just need to
> work out a syntax for a link to the heading that also includes the
> property name. e.g.  [[property:file.org::*Heading::property]]
>
> then, define a :follow function that probably opens the heading when
> you open it, and an :export function that looks up the property and
> uses that value on export.
>
> You would split your path on ::, then you should have a list like
> (file heading property-name). For the follow function, just find-file
> on the filename, then search for the heading. For the export, wrap
> that in save-window-excursion, and use (org-entry-get) on the heading
> to get the property value.

Hmm. Interesting. I'll have to think about that.
-- 
David Masterson



Re: References?? (feature idea)

2021-03-14 Thread John Kitchin
You could define a new org link with this behavior. You just need to work
out a syntax for a link to the heading that also includes the property
name. e.g. [[property:file.org::*Heading::property]]

then, define a :follow function that probably opens the heading when you
open it, and an :export function that looks up the property and uses that
value on export.

You would split your path on ::, then you should have a list like (file
heading property-name). For the follow function, just find-file on the
filename, then search for the heading. For the export, wrap that in
save-window-excursion, and use (org-entry-get) on the heading to get the
property value.

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, Mar 14, 2021 at 7:41 PM David Masterson <
dsmasterson92...@outlook.com> wrote:

> I don't see this capability in Org, but maybe I'm missing it.
>
> My use case is that I setup an Org file as my phonebook.  Each child
> header (ie. no subheaders) is a person in my phonebook.  I can
> categorize them using parent headers.  All information about a person is
> stored in PROPERTY drawers (but, you could have information outside the
> drawer).
>
> What I'd like to do is include a "reference" to a PROPERTY in the
> phonebook entry in other Org files so that phone and address is stored
> in the phonebook, but I want the "reference" to become the value of the
> PROPERTY when the other Org file is exported.  I could do a link to the
> phonebook Org file, but that is a link and not the data.  I'd prefer to
> have (say) an exported PDF be standalone and not have references to the
> other file that I would also have to export.  One reason is that I might
> have "confidential" information in the phonebook.
>
> Does this make sense?  Has it been done?
> --
> David Masterson
>
>


References?? (feature idea)

2021-03-14 Thread David Masterson
I don't see this capability in Org, but maybe I'm missing it.

My use case is that I setup an Org file as my phonebook.  Each child
header (ie. no subheaders) is a person in my phonebook.  I can
categorize them using parent headers.  All information about a person is
stored in PROPERTY drawers (but, you could have information outside the
drawer).

What I'd like to do is include a "reference" to a PROPERTY in the
phonebook entry in other Org files so that phone and address is stored
in the phonebook, but I want the "reference" to become the value of the
PROPERTY when the other Org file is exported.  I could do a link to the
phonebook Org file, but that is a link and not the data.  I'd prefer to
have (say) an exported PDF be standalone and not have references to the
other file that I would also have to export.  One reason is that I might
have "confidential" information in the phonebook.

Does this make sense?  Has it been done?
-- 
David Masterson



Re: org-capture-template: table lines including newline of sorts

2021-03-14 Thread David Masterson
Uwe Brauer  writes:

> Currently I have the following setting for one org-capture-template:
>
>
> ("mu" "Stat+Num:Exercises English"
> table-line (file+headline "~/Somefile.org" "Exercise Group-E")
> "| %:fromname|%:fromaddress | 
> %(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date | "  
> :prepend t
> )
>
> That line is too long, I'd like something like this 
> ("mu" "Stat+Num:Exercises English"
> table-line (file+headline "~/Somefile.org" "Exercise Group-E")
> "| %:fromname|%:fromaddress\n 
> %(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date | "  
> :prepend t
> )
>
> Or 
>
> ("mu" "Stat+Num:Exercises English"
> table-line (file+headline "~/Somefile.org" "Exercise Group-E")
> "| %:fromname|%:fromaddress\n 
> %(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date | "  
> :prepend t
> "|   | %(my-extract-cc) |   |   |   |   |   |   ||  |   |   ||
> | "  :prepend t 
> )
>
>
> But nothing worked, any ideas?

Break up the line however you wish into quoted substrings and concat
them together..?

-- 
David Masterson



Re: How to get shell source blocks to read my profile?

2021-03-14 Thread Tim Cross


Is this perhaps on a Mac where Emacs is started from the dock? If so, it
could be because on the mac, applications started from the dock are not
executed inside a login shell. Do you get different results if you start
emacs from within a terminal? If so, this is almost certainly the source
of your issue/difference.

I am also a little confused by your examples. Some of them are
attempting to source .bash_profile, others .bashrc and others .zshrc.
Which shell are you using and which files do you have? I get the feeling
that in your frustration, you have taken a 'shotgun' approach and added
the variable everywhere. It might be time to go back and look at all
your shell environment files and rationalise them a bit. Things can
become a little confusing when running zsh as so many things
assume/expect a bash shell. While zsh is pretty compatible with bash, so
few problems arise, it can lead to confusion regarding where to set
variables and understand what is being sourced and when.

For some reason, there seems to be some confusion these days about the
difference between .profile, .bash_profile, .bashrc, .zsh_profile and
.zshrc. In particular, I frequently see incorrect/wrong advice regarding
the use of 'profile' and 'rc' files. Most of it can
be blamed on wrong advice in forums like stack overflow!

The 'profile' and the 'rc' files fulfil different purposes and are
sourced at different times. Have a careful read of the bash man page
(even if your running zsh as they all tend to follow the same pattern).
I would also experiment with just dumping out the output of 'env' and
not run it through grep so that you can see what is being defined. This
can help you understand what is being sourced. I also think it is a good
idea to be explicit about the shell so that you have more
control/understanding over what is being run e.g. put the line

#!/bin/bash

or

#!/bin/zsh

or

#!/bin/sh

as the first line.

In very broad terms (glossing over some of the subtleties, which is
likely the cause of some of your issues), the 'profile' files are only
sourced for login shells and the 'rc' files are sourced whenever a new
shell process is run. Note that these processes run in a hierarchy i.e.
shell processes have a parent process. Some things have to be set in
your 'profile' (or are better set there) while other things must be set
in your 'rc' file. For example, setting PATH in your 'profile' is normal
because you typically just want that set once and then 'exported' to all
child processes. Setting a dynamic prompt which changes depending on the
directory your in (or because it has some other dynamic data, like the
time) need to be set in your 'rc' file because these are sourced before
each shell process is executed. I the 'old days' it was important to get
these distinctions correct because sourcing the files could have a
performance impact - not as big an issue these days.

These days, things seem to have become even more confusing in an attempt
to make things easier. I often see people with a .profile, a
.bash_profile, a .bashrc, a .zsh_profile and a .zshrc with variables set
and exported mixed in across all these files. This is a source of
terrible confusion and unexpected results. Some 'canned' shell
configurations, like 'oh-my-zsh' also try to be extra helpful by
sourcing files which are not normally sourced by that shell (to make
smoother migration from bash shells for example). Sometimes, it can be
helpful to put a line like the following into each of these files

echo "Executing  at `date`" >> ~/profile.log

just to see what is getting executed when (you won't want to leave this
there - just for diagnostic and experimentation to help understand when
things are being sourced. You could even dump out the output of 'env' so
that you can see how the environment is being changed as each of these
files executes.


George Mauer  writes:

> I am confused why no matter how I try to run shell commands they seem to be 
> missing variables exported in profiles.
>
> I have added 3 variables to various startup scripts
>
>   - ~./bash-profile~ :: ~export GIM_BASH_PROFILE="yes"~
>   - ~./bashrc~ :: ~export GIM_BASHRC="yes"~
>   - ~./zshrc~ :: ~export GIM_ZSHRC="yes"~
>
> I am running emacs in GUI mode so I get why none of these are available 
> *directly* in emacs, so then I try
>
>   #+begin_src shell :results list
> env | grep GIM
>   #+end_src
>
>   #+RESULTS:
>
> Ok that's kinda surprising, but I suppose it could be running ~/bin/zsh~ 
> (that's my ~shell-file-name~) directly
>
> what about
>
>   #+begin_src shell :results list
> bash -c env | grep GIM
>   #+end_src
>
>   #+RESULTS:
>
> That's pretty surprising. I would have expected running it directly to 
> actually run my profile.
>
> Shockingly
>
>   #+begin_src shell :results list
> bash --rcfile ~/.bashrc -c env | grep GIM
>   #+end_src
>
>   #+RESULTS:
>
> That is *still* nothing!
>
> Sanity is restored slightly when I run
>
>   #+begin_src shell :results list

Re: org-capture-template: table lines including newline of sorts

2021-03-14 Thread Charles Millar

Hi,

On 3/14/21 1:00 PM, TRS-80 wrote:

On 2021-03-13 02:24, Uwe Brauer wrote:

Hi

Currently I have the following setting for one org-capture-template:


("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress |
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date |
"  :prepend t
)

That line is too long, I'd like something like this
("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress\n
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date |
"  :prepend t
)

Or

("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress\n
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date |
"  :prepend t
"|   | %(my-extract-cc) |   |   |   |   |   |   |    |  |   |   |    |
   | "  :prepend t
)


But nothing worked, any ideas?

Thanks and regards

Uwe Brauer


Do you need to add more pipes to keep the table structure on the line
after the newline?

Cheers,
TRS-80


You may have to escape the pipes. I did that in a similar capture template.

Charlie Millar



How to get shell source blocks to read my profile?

2021-03-14 Thread George Mauer
I am confused why no matter how I try to run shell commands they seem to be
missing variables exported in profiles.

I have added 3 variables to various startup scripts

  - ~./bash-profile~ :: ~export GIM_BASH_PROFILE="yes"~
  - ~./bashrc~ :: ~export GIM_BASHRC="yes"~
  - ~./zshrc~ :: ~export GIM_ZSHRC="yes"~

I am running emacs in GUI mode so I get why none of these are available
*directly* in emacs, so then I try

  #+begin_src shell :results list
env | grep GIM
  #+end_src

  #+RESULTS:

Ok that's kinda surprising, but I suppose it could be running ~/bin/zsh~
(that's my ~shell-file-name~) directly

what about

  #+begin_src shell :results list
bash -c env | grep GIM
  #+end_src

  #+RESULTS:

That's pretty surprising. I would have expected running it directly to
actually run my profile.

Shockingly

  #+begin_src shell :results list
bash --rcfile ~/.bashrc -c env | grep GIM
  #+end_src

  #+RESULTS:

That is *still* nothing!

Sanity is restored slightly when I run

  #+begin_src shell :results list
bash --login -c env | grep GIM
  #+end_src

which *does* indeed visit ~.bash_profile~ but only slightly.

What is going on, and is there a straightforward way in which I can get
shell block to read from a profile?


Re: org-capture-template: table lines including newline of sorts

2021-03-14 Thread Uwe Brauer

> On 2021-03-13 02:24, Uwe Brauer wrote:

> Do you need to add more pipes to keep the table structure on the line
> after the newline?


I don't think so.


smime.p7s
Description: S/MIME cryptographic signature


Re: Why is there no inline-src syntax highlighting?

2021-03-14 Thread Colin Baxter
> Timothy   writes:

> Colin Baxter writes:

>> There is this:
>> 
https://stackoverflow.com/questions/20309842/how-to-syntax-highlight-for-org-mode-inline-source-code-src-lang

> I take it you didn't look at the pages I linked? I explicitly link
> that page myself and complain that it isn't good enough .

You're right, I didn't.



Re: Why is there no inline-src syntax highlighting?

2021-03-14 Thread Timothy


Eric S Fraga  writes:

>> I'm wondering why this is. Might anyone know?
>
> Possibly because nobody had done it before?  Or maybe it slows things
> down too much.  I don't know but I would definitely be interested in
> having this feature; your screenshot looks good.

I may well submit a patch them :) Org doesn't seem any slower to me, and
it's not really doing much more that we're doing already AFAICT so I
think it would be good to include.

If I submit a patch will we be waiting till Bastien is active on the ML
again? If so I'll likely just PR this to Doom in the meantime and submit
a patch when Bastien is back.

--
Timothy



Re: Why is there no inline-src syntax highlighting?

2021-03-14 Thread Timothy


Colin Baxter writes:

> There is this: 
> https://stackoverflow.com/questions/20309842/how-to-syntax-highlight-for-org-mode-inline-source-code-src-lang

I take it you didn't look at the pages I linked? I explicitly link that
page myself and complain that it isn't good enough .

Oh, and FWIW in my limited testing using native highlighting hasn't had
any noticeable adverse effect on performance.

--
Timothy



Re: Why is there no inline-src syntax highlighting?

2021-03-14 Thread Colin Baxter
> Eric S Fraga  writes:

> On Sunday, 14 Mar 2021 at 18:19, Timothy wrote:
>> It's great how #+begin_src blocks support 'native' syntax
>> highlighting, but inline src_lang{} blocks don't seem to be
>> formatted/highlighted at all.
>> 
>> I'm wondering why this is. Might anyone know?

> Possibly because nobody had done it before?  Or maybe it slows
> things down too much.  I don't know but I would definitely be
> interested in having this feature; your screenshot looks good.

> -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

There is this: 
https://stackoverflow.com/questions/20309842/how-to-syntax-highlight-for-org-mode-inline-source-code-src-lang

Best wishes,

Colin Baxter.



Re: Problems while trying to load feature

2021-03-14 Thread Richard Lawrence
Hi Ypo,

Ypo  writes:

> Problems while trying to load feature ‘ol-org-w3m’ [etc.]
>
> It says "ol-..." because I tried to solve it after reading the mail 
> list. It is said that it happens because in version 27.1 files changed 
> their name from "org-bbdb" to "ol-org-bbdb", but as you can see, the 
> problems keep popping up. I'd say those files don't even exist on my 
> computer.
>
> /GNU Emacs 27.1 (build 1, i686-w64-mingw32)//of 2020-08-21/
>
> /org:  Version: 20210308/

I think we need some more information to help you:

1) How did you install Org? (Git? MELPA?) It looks like you are using a
very recent version, more recent than what ships with Emacs or is
available on ELPA.

2) It's not clear to me whether you have verified that you have the
files. Have you checked that these files exist and are somewhere on your
Emacs load-path?

3) Do you still see this problem if you run emacs -q? 
What happens if you then execute 

(require 'org)

via M-: or via C-x C-e in *scratch*?

-- 
Best,
Richard



Re: org-capture-template: table lines including newline of sorts

2021-03-14 Thread TRS-80

On 2021-03-13 02:24, Uwe Brauer wrote:

Hi

Currently I have the following setting for one org-capture-template:


("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress |
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date |
"  :prepend t
)

That line is too long, I'd like something like this
("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress\n
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date |
"  :prepend t
)

Or

("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress\n
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date |
"  :prepend t
"|   | %(my-extract-cc) |   |   |   |   |   |   ||  |   |   ||
   | "  :prepend t
)


But nothing worked, any ideas?

Thanks and regards

Uwe Brauer


Do you need to add more pipes to keep the table structure on the line
after the newline?

Cheers,
TRS-80



Problems while trying to load feature

2021-03-14 Thread Ypo

Hi

This is my first message to this list. I am an orgmode dependant user, 
but not an advanced user, nor a programmer. My emacs is quite 
customized, though.


I have been cleaning up my init.el file a little this Sunday, and 
solving some problems shown in "Messages" buffer after launching emacs.


But there is an issue I don't know how to solve. I have search in the 
list and reddit but I can't solve it. It is this message:


   Problems while trying to load feature ‘ol-org-bbdb’
   Problems while trying to load feature ‘ol-org-bibtex’
   Problems while trying to load feature ‘ol-org-docview’
   Problems while trying to load feature ‘ol-org-gnus’
   Problems while trying to load feature ‘ol-org-info’
   Problems while trying to load feature ‘ol-org-irc’
   Problems while trying to load feature ‘ol-org-mhe’
   Problems while trying to load feature ‘ol-org-rmail’
   Problems while trying to load feature ‘ol-org-w3m’

It says "ol-..." because I tried to solve it after reading the mail 
list. It is said that it happens because in version 27.1 files changed 
their name from "org-bbdb" to "ol-org-bbdb", but as you can see, the 
problems keep popping up. I'd say those files don't even exist on my 
computer.


   /GNU Emacs 27.1 (build 1, i686-w64-mingw32)//of 2020-08-21/

   /org:  Version: 20210308/

   Best regards



Re: org source block execute not working correctly with GNU Guile source block?

2021-03-14 Thread Zelphir Kaltstahl
Ah, I am sorry, I forgot to include basic information:

Emacs installed via GNU Guix:

GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo 
version 1.16.0)

Org:

org, 9.3, built-in

On 3/14/21 4:28 PM, Zelphir Kaltstahl wrote:
>
> Hello!
>
> I have an org-mode spreadsheet, in which I calculate durations from timestamps
> like "[2021-03-14 Sun 03:50]" for example. Recently I saw, that using org-sbe
> (org source block execute) in combination with the :var header argument can be
> used to run arbitrary code for calculating values to put as result of
> spreadsheet formulas (on
> https://home.fnal.gov/~neilsen/notebook/orgExamples/org-examples.html
> ). So I
> went trying it out. The following is some GNU Guile code for calculating time
> differences in hours:
>
> 
> #+NAME: allinone
> #+begin_src scheme :noweb yes :var org-timestamp-1="[2021-01-01 Fri 00:00]", 
> org-timestamp-2="[2021-01-01 Fri 01:00]" :results output drawer replace 
> :exports none
> (import (srfi srfi-19))
>
> (define SECOND 1)
> (define MINUTE (* 60 SECOND))
> (define HOUR (* 60 MINUTE))
>
> (define org-timestamp-format "[~Y-~m-~d ~a ~H:~M]")
>
> (define duration->time-utc
>   (λ (duration)
> (make-time time-utc
>(time-nanosecond duration)
>(time-second duration
>
> (define org-timestamp->time-utc
>   (λ (timestamp-string)
> (let ([parsed-date (string->date timestamp-string org-timestamp-format)])
>   (date->time-utc parsed-date
>
> (define org-time-duration
>   (λ (org-timestamp-1 org-timestamp-2)
> (time-difference (org-timestamp->time-utc org-timestamp-2)
>  (org-timestamp->time-utc org-timestamp-1
>
> (define duration->org-timestamp
>   (λ (duration)
> (time-utc->date
>  (duration->time-utc duration)
>  ;; timezone offset, assume all with no offset
>  0)))
>
> (define duration->hours
>   (λ (duration)
> (/ (time-second duration) HOUR)))
>
> (number->string
>  (duration->hours
>   (org-time-duration org-timestamp-1
>  org-timestamp-2)))
> #+end_src
> 
>
> The source block is named "allinone", because I tried previously with :noweb
> yes and referencing other code blocks to be included, but thought that perhaps
> org-sbe does not deal well with :noweb yes, so I wanted to make sure to keep
> everything in one source block.
>
> The variables org-timestamp-1 and org-timestamp-2 are referenced at the bottom
> of the code.
>
> The code runs find in run-guile for example, when I replace the 2 variables
> with the default values of the variables, given in the header argument :var,
> as you can see in this transcript:
>
> 
> GNU Guile 3.0.5
> Copyright (C) 1995-2021 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> (import (srfi srfi-19))
>
> (define SECOND 1)
> (define MINUTE (* 60 SECOND))
> (define HOUR (* 60 MINUTE))
>
> (define org-timestamp-format "[~Y-~m-~d ~a ~H:~M]")
>
> (define duration->time-utc
>   (λ (duration)
> (make-time time-utc
>(time-nanosecond duration)
>(time-second duration
>
> (define org-timestamp->time-utc
>   (λ (timestamp-string)
> (let ([parsed-date (string->date timestamp-string org-timestamp-format)])
>   (date->time-utc parsed-date
>
> (define org-time-duration
>   (λ (org-timestamp-1 org-timestamp-2)
> (time-difference (org-timestamp->time-utc org-timestamp-2)
>  (org-timestamp->time-utc org-timestamp-1
>
> (define duration->org-timestamp
>   (λ (duration)
> (time-utc->date
>  (duration->time-utc duration)
>  ;; timezone offset, assume all with no offset
>  0)))
>
> (define duration->hours
>   (λ (duration)
> (/ (time-second duration) HOUR)))
> scheme@(guile-user)> (define org-timestamp-1 "[2021-01-01 Fri 00:00]")
> scheme@(guile-user)> (define org-timestamp-2 "[2021-01-01 Fri 01:00]")
> scheme@(guile-user)> (number->string
>  (duration->hours
>   (org-time-duration org-timestamp-1
>  org-timestamp-2)))
> $2 = "1"
> scheme@(guile-user)>
> 
>
> This code assumes, that I have to convert to a string at the end, to make a
> good return value for org-mode spreadsheets.
>
> Then I have this table in my document:
>
> 
> |   | timestamp 1| timestamp 2| result |
> |---+++|
> | # | [2021-03-14 Sun 03:50] | [2021-03-14 Sun 03:55] ||
> | # | [2021-03-14 Sun 03:50] | [2021-03-14 Sun 03:50] | nil|
> | # | [2021-03-14 Sun 03:50] | [2021-03-14 Sun 03:50] ||
> #+TBLFM: $4='(org-sbe "allinone" (org-timestamp-1 $2) (org-timestamp-2 $3))
> 
>
> 

org source block execute not working correctly with GNU Guile source block?

2021-03-14 Thread Zelphir Kaltstahl
Hello!

I have an org-mode spreadsheet, in which I calculate durations from timestamps
like "[2021-03-14 Sun 03:50]" for example. Recently I saw, that using org-sbe
(org source block execute) in combination with the :var header argument can be
used to run arbitrary code for calculating values to put as result of
spreadsheet formulas (on
https://home.fnal.gov/~neilsen/notebook/orgExamples/org-examples.html
). So I
went trying it out. The following is some GNU Guile code for calculating time
differences in hours:


#+NAME: allinone
#+begin_src scheme :noweb yes :var org-timestamp-1="[2021-01-01 Fri 00:00]", 
org-timestamp-2="[2021-01-01 Fri 01:00]" :results output drawer replace 
:exports none
(import (srfi srfi-19))

(define SECOND 1)
(define MINUTE (* 60 SECOND))
(define HOUR (* 60 MINUTE))

(define org-timestamp-format "[~Y-~m-~d ~a ~H:~M]")

(define duration->time-utc
  (λ (duration)
(make-time time-utc
   (time-nanosecond duration)
   (time-second duration

(define org-timestamp->time-utc
  (λ (timestamp-string)
(let ([parsed-date (string->date timestamp-string org-timestamp-format)])
  (date->time-utc parsed-date

(define org-time-duration
  (λ (org-timestamp-1 org-timestamp-2)
(time-difference (org-timestamp->time-utc org-timestamp-2)
 (org-timestamp->time-utc org-timestamp-1

(define duration->org-timestamp
  (λ (duration)
(time-utc->date
 (duration->time-utc duration)
 ;; timezone offset, assume all with no offset
 0)))

(define duration->hours
  (λ (duration)
(/ (time-second duration) HOUR)))

(number->string
 (duration->hours
  (org-time-duration org-timestamp-1
 org-timestamp-2)))
#+end_src


The source block is named "allinone", because I tried previously with :noweb yes
and referencing other code blocks to be included, but thought that perhaps
org-sbe does not deal well with :noweb yes, so I wanted to make sure to keep
everything in one source block.

The variables org-timestamp-1 and org-timestamp-2 are referenced at the bottom
of the code.

The code runs find in run-guile for example, when I replace the 2 variables with
the default values of the variables, given in the header argument :var, as you
can see in this transcript:


GNU Guile 3.0.5
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (import (srfi srfi-19))

(define SECOND 1)
(define MINUTE (* 60 SECOND))
(define HOUR (* 60 MINUTE))

(define org-timestamp-format "[~Y-~m-~d ~a ~H:~M]")

(define duration->time-utc
  (λ (duration)
(make-time time-utc
   (time-nanosecond duration)
   (time-second duration

(define org-timestamp->time-utc
  (λ (timestamp-string)
(let ([parsed-date (string->date timestamp-string org-timestamp-format)])
  (date->time-utc parsed-date

(define org-time-duration
  (λ (org-timestamp-1 org-timestamp-2)
(time-difference (org-timestamp->time-utc org-timestamp-2)
 (org-timestamp->time-utc org-timestamp-1

(define duration->org-timestamp
  (λ (duration)
(time-utc->date
 (duration->time-utc duration)
 ;; timezone offset, assume all with no offset
 0)))

(define duration->hours
  (λ (duration)
(/ (time-second duration) HOUR)))
scheme@(guile-user)> (define org-timestamp-1 "[2021-01-01 Fri 00:00]")
scheme@(guile-user)> (define org-timestamp-2 "[2021-01-01 Fri 01:00]")
scheme@(guile-user)> (number->string
 (duration->hours
  (org-time-duration org-timestamp-1
 org-timestamp-2)))
$2 = "1"
scheme@(guile-user)>


This code assumes, that I have to convert to a string at the end, to make a good
return value for org-mode spreadsheets.

Then I have this table in my document:


|   | timestamp 1| timestamp 2| result |
|---+++|
| # | [2021-03-14 Sun 03:50] | [2021-03-14 Sun 03:55] ||
| # | [2021-03-14 Sun 03:50] | [2021-03-14 Sun 03:50] | nil|
| # | [2021-03-14 Sun 03:50] | [2021-03-14 Sun 03:50] ||
#+TBLFM: $4='(org-sbe "allinone" (org-timestamp-1 $2) (org-timestamp-2 $3))


The one nil is from one time, when I answered "no" to the question, whether I
want to run the associated source block:


Evaluate this emacs-lisp code block on your system? (yes or no)


What is weird is, that it asks about an emacs-lisp code block, while my block is
a scheme block, which is set to GNU Guile on my Emacs.

When I answer "yes" instead, I get an error pasted into my table, destroying its
structure:


|   | timestamp 1| timestamp 2| result 

Re: [bug] :prologue and :epilogue header arguments don't work in latex code blocks

2021-03-14 Thread Eric S Fraga
On Saturday, 13 Mar 2021 at 06:30, Rodrigo Morales wrote:
> I've noticed that the =:prologue= and =:epilogue= header arguments
> don't work in code blocks whose language is =latex=.

It's not that they don't work, it's that those features have not (yet)
been implemented for LaTeX src blocks.  I would guess that nobody has
found a need for them before now.

As an aside, I am not sure why there isn't a generic implementation of
prologue and epilogue.

In any case, maybe tells us a bit more about what you would like to do
with LaTeX src blocks as there may be another way (there usually is) of
achieving what you want.  I only use LaTeX src blocks to implement
specific aspects that org does not handle itself when exporting to
LaTeX, e.g. include tikz figures.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c



Re: Why is there no inline-src syntax highlighting?

2021-03-14 Thread Eric S Fraga
On Sunday, 14 Mar 2021 at 18:19, Timothy wrote:
> It's great how #+begin_src blocks support 'native' syntax highlighting,
> but inline src_lang{} blocks don't seem to be formatted/highlighted at
> all.
>
> I'm wondering why this is. Might anyone know?

Possibly because nobody had done it before?  Or maybe it slows things
down too much.  I don't know but I would definitely be interested in
having this feature; your screenshot looks good.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c



Why is there no inline-src syntax highlighting?

2021-03-14 Thread Timothy
Hi all,

It's great how #+begin_src blocks support 'native' syntax highlighting,
but inline src_lang{} blocks don't seem to be formatted/highlighted at
all.

I'm wondering why this is. Might anyone know?

Also, if this is just a case of no-one bothering to provide that
functionality would there be any interest in me submitting
https://tecosaur.github.io/emacs-config/config.html#fontifying-inline-src
as a patch? (see https://0x0.st/-ZRa.png for a preview, this also
includes prettifying {{{results()}}}, which I'm quite a fan of).

--
Timothy.