Re: [O] Missing `Specific Header Arguments' in Manual

[Berry, Charles]

> On May 1, 2018, at 2:49 PM, Nicolas Goaziou  wrote:
> 
> Hello,
> 
> "Berry, Charles"  writes:
> 
>> I miss not being able to refer to a single section in the manual so
>> I can browse the useful babel header arguments whose name, spelling,
>> or function I have forgotten. I guess it was re-organized out of the
>> manual in the update to the new org formatted manual.
> 
> Yes, and it took me a long while to properly put all these arguments in
> a logical place instead of having them piled on top of each other.

Comparing `org-babel-common-header-args-w-values' to the info virtual index 
from 'Iheader arguments', I do not see  these header args in the manual and did 
not find them using `M-s o' in org-manual.org: 

cmdline (not in the previous info version either)

sep

tangle-mode

wrap

Also, `exports' is indexed as `@samp{export}'.

HTH,

Chuck

Re: [O] Missing `Specific Header Arguments' in Manual

[Berry, Charles]

> On May 1, 2018, at 3:10 PM, Kaushal Modi  wrote:
> 
> Hi Nicolas,
> 
> I ran into this issue too very recently when I wanted to search for ":eval". 
> Details below.
> 
> On Tue, May 1, 2018 at 5:50 PM Nicolas Goaziou  wrote:
> 
> Yes, and it took me a long while to properly put all these arguments in
> a logical place instead of having them piled on top of each other.

I should have said `Thanks!' for that.

> 
> In the Org 9.1 version manual, it was possible to search ":eval" and find 
> what I was looking for. In 9.2 manual, very few of the header arguments are 
> documented with the colon prefix. So searching is not consistent any more.
> 
> I was able to do this earlier.. open Org Info manual, C-s :eval, keep on C-s 
> as it found *all hits* in the manual. Now in 9.2, the only hits are in (org) 
> Exporting Code Blocks, which is not very useful. 
> 
> Can we prefix all the header arg references in the manual with ":" so that 
> while searching, I can easily find the (org) Evaluating Code Blocks node? I 
> was having trouble finding this node as "eval" is too generic of a string.. 
> thankfully I remembered the "never-export" value, searched for that and found 
> that node.
>  
>  You don't have to hunt them down. Within info, "i" then "header
> argument". A half-decent completion mechanism will display all of them.
> 

I guess I don't have a half-decent completion mechanism - just ido. But this 
got me looking at info, which I do not know well enough. 

It turns out that (upper case) `I' followed by `header argument' followed by 
RET pops up an `Info Virtual Index' which is what I wanted. 

And this works even without any completion add-ons.


> Thanks for that tip! I guess I need to use the "i" approach more often than 
> the plain old C-s. But I confirm that with "i" followed by "header argument", 
> it presents a nice list of all arguments in the Ivy interface.

Yes. This expands my `info fu'. So thanks again.

Chuck

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-02 01:12 +03, Göktuğ Kayaalp  wrote:
> Okay, I'll read up on these, both code and manuals.  So we've agreed
> that what we want is a new header argument, ‘:edit-vars’, whose value is
> a form similar to a varlist, where
>
> - a form (var val) means bind var to val in the editing buffer,
>
> - a symbol var means bind var in the editing buffer to the buffer-local
>   value of it in the relevant x.org buffer, as in (setq
>   (make-local-variable var) (with-current-buffer "x.org" var))
>
> Do you confirm?  Also, what do you think about :edit-bindings or
> :edit-locals instead of :edit-vars? :var is a completely different
> thing, and :edit-vars may cause confusion, given the similarity of the
> name.

Also, another question remains: how do we extend this to #+begin_export
blocks?  But that's unclear to me maybe because I don't know in detail
how header arguments work.  Ideally this feature would work for _any
block_ editable by ‘org-edit-special’ (i.e. C-c '), and again ideally
using the same syntax.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Aaron Ecay]

2018ko maiatzak 1an, Göktuğ Kayaalp-ek idatzi zuen:

[...]

> So we've agreed
> that what we want is a new header argument, ‘:edit-vars’, whose value is
> a form similar to a varlist, where
> 
> - a form (var val) means bind var to val in the editing buffer,
> 
> - a symbol var means bind var in the editing buffer to the buffer-local
>   value of it in the relevant x.org buffer, as in (setq
>   (make-local-variable var) (with-current-buffer "x.org" var))
> 
> Do you confirm?  

Thatʼs how I understand the proposal, and it seems good to me.

> Also, what do you think about :edit-bindings or :edit-locals instead
> of :edit-vars? :var is a completely different thing, and :edit-vars
> may cause confusion, given the similarity of the name.

Agreed.  I prefer -bindings, but I suppose itʼs not terribly important:
either of your proposed names is a big improvement.

-- 
Aaron Ecay

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-01 21:53 +01, Aaron Ecay  wrote:
> That is excellent news :) If you run into anything you canʼt figure out
> then let us know.

I will probably be able to start working on this next weekend (tho there
is some stuff that can inevitably slow me down this week).  In the mean
time other people can comment both on this and on where to put the
resulting feature.

> But because of the nature of the variable (a lisp list), it can only be
> set once.  So you can have only one of:
> [...]
> But they canʼt be combined.  AFAIR, :var is the only header argument
> that can be meaningfully specified more than once.

Okay, I'll read up on these, both code and manuals.  So we've agreed
that what we want is a new header argument, ‘:edit-vars’, whose value is
a form similar to a varlist, where

- a form (var val) means bind var to val in the editing buffer,

- a symbol var means bind var in the editing buffer to the buffer-local
  value of it in the relevant x.org buffer, as in (setq
  (make-local-variable var) (with-current-buffer "x.org" var))

Do you confirm?  Also, what do you think about :edit-bindings or
:edit-locals instead of :edit-vars? :var is a completely different
thing, and :edit-vars may cause confusion, given the similarity of the
name.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Missing `Specific Header Arguments' in Manual

[Kaushal Modi]

Hi Nicolas,

I ran into this issue too very recently when I wanted to search for
":eval". Details below.

On Tue, May 1, 2018 at 5:50 PM Nicolas Goaziou 
wrote:

>
> Yes, and it took me a long while to properly put all these arguments in
> a logical place instead of having them piled on top of each other.
>

In the Org 9.1 version manual, it was possible to search ":eval" and find
what I was looking for. In 9.2 manual, very few of the header arguments are
documented with the colon prefix. So searching is not consistent any more.

I was able to do this earlier.. open Org Info manual, C-s :eval, keep on
C-s as it found *all hits* in the manual. Now in 9.2, the only hits are in
(org) Exporting Code Blocks, which is not very useful.

Can we prefix all the header arg references in the manual with ":" so that
while searching, I can easily find the (org) Evaluating Code Blocks node? I
was having trouble finding this node as "eval" is too generic of a string..
thankfully I remembered the "never-export" value, searched for that and
found that node.


>  You don't have to hunt them down. Within info, "i" then "header
> argument". A half-decent completion mechanism will display all of them.
>

Thanks for that tip! I guess I need to use the "i" approach more often than
the plain old C-s. But I confirm that with "i" followed by "header
argument", it presents a nice list of all arguments in the Ivy interface.

Kaushal
-- 

Kaushal Modi

Re: [O] Missing `Specific Header Arguments' in Manual

[Nicolas Goaziou]

Hello,

"Berry, Charles"  writes:

> I miss not being able to refer to a single section in the manual so
> I can browse the useful babel header arguments whose name, spelling,
> or function I have forgotten. I guess it was re-organized out of the
> manual in the update to the new org formatted manual.

Yes, and it took me a long while to properly put all these arguments in
a logical place instead of having them piled on top of each other.

> Is there any way to recover this?  
>
> Or maybe add an appendix just for specific header args rather than
> having to hunt them down in the Main Appendix?

You don't have to hunt them down. Within info, "i" then "header
argument". A half-decent completion mechanism will display all of them.

In the worse case, i.e., you have no decent completion mechanism, you
can go to the Main Index then "C-s header argument M-s o".

Now they are sorted, you can also search by topic. For example, if you
know the specific header argument your are looking after is related to
tangling, you can go directly to (info "(org) Extracting Source Code").

Regards,

-- 
Nicolas Goaziou

[O] Missing `Specific Header Arguments' in Manual

[Berry, Charles]

I miss not being able to refer to a single section in the manual so I can 
browse the useful babel header arguments whose name, spelling, or function I 
have forgotten.  I guess it was re-organized out of the manual in the update to 
the new org formatted manual.

Is there any way to recover this?  

Or maybe add an appendix just for specific header args rather than having to 
hunt them down in the Main Appendix?

Chuck

Re: [O] Inheriting some local variables from source code block editing buffers

[Aaron Ecay]

2018ko maiatzak 1an, Göktuğ Kayaalp-ek idatzi zuen:
> 
> On 2018-05-01 20:35 +01, Aaron Ecay  wrote:
>> Thinking about it some more, lexical binding is not a good case for
>> this feature, since it has to be set not only in the edit buffer, but
>> also when C-c C-c is used in the org-mode buffer to evaluate the src
>> block.  The :lexical header arg (which I did not know about) works for
>> the latter but not the former.  To complete the picture, Someone™ needs
>> to implement a org-babel-edit-prep:emacs-lisp function which looks for
>> :lexical yes in the header arguments and sets the value in the edit
>> buffer appropriately.
> 
> I can (and plan to) take on that task once a design is agreed upon.  I
> don't really know much about Org internals, but I think I can figure
> out.

That is excellent news :) If you run into anything you canʼt figure out
then let us know.

> 
>> If lexical-binding is the major motivating factor, then maybe the above
>> is enough.  My original suggestion was for something like:
>> 
>> #+begin_src emacs-lisp :edit-vars ((fill-column 72) (other-var other-val))
>> ...
>> #+end_src
>> 
>> This would set the variables in the edit buffer in the (hopefully)
>> obvious way.  It is not implemented yet, though.
> 
> I do like that syntax.  A minor addition might be for the case when one
> wants to pass the value of a variable local to the org buffer to the
> editing buffer:

That looks fine to me.

> 
> -*- fill-column: 65; indent-tabs-mode: nil -*-
> #+edit-vars: (indent-tabs-mode)

A minor note, the above line should read:
#+header: :edit-vars (indent-tabs-mode)

> #+begin_src emacs-lisp :edit-vars (fill-column (lexical-binding t))

But because of the nature of the variable (a lisp list), it can only be
set once.  So you can have only one of:
#+header :edit-vars ...
OR
#+begin_src emacs-lisp :edit-vars ...
OR
#+property: header-args:emacs-lisp :edit-vars ...
OR
:PROPERTIES:
:header-args:emacs-lisp: :edit-vars ...
:END:

But they canʼt be combined.  AFAIR, :var is the only header argument
that can be meaningfully specified more than once.

-- 
Aaron Ecay

Re: [O] Babel: Shell source block outputting latex for export

[Berry, Charles]

> On May 1, 2018, at 9:29 AM, Russell Adams  wrote:
> 
> Seems like this recently broke.
> 
> Here's an example:
> 
> #+begin_src sh :results latex :exports results
>echo '\begin{lstlisting}'
>echo 'latex test should not be table'
>echo '\end{lstlisting}'
> #+end_src
> 
> #+RESULTS:
> #+BEGIN_EXPORT latex
> | \begin{lstlisting} |  || ||   |
> | latex  | test | should | not | be | table |
> | \end{lstlisting}   |  || ||   |
> #+END_EXPORT
> 
> The expected result is:
> 
> #+RESULTS:
> #+BEGIN_LATEX
> \begin{lstlisting}
> latex test should not be table
> \end{lstlisting}
> #+END_LATEX
> 
> I use shell commands to output listings of source files with custom 
> formatting,
> and highlight source code segments instead of entire files for review.
> 
> Any suggestions how I can prevent the automatic tabling of output?
> 


On my system, this works (note the double backslash in the first line)

#+begin_src sh :exports results :results raw :wrap export latex
echo '\\begin{lstlisting}'
echo 'latex test should not be table'
echo '\end{lstlisting}'
#+end_src

Note that in Version 9.0 the syntax for export blocks changed (see ORG-NEWS) as 
the first #+RESULTS has it.

HTH,

Chuck

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-01 20:35 +01, Aaron Ecay  wrote:
> Thinking about it some more, lexical binding is not a good case for
> this feature, since it has to be set not only in the edit buffer, but
> also when C-c C-c is used in the org-mode buffer to evaluate the src
> block.  The :lexical header arg (which I did not know about) works for
> the latter but not the former.  To complete the picture, Someone™ needs
> to implement a org-babel-edit-prep:emacs-lisp function which looks for
> :lexical yes in the header arguments and sets the value in the edit
> buffer appropriately.

I can (and plan to) take on that task once a design is agreed upon.  I
don't really know much about Org internals, but I think I can figure
out.

> If lexical-binding is the major motivating factor, then maybe the above
> is enough.  My original suggestion was for something like:
>
> #+begin_src emacs-lisp :edit-vars ((fill-column 72) (other-var other-val))
>   ...
> #+end_src
>
> This would set the variables in the edit buffer in the (hopefully)
> obvious way.  It is not implemented yet, though.

I do like that syntax.  A minor addition might be for the case when one
wants to pass the value of a variable local to the org buffer to the
editing buffer:

-*- fill-column: 65; indent-tabs-mode: nil -*-
#+edit-vars: (indent-tabs-mode)
#+begin_src emacs-lisp :edit-vars (fill-column (lexical-binding t))
;; here, when editing, fill-column is 65, lexical binding is t
;; and indent-tabs-mode is nil
#+end_src

> PS Itʼs best to use “reply all” and include the org mode mailing list in
> replies, to make sure everyone following the thread sees all the
> messages.

Whoops! Sorry, yeah, I have been hitting the wrong keybinding for the
last couple of messages I think...

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Does :block field of clocktable respect org-extend-today-until?

[Robert Irelan]

I've updated my repo at https://github.com/telotortium/org-mode (branch
org-clock-table-extend-today-until-block). (I know I cloned it from an older
org-mode repo on Github, but I've updated it so that my branch is rebased
onto
the current master.) I hope that'll work.
On Tue, May 1, 2018 at 1:11 AM Bastien  wrote:

> Hi Robert,

> Robert Irelan  writes:

> > I have a patch to fix this in https://github.com/telotortium/org-mode
> > (branch org-clock-table-extend-today-until-block). I've submitted a
> > copyright assignment with the FSF.

> I confirm your copyright assignment is okay.

> Can you send a patch against Org's current master branch?

> Thanks!

> --
>   Bastien



-- 
Robert Irelan
rire...@gmail.com

Re: [O] Inheriting some local variables from source code block editing buffers

[Aaron Ecay]

2018ko maiatzak 1an, Göktuğ Kayaalp-ek idatzi zuen:

[...]

>> The approach that should be taken should be to use a header argument to
>> specify an alist of variables and values to set in src block edit buffers.
>> Then the usual methods (info "(org) Using header arguments") could be used
>> to control the feature globally, per-buffer, per-language, per-subtree,
>> and per-individual source block.
> 
> I agree.  But note that what I want to do is to set some buffer local
> variables in the special block editing buffer.  The header argument
> ":lexical yes" seems to not affect the editing buffer

Thinking about it some more, lexical binding is not a good case for
this feature, since it has to be set not only in the edit buffer, but
also when C-c C-c is used in the org-mode buffer to evaluate the src
block.  The :lexical header arg (which I did not know about) works for
the latter but not the former.  To complete the picture, Someone™ needs
to implement a org-babel-edit-prep:emacs-lisp function which looks for
:lexical yes in the header arguments and sets the value in the edit
buffer appropriately.

If lexical-binding is the major motivating factor, then maybe the above
is enough.  My original suggestion was for something like:

#+begin_src emacs-lisp :edit-vars ((fill-column 72) (other-var other-val))
  ...
#+end_src

This would set the variables in the edit buffer in the (hopefully)
obvious way.  It is not implemented yet, though.

Aaron

PS Itʼs best to use “reply all” and include the org mode mailing list in
replies, to make sure everyone following the thread sees all the
messages.

-- 
Aaron Ecay

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "

[Eric S Fraga]

On Tuesday,  1 May 2018 at 16:49, Aaron Ecay wrote:

[...]

> On the other hand, as an org user breaking changes are inconvenient.  

We should be clear that there are two different kinds of changes and
your post had references to both types:

1. changes to the user interface, e.g. what is being proposed here.
2. changes to the actual structure of org files, e.g. begin_latex
   becoming begin_export latex.

The first are inconvenient but usually (?) only for a short period of
time until finger memory has adapted.  The second can be much more
serious, leading to impact over quite a period of time, especially for
those that have accumulated many org files over years.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-474-g92785f


signature.asc
Description: PGP signature

Re: [O] Moving from Jekyll to Orgmode

[Diego Zamboni]

Hi Kaushal,

First of all, thanks for your kind words, and most of all for all your work on 
ox-hugo!

> So I don't recommend embedding Hugo shortcodes directly in Org files (even if 
> they work.. not guaranteeing that such embedded Hugo shortcodes will always 
> work). But shortcodes are still supported, though in a different style, 
> leveraging the Org special blocks. That feature is yet undocumented. But it 
> is fully implemented, tested (and used by me). See 
> https://github.com/kaushalmodi/ox-hugo/issues/126 
>  for more info.

Agree - the ideal would be to use regular org constructs for everything, but 
provide enough information to translate it into the appropriate shortcodes when 
appropriate.

> I also have this little annotated diagram:
> https://discourse-cdn-sjc2.com/standard12/uploads/gohugo/original/2X/8/8dd4af3e103c3a691a71356aa3f91bfe1019ebae.png
>  
> 

Very useful! I had seen the table but the diagram (although it takes a bit to 
understand) make it all very visual.

> Apart of the binary-static-ness of the hugo static site generator, another 
> reason it appealed to me is that the Go templating syntax feels a bit 
> /lispy/. For example, I use this:
> 
> {{ $.Scratch.Set "__repo_updated_time" (index (index (index (index $repo_json 
> "commit") "commit") "committer") "date") }} 

Indeed, Hugo is incredibly powerful. I’m still far from an expert on it, 
although I’ve started dabbling into modifying/creating my own templates. Hugo 
has quite a bit of a learning curve, so it’s not for everyone, but if you are 
willing to spend some time learning it, it’s really worth the effort.

Cheers,
—Diego

Re: [O] org-plus-contrib fails to compile

[Glyn Millington]

Tim Cross  writes:

I found this will most often occur because you have org loaded 
before you try to do the upgrade. Basically, org gets confused 
because of having an already loaded version while trying to 
install a new version. 

I was seeing this quite often. Once I re-arranged by init file 
to ensure that I can do a package upgrade before org is loaded, 
all works fairly reliably. 

An easy way to 'fix' the problem is to just delete the 
org-plus-contrib directory from your ELPA directory, then 
restart emacs. Your emacs will probably downlload and install 
the package during startup. Just make sure your org setup comes 
after your package setup. 


Thanks Tim and Bastien,

The 'fix' works - will check the sequence of events in init.el 
again.


with best wishes


Glyn

Re: [O] org-plus-contrib fails to compile

[Tim Cross]

Glyn Millington  writes:

> Good morning list!
>
> Emacs 25.3.1 on Linux
>
> For many upgrades now (over the last year or so) when I have tried 
> to upgrade org-plus-contrib with the package management system 
> pointed at the Org repository, the package is installed but 
> compilation fails with a massive (23.6MB!) backtrace  which begins 
> like this:
>
>  
> Debugger entered--Lisp error: (void-variable This) 
>   eval-buffer(# nil 
>   "/home/glyn/.emacs.d/elpa/org-plus-contrib-20180430/org" nil t) 
>   ; Reading at buffer position 5 
>   
> load-with-code-conversion("/home/glyn/.emacs.d/elpa/org-plus-contrib-20180430/org"
>  
>   "/home/glyn/.emacs.d/elpa/org-plus-contrib-20180430/org" nil t) 
>
> None of the lisp files in the package are compiled.
>
> Can anyone point me to likely sources of the problem (my own 
> cluelessness goes without saying! ) ?
>

I found this will most often occur because you have org loaded before
you try to do the upgrade. Basically, org gets confused because of
having an already loaded version while trying to install a new version.

I was seeing this quite often. Once I re-arranged by init file to ensure
that I can do a package upgrade before org is loaded, all works fairly
reliably.

An easy way to 'fix' the problem is to just delete the org-plus-contrib
directory from your ELPA directory, then restart emacs. Your emacs will
probably downlload and install the package during startup. Just make
sure your org setup comes after your package setup. 


-- 
Tim Cross

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "

[Cook, Malcolm]

Thanks for the re-cap.  

I'm changing my vote.

Make the change!  Change the default!  And make lots of noise advertising it 
(make more prominent https://orgmode.org/Changes.html , etc).

Someone suggested going to v10.x  Is there a case for this?

Thx of org!

 > -Original Message-
 > From: Emacs-orgmode  bounces+mec=stowers@gnu.org> On Behalf Of Nicolas Goaziou
 > Sent: Tuesday, May 01, 2018 7:36 AM
 > To: Steve Downey 
 > Cc: Bastien ; Tim Cross ; Org-
 > mode ; Jon Snader 
 > Subject: Re: [O] [POLL] Should Org tempo be enabled by default? (expand
 > templates thru e.g. " 
 > Hello,
 > 
 > Steve Downey  writes:
 > 
 > > Asking users to accept any breakage in the tool they use to get work done
 > > is a lot. Changes in UI in emacs are opt-in.
 > >
 > > Even if the change is the right thing to do.
 > 
 > I think some of you (basically, anyone thinking we should enable " TAB" by default ;)) are missing the point.
 > 
 > 
 > The first important thing to understand is that, even if we enable
 > `org-tempo' by default, next Org release /will break/ for some of us.
 > 
 > - It will break because `org-tempo' is only 99% backward-compatible.  So
 >   anyone having customizing templates is bound to change them.
 > 
 > - It will break because there are 9 other incompatible changes between
 >   9.1 and 9.2.
 > 
 > So, asking to load `org-tempo' by default just to avoid breaking users
 > set-up is a wrong argument. It will only "protect" those among us that
 > use " incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be
 > smooth for everyone. No matter what `org-tempo' becomes.
 > 
 > 
 > The second important point is there is a general design issue at stake.
 > Sorry, there is no pleasure in inflicting "torture" (as I read in this
 > thread) to users.
 > 
 > Org is too big. Its (lack of) design is wrong.
 > 
 > This is not from me, but from some the Emacs developers, in particular
 > Richard Stallman. You may want to read the thread "Differences between
 > Org-Mode and Hyperbole" in emacs-devel mailing list archives for the
 > exact quote.
 > 
 > Org has to be big, because it is featureful. Yet, we cannot ignore the
 > remark. Also, that doesn't mean we cannot do anything to improve the
 > situation. Actually, there are, at least, two areas in which we can make
 > progress:
 > 
 > 1. externalize Org features that apply to other major modes, or drop
 >them if there are equivalents to them,
 > 
 > 2. re-using (external) Emacs facilities for Org mode features that are
 >not central for us.
 > 
 > Not so long ago, we provided footnotes for other modes, even though
 > "footnote.el" had been there for a long time. This clearly felt into
 > (1), so we dropped the feature. Recently, I wrote "orgalist.el", which
 > ports Org plain lists into other modes. I moved it out of Org core
 > because of (1). It is now available in GNU ELPA.
 > 
 > Expansion templates are a great thing, but this is only sugar for Org,
 > which is totally usable without them. Besides, some facilities are
 > providing it for us. This falls into (2). By design, I'm convinced we
 > should not include them. I also wish that anyone involved in this thread
 > can take a step back to see the whole picture.
 > 
 > The question is not about you using " 'org-tempo) could solve this. The question is not about breaking other
 > configurations: there always have been breakage and there will be again.
 > The question is about designing Org so it fits well -- better, at
 > least -- in the Emacs ecosystem. This means no unreasonable feature
 > overlap and enough modularity to be re-usable from other parts in Emacs.
 > 
 > 
 > Back to the current poll. It would be more efficient to think about
 > solutions to make the update less painful. In particular, how can we
 > tell users updating from ELPA about the necessary changes involved.
 > 
 > I remember that Magit experimented displaying a message the first time
 > you used a new release; you would silence it only by setting a variable.
 > I don't think this is the case anymore, so it may have failed, though.
 > We could also make the  page more
 > prominent in the summary displayed along with the package.
 > 
 > 
 > Now back to the poll.
 > 
 > Regards,
 > 
 > --
 > Nicolas Goaziou
 > 
 > P.S: Bastien, would you please stop lobbying in every other
 > communication canal out there, that's not fair ;)

Re: [O] Inheriting some local variables from source code block editing buffers

[Aaron Ecay]

2018ko maiatzak 1an, Nicolas Goaziou-ek idatzi zuen:
> 
> No, because you can use Noweb syntax wherever you need these local
> variables set:
> 
>   <>

This would still require adding something to each source block, which I
think Göktuğ wants to avoid doing.

With respect to the original proposal, I donʼt think itʼs a good idea to
inherit the values from the org buffer.  I can imagine that one might
want to have different values of (e.g.) fill-column in org-mode vs
emacs-lisp-mode.

The approach that should be taken should be to use a header argument to
specify an alist of variables and values to set in src block edit buffers.
Then the usual methods (info "(org) Using header arguments") could be used
to control the feature globally, per-buffer, per-language, per-subtree,
and per-individual source block.

If this isnʼt desired as a core feature I wouldnʼt see an impediment to
having it be part of org-contrib, though it could also be distributed
via (GNU/M)ELPA; it would be Göktuğʼs choice I guess.

Aaron

PS My view is the lexical-binding case is important enough that this
feature should be included in core, and that core should default to
lexical-binding: t in elisp src blocks

-- 
Aaron Ecay

[O] Babel: Shell source block outputting latex for export

[Russell Adams]

Seems like this recently broke.

Here's an example:

#+begin_src sh :results latex :exports results
echo '\begin{lstlisting}'
echo 'latex test should not be table'
echo '\end{lstlisting}'
#+end_src

#+RESULTS:
#+BEGIN_EXPORT latex
| \begin{lstlisting} |  || ||   |
| latex  | test | should | not | be | table |
| \end{lstlisting}   |  || ||   |
#+END_EXPORT

The expected result is:

#+RESULTS:
#+BEGIN_LATEX
\begin{lstlisting}
latex test should not be table
\end{lstlisting}
#+END_LATEX

I use shell commands to output listings of source files with custom formatting,
and highlight source code segments instead of entire files for review.

Any suggestions how I can prevent the automatic tabling of output?

This worked in Org 8, and I'm on the latest release on ELPA (9.1.2).

Thanks.


--
Russell Adamsrlad...@adamsinfoserv.com

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

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

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "

[Aaron Ecay]

Hi Nicolas,

Iʼm very sympathetic to the direction of travel of these changes, and to
the suggestion that you make in your message about using warnings to
advert users to incompatible changes.  (As you can read in my message to
the parent thread).

However (with great respect for all that you have done to improve org
over the years), I think you missed the point in some of the things you
wrote.

2018ko maiatzak 1an, Nicolas Goaziou-ek idatzi zuen:

[...]

> I think some of you (basically, anyone thinking we should enable " TAB" by default ;)) are missing the point.
> 
> 
> The first important thing to understand is that, even if we enable
> `org-tempo' by default, next Org release /will break/ for some of us.
> 
> - It will break because `org-tempo' is only 99% backward-compatible.  So
>   anyone having customizing templates is bound to change them.
> 
> - It will break because there are 9 other incompatible changes between
>   9.1 and 9.2.
> 
> So, asking to load `org-tempo' by default just to avoid breaking users
> set-up is a wrong argument. It will only "protect" those among us that
> use " incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be
> smooth for everyone. No matter what `org-tempo' becomes.

By this logic, since org 9.2 already contains 9 breaking changes, we can
change anything else in that version.  Make all the key bindings start
with M-S-C-e instead of C-c, sort all the headings in a file in
alphabetical order when opening it, ...

No software update will ever be entirely disruption-free, if nothing
else because bugs will always happen.  So we have to think about the
impact of (intentional) changes not in a binary Yes/No fashion, but in
terms of how many users they affect, and how bad that effect is.  In
this case, the number affected is large (as measured informally by
participation in this poll) and the disruption is severe (a specifically
documented org feature now doesnʼt work, with no obviously discoverable
reason why).  So that is a powerful argument against making the change
in this way, when we can achieve the same long-term effect in a less
disruptive way (with deprecation warnings).

I do think that breaking changes should be grouped into batches.  And
if org has as many as ten that are pending, it is a strong argument to
call the next release version 10, with all the associated fanfare (and
breakage warnings!)  Or if point releases are needed in the meantime,
hold these breaking changes on a branch that can be merged before Org
10.


[...]

> Expansion templates are a great thing, but this is only sugar for Org,
> which is totally usable without them. Besides, some facilities are
> providing it for us. This falls into (2). By design, I'm convinced we
> should not include them. I also wish that anyone involved in this thread
> can take a step back to see the whole picture.

This is a red herring.  The changes do not eliminate expansion template
code from org.  They merely substitute (incompatibly) one expansion
template mechanism for a new one.

FWIW, I do think the idea is worth exploring of getting rid of the (old
and new) template expansion code and using emacsʼs built-in SRecode
template facility.  Like most of the CEDET stuff, it looks horridly
overengineered at a first glance.  But it is also included with emacs by
default (unlike e.g. yasnippet which otherwise looks more pleasant to
program to me), and it would be (even more) responsive to the concerns
from emacs-devel that were quoted in your full message.  To be specific,
this would entail (eventually) getting rid of the
org-structure-template-alist variable entirely, as well as the menu now
bound to C-c C-,; the former would be replaced by (AFAIUI) template
files that would be included with org and/or created by users for their
custom templates; the latter would use SRecodeʼs built-in template
selection instead.

-- 
Aaron Ecay

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "

[Aaron Ecay]

2018ko apirilak 29an, Tim Cross-ek idatzi zuen:

[...]

> I think org itself should provide a very stable core and avoid
> incorporating too many add on enhancements. It should be as stable as
> possible to encourage others to develop and maintain such enhancements
> and extensions. 

As someone who has worked (in a small way) on orgʼs development, I
certainly agree with the above sentiment.  Org is a many-headed
hydra, and decreasing its surface area makes for a better org (since
development efforts can be concentrated) as well as a better overall
user experience (because users can rely on packages, like in this
case yasnippet, that are better at doing something that Org tried to
do).

On the other hand, as an org user breaking changes are inconvenient.  I
have the impression that I can keep up with using org-mode only because
I follow the development list.  Whatʼs much worse, I feel like I should
not advocate the use of org-mode to my colleagues (who are often quite
computer-literate but value long-term stability of software they use),
basically because of the potential problems Bastien listed in his
message.

This situation is also inconvenient for developers...I have in mind a
change several years ago to the #+begin_src lines for shell code.  We
changed from #+begin_src shell to #+begin_src sh (or vice versa, I
canʼt remember precisely).  The result was that “bug” reports trickled
in for over a year, all of which had to be answered with the advice to
change to the new specification.  At the time I paid close attention to
babel-related bug reports because I was working on that code a lot.
Answering these reports (or even just reading them to see that they had
been answered by someone else) took away from my opportunity to do
(what I saw as) interesting things with orgʼs code.  I can only imagine
that for ML subscribers who were not as interested in babel bugs as I
was, the distraction could only have been worse.

As a general (idealized) principle, I think user-visible changes should
be phased in over at least one org major version.  I have no problem
with “intrusive” deprecation warnings, but abrupt changes in behavior
should be avoided.

Hereʼs what I imagine that could look like in the org-tempo case:

For org 9.X:
- Introduce the new functions and machinery for org-tempo as well as the
  new C-c C-, keybinding
- Enable org-tempo by default
- Show a user warning whenever a “>From 012f8d0b71c76f5d255af6bdaeb2d9c83a47cf85 Mon Sep 17 00:00:00 2001
From: Aaron Ecay 
Date: Tue, 1 May 2018 15:32:36 +0100
Subject: [PATCH] Use minor-mode machinery for org-tempo

* lisp/org-tempo.el (org-tempo-mode):
(org-tempo-global-mode): New minor modes.
(org-tempo-mode--activate-in-buffer): New function.
---
 lisp/org-tempo.el | 33 ++---
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
index e1268b893..2feed24dc 100644
--- a/lisp/org-tempo.el
+++ b/lisp/org-tempo.el
@@ -170,17 +170,28 @@ didn't succeed."
 		   'org-tempo-tags)
 
 
-;;; Setup of Org Tempo
-;;
-;; Org Tempo is set up with each new Org buffer and potentially in the
-;; current Org buffer.
-
-(add-hook 'org-mode-hook 'org-tempo-setup)
-(add-hook 'org-tab-before-tab-emulation-hook 'org-tempo-complete-tag)
-
-;; Enable Org Tempo in all open Org buffers.
-(dolist (b (org-buffer-list 'files))
-  (with-current-buffer b (org-tempo-setup)))
+;;; Org Tempo minor mode
+
+;;;###autoload
+(define-minor-mode org-tempo-mode
+  "Expand \"

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "

[Christophe Schockaert]

Alan Tyree writes:

> [...]
>
> Here is a question: I see specialised snippet packages in the ELPA
> respositories. Is it possible to provide snippets that reproduce the
> existing "Easy Templates", maybe even keep the same key bindings so that
> the change is transparent to the users that are likely to have the troubles
> referred to by Bastien?

By chances, I spent some spare time reading this thread, and the
previous one.

Well, Org is my daily-life tool, I am a bit outdated, although. And I
would like to change that, by getting closer to Org upgrades.

I fully understand and can value the need for improving software design
and focusing towards consistent functions, as time passes by and
software grows and evolves.

Also, when there are breaking changes, the thing is that it's often
never the right time. I mean, however small it is, when you are in your
daily process, it does not necesserily fit your agenda. So, I try to
carefully select times for my upgrades, and I am glad to be aware of
this one.

So, I am ready to adapt myself. I will probably learn the new keys if
they are easy to work with. However, the existing shortcut seems so
natural to remember for whom is used to markup tags. And it's easy to
type.

If yasnippets is the way to go, I'll use them. I never took the time yet
to address them. Thus, I like Alan idea to prepare a set of shortcuts
that would match the existing ones. That way, we would have a common set
acting as a base for org users.

I will have a look at org-tempo, too, as it exists and easy to handle.

As for letting know the users, I think it's a very important part.
Could the ORG-NEWS clearly identify the expected breaking changes and
refer to a receipe for handling them ?

Also, would it be possible to add a link to the ORG-NEWS file in the
ELPA package description ? I don't think there is.

I know it exists, and that's where I went for my first breaking changes,
but if we can make it obvious for those would might not be long time
users, that would be great :-)


I any case, thank you for the awesome work you're all doing here.


Cheers,

Christophe


> It is a genuine question since I have no idea of the problems involved.
>
> I'll keep using org no matter what you decide!
>
> Cheers,
> Alan
>
>
> On 1 May 2018 at 08:49, Kaushal Modi  wrote:
>
>> Hi all,
>>
>> I normally am all for adapting to changes, staying on bleeding edges of
>> emacs, Org, etc.
>>
>> But FWIW, for this particular change to the "> the camp of "It was working awesome, it was beautiful! Why change it?". For
>> record, I understand the "why", but it just doesn't seem worth it in this
>> case.
>>
>> But the good thing is that this is open source, and you can backport the
>> stuff you like from the original Easy Template code into your personal
>> Emacs config (and then later adapt to the new way of doing the similar when
>> you have time and motivation).
>>
>> Kaushal
>> --
>>
>> Kaushal Modi
>>


--
--->  https://www.citadels.earth
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and quickly.
[Words of Erenthar, the bowman ranger] <---

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Göktuğ Kayaalp  writes:

> On 2018-05-01 13:55 +02, Nicolas Goaziou  wrote:
>
>> No, because you can use Noweb syntax wherever you need these local
>> variables set:
>>
>>   <>
>
> This seems to only expand when tangling,

When tangling, exporting and evaluating.

> not while editing via C-c '.

Correct.

> What I propose is about setting up the editing buffer (e.g. making
> sure in the org-edit-special lexical-binding is the same as in the
> org-mode buffer so that the results from live evaluation and from when
> tangling and loading the file agree).

Lexical binding is not a good example, because there's already a header
argument to control this:

  #+begin_src emacs-lisp :lexical t
  ...
  #+end_src

and you can set header arguments document-wise, or globally.

Other file local variables you could set in an Org buffer do not usually
make sense in programming languages.

I'm Cc'ing Emacs Org mailing list.

Re: [O] Clocktable Naming

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Dave Marquardt  writes:

> I wanted to add a #+PLOT to the clock table header, and used the
> advice mechanism to do it. E.g.
>
> (defadvice org-clock-report (after insert-plot-line
>  activate)
>   "Add #+PLOT: line appropriate for clock table."
>   (insert
>"#+PLOT: ind:1 deps:(4) type:2d with:histograms set:\"style fill solid\"
> "))
>
> You might be able to do something similar for your purpose.
>
> You might also check to see if there's some sort of hook to use when
> inserting clock tables.
>
> ---
> On Mon, Oct 09 2017, Shawn Way wrote:
>
> Is there a method for automatically naming a timeclock?  For example,
>
> :name table1
>
> to be used in the #+BEGIN line?
>
> This would allow the clocktable to be post processed using something like 
> perl or python for in depth analysis.
>
> SHAWN WAY, P.E.

Hi, Dave. How do you implement this right now?

I'm interested in this plotting org-clock dynamic block. Can you show me
an Org example?

Thanks in advance.

- --
[ stardiviner ] don't need to convince with trends.
   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAlrobPcACgkQG13xyVro
msMWtAf+OwuxRolP4tXYkf9llunX9xOYOkNrhKh8yEGEgNRfWPGFwgA7cP/IU4ZQ
SoNW33NlehAY6kMw+0Rn2qJWUfJE01G03+hTnHrRiWYXTTfFOjq5Q8RBNUJgDN1u
mOqLQH/Xw7rCIJuNnu9QXLmvqA4JTIi6kNwAgQ/Te6BaA+LgGuYpw2+ZF40YtQSI
VYIAscFKBW4CJp0fJ2C7ZbkQNNNF3zq7GOlL4PbaY9bjA0smfOzt7Sum+b4TtYsZ
ZsHu8ZVsMKdSLxV6r4rQnstBvEcmT5XxfN8W21zHEhFNUiG7LuFI7bxY5UvNJl5q
1RpI5m+MK6aodpyw3E5PEgxEmt7+eA==
=lHBw
-END PGP SIGNATURE-

Re: [O] [SOLVED] How to use xml src block as data input?

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is great. Thanks John.

- -- 
[ stardiviner ] don't need to convince with trends.
   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAlroZzkACgkQG13xyVro
msO8kQf+OhzChdi9GRrjKEJOQNod2Gg9g86eGBu5w97ZOHgj/MkOzu2jd3AMxKDN
mt6LKXmcJCDEzKIO36xiiypdckwfU98zAZGrpLFbUlYZ3wdLT/HY1XWXkOHGiQvk
h6rxi7jWdkKw4/tSMZ/Mh70bJ803Y2jZ5JnKx4hwVlgBfoettgWfRf6h91Zg/VcU
QDrIMG5aYcgoMA0GwWtOWeYuYIkq18/Elg6gQhSg+vIe0s0U/4qoArlIFL0AoZcF
qwBZ1hBukWOf1gHvvI8rjbqQ4BOFFjDSbPS6/C+NMZL7oDkbpErH5JAaZTsYYH5e
QBLsOjao+bG1d+7TtZzD92kAsWN5Kg==
=/XVs
-END PGP SIGNATURE-

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "

[Nicolas Goaziou]

Hello,

Steve Downey  writes:

> Asking users to accept any breakage in the tool they use to get work done
> is a lot. Changes in UI in emacs are opt-in.
>
> Even if the change is the right thing to do.

I think some of you (basically, anyone thinking we should enable "https://orgmode.org/Changes.html> page more
prominent in the summary displayed along with the package.


Now back to the poll.

Regards,

-- 
Nicolas Goaziou

P.S: Bastien, would you please stop lobbying in every other
communication canal out there, that's not fair ;)

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "

[Nick Helm]

On Sun, 29 Apr 2018 at 23:05:20 +1200, Bastien wrote:

> I may be wrong in thinking disabling this will cause trouble to
> many users.  Let's just take a moment to see what users think.

I vote to drop "

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Göktuğ Kayaalp  writes:

> But in my case (which is quite common I think) this would require adding
> those local variables sections to each code block.  My Emacs config
> alone has upwards of 170 code blocks, which means same three lines
> repeated 170 times adding up to extra 510 lines, just for setting one
> variable consistently.

No, because you can use Noweb syntax wherever you need these local
variables set:

  <>

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

BTW I can also implement this as a 3rd party extension instead of as a
core feature, I can see how it's possibly not generic enough for that.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-01 10:43 +02, Nicolas Goaziou  wrote:
> I think this machinery is not necessary.
>
> First add a call to `hack-local-variables-apply' somewhere in
> `org-src--edit-element'.
>
> Then, just use regular file-local variables ,e.g.,
>
> #+begin_src emacs-lisp
> (foo)
> ;; Local Variables:
> ;; fill-column: 99
> ;; End:
> #+end_src

But in my case (which is quite common I think) this would require adding
those local variables sections to each code block.  My Emacs config
alone has upwards of 170 code blocks, which means same three lines
repeated 170 times adding up to extra 510 lines, just for setting one
variable consistently.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] org-plus-contrib fails to compile

[Bastien]

Hi Glyn,

good morning!

Did you try to uninstall org-plus-contrib first? Maybe by manually
deleting ~/.emacs.d/elpa/org-plus-contrib-20180430/ ?

Just shooting in the dark...

-- 
 Bastien

[O] [SOLVED] (was: problems with tables using https://orgmode.org/worg/org-tutorials/org-lookups.html)

[Uwe Brauer]

>>> "Nicolas" == Nicolas Goaziou  writes:

   > Hello,
   > Uwe Brauer  writes:


   > It definitely works here.

Sorry by bad, I did not eval the lisp command in-interval!

Now everything works as expected. Thanks!


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] problems with tables using https://orgmode.org/worg/org-tutorials/org-lookups.html

[Nicolas Goaziou]

Hello,

Uwe Brauer  writes:

> Here is the table I consider
>
> #+name: raw-data2
> |---+-+-+-+-+-+-+-+-|
>
> |   | Nombre Completo | DNI | Ej1 | Ej2 | Ej3 | Ej4 | Ej5 | Res |
> |---+-+-+-+-+-+-+-+-|
> |   | Candidate1  |   1 |   0 |   5 |   5 |   0 |  10 |   2 |
> |   | Candidate2  |   2 |   5 |   0 |   5 |   0 |   0 |   1 |
> |   | Candidate3  |   3 |   0 |   0 |   0 |  20 |  25 | 4.5 |
> |   | Candidate4  |   4 |   0 |   0 |   0 |  25 |  15 |   4 |
> |   | Candidate5  |   5 |  15 |  15 |  20 |  25 |  25 |  10 |
> |   | Candidate6  |   6 |  15 |  10 |  20 |  20 |  20 | 8.5 |
> |   | Candidate7  |   7 |  15 |  10 |  10 |  20 |  15 |   7 |
>
> #+TBLFM: $9=($4+$5+$6+$7+$8)/10
>
> | lower bound | upper bound | frequency |
> |-+-+---|
> |   1 |   5 | #ERROR|
> |   5 |  10 | #ERROR|
>
> #+TBLFM: $3='(length (org-lookup-all '($1 $2) '(remote(raw-data2,@2$9..@>$9)) 
> nil 'in-interval));N

>
> I put the cursor on #+TBLFM: $3='(length (org-lookup-all '($1 $2) 
> '(remote(raw-data2,@2$9..@>$9)) nil 'in-interval));N
>
> And run C-c C-c
> I obtain an errror and the message

I obtain:

| lower bound | upper bound | frequency |
|-+-+---|
|   1 |   5 | 4 |
|   5 |  10 | 3 |
#+TBLFM: $3='(length (org-lookup-all '($1 $2) '(remote(raw-data2,@2$9..@>$9)) 
nil 'in-interval));N

I have no explaination for the discrepancy.

Regards,

-- 
Nicolas Goaziou

Re: [O] problems with tables using https://orgmode.org/worg/org-tutorials/org-lookups.html

[Uwe Brauer]

>>> "Nicolas" == Nicolas Goaziou  writes:

Since I am using a git version from July I just pulled the latest master
compiled and installed.


   > It definitely works here.


Here is the table I consider

#+name: raw-data2
|---+-+-+-+-+-+-+-+-|
|   | Nombre Completo | DNI | Ej1 | Ej2 | Ej3 | Ej4 | Ej5 | Res |
|---+-+-+-+-+-+-+-+-|
|   | Candidate1  |   1 |   0 |   5 |   5 |   0 |  10 |   2 |
|   | Candidate2  |   2 |   5 |   0 |   5 |   0 |   0 |   1 |
|   | Candidate3  |   3 |   0 |   0 |   0 |  20 |  25 | 4.5 |
|   | Candidate4  |   4 |   0 |   0 |   0 |  25 |  15 |   4 |
|   | Candidate5  |   5 |  15 |  15 |  20 |  25 |  25 |  10 |
|   | Candidate6  |   6 |  15 |  10 |  20 |  20 |  20 | 8.5 |
|   | Candidate7  |   7 |  15 |  10 |  10 |  20 |  15 |   7 |
#+TBLFM: $9=($4+$5+$6+$7+$8)/10

| lower bound | upper bound | frequency |
|-+-+---|
|   1 |   5 | #ERROR|
|   5 |  10 | #ERROR|
#+TBLFM: $3='(length (org-lookup-all '($1 $2) '(remote(raw-data2,@2$9..@>$9)) 
nil 'in-interval));N


I put the cursor on #+TBLFM: $3='(length (org-lookup-all '($1 $2) 
'(remote(raw-data2,@2$9..@>$9)) nil 'in-interval));N

And run C-c C-c
I obtain an errror and the message
Cells in the region copied, use M-x org-table-paste-rectangle to paste them in 
a table. [2 times]

But when I run that command org does not present the frequencies I am
looking for, what do I miss?


smime.p7s
Description: S/MIME cryptographic signature

[O] org-plus-contrib fails to compile

[Glyn Millington]

Good morning list!

Emacs 25.3.1 on Linux

For many upgrades now (over the last year or so) when I have tried 
to upgrade org-plus-contrib with the package management system 
pointed at the Org repository, the package is installed but 
compilation fails with a massive (23.6MB!) backtrace  which begins 
like this:



Debugger entered--Lisp error: (void-variable This) 
 eval-buffer(# nil 
 "/home/glyn/.emacs.d/elpa/org-plus-contrib-20180430/org" nil t) 
 ; Reading at buffer position 5 
 load-with-code-conversion("/home/glyn/.emacs.d/elpa/org-plus-contrib-20180430/org" 
 "/home/glyn/.emacs.d/elpa/org-plus-contrib-20180430/org" nil t) 


None of the lisp files in the package are compiled.

Can anyone point me to likely sources of the problem (my own 
cluelessness goes without saying! ) ?


with thanks


Glyn

Re: [O] Smart archiving of subtrees with parent headlines

[Bastien]

Hi Mark,

Mark Edgington  writes:

> I don't know why not -- I'm OK with the code being used in
> org-archive.el.  As far as I'm concerned, you can use it however you
> wish (it is based on Ken's code though, so he would also need to sign
> off on its use, I suppose).

Would you like to contribute by submitting a patch against master?

For this you would need to sign FSF copyright assignment.

See http://orgmode.org/request-assign-future.txt

Thanks!

-- 
 Bastien

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Nicolas Goaziou  writes:

> First add a call to `hack-local-variables-apply' somewhere in
> `org-src--edit-element'.

I meant `hack-local-variables'.

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Hello,

Göktuğ Kayaalp  writes:

> One case I can think of is to set variables like fill-column when
> editing inline LaTeX, HTML, &c blocks, and also, those like
> c-file-style, where say when writing a paper the author wants to use k&r
> style, but when writing a literate source prefers gnu style.
>
> Maybe a good way to achieve this would be to have the way you suggest to
> set defaults for Babel, but allow to define such bindings also in
> individual org mode files, either via the local variables or with a
> specific #+keyword like:
>
> #+edit_special_bindings: lexical-binding:t
> # or
> #+edit_special_bindings: c-file-style:gnu fill-column:80
>
> which is better IMO because there is no need to declare separately which
> variables to copy, and is more granular.  Also, in this case, a shortcut
> syntax for inheriting the buffer local value of a variable can be
> useful:
>
>  x.org ===
> # -*- fill-column: 65 -*-
> #+edit_special_bindings: c-file-style:gnu fill-column*
>
> This can be useful when one needs/wants to keep a consistent style in a
> given file.

I think this machinery is not necessary.

First add a call to `hack-local-variables-apply' somewhere in
`org-src--edit-element'.

Then, just use regular file-local variables ,e.g.,

#+begin_src emacs-lisp
(foo)
;; Local Variables:
;; fill-column: 99
;; End:
#+end_src

Regards,

-- 
Nicolas Goaziou

Re: [O] Does :block field of clocktable respect org-extend-today-until?

[Bastien]

Hi Robert,

Robert Irelan  writes:

> I have a patch to fix this in https://github.com/telotortium/org-mode
> (branch org-clock-table-extend-today-until-block). I've submitted a
> copyright assignment with the FSF.

I confirm your copyright assignment is okay.

Can you send a patch against Org's current master branch?

Thanks!

-- 
 Bastien