help with sexp in org-capture-template
Hello All, Hope everyone's safe. I am working on a org-capture-template and one of the entries is a date (30 days later) I want in European format. My solution is this: | *Due Date*: %(concat (substring (org-read-date nil nil "+30d") 8 10) "-" (substring(org-read-date nil nil "+30d") 5 7) "-" (substring(org-read-date nil nil "+30d") 0 4)) | Although this does the job, it is extremely inelegant and only reflects my poor knowledge in elisp. Can any of you please help me in making this code better? Thanks and have a safe day! Bala http://balaramadurai.net
Bug: org-archive-subtree-save-file-p results in data loss [9.3.6 (release_9.3.6-432-g73bd24 @ /home/n/.emacs.d/straight/build/org/)]
I'm bumping this because it's bitten me several times. The default value of 'from-org is not covered in the saving logic in org-archive-subtree: https://lists.gnu.org/archive/html/emacs-orgmode/2020-03/msg9.html I keep notes in Org for development projects. Archiving removes the node from the original file, but does not modify the archive file. Unless I remember about this bug or have patched it on that machine, the data is missed in the commit until I do notice it. I've also had a crash or two where the archive file was not saved because of this.
[Patch] Document org-capture-templates entry type default strings
I've included the default entry type strings for each entry type in org-capture-tempalte's docstring. Made a couple clarifying edits as well. IMO this is better than having the user hunt for the defaults in the source or experimenting by creating each type of template: diff --git a/lisp/org-capture.el b/lisp/org-capture.el index d292defd6..ac4d633cb 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -159,14 +159,20 @@ description A short string describing the template, will be shown during type The type of entry. Valid types are: entry an Org node, with a headline. Will be filed as the child of the target entry or as a - top-level entry. + top-level entry. Its default template is: + \"* %?\n %a\" itema plain list item, will be placed in the - first plain list at the target - location. + first plain list at the target location. + Its default template is: + \"- %?\" checkitem a checkbox item. This differs from the plain list item only in so far as it uses a - different default template. + different default template. Its default + template is: + \"- [ ] %?\" table-line a new line in the first table at target location. + Its default template is: + \"| %? |\" plain text to be inserted as it is. target Specification of where the captured item should be placed. @@ -214,9 +220,10 @@ target Specification of where the captured item should be placed. Most general way: write your own function which both visits the file and moves point to the right location -template The template for creating the capture item. If you leave this - empty, an appropriate default template will be used. See below - for more details. Instead of a string, this may also be one of +template The template for creating the capture item. + If it is an empty string or nil, a default template based on + the entry type will be used (see the \"type\" section above). + Instead of a string, this may also be one of: (file \"/path/to/template-file\") (function function-returning-the-template) ===File /mnt/data/programming/repos/org-mode/0001-Document-entry-type-default-template-strings.patch=== From 1b91f8ad184d191e1ee09e79e150d7f51c0c3b18 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Subject: [PATCH] Document entry type default template strings --- lisp/org-capture.el | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index d292defd6..ac4d633cb 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -159,14 +159,20 @@ description A short string describing the template, will be shown during type The type of entry. Valid types are: entry an Org node, with a headline. Will be filed as the child of the target entry or as a - top-level entry. + top-level entry. Its default template is: + \"* %?\n %a\" itema plain list item, will be placed in the - first plain list at the target - location. + first plain list at the target location. + Its default template is: + \"- %?\" checkitem a checkbox item. This differs from the plain list item only in so far as it uses a - different default template. + different default template. Its default + template is: + \"- [ ] %?\" table-line a new line in the first table at target location. + Its default template is: + \"| %? |\" plain text to be inserted as it is. target Specification of where the captured item should be placed. @@ -214,9 +220,10 @@ target Specification of where the
Re: Org-babel-lilypond always renders full pages
On Tue, 2020-03-31 at 10:48 -0300, Jonathan Gregory wrote:
> Hi
>
> On 30 Mar 2020, stardiviner wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> >
> > stardiviner writes:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > >
> > > You might want to try this:
> > >
> > > #+begin_src emacs-lisp
> > > (add-to-list 'org-babel-default-header-args:lilypond
> > > '((:prologue . "\paper{
> > > indent=0\mm
> > > line-width=120\mm
> > > oddFooterMarkup=##f
> > > oddHeaderMarkup=##f
> > > bookTitleMarkup = ##f
> > > scoreTitleMarkup = ##f
> > > }")))
> > > #+end_src
> > >
> >
> > I found this custom setting lilypond header arguments will not work.
> > Because this code
> > function:
> >
> > #+begin_src emacs-lisp
> > (defun org-babel-lilypond-get-header-args (mode)
> > "Default arguments to use when evaluating a lilypond source block.
> > These depend upon whether we are in Arrange mode i.e. MODE is t."
> > (cond (mode
> > '((:tangle . "yes")
> >(:noweb . "yes")
> >(:results . "silent")
> >(:cache . "yes")
> >(:comments . "yes")))
> > (t
> > '((:results . "file")
> >(:exports . "results")
> >
> > (defun org-babel-lilypond-set-header-args (mode)
> > "Set org-babel-default-header-args:lilypond
> > dependent on ORG-BABEL-LILYPOND-ARRANGE-MODE."
> > (setq org-babel-default-header-args:lilypond
> > (org-babel-lilypond-get-header-args mode)))
> > #+end_src
> >
> > It always reset and return one result of two conditions.
> >
> > I think this is a bug.
>
> So are all org-babel-default-header-args:LANG custom variables? In the
> ob-lilypond.el library the headers are hard-coded.
>
> [...]
>
> --
> Jonathan
>
Hi all. This is very interesting.
I quickly tried setting the org-babel-default-header-args:LANG using
exactly
the src emacs-lisp example block above.
However that variable remained nil before and after org export lilypond to PDF.
Am sure I must have done something wrong.
Thank you for drawing my attention to that variable, as it seems the right
place
for lilypond headers and options too.
Off-topic: Oliver is exporting/engraving to a fixed-resolution png. An
alternative
is to export scalable vector graphics of the score to PDF.
Re: rmarkdown-like production of multiple plots in org
On Tue, Mar 31, 2020 at 2:22 PM Matt Price wrote:
>
> I'm completely new to R.
>
> I've started working with a project that creates plots using the ggplot
> package -- so by default it creates grid objects, rather than writing to
> files.
>
> In rmarkdown/rstudio, I can write something like this in a SOMEFILE.Rmd :
>
> ```
> install_github('eeholmes/CoV19')
> library(CoV19)
> getdata();
> plot4(world, 'Ontario Canada')
> plot2(world, 'Italy')
> plot4(states, "WA")
> ```
>
Interesting. I hadn't really thought that approach through. For
exploratory analysis, this sounds awesome and I don't think I've ever
tried multiple plots in a single chunk in RStudio. Only after seeing
Thomas' reply just now did I realize this isn't just plot(), though...
where are those functions from? There might be hidden conveniences
that don't apply to pure ggplot() calls... dunno.
I will add that as soon as you want to start tailoring sizes or how
these appear in the resultant file, I think you'd have to split these
into separate chunks in order to set the options, no?
> I sort of love how the rmarkdown package will just create all 3 of those
> plots, save them to auto-named files, and render to HTML. In RStudio,
> running just that block will also create all three blocks and display them in
> the editor.
>
> By contrast, creating a series of many plots in org is fairly tedious. I
> have to name the plot individually & put each function call in its own src
> block. Is there any way to mimic the behaviour of rmarkdown instead? I odn't
> understand babel or R enough to really even see how something like that could
> be implemented, but I'd appreciate some pointers. Thank you!
Perhaps an alternative is running all your plots in one block, but
using ggsave() (or similar) to save out the files directly (vs. using
:output/:file to do it). Then you could have file links in the org
file instead of the typical 1:1 match-up of a single block to a single
result. I did this once during an effort to optimize a neural network.
I had a big loop iterating through parameters, and would
programmatically save out one residual plot per combination, e.g.
model_var1-value_var2-value_etc.png, I also generated an org-mode
section and exported headers for each combination, embedding the
corresponding [[./plots/foo.png]] image link within that heading.
Exporting to pdf let me page through all my residual plots handily to
compare them.
Anyway, maybe something helpful in there?
John
Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]
Eric S Fraga writes: > And I believe that a reasonable expectation is symmetry with inserting a > row. The way I think of it is the arrow indicates to make space by > moving columns/rows in that direction. Most spreadsheets work in this > way, in my experience (but I could be wrong). I understand now. Thanks. Then I agree with you, it would be better to change the behaviour instead of the documentation. > Unfortunately, this only inserts a cell, not a column. Indeed. Regards,
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
On Tue, Mar 31 2020, Berry, Charles via General discussions about Org-mode. wrote: `org-babel-view-src-block-info' (C-c C-v C-i with point in the src block below) reports I didn't know about that command, it's proven to be very helpful. Thanks! Joost -- Joost Kremers Life has its moments
Re: rmarkdown-like production of multiple plots in org
Aloha Matt, A guess based on my experience with ggplot2 is that the auto-naming and saving take place in the functions plot2() and plot4(). If so, then calling them from Org mode babel blocks will also get you auto-naming and saving. I think you're right that you'll need to put each of the plots in its own babel source code block and then set up the html export to your satisfaction. IIUC, these are the prices one pays for working in a system like Org mode which is both language agnostic and export target agnostic. The rmarkdown/rstudio solution is nifty, but it is tied to one language and one export target. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
On Tue, Mar 31 2020, Ken Mankoff wrote: Yes I'm sure. From the link Thomas sent, Any property specification, unless it is postfixed with a `+`, will *reset* the value of that property to its current value. Yes, I realise now I was mistaken. For some reason, I though that `:results function` meant something, which it doesn't. C-c C-v (for me, Charles uses C-c C-v C-i) withitn a code block shows you the header args that are set for that block. Useful for debugging. Yes, that turned out to be very useful. Thanks. Joost -- Joost Kremers Life has its moments
Statistic cookies for headings and list items
Is this all intended behaviour? When I start with ~C-c C-c~ on [ of line A, Org seems to count list items: * [0/2] A - [ ] B - [ ] C ** DONE D Then ~S-~ on line D seems to count subheadings: * [0/1] A - [ ] B - [ ] C ** TODO D Then ~C-c C-c~ on [ of line A seems to count list items again: * [0/2] A - [ ] B - [ ] C ** TODO D Then ~C-c -~ on line D makes D a subitem which makes no sense to me: * [0/2] A - [ ] B - [ ] C - [ ] D But when I start with this: #+STARTUP: indent * [0/2] A - [ ] B - [ ] C ** TODO D Then ~C-c -~ on line D makes D a sibling which I prefer to the above: #+STARTUP: indent * [0/2] A - [ ] B - [ ] C - [ ] D Except that the automatic update like ~C-c C-c~ on [ of line A is missing: #+STARTUP: indent * [0/3] A - [ ] B - [ ] C - [ ] D (This is Org on today's master.) Michael
rmarkdown-like production of multiple plots in org
I'm completely new to R.
I've started working with a project that creates plots using the ggplot
package -- so by default it creates grid objects, rather than writing to
files.
In rmarkdown/rstudio, I can write something like this in a SOMEFILE.Rmd :
```
install_github('eeholmes/CoV19')
library(CoV19)
getdata();
plot4(world, 'Ontario Canada')
plot2(world, 'Italy')
plot4(states, "WA")
```
I sort of love how the rmarkdown package will just create all 3 of those
plots, save them to auto-named files, and render to HTML. In RStudio,
running just that block will also create all three blocks and display them
in the editor.
By contrast, creating a series of many plots in org is fairly tedious. I
have to name the plot individually & put each function call in its own src
block. Is there any way to mimic the behaviour of rmarkdown instead? I
odn't understand babel or R enough to really even see how something like
that could be implemented, but I'd appreciate some pointers. Thank you!
Re: Preventing org-cycle from scrolling the buffer
Dmitrii Korobeinikov writes:
> When calling org-cycle on a collapsed section which contains a lot of
> text, the headline is adjusted to the top of the page. Collapsing it
> doesn't revert the scroll, which makes it hard to quickly peek at
> what's in the section without getting disoriented. Is there a flag or
> some other way of turning off this autoscroll?
AFAICS this behavior can be controlled via customizable variable
org-cycle-hook { M-x customize-variable RET org-cycle-hook RET } by
removing entry org-optimize-window-after-visibility-change.
> Scroll revert wouldn't be so bad to have either, by the way (in
> addition to, not instead of, though). Since org knows when the cursor
> moves away from the headline after tabbing, it seems this feature can
> be implemented without too much hassle. I would even go as far as to
> suggest making it a default if it gets done.
>
> What do you think?
IDK. AFAICS you are right with your argumentation. I don't see the
need of that feature, though, yet. But that's just me. I think you are
the best candidate to try an implementation of the feature.
Best regards,
-- Marco
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
Yes I'm sure. From the link Thomas sent, Any property specification, unless it is postfixed with a `+`, will *reset* the value of that property to its current value. C-c C-v (for me, Charles uses C-c C-v C-i) withitn a code block shows you the header args that are set for that block. Useful for debugging. -k. On Mon, Mar 30, 2020 at 3:24 PM Joost Kremers wrote: > > On Mon, Mar 30 2020, Ken Mankoff wrote: > > Header args overwrite. Change python to python+ to append header > > args. > > Are you sure? That's not documented anywhere I can find and it > seems to be belied by the fact that if I put the headers in the > order: > > ``` > :PROPERTIES: > :header-args:python: :tangle out1.py > :header-args:python: :session py1 :results function > :END: > ``` > > everything works as I would expect (the code blocks are tangled to > a file `out1.py` *and* they are evaluated in a python session > `py1`), meaning that *all* header args are picked up. > > If I reverse the order and add a `+` sign, like so: > > ``` > :PROPERTIES: > :header-args:python+: :session py1 :results function > :header-args:python+: :tangle out1.py > :END: > ``` > > the code does indeed get tangled, but the `:results` header arg > isn't picked up, because the code block doesn't produce any > output. > > For reference, this is my test file: > > ``` > * Header 1 > :PROPERTIES: > :header-args:python+: :session py1 :results function > :header-args:python+: :tangle out1.py > :END: > > #+begin_src python > a=1 > b=2 > c=a+b > return c > #+end_src > > #+RESULTS: > ``` > > > -- > Joost Kremers > Life has its moments >
Re: Org-babel-lilypond always renders full pages
Thanks, Jonathan, but the first advise does not work.
Where would I put the elisp code you proposed?
Oliver
On 31.03.20 15:43, Jonathan Gregory wrote:
Hi Oliver
On 30 Mar 2020, Oliver Heck wrote:
Hi Jonathan,
that works fine. Thank you!
Can I set this as default header somewhere in the org file or will I
have to include it to every snippet (I will have a lot of them).
Oliver
You can use the Noweb Reference Syntax[1]
#+name: paper
#+begin_src text :exports none
\paper{ oddFooterMarkup=##f }
#+end_src
#+name: Lilypond
#+begin_src lilypond :file test.png
<>
\relative c'' { c d e f }
#+end_src
You can also append the extra header to the
org-babel-default-header-args:lilypond variable:
(advice-add 'org-babel-lilypond-set-header-args :filter-return
(lambda (_mode)
(setq org-babel-default-header-args:lilypond
(append org-babel-default-header-args:lilypond
'((:epilogue . "\\paper{ oddFooterMarkup=##f
}"))
On 30.03.20 01:58, Jonathan Gregory wrote:
Hi
On 29 Mar 2020, Oliver Heck wrote:
Hi,
I am trying to use org-babel-lilypond and basically got it running.
But somehow I always get full lilypond pages back instead of a small
snippet.
This is what I have in my org-file:
#+NAME: Lilypond
#+BEGIN_SRC lilypond :file test.png
\relative c'' { c d e f }
#+END_SRC
I read through the documentation on
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
but cannot find a clue.
Any idea what I am doing wrong here?
Cheers,
Oliver
The lilypond manual suggests using \paper variables to reduce the white
space around the score. In particular, you should set oddFooterMarkup
and oddHeaderMarkup to false.
\paper{
indent=0\mm
line-width=120\mm
oddFooterMarkup=##f
oddHeaderMarkup=##f
bookTitleMarkup = ##f
scoreTitleMarkup = ##f
}
http://lilypond.org/doc/v2.18/Documentation/usage/lilypond-output-in-other-programs
--
Jonathan
--
--
Jonathan
Footnotes:
[1] https://orgmode.org/manual/Noweb-Reference-Syntax.html
--
--
If you are thinking without writing, you only think you are thinking.
(Leslie Lamport)
Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]
On Tuesday, 31 Mar 2020 at 16:05, Nicolas Goaziou wrote: > Hello, > > Well, since I apparently made the change, I have to speak for it. Thank you. It's good to discuss! > When one presses M-S-Right in order to create a new column, I think > a reasonable expectation is : > > 1. to move point to the right, > 2. to move point in the newly created column. And I believe that a reasonable expectation is symmetry with inserting a row. The way I think of it is the arrow indicates to make space by moving columns/rows in that direction. Most spreadsheets work in this way, in my experience (but I could be wrong). > Note that adding a column to the beginning of the row is easy: just type > "|" near the beginning of the first cell. Unfortunately, this only inserts a cell, not a column. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-438-g5b9698
Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]
Am 31.03.20 um 16:05 schrieb Nicolas Goaziou: > Note that adding a column to the beginning of the row is easy: just type > "|" near the beginning of the first cell. Does not seem correct. I had table #+begin_src org | 1 | 2 | | 3 | 4 | #+end_src Adding a | at the beginning of the first cell changed that to: #+begin_src org | | 1 | 2 | | 3 | 4 | | #+end_src That's not adding a column, just a cell, and breaking columns. What would I have to type to have that add a column? TIA, Julius
Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]
Hello, Eric S Fraga writes: > On Monday, 30 Mar 2020 at 23:22, Kyle Meyer wrote: >> It looks like the documentation became stale with b8d473a04 (org-table: >> Insert new column to the right instead of the left, 2017-11-19). Thanks >> for updating it. > > Annoyingly, I would have preferred to have the column inserted to the > left of the current column as this would be consistent with the > insertion of rows. It gets me every time I try to insert a column as I > then have to shift columns. And there's no way to insert a column at > the beginning of the row easily. Whereas adding a new column to the end > is trivial: type anything after the last |. > > Could we leave the documentation as it is and change the behaviour? Well, since I apparently made the change, I have to speak for it. When one presses M-S-Right in order to create a new column, I think a reasonable expectation is : 1. to move point to the right, 2. to move point in the newly created column. Consequently, a reasonable expectation is to create the column to the right. Note that adding a column to the beginning of the row is easy: just type "|" near the beginning of the first cell. Does that make sense? Regards, -- Nicolas Goaziou
Re: Org-babel-lilypond always renders full pages
Hi
On 30 Mar 2020, stardiviner wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> stardiviner writes:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>>
>> You might want to try this:
>>
>> #+begin_src emacs-lisp
>> (add-to-list 'org-babel-default-header-args:lilypond
>> '((:prologue . "\paper{
>> indent=0\mm
>> line-width=120\mm
>> oddFooterMarkup=##f
>> oddHeaderMarkup=##f
>> bookTitleMarkup = ##f
>> scoreTitleMarkup = ##f
>> }")))
>> #+end_src
>>
>
> I found this custom setting lilypond header arguments will not work. Because
> this code function:
>
> #+begin_src emacs-lisp
> (defun org-babel-lilypond-get-header-args (mode)
> "Default arguments to use when evaluating a lilypond source block.
> These depend upon whether we are in Arrange mode i.e. MODE is t."
> (cond (mode
> '((:tangle . "yes")
>(:noweb . "yes")
>(:results . "silent")
>(:cache . "yes")
>(:comments . "yes")))
> (t
> '((:results . "file")
>(:exports . "results")
>
> (defun org-babel-lilypond-set-header-args (mode)
> "Set org-babel-default-header-args:lilypond
> dependent on ORG-BABEL-LILYPOND-ARRANGE-MODE."
> (setq org-babel-default-header-args:lilypond
> (org-babel-lilypond-get-header-args mode)))
> #+end_src
>
> It always reset and return one result of two conditions.
>
> I think this is a bug.
So are all org-babel-default-header-args:LANG custom variables? In the
ob-lilypond.el library the headers are hard-coded.
[...]
--
Jonathan
Re: Org-babel-lilypond always renders full pages
Hi Oliver
On 30 Mar 2020, Oliver Heck wrote:
> Hi Jonathan,
>
> that works fine. Thank you!
>
> Can I set this as default header somewhere in the org file or will I
> have to include it to every snippet (I will have a lot of them).
>
> Oliver
You can use the Noweb Reference Syntax[1]
#+name: paper
#+begin_src text :exports none
\paper{ oddFooterMarkup=##f }
#+end_src
#+name: Lilypond
#+begin_src lilypond :file test.png
<>
\relative c'' { c d e f }
#+end_src
You can also append the extra header to the
org-babel-default-header-args:lilypond variable:
(advice-add 'org-babel-lilypond-set-header-args :filter-return
(lambda (_mode)
(setq org-babel-default-header-args:lilypond
(append org-babel-default-header-args:lilypond
'((:epilogue . "\\paper{ oddFooterMarkup=##f
}"))
> On 30.03.20 01:58, Jonathan Gregory wrote:
>> Hi
>>
>> On 29 Mar 2020, Oliver Heck wrote:
>>
>>> Hi,
>>>
>>> I am trying to use org-babel-lilypond and basically got it running.
>>> But somehow I always get full lilypond pages back instead of a small
>>> snippet.
>>> This is what I have in my org-file:
>>>
>>> #+NAME: Lilypond
>>> #+BEGIN_SRC lilypond :file test.png
>>>\relative c'' { c d e f }
>>> #+END_SRC
>>>
>>>
>>> I read through the documentation on
>>> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
>>> but cannot find a clue.
>>>
>>> Any idea what I am doing wrong here?
>>>
>>> Cheers,
>>> Oliver
>>
>> The lilypond manual suggests using \paper variables to reduce the white
>> space around the score. In particular, you should set oddFooterMarkup
>> and oddHeaderMarkup to false.
>>
>> \paper{
>>indent=0\mm
>>line-width=120\mm
>>oddFooterMarkup=##f
>>oddHeaderMarkup=##f
>>bookTitleMarkup = ##f
>>scoreTitleMarkup = ##f
>> }
>>
>> http://lilypond.org/doc/v2.18/Documentation/usage/lilypond-output-in-other-programs
>>
>> --
>> Jonathan
>>
>
> --
--
Jonathan
Footnotes:
[1] https://orgmode.org/manual/Noweb-Reference-Syntax.html
Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]
On Monday, 30 Mar 2020 at 23:22, Kyle Meyer wrote: > It looks like the documentation became stale with b8d473a04 (org-table: > Insert new column to the right instead of the left, 2017-11-19). Thanks > for updating it. Annoyingly, I would have preferred to have the column inserted to the left of the current column as this would be consistent with the insertion of rows. It gets me every time I try to insert a column as I then have to shift columns. And there's no way to insert a column at the beginning of the row easily. Whereas adding a new column to the end is trivial: type anything after the last |. Could we leave the documentation as it is and change the behaviour? Thank you. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-438-g5b9698
