Re: Free up C-c SPC/org-table-blank-field?

[Carsten Dominik]

On Fri, Feb 5, 2021 at 7:33 PM Eric Abrahamsen 
wrote:

> Carsten Dominik  writes:
>
> > On Fri, Feb 5, 2021 at 11:13 AM Christian Moe 
> wrote:
> >
> >>
> >> Tim Cross writes:
> >>
> >> > Eric Abrahamsen  writes:
> >> >
> >> >>> Does it actually need a key binding? I've never used it and just use
> >> >>>  to move to the next field, leaving the field blank.
> >> >>
> >> >> I assume it's meant for blanking a field you've already typed
> something
> >> >> into. But yes, I can't imagine it's a heavily-used command, and I
> >> >> suspect the C-c  binding is mostly mnemonic: "make this field
> >> >> contain only blanks".
> >> >>
> >> >
> >> > I guess that makes sense, but not convinced the use of a valuable key
> >> > binding is justified given the need. Then again, others probably have
> >> > vastly different use cases to mine.
> >>
> >> One can also blank a field by pressing  immediately after tabbing
> >> into it. So C-c  isn't strictly needed.
> >>
> >
> > Hi,
> >
> > I think there would be minimal impact from releasing this key binding.
> So
> > I think we could remove it.
>
> Well that would be pretty nice, if you don't think it would be too
> disruptive. Shall I prepare a patch?
>

I am not taking the decisions, but I would say: yes, please do.

Carsten

>
> Thanks,
> Eric
>

Re: Free up C-c SPC/org-table-blank-field?

[Carsten Dominik]

On Fri, Feb 5, 2021 at 11:13 AM Christian Moe  wrote:

>
> Tim Cross writes:
>
> > Eric Abrahamsen  writes:
> >
> >>> Does it actually need a key binding? I've never used it and just use
> >>>  to move to the next field, leaving the field blank.
> >>
> >> I assume it's meant for blanking a field you've already typed something
> >> into. But yes, I can't imagine it's a heavily-used command, and I
> >> suspect the C-c  binding is mostly mnemonic: "make this field
> >> contain only blanks".
> >>
> >
> > I guess that makes sense, but not convinced the use of a valuable key
> > binding is justified given the need. Then again, others probably have
> > vastly different use cases to mine.
>
> One can also blank a field by pressing  immediately after tabbing
> into it. So C-c  isn't strictly needed.
>

Hi,

I think there would be minimal impact from releasing this key binding.  So
I think we could remove it.

Carsten


>
> (Though since you typically discover you want to blank a field only when
> you're actually in it, it can help shave a few seconds off your day that
> you'd otherwise use to move out of the field you want to blank and tab
> back in ... which is how I've done this until now, being unaware of C-c
> ).
>
> Yours,
> Christian
>
>

Re: stability of toc links

[Carsten Dominik]

Dear all,

I am sorry, I have trouble finding the time to work on this - so if someone
else wants to look further into this, that would be great.

Carsten

On Fri, Dec 11, 2020 at 8:51 AM Carsten Dominik  wrote:

> Dear all,
>
> let me test this a bit, and then I am going to proposa a patch.
>
> Kind regards
>
> Carsten
>
> On Thu, Dec 10, 2020 at 3:38 PM TEC  wrote:
>
>>
>> > There are a few touch ups I'll do to my code shortly
>>
>> I'm pleased to say that I've improved the readability and documentation
>> of my code (hopefully) in
>>
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftecosaur%2Femacs-config%2Fcommit%2Fdc873d3data=04%7C01%7Cc.dominik%40uva.nl%7C783e4577fb6342a7a43e08d89d193c38%7Ca0f1cacd618c4403b94576fb3d6874e5%7C1%7C0%7C637432078994585612%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0i0U93RLqza1tVFDzVEXCc4xzwHAEvDmmZ51Woom%2F8A%3Dreserved=0
>>
>> I hope this may be of some help,
>>
>> Timothy
>>
>

Re: stability of toc links

[Carsten Dominik]

Dear all,

let me test this a bit, and then I am going to proposa a patch.

Kind regards

Carsten

On Thu, Dec 10, 2020 at 3:38 PM TEC  wrote:

>
> > There are a few touch ups I'll do to my code shortly
>
> I'm pleased to say that I've improved the readability and documentation
> of my code (hopefully) in
>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftecosaur%2Femacs-config%2Fcommit%2Fdc873d3data=04%7C01%7Cc.dominik%40uva.nl%7C783e4577fb6342a7a43e08d89d193c38%7Ca0f1cacd618c4403b94576fb3d6874e5%7C1%7C0%7C637432078994585612%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0i0U93RLqza1tVFDzVEXCc4xzwHAEvDmmZ51Woom%2F8A%3Dreserved=0
>
> I hope this may be of some help,
>
> Timothy
>

Re: stability of toc links

[Carsten Dominik]

On Wed, Dec 9, 2020 at 10:25 PM Samuel Wales  wrote:

> just so everybody is on the same page, i think carsten is talking
> about tec's code that generates html id's that are then used in urls?
>

Yes, I mean this code, or something like this, to aid the automatic
creation of links that are somewhat stable.  I have been missing this very
much.

Kind regards

Carsten


>
> imo great idea.
>
>
> On 12/9/20, Carsten Dominik  wrote:
> > I think we should merge this code into Org.
> >
> > Kind regards
> >
> > Carsten
> >
> > On Wed, Dec 9, 2020 at 3:54 AM TEC  wrote:
> >
> >>
> >> Hi Sam, link stability is a concern I've had too. I currently have a fix
> >> (or at the very least, an improvement) for this in my config where I
> >> overwrite org-export-get-reference. (see:
> >>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftecosaur.github.io%2Femacs-config%2Fconfig.html%23nicer-generated-headingdata=04%7C01%7Cc.dominik%40uva.nl%7C64cff9b5261046b136f808d89c88ebcf%7Ca0f1cacd618c4403b94576fb3d6874e5%7C1%7C0%7C637431459175966570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=jE5t3HVjViPeswx%2BQP7Qe0kdrHTZaS3r4WByndfU71g%3Dreserved=0
> >> ).
> >>
> >> I raised this on the list a while ago ---
> >>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Forgmode.org%2Flist%2FE1jxAjq-0004Dk-LH%40lists.gnu.org%2Fdata=04%7C01%7Cc.dominik%40uva.nl%7C64cff9b5261046b136f808d89c88ebcf%7Ca0f1cacd618c4403b94576fb3d6874e5%7C1%7C0%7C637431459175966570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2Fpl%2BCWuuwqY2voqj0VZpu0MCqniow5%2FRjixB8SycDUM%3Dreserved=0
> but there
> >> didn't seem to be much interest.
> >>
> >> All the best,
> >> Timothy
> >>
> >> Samuel Wales  writes:
> >>
> >> > when you link to a section using toc, you get a link like
> >> >
> >> >
> >>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fthekafkapandemic.blogspot.com%2F2020%2F02%2Fcrimes-against-humanity_3.html%23org080f0abdata=04%7C01%7Cc.dominik%40uva.nl%7C64cff9b5261046b136f808d89c88ebcf%7Ca0f1cacd618c4403b94576fb3d6874e5%7C1%7C0%7C637431459175966570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nHDQx0BMqTeDGLt3OFCAWcLoCrpDoWEbticHf9NT1ZY%3Dreserved=0
> >> >
> >> > will these links break if somebody copies them and pastes them
> >> > elsewhere?  what if you add a section?
> >> >
> >> > there doesn't seem to be a perfect solution, short of adding custom id
> >> > or id to everything, but perhaps a fuzzy hash of the header and
> >> > contents of the section could be used?  or a strict hash of the
> >> > header?  is anything like this being done?  just curious.
> >>
> >>
> >>
> >
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fthekafkapandemic.blogspot.com%2F2013%2F10%2Fwhy-some-diseases-are-wronged.htmldata=04%7C01%7Cc.dominik%40uva.nl%7C64cff9b5261046b136f808d89c88ebcf%7Ca0f1cacd618c4403b94576fb3d6874e5%7C1%7C0%7C637431459175966570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=db%2FAmlA1knJ%2Bph6jM%2B6AvXND%2BdMT8YFpmmcT33kqJrg%3Dreserved=0
>

Re: stability of toc links

[Carsten Dominik]

I think we should merge this code into Org.

Kind regards

Carsten

On Wed, Dec 9, 2020 at 3:54 AM TEC  wrote:

>
> Hi Sam, link stability is a concern I've had too. I currently have a fix
> (or at the very least, an improvement) for this in my config where I
> overwrite org-export-get-reference. (see:
> https://tecosaur.github.io/emacs-config/config.html#nicer-generated-heading
> ).
>
> I raised this on the list a while ago ---
> https://orgmode.org/list/e1jxajq-0004dk...@lists.gnu.org/ but there
> didn't seem to be much interest.
>
> All the best,
> Timothy
>
> Samuel Wales  writes:
>
> > when you link to a section using toc, you get a link like
> >
> >
> https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.html#org080f0ab
> >
> > will these links break if somebody copies them and pastes them
> > elsewhere?  what if you add a section?
> >
> > there doesn't seem to be a perfect solution, short of adding custom id
> > or id to everything, but perhaps a fuzzy hash of the header and
> > contents of the section could be used?  or a strict hash of the
> > header?  is anything like this being done?  just curious.
>
>
>

Re: Thoughts on the standardization of Org

[Carsten Dominik]

Dear all,

this is an interesting discussion to read, and I think lots of  clever
people have made this an interesting discussion. So I hesitated to even
join the discussion, because I am quite removed from current development
and no longer feel qualified to guide it.  Still, my 5c.

For me, it seems unrealistic to standardize Org in a way that make it
desirable or even feasible to have *full implementations* in other tools.
What makes sense it to have tools that can

- *display* org files in a pleasant and useful way
- *convert* org files into other formats, with some accepted loss of
functionality
- *write* org files that then will function properly in Emacs.

Orgzly is a fantastic example.  It reads and displays Org files,
understands enough syntax to provide very useful functionality, and is
decent enough to not change stuff that is does not understand and use, so
that the files it writes are again fully functional in Emacs.

It seems to me that this covers most of what we can hope for, as a basic
formula.  No definition of Org syntax can fully know what I have done in my
personal environment, and therefore will not be able to reproduce that
functionality elsewhere.  This is intrinsic in Org and Emacs, I think.

The efforts to clean up the markup syntax have been fantastic (thank you,
in particular, Nicolas), and they have made it possible to have meaningful
parsers like the one on github.  And they provide a certain guarantee that
the three items I list above will work, also going forward.

Now, do I want that an arbitrary web browser or email client understands if
a file is org syntax, and that clicking on it should open Emacs.  Yes, I
would like that.  So in that sense, a mime type would be useful, for sure.

Greetings

Carsten

On Mon, Nov 2, 2020 at 4:50 PM Eric S Fraga  wrote:

> On Monday,  2 Nov 2020 at 16:23, Russell Adams wrote:
> > #+BEGIN_RANT
> > [...]
> > #+END_RANT
>
> Apologies for my comment then!  :-( I am fully sympathetic to the views
> you have expressed.
>
> Let me rephrase, therefore: it could be interesting to see Emacs as a
> SaaS which processes org mode documents.  But, note, I only say it might
> be interesting.  I am not particularly keen on cloud services for all
> kinds of reasons including ownership, security, etc.
>
> My solution is to have Emacs with me at all times so I have org & gnus &
> erc & emms & ... :-) I have a Planet Computers Gemini and an
> OpenPandora, for this reason, and am awaiting the soon to be available
> Pyra with impatience to have a fully open system (open software in the
> form of Debian & Emacs and open hardware, as much as is possible at the
> moment).
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
>
>

Re: New website - back to the old unicorn!

[Carsten Dominik]

On Mon, Oct 26, 2020 at 7:28 PM Scott Randby  wrote:

> On 10/26/20 5:41 AM, Bastien wrote:
> > Dear all,
> >
> > thanks to the initiative and the patient efforts of Timothy, our
> > website has been revamped: new contents, new look and... the old
> > unicorn!
>
> The new site is wonderful. The Features page is especially useful. Now my
> friends and students can easily see why Org is so great.
>

Yes, in particular the animated examples are totally cool.

Carsten


> Scott Randby
>
>

Re: New website - back to the old unicorn!

[Carsten Dominik]

On Mon, Oct 26, 2020 at 11:11 AM Carsten Dominik  wrote:

> Hi,
>
> I like it!
>
> :)
>
> Carsten
>
> P.S.  One of the pages advertises that this
>
>[[
> https://upload.wikimedia.org/wikipedia/commons/5/5d/Konigsberg_bridges.png
> ]]
>
> should inline an image.  Does not do it yet for me.  What am I missing?
>

Never mind, it works in export, not tin the buffer.  Still, the text on the
webpage is a bit confusing.

Carsten


>
> Carsten
>
> On Mon, Oct 26, 2020 at 10:42 AM Bastien  wrote:
>
>> Dear all,
>>
>> thanks to the initiative and the patient efforts of Timothy, our
>> website has been revamped: new contents, new look and... the old
>> unicorn!
>>
>> Thanks very much to Timothy and to everyone who contributed with
>> feedback and ideas.
>>
>> This is a new basis that we will continue to polish and enhance.
>>
>> Enjoy :)
>>
>> https://orgmode.org
>>
>> --
>>  Bastien
>>
>>

Re: New website - back to the old unicorn!

[Carsten Dominik]

Hi,

I like it!

:)

Carsten

P.S.  One of the pages advertises that this

   [[
https://upload.wikimedia.org/wikipedia/commons/5/5d/Konigsberg_bridges.png]]

should inline an image.  Does not do it yet for me.  What am I missing?

Carsten

On Mon, Oct 26, 2020 at 10:42 AM Bastien  wrote:

> Dear all,
>
> thanks to the initiative and the patient efforts of Timothy, our
> website has been revamped: new contents, new look and... the old
> unicorn!
>
> Thanks very much to Timothy and to everyone who contributed with
> feedback and ideas.
>
> This is a new basis that we will continue to polish and enhance.
>
> Enjoy :)
>
> https://orgmode.org
>
> --
>  Bastien
>
>

Re: How to restore old C-u C-c C-t behavior?

[Carsten Dominik]

On Mon, Oct 26, 2020 at 5:59 AM Piotr Isajew via General discussions about
Org-mode.  wrote:

> Hi,
>
> I've recently upgraded from version 8.2 to 9.3 and one change
> I've noticed is that the behavior of C-u C-c C-t is different.
>
> It used to prompt me for a desired target state to which the task
> is going to be set. Now it just advances to next state and
> captures the note on its way.
>

This is what C-c C-t does.  It prompts you for a key to select the secured
state.

Also take a look at the variable `org-use-fast-todo-selection'.

Carsten


>
> Is there an easy way to revert to the old behavior?
>
>
>
>

Re: The Website Revamp: The final stretch

[Carsten Dominik]

Hi

A or B, no strong preference.

About the text, maybe we can change the "there are dozens of them", that
struck me as a bit odd.  Because what is a "feature".

Maybe
Features - which subset will you use?
Features - something for everyone
Features - start digging

I don't know...

Cheers

Carsten

On Thu, Sep 24, 2020 at 6:42 PM Nick Dokos  wrote:

> Nix on variant C from me.
>
> Slight lean towards B, but I personally would be happy with either A or B.
>
> Thanks!
> --
> Nick
>
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
>
>
>

Re: Agenda view: On this day

[Carsten Dominik]

Dear Klaus,

I am not aware of code that does that.

Carsten


On Wed, Sep 9, 2020 at 3:55 PM Klaus Thoben  wrote:

> Carsten Dominik  writes:
>
> > On Wed, Sep 9, 2020 at 3:06 PM Eric S Fraga  wrote:
> >
> >> On Wednesday,  9 Sep 2020 at 14:35, Klaus Thoben wrote:
> >> > Does such a function exist already? Or can somebody help me out with
> >> > some Lisp code for that?
> >>
> >> The org agenda viewer will display timestamped events from all files
> >> listed in org-agenda-files.  Set the latter and invoke the agenda
> >> (org-agenda, which is bound to C-c a for me) and select "a".  You can
> >> then view any particular day you may wish.
> >>
> >
> > To make this work for a number of files, Org has to be told which files
> to
> > look at.  The variable org-agenda-files can be customized to be a list of
> > all such files.
> >
> > - Carsten
> >
> >
> >>
> >> --
> >> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-725-g7bc18e
> >>
> >>
> Hi and thanks,
> the things you wrote I did already, maybe I didn't make myself clear
> enough. What I envision is an extension to the
> birthday/diary/anniversary function
>
> This I already have:
>
> > Monday 27 July 2020 W31
> >   Birthday: Matthew Daniels (36th)
> >   Birthday: Annie Rose (76th)
>
> What I'd also like to see:
>
> > Tuesday 28 July 2020 W31
> >   Birthday: Matthew Daniels (32th)
> >   Birthday: Annie Rose (67th)
> >   This day in 2015: 0:05 lastfm: Under Pressure (Queen And David Bowie)
> >   This day in 2015: 7:51 lastfm: Radio Ga Ga
>
> >   This day in 2016: 13:36 SMS from Katwarn: KATWARN - DWD:
> UNWETTERWARNUNG
> >   This day in 2016: 14:44 SMS from Katwarn: KATWARN - DWD:
> UNWETTERWARNUNG
> >   This day in 2019: 13:18 Photo K50_2685.JPG
> >   This day in 2019: 13:19 Photo K50_2686.JPG
>
> Klaus
>
>
>
>

Re: Agenda view: On this day

[Carsten Dominik]

On Wed, Sep 9, 2020 at 3:06 PM Eric S Fraga  wrote:

> On Wednesday,  9 Sep 2020 at 14:35, Klaus Thoben wrote:
> > Does such a function exist already? Or can somebody help me out with
> > some Lisp code for that?
>
> The org agenda viewer will display timestamped events from all files
> listed in org-agenda-files.  Set the latter and invoke the agenda
> (org-agenda, which is bound to C-c a for me) and select "a".  You can
> then view any particular day you may wish.
>

To make this work for a number of files, Org has to be told which files to
look at.  The variable org-agenda-files can be customized to be a list of
all such files.

- Carsten


>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-725-g7bc18e
>
>

Re: org-format-outline-path fonts sizes in the minibuffer

[Carsten Dominik]

Dear Bastien,

yes, keeping the color would be good, this can make reading these strings
much easier.

Carsten

On Fri, Sep 4, 2020 at 10:06 AM Bastien  wrote:

> Hi,
>
> thanks for reporting this. I think the echo area should display
> the outline path using Emacs default font, removing both height
> and colors.  That's fixed in maint now as a3576543f.
>
> If someone want to remove the height while preserving colors,
> let's consider this option too.
>
> Thanks,
>
> --
>  Bastien
>
>

Re: Bug: no math-mode detection for align-environment [9.3.7 (9.3.7-13-ge62ca4-elpaplus @ /home/stefi/.emacs.d/elpa/org-plus-contrib-20200713/)]

[Carsten Dominik]

Hi,

AUCTeX has taken back this change, realizing that texmathp.el is also used
in contexts where the mechanisms of AUCTeX to find out about LaTeX packages
being used does not work.  I do think this is already fixed in the latest
AUCTeX version.  At least it is fixed in their git.

- Carsten

Carsten

On Fri, Aug 28, 2020 at 7:09 AM Kyle Meyer  wrote:

> Stefi writes:
>
> > It might be a change to texmathp.el. It is part of Auctex and checks if
> > math mode is on or off. I could not find align environment in the list
> > of default environments. Maybe that has changed.
> >
> > However, I added align and align* to "Texmathp Tex Commands" from the
> > customize browser (open a .tex file to customize auctex). Tab-expansion
> > is working now. Can anyone confirm?
> >
> > In my .emacs, it added to custom-set-variables:
> > '(texmathp-tex-commands (quote (("align*" env-on) ("align" env-on
>
> Yes, that results in expansion on my end as well.
>
> It looks like this issue was introduced with AUCTeX's 91701704 (Delete
> overhead in extending font lock range of math expression, 2020-06-11).
> If you're getting AUCTeX from ELPA, the regression is included the
> current version there (12.2.4, 2020-06-29).
>
> At the start of this month, it was fixed in f04a508f (Restore all math
> environments in texmathp.el, 2020-08-01), so the issue should go away
> with the next update that lands on ELPA.
>
>

Re: convert a org table to plain text

[Carsten Dominik]

You can also export to an ascii buffer with  C-c C-e t A
and get the result from there.  Not sure if this is what you want, how
important is it that the results is in the same buffer right away?

Cheers

Carsten

On Wed, Aug 26, 2020 at 3:17 PM Nick Dokos  wrote:

> Uwe Brauer  writes:
>
> >> Uwe Brauer  writes:
> >
> >> Does this:
> >
> >>
> https://stackoverflow.com/questions/17717483/howto-convert-org-mode-table-to-original-tabbed-format/17726489#17726489
> >
> >
> > Yes, very much so. It would be great to have that code included in
> > orgmode. Did anybody try to contact the author?
> >
>
> You mean orgtbl-to-tsv and related? All of that *is* part of Org mode. All
> you have to do is write a code block calling it
> to convert.
>
> --
> Nick
>
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
>
>
>

Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

[Carsten Dominik]

Strange.  I did pull and compile, to no avail.

I will check.

Carsten

On Mon, May 11, 2020 at 4:27 PM Kyle Meyer  wrote:

> Carsten Dominik writes:
>
> > I just tried to archive something and hit again the issue that
> > org-get-outline-paths undefined.  Is there a specific holdup why this
> > function has not been moved back into org.el?
>
> org-get-outline-path was moved back to org.el in 3c3194113 (2020-04-26).
>
>   % git rev-parse master
>   20c13221942183290dc440ca6ba91597f243b9e7
>   % git grep 'defun org-get-outline-path' master
>   master:lisp/org.el:(defun org-get-outline-path ( with-self
> use-cache)
>

Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

[Carsten Dominik]

Hi everyone,

I just tried to archive something and hit again the issue that
org-get-outline-paths undefined.  Is there a specific holdup why this
function has not been moved back into org.el?

Thanks

Carsten


On Thu, Feb 27, 2020 at 3:02 PM Kaushal Modi  wrote:

> Hello,
>
> I recently updated to the latest org-mode master and it is failing
> ox-hugo[1] build and tests at 2 places.
>
> Failure 1: org-get-outline-path has moved, and not mentioned in ORG-NEWS
>
> Compiling ox-hugo.el now gives:
>
> ox-hugo.el:4284:1: Warning: the function ‘org-get-outline-path’ is not
> known to be defined.
>
> I see that defun has now moved to org-refile.el. I see that
> org-get-outline-path has nothing to do specific to refiling. Can that be
> moved back to org.el, or may be a separate library? Otherwise, ox-hugo.el
> will have to load org-refile.el too (yes, I don't use org-refile (yet), and
> that's how I discovered this :))
>
> Failure 2: Change in parsing of org babel header arguments.
>
> This was caught by my weekly Travis CI cron jobs for ox-hugo:
> https://travis-ci.org/kaushalmodi/ox-hugo/jobs/655410731#L2426
>
> 26c26
> < {{< highlight emacs-lisp "hl_lines=1" >}}
> ---
> > {{< highlight emacs-lisp "hl_lines=1 3-5" >}}
>
> Earlier this kind of src block header:
>
> #+begin_src emacs-lisp :hl_lines 1,3-5
> ...
> #+end_src
>
> got exported as
>
> {{< highlight emacs-lisp "hl_lines=1 3-5" >}}
>
> The regression is that now it is getting exported as
>
> {{< highlight emacs-lisp "hl_lines=1" >}}
>
> The values that I have after the comma in ":hl_lines 1,3-5" are getting
> lost.
>
> The relevant snippet where I parse the header arguments in ox-hugo.el is
> at
> https://github.com/kaushalmodi/ox-hugo/blob/f8ec4aa5ad7d92f94bd8dbb814d85f980be67aea/ox-hugo.el#L2563
>
> This behavior change in org-babel-parse-header-arguments is also not
> documented in ORG-NEWS. I will now investigate what cause this regression.
>
> ...
>
> --
> Kaushal Modi
>
> [1]: https://github.com/kaushalmodi/ox-hugo
>

Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

[Carsten Dominik]

On Fri, Feb 28, 2020 at 1:04 AM Adam Porter  wrote:

> Kaushal Modi  writes:
>
> > Failure 1: org-get-outline-path has moved, and not mentioned in ORG-NEWS
> >
> > Compiling ox-hugo.el now gives:
> >
> > ox-hugo.el:4284:1: Warning: the function ‘org-get-outline-path’ is not
> known to be defined.
> >
> > I see that defun has now moved to org-refile.el. I see that
> > org-get-outline-path has nothing to do specific to refiling. Can that
> > be moved back to org.el, or may be a separate library? Otherwise,
> > ox-hugo.el will have to load org-refile.el too (yes, I don't use
> > org-refile (yet), and that's how I discovered this :))
>
> Yes, please move that function back.  This is going to cause breakage in
> a variety of packages that use that function but do not load
> org-refile.  I can hear the bug reports rumbling already...  ;)
>

I support this. getting the outline path has more general applications that
just refiling, so tugging it away into org-refile does not make sense.

- Carsten

Re: $LR in Table Formula

[Carsten Dominik]

On Sat, Apr 18, 2020 at 10:33 PM Marco Wahl  wrote:

> Carsten Dominik  writes:
>
> > This was an old way to refer to fields in the last row.  It was already
> > deprecated in 2011.  I also does not seem to work anymore.
> >
> > I had forgotten all about it and only found it back with
> >
> > git log -S \$LR --source --all | less
> >
> > which pointed me to commit 8237c9ae6d587a22646333e0315683675e2db538
>
> Thanks for the eludication!
>
> If the Org code shall iterate towards clarity then the question would be
> resurrection or elimination of the Last Row (LR) feature AFAICS.
>

Elimination should be fine in this case since it does not work anymore
anyway.

Carsen


>
>
> My 2 ct,
> -- Marco
>

Re: $LR in Table Formula

[Carsten Dominik]

This was an old way to refer to fields in the last row.  It was already
deprecated in 2011.  I also does not seem to work anymore.

I had forgotten all about it and only found it back with

git log -S \$LR --source --all | less

which pointed me to commit 8237c9ae6d587a22646333e0315683675e2db538

Carsten

On Sat, Apr 18, 2020 at 1:56 PM Eric S Fraga  wrote:

> Ignore my previous email/post.  I was obviously under the influence.  I
> see the LR references in the code.
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-492-gc990d4
>
>

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/)]

[Carsten Dominik]

Hi Marco,

thank you for the reply.  For the record, I am in favor of the old
workings, as described by Eric.  It is more consistent in several ways.

Carsten

On Wed, Apr 1, 2020 at 7:52 PM Marco Wahl  wrote:

> Hi Carsten,
>
> > I just pulled the lates master, and I think the creation of a new column
> > has not been set back to the way it used to be, even though Nicolas
> agreed
> > to do so.  Am I missing something?
>
> As I understood, we practice some patience now to see if someone votes
> for keeping the current behavior.  And then act according to the
> discussion (or non-discussion.)
>
>
> Best regards,
> -- Marco
>

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/)]

[Carsten Dominik]

Hi,

I just pulled the lates master, and I think the creation of a new column
has not been set back to the way it used to be, even though Nicolas agreed
to do so.  Am I missing something?

Thanks.

Carsten

On Tue, Mar 31, 2020 at 10:10 PM Nicolas Goaziou 
wrote:

> 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: Org mode for meeting minutes

[Carsten Dominik]

Hi Christian,

very useful blog post indeed, thank you.

Thanks for finding the :match parameter and for pointing out that it is not
documented in the manual.

I have fixed that in org-manual.org.

Carsten

- Carsten

On Mon, Mar 23, 2020 at 10:37 AM Christian Egli 
wrote:

> Hi all
>
> I'm picking up this thread again since I think I have solved the issue
> for myself. I do use org-mode for meeting minutes now. Thanks to the
> input from this list I managed to solve the outstanding issues such as
> tabular reports of action items.
>
> I wrote a blog post summarizing my findings which you can find here
> https://egli.dev/posts/using-org-mode-for-meeting-minutes/
>
> Hope that helps
> Christian
>
> "Fraga, Eric"  writes:
>
> > On Thursday, 31 Oct 2019 at 15:03, Christian Egli wrote:
> >> His mail is from 2008 and a lot has happened in the mean time.
> >
> > Although a lot has happened in the meantime, I've not seen anything pass
> > by which addresses minutes of meetings and tracking actions.  I used to
> > use org to take minutes but haven't done so in a very long time
> > (advantage of having somebody else do it for me now ;-)).  What you've
> > done with an active dblock (and TODO states being the names of people!)
> > looks good and should definitely be put on Worg at the very least.
>
> --
> Christian Egli
> Swiss Library for the Blind, Visually Impaired and Print Disabled
> Grubenstrasse 12, CH-8045 Zürich, Switzerland
>
>
>

Re: Can Org Mode tag support dash character "-"?

[Carsten Dominik]

On Fri, Mar 13, 2020 at 3:08 PM stardiviner  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> I found Org Mode tags does not support tag like "COVID-9", The dash
> character "-" is not supported.


> Can Org Mode support the dash char because it is very often used.
>

This is not a good idea, because searches can be built with +tag and -tag .

Use COVID9 or COVID_9 instead.

Carsten


>
> - --
> [ stardiviner ]
>I try to make every word tell the meaning what I want to express.
>
>Blog: https://stardiviner.github.io/
>IRC(freenode): stardiviner, Matrix: stardiviner
>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>
> -BEGIN PGP SIGNATURE-
>
> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5rkPsUHG51bWJjaGls
> ZEBnbWFpbC5jb20ACgkQG13xyVromsNJpggAkpjsjbLKi/qF+MroVNyQRxRjC51v
> SEgU45CWgrNnusgO6m53btRKemcAwsvQEWiqecAXxDpozReRXECyUQSTRGlqwmG/
> cHSArejGF8zr3kvC/Md7Ay+azFA9/h7Tc7PDW/BVerouXLIJ2dfMQjut406oWq43
> vuxAqzzHgiZ1PQCuYDvBq6Z4YqcPecER0cVHOFvbRgG9ZxM1VwN3AmMr/4T4U39v
> FACnWfpo77nVYydhWUc8Cgi6+oUHSe6lUYAPgVTDuppXqi9rFfMQ8OgEP9Cw014/
> PHGPgHsV7fOV7zHmMpY9bci/bPEL14PJ8ZjTQ31NCELOXWddtGg9PdlD9g==
> =Mrnk
> -END PGP SIGNATURE-
>
>

Re: [O] org-fast-todo-selection window behaviour?

[Carsten Dominik]

Hi Matt,

:)

Have you tried

(setq org-use-fast-todo-selection 'expert)

It is the least jarring implementation, and it is the setting I use.

Carsten

On Wed, Oct 23, 2019 at 8:10 PM Matt Price  wrote:

> Ah well. I find the new way jarring, but it doesn't seem to bother anyone
> else, and as it's a one-line (2 character!) change for me I think I can
> carry the diff in my init file for now. In any case it's a small issue I
> think.An honour to find myself in disagreement with the org-founder!
>
> On Mon, Oct 21, 2019 at 5:47 AM Carsten Dominik  wrote:
>
>> Hi Matt,
>>
>> I made this change, because I found the previous way jarring.  The window
>> with the selection information showed up in different places depending on
>> what the current window setup is. With the new implementation, the info
>> window is always in the same predictable place.  After the selection is
>> done, the old window setup is restored to exactly what it was
>>
>> Carsten
>>
>> On Sun, Oct 20, 2019 at 8:46 PM Matt Price  wrote:
>>
>>> I've recently noticed a slightly frustrating behavour on the part of
>>> org-todo that I think is new and maybe was introduced in mid-August with
>>>
>>> f1c030bed54737319aeb1d592e3340d6a48cea3a
>>>
>>> In a split frame,calling org-todo with org-use-fast-todo-selection
>>> enabled, ~C-c C-t~ now calls ~delete-other-windows~ before popping up the
>>> org-todo keywords window.  Is this necessary? I find this behaviour
>>> visually confusing and distracting, and a slowdown to my workflow.  Would
>>> it make sense to introduce some kind of defcustom for this? For now I'm
>>> just commenting out line 10614 of org.el, but if others want to be able to
>>> customize the behaviour I will submit a patch.
>>>
>>> Maybe there's a reason delete-other-window is necessary, but i don't see
>>> it in the commit message nor immediately in the other parts of this
>>> otherwise very well-documented commit
>>>
>>> Thanks!
>>>
>>>

Re: [O] org-fast-todo-selection window behaviour?

[Carsten Dominik]

Hi Matt,

I made this change, because I found the previous way jarring.  The window
with the selection information showed up in different places depending on
what the current window setup is. With the new implementation, the info
window is always in the same predictable place.  After the selection is
done, the old window setup is restored to exactly what it was

Carsten

On Sun, Oct 20, 2019 at 8:46 PM Matt Price  wrote:

> I've recently noticed a slightly frustrating behavour on the part of
> org-todo that I think is new and maybe was introduced in mid-August with
>
> f1c030bed54737319aeb1d592e3340d6a48cea3a
>
> In a split frame,calling org-todo with org-use-fast-todo-selection
> enabled, ~C-c C-t~ now calls ~delete-other-windows~ before popping up the
> org-todo keywords window.  Is this necessary? I find this behaviour
> visually confusing and distracting, and a slowdown to my workflow.  Would
> it make sense to introduce some kind of defcustom for this? For now I'm
> just commenting out line 10614 of org.el, but if others want to be able to
> customize the behaviour I will submit a patch.
>
> Maybe there's a reason delete-other-window is necessary, but i don't see
> it in the commit message nor immediately in the other parts of this
> otherwise very well-documented commit
>
> Thanks!
>
>

Re: [O] BUG? Extra colon for inherited tags in agenda

[Carsten Dominik]

Hi David

On Sat, Sep 7, 2019 at 1:14 AM David Masterson 
wrote:

> Carsten Dominik  writes:
>
> > On Thu, Sep 5, 2019, 00:45 David Masterson 
> wrote:
>
> >>  I see that, for tags picked up via inheritance from parent headlines,
> >>  when the tags are produced in the agenda, the current agenda item will
> >>  have an extra colon after the inherited tags.  Is this by design?
>
> > Yes, it is by design, for display in the agenda only, to show the
> > difference between direct and inherited tags.
> >
> > Why would. You want to change it?
>
> Maybe not. Didn't remember seeing it in the documentation, so, at first,
> I thought it might be a bug, but it made sense after I thought about it.
> As to in the agenda only, I could also see this being something that
> export backend might want access to (if it doen't already have access
> to it).  Other than that, it's good.
>

Yes, if an export backend wanted to show inherited tags at entries, the
same syntax could be used.  I don't know if any backend is trying to show
inherited tags.

In the Agenda this is necessary because entries are shown outside of their
normal hierarchy.  In an Org buffer, or in an exported version of it, the
original hierarchy is still in place.

Cheers

Carsten


> --
> David
>

Re: [O] Bug? SCHEDULED lines treated differently when text precedes them

[Carsten Dominik]

On Thu, Sep 5, 2019 at 3:38 PM Christoph Groth 
wrote:

> Nicolas Goaziou wrote:
>
> > Planning information (SCHEDULED, DEADLINE and CLOSED keywords) must
> > appear right after the headline, per Org syntax. This is specified at
> > the first paragraph in (info "(org) Deadlines and Scheduling").
> >
> > Elswhere, only the timestamp is meaningful to Org.
>
> Thanks for the quick clarification!  I didn't see the relevant line in
> the documentation since my Emacs from Debian shows only the info
> documentation for the (outdated) Org that is bundled with Emacs [1].
>

This is, in fact, one of the very few things that did change with the
introduction of org-elements.el and the fore formal parsing of Org files.
Originally, SCHEDULED and DEADLINE could be anywhere in the entry.  But
with the development of the parser, and (I think) in order to define
everything well in particular also for the export backends, the planning
information was confined to the first line.

I don't think you need to be worried about more surprises, this was the
most significant one IIRC.

Carsten


>
> I understand now that Org does what it should.  However, I find this
> behavior quite dangerous.  It caught me after more than 10 years of
> using Org.  If there's a list of long-term issues with Org somewhere,
> this problem may deserve being added to it.
>
> Cheers
> Christoph
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725408
>
>

Re: [O] BUG? Extra colon for inherited tags in agenda

[Carsten Dominik]

Hi,




On Thu, Sep 5, 2019, 00:45 David Masterson  wrote:

> I see that, for tags picked up via inheritance from parent headlines,
> when the tags are produced in the agenda, the current agenda item will
> have an extra colon after the inherited tags.  Is this by design?


Yes, it is by design, for display in the agenda only, to show the
difference between direct and inherited tags.

Why would. You want to change it?

Carsten


Can
> that be controlled?
>
> Example Parent  :tag1:
> Example child of Parent :tag1::
> --
> David
>
>

Re: [O] org-id fixups and minor changes

[Carsten Dominik]

On Sun, Sep 1, 2019, 08:49 Stig Brautaset  wrote:

> Hi Gustav,
>
> Gustav Wikström  writes:
> > [...] I also wonder how common it will be to try to batch-add ID’s…?
>
> Not especially uncommon, I think.  Both the org-rss and org-drill
> packages batch-add IDs on first use.
>

And even if that would be uncomment - at least the defaults need to be
safe.

Carsten


> Regards,
> Stig
>

Re: [O] Insert subheading at top respect content

[Carsten Dominik]

You are welcome. Good to hear that you have a good solution now.

Carsten



On Thu, Aug 22, 2019 at 9:14 PM Nathan Neff  wrote:

>
>
> On Wed, Aug 21, 2019 at 12:28 AM Carsten Dominik  wrote:
>
>> Hi Nate,
>>
>> What do you mean by passing "the right argument".  Which argument do you
>> want to pass?
>>
>
> I mean the hard-coded 1 on org-next-visible-heading.
>
>
>>
>> At first, I thought the direct way to fix your function would be
>>
>> (defun njn-subheading-respect-content ()
>>   (interactive "")
>>   (org-next-visible-heading 1)
>>   (org-insert-heading nil)
>>  )
>>
>> because in your original example, the heading did already have a child.
>> However, that is not guaranteed, and in the above implementation, the
>> new heading is created with the level of the next headline, and that
>> next headline might be a sibling, a child or a parent.  So we need to
>> explicitly set the level:
>>
>> (defun njn-subheading-respect-content ()
>>   (interactive "")
>>   (let ((level (car (org-heading-components
>> (org-next-visible-heading 1)
>> (org-insert-heading nil)
>> (while (<= (car (org-heading-components)) level)
>>   (org-demote
>>
>> I am using (possibly repeated) calls to `org-demote', because this will
>> do everything correct, also with stuff like org-odd-levels only etc.
>>
>>
> Cool!  I tried the above solution and made some modifications:
>
> (defun njn-subheading-respect-content ()
>   (interactive "")
>   (org-show-children)
>   (let
> ((level (car (org-heading-components)))
>   )
> (outline-next-heading)
> (org-insert-heading)
> (while (<= (car (org-heading-components)) level)
>   (org-demote))
>   ))
>
>
> I added (org-show-children) to work when cursor is on a folded heading.
>
> I removed the 1 argument to org-next-visible-heading
>
> This appears to do what I want - thanks for the help!
>
>
>
>
>> Hope this helps.
>>
>> - Carsten
>>
>>
>>
>>
>>
>> On Wed, Aug 21, 2019 at 12:43 AM Nathan Neff 
>> wrote:
>>
>>>
>>>
>>> On Fri, Aug 16, 2019 at 4:03 AM Carsten Dominik  wrote:
>>>
>>>>
>>>>
>>>> On Fri, Aug 16, 2019 at 10:21 AM Nathan Neff 
>>>> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> Something that's eluded me all this time has been an
>>>>> "Insert subheading, after the content, but before other subheadings"
>>>>>
>>>>> For example:
>>>>> If my cursor is anywhere between lines 1 and 4, I would like the
>>>>> subheading
>>>>> to be inserted at line 5.
>>>>>
>>>>> 1* Heading
>>>>> :PROPERTIES:...
>>>>> 2 Some content
>>>>> 3 More content
>>>>> 4
>>>>> 5** Subheading 1
>>>>> 6** Subheading 2
>>>>> 7
>>>>> I know there's org-insert-subheading and C-u which respects content,
>>>>> but
>>>>> respect-content will insert a subheading at line 7 in the example
>>>>> above.  I would
>>>>> like to have a new subheading at line 4.
>>>>>
>>>>
>>>> What about C-c C-n M-RET
>>>>
>>>
>>> Thanks Carsten - I created a function:
>>> (defun njn-subheading-respect-content ()
>>>   (interactive "")
>>>   (org-next-visible-heading 1)
>>>   (org-insert-subheading 't)
>>>  )
>>>
>>> But I'm trying to find out where to get the "correct" arg
>>> to org-next-visible-heading - I have hard-coded a 1 in the
>>> above example, but this produces the following subheading:
>>>
>>> * Heading <-exec when cursor on this heading
>>> Some content about Heading
>>> *** New heading is inserted here (and is the wrong level - should be 2
>>> instead of 3)
>>> ** Sub1
>>> ** Sub2
>>>
>>> I will mess with this function a bit and post if I find a solution.
>>>
>>> Thanks,
>>> --Nate
>>>
>>>>
>>>> Carsten
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> --Nate
>>>>>
>>>>

Re: [O] Insert subheading at top respect content

[Carsten Dominik]

Hi Nate,

What do you mean by passing "the right argument".  Which argument do you
want to pass?

At first, I thought the direct way to fix your function would be

(defun njn-subheading-respect-content ()
  (interactive "")
  (org-next-visible-heading 1)
  (org-insert-heading nil)
 )

because in your original example, the heading did already have a child.
However, that is not guaranteed, and in the above implementation, the
new heading is created with the level of the next headline, and that
next headline might be a sibling, a child or a parent.  So we need to
explicitly set the level:

(defun njn-subheading-respect-content ()
  (interactive "")
  (let ((level (car (org-heading-components
(org-next-visible-heading 1)
(org-insert-heading nil)
(while (<= (car (org-heading-components)) level)
  (org-demote

I am using (possibly repeated) calls to `org-demote', because this will
do everything correct, also with stuff like org-odd-levels only etc.

Hope this helps.

- Carsten





On Wed, Aug 21, 2019 at 12:43 AM Nathan Neff  wrote:

>
>
> On Fri, Aug 16, 2019 at 4:03 AM Carsten Dominik  wrote:
>
>>
>>
>> On Fri, Aug 16, 2019 at 10:21 AM Nathan Neff 
>> wrote:
>>
>>> Hello all,
>>>
>>> Something that's eluded me all this time has been an
>>> "Insert subheading, after the content, but before other subheadings"
>>>
>>> For example:
>>> If my cursor is anywhere between lines 1 and 4, I would like the
>>> subheading
>>> to be inserted at line 5.
>>>
>>> 1* Heading
>>> :PROPERTIES:...
>>> 2 Some content
>>> 3 More content
>>> 4
>>> 5** Subheading 1
>>> 6** Subheading 2
>>> 7
>>> I know there's org-insert-subheading and C-u which respects content, but
>>> respect-content will insert a subheading at line 7 in the example
>>> above.  I would
>>> like to have a new subheading at line 4.
>>>
>>
>> What about C-c C-n M-RET
>>
>
> Thanks Carsten - I created a function:
> (defun njn-subheading-respect-content ()
>   (interactive "")
>   (org-next-visible-heading 1)
>   (org-insert-subheading 't)
>  )
>
> But I'm trying to find out where to get the "correct" arg
> to org-next-visible-heading - I have hard-coded a 1 in the
> above example, but this produces the following subheading:
>
> * Heading <-exec when cursor on this heading
> Some content about Heading
> *** New heading is inserted here (and is the wrong level - should be 2
> instead of 3)
> ** Sub1
> ** Sub2
>
> I will mess with this function a bit and post if I find a solution.
>
> Thanks,
> --Nate
>
>>
>> Carsten
>>
>>
>>>
>>> Thanks,
>>> --Nate
>>>
>>

[O] MobileOrg and other tools

[Carsten Dominik]

Hi,

does anyone know if the MobileOrg apps for both iOS and Android are still
supported, and by who?

I know that Orgzly is actively supported and in excellent shape.  But I
don't know about MobileOrg or Syncorg for that matter, or any other similar
tools.

Does anyone have an overview over all these implementations and their
status?

Thanks.

Carsten

Re: [O] NLS/Augment

[Carsten Dominik]

On Fri, Aug 16, 2019 at 4:59 PM Jean Louis  wrote:

> * Samuel Wales  [2019-08-14 21:57]:
> > org-mouse works well for me and i depend on it frequently.
> >
> > the main thing i am missing in it is the ability to select a todo kw
> > for a header.
> >
> > i use require.  i never understood modules or their purpose.
>

Yes, not sure if modules was a good idea.  I wanted a clickable list of
stuff
 to add, because the parts became so many.  Require is a fine replacement.


> I would like to know if Carsten Dominik came up with idea by knowing
> about Doug Engelbart?
>

Do you mean with Org-mode in general?  No, I learned about Engelbart later
and was amazed.

Carsten

>
> Jean
>
>

Re: [O] Bug: Description of org agenda columns format in manual not correct/misleading

[Carsten Dominik]

It is already in the git master branch.

Carsten

On Fri, Aug 16, 2019 at 1:46 PM Andrew Francis Swann 
wrote:

> Dear Carsten,
>
>
>
> This sounds like a very good solution.  I look forward to it being
> implemented.
>
>
>
> Andrew
>
>
>
> --
>
> Andrew Swann | Associate Professor | Tel +45 871 55767 | sw...@math.au.dk |
> http://home.math.au.dk/swann/ | Department of Mathematics, Aarhus
> University, Ny Munkegade 118, Bldg 1530, DK-8000 Aarhus C, Denmark | Dept
> +45 871 5 | Fax +45 8613 1769
>
>
>
>
>
> *From: *Emacs-orgmode  on
> behalf of Carsten Dominik 
> *Date: *Friday, 16 August 2019 at 10:19
> *To: *"Fraga, Eric" 
> *Cc: *Nick Dokos , Org mode 
> *Subject: *Re: [O] Bug: Description of org agenda columns format in
> manual not correct/misleading
>
>
>
> Hi,
>
>
>
> On Thu, Aug 15, 2019 at 9:50 AM Fraga, Eric  wrote:
>
> On Wednesday, 14 Aug 2019 at 15:57, Nick Dokos wrote:
> > "Fraga, Eric"  writes:
> >
> >> I have this setting in my Emacs initialization:
> >>
> >> (setq org-agenda-overriding-columns-format "%5TODO %TIMESTAMP %40ITEM
> %LOCATION %TAGS")
> >>
> >> HTH,
> >> eric
> >
> > Shouldn't you be using org-columns-default-format instead?
>
> No because it's about setting the columns format for the agenda view
> alone, not the format for normal org buffers.  My error was in using a
> deprecated variable; the actual variable is
> org-overriding-columns-format.
>
> The OP's post was actually about the documentation (which I
> misunderstood).
>
>
>
> I have discussed this problem with Allen Li, who fixed a bug in the agenda
> column setting a while ago.
>
>
>
> I think what is missing to make this more transparent is a variable
> `org-default-columns-format-for-agenda' which is a proper user option.
> This option can be set in your init.el or through customize, and it will
> provide a default format for the agenda.  `org-overriding-columns-format
> should ONLY EVER be used in the local setting section of a custom agenda
> view.
>
>
>
> This new variable is not available in master.
>
>
>
> - Carsten
>

Re: [O] Insert subheading at top respect content

[Carsten Dominik]

On Fri, Aug 16, 2019 at 10:21 AM Nathan Neff  wrote:

> Hello all,
>
> Something that's eluded me all this time has been an
> "Insert subheading, after the content, but before other subheadings"
>
> For example:
> If my cursor is anywhere between lines 1 and 4, I would like the subheading
> to be inserted at line 5.
>
> 1* Heading
> :PROPERTIES:...
> 2 Some content
> 3 More content
> 4
> 5** Subheading 1
> 6** Subheading 2
> 7
> I know there's org-insert-subheading and C-u which respects content, but
> respect-content will insert a subheading at line 7 in the example above.
> I would
> like to have a new subheading at line 4.
>

What about C-c C-n M-RET

Carsten


>
> Thanks,
> --Nate
>

Re: [O] Bug: Description of org agenda columns format in manual not correct/misleading

[Carsten Dominik]

Hi,

On Thu, Aug 15, 2019 at 9:50 AM Fraga, Eric  wrote:

> On Wednesday, 14 Aug 2019 at 15:57, Nick Dokos wrote:
> > "Fraga, Eric"  writes:
> >
> >> I have this setting in my Emacs initialization:
> >>
> >> (setq org-agenda-overriding-columns-format "%5TODO %TIMESTAMP %40ITEM
> %LOCATION %TAGS")
> >>
> >> HTH,
> >> eric
> >
> > Shouldn't you be using org-columns-default-format instead?
>
> No because it's about setting the columns format for the agenda view
> alone, not the format for normal org buffers.  My error was in using a
> deprecated variable; the actual variable is
> org-overriding-columns-format.
>
> The OP's post was actually about the documentation (which I
> misunderstood).
>

I have discussed this problem with Allen Li, who fixed a bug in the agenda
column setting a while ago.

I think what is missing to make this more transparent is a variable
`org-default-columns-format-for-agenda' which is a proper user option.
This option can be set in your init.el or through customize, and it will
provide a default format for the agenda.  `org-overriding-columns-format
should ONLY EVER be used in the local setting section of a custom agenda
view.

This new variable is not available in master.

- Carsten

Re: [O] RFC: changes to the way prefix arguments work for the command org-todo

[Carsten Dominik]

I have pushed these changes now.

Carsten

On Tue, Aug 13, 2019 at 10:24 AM Carsten Dominik  wrote:

> Hi,
>
> I have been looking at the code for the command org-todo in combination
> with the setting of the variable org-use-fast-todo-selection.  And I am
> frustrated with the complication and special cases, so I would like to
> simplify.  Much of this complication stems from a time when the fast
> selection interface had just been implemented and I was not yet sure if I
> and others wanted to use it. I think things can be better.
>
> But that does changes something with the user interface, so I am trying to
> figure out if anyone would be bothered by this change.
>
> 1. Right now, you can set org-use-fast-todo-selection to `prefix'.  With
> this setting, fast todo keyword selection is used when you call org-todo
> with a prefix argument.  I think this is not useful and I would like to
> remove that functionality.  Is anyone even aware of this effect of C-u and
> is using this?
>
> 2. I want to change org-use-fast-todo-selection to allow these values:
>- nilNever use it
>- autoUse it, if keys have been defined.  This would make it
> similar
>  to the tags selection.  I would accept the value `t' to
> mean the same,
>  for backward compatibility
>- expert  Use it, but do not pop up the window with the selections,
> only show them in the prompt (or don't show them at all,  am still
> considering).  This is because I have been bothered by the jumping windows
> when I do a selection that I do so many times a day, and where I know the
> keys blindly.
>
> The default setting would be `auto'.  I myself would be using `expert'.
>
> 3. I want to make `C-u C-c C-t' to switch the TODO state and force logging
> a time stamp and taking a note.  I am already using that functionality (now
> harder to access, on `C-u C-u C-u C-c C-t'), I find it very natural and I
> think it is often better than configuring automatic note-taking for every
> change, at least for my working environment.  Automatic note-taking slows
> me down too often.
>
> Any comments?
>
> Thanks
>
> - Carsten
>
>
>
>

[O] RFC: changes to the way prefix arguments work for the command org-todo

[Carsten Dominik]

Hi,

I have been looking at the code for the command org-todo in combination
with the setting of the variable org-use-fast-todo-selection.  And I am
frustrated with the complication and special cases, so I would like to
simplify.  Much of this complication stems from a time when the fast
selection interface had just been implemented and I was not yet sure if I
and others wanted to use it. I think things can be better.

But that does changes something with the user interface, so I am trying to
figure out if anyone would be bothered by this change.

1. Right now, you can set org-use-fast-todo-selection to `prefix'.  With
this setting, fast todo keyword selection is used when you call org-todo
with a prefix argument.  I think this is not useful and I would like to
remove that functionality.  Is anyone even aware of this effect of C-u and
is using this?

2. I want to change org-use-fast-todo-selection to allow these values:
   - nilNever use it
   - autoUse it, if keys have been defined.  This would make it similar
 to the tags selection.  I would accept the value `t' to
mean the same,
 for backward compatibility
   - expert  Use it, but do not pop up the window with the selections, only
show them in the prompt (or don't show them at all,  am still
considering).  This is because I have been bothered by the jumping windows
when I do a selection that I do so many times a day, and where I know the
keys blindly.

The default setting would be `auto'.  I myself would be using `expert'.

3. I want to make `C-u C-c C-t' to switch the TODO state and force logging
a time stamp and taking a note.  I am already using that functionality (now
harder to access, on `C-u C-u C-u C-c C-t'), I find it very natural and I
think it is often better than configuring automatic note-taking for every
change, at least for my working environment.  Automatic note-taking slows
me down too often.

Any comments?

Thanks

- Carsten

Re: [O] Bug: Org agenda category max length raise error [9.2.5 (9.2.5-1-gff6508-elpaplus @ /home/edo/.emacs.d/elpa/org-plus-contrib-20190805/)]

[Carsten Dominik]

Fixed, thank you.

Carsten

On Sun, Aug 11, 2019 at 4:50 PM Héctor Enríquez Ramón 
wrote:

> --text follows this line--
>
> Hi.
>
>
> * Issue:
>
> 1. Use max length format %., example
>
> (setq org-agenda-prefix-format
>   '((agenda . " %i %-4.4 c%?-12t% s")  ;; (agenda . " %i %-12:c%?-12t%
> s")
> (timeline . "  % s")
> (todo . " %i %-4.4 c%?-12t% s");; (todo . " %i %-12:c")
> (tags . " %i %-4.4 c") ;; (tags . " %i %-12:c")
> (search . " %i %-4.4 c"))  ;; (search . " %i %-12:c"))
>
> 2. Open an org file.
>
> 3. Typing C-c a a (for example) raise:
>
>org-compile-prefix-format: Args out of range: "-4.4", 4, 11
>
>
> * How to fix it:
>
> org-agenda.el: (see comments ;; + line added, ;; - line removed)
>
>   (when (eq var 'category)
> (setq org-prefix-category-length
>   (floor (abs (string-to-number (match-string 2 s)
> (setq org-prefix-category-max-length
>   (let ((x (match-string 2 s)))
> (save-match-data
>;; +
>   (when (string-match "\\.[0-9]+" x)
> (string-to-number (substring (match-string 0 x)
> 1)))  ;; +
> ;; (when (string-match-p "\\.[0-9]+" x)
> ;; -
> ;;   (string-to-number (substring (match-string 0 x)
> 1))  ;; -
>   (if (eq var 'eval)
>   (setq varform `(format ,f (org-eval ,(read (match-string 4
> s)
>
>
>
> Best regards. Hector
>
> Emacs  : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw
> scroll bars)
>  of 2019-04-13
> Package: Org mode version 9.2.5 (9.2.5-1-gff6508-elpaplus @
> /home/edo/.emacs.d/elpa/org-plus-contrib-20190805/)
>

Re: [O] Bug: Org agenda category max length raise error [9.2.5 (9.2.5-1-gff6508-elpaplus @ /home/edo/.emacs.d/elpa/org-plus-contrib-20190805/)]

[Carsten Dominik]

Hi Hector,

you fix does not work, because it changes the match data, which is still
needed further down.  Could you please try the attached patch and report
back?

Thank you

Carsten



On Sun, Aug 11, 2019 at 4:50 PM Héctor Enríquez Ramón 
wrote:

> --text follows this line--
>
> Hi.
>
>
> * Issue:
>
> 1. Use max length format %., example
>
> (setq org-agenda-prefix-format
>   '((agenda . " %i %-4.4 c%?-12t% s")  ;; (agenda . " %i %-12:c%?-12t%
> s")
> (timeline . "  % s")
> (todo . " %i %-4.4 c%?-12t% s");; (todo . " %i %-12:c")
> (tags . " %i %-4.4 c") ;; (tags . " %i %-12:c")
> (search . " %i %-4.4 c"))  ;; (search . " %i %-12:c"))
>
> 2. Open an org file.
>
> 3. Typing C-c a a (for example) raise:
>
>org-compile-prefix-format: Args out of range: "-4.4", 4, 11
>
>
> * How to fix it:
>
> org-agenda.el: (see comments ;; + line added, ;; - line removed)
>
>   (when (eq var 'category)
> (setq org-prefix-category-length
>   (floor (abs (string-to-number (match-string 2 s)
> (setq org-prefix-category-max-length
>   (let ((x (match-string 2 s)))
> (save-match-data
>;; +
>   (when (string-match "\\.[0-9]+" x)
> (string-to-number (substring (match-string 0 x)
> 1)))  ;; +
> ;; (when (string-match-p "\\.[0-9]+" x)
> ;; -
> ;;   (string-to-number (substring (match-string 0 x)
> 1))  ;; -
>   (if (eq var 'eval)
>   (setq varform `(format ,f (org-eval ,(read (match-string 4
> s)
>
>
>
> Best regards. Hector
>
> Emacs  : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw
> scroll bars)
>  of 2019-04-13
> Package: Org mode version 9.2.5 (9.2.5-1-gff6508-elpaplus @
> /home/edo/.emacs.d/elpa/org-plus-contrib-20190805/)
>


patch
Description: Binary data

Re: [O] org-todo & empty title -> misaligned tags

[Carsten Dominik]

Fixed, thank you for the report.

Carsten

On Sun, Aug 11, 2019 at 1:27 PM Dmitrii Korobeinikov 
wrote:

>Reproduction steps (tested w/ emacs -Q):
>Version: GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.8) of 2019-04-13
>
>1. M-x org-mode
>2. (insert "* ")
>3. M-x org-set-tags-command, enter any tag name
>4. M-x org-todo
>
>The tag jumps right next to the asterisk (expected: stays where it is).
> Doesn't happen if the title is not empty.
>
>5. M-x org-set-tags-command resets the tags back where they belong
>
>I think it's a bug.
>

[O] Fontification of block delimiting lines

[Carsten Dominik]

Hi,

upon request from Emacs developers, it is now configurable if org-mode
fortifies the block delimiting lines #+begin... and #+end... up and
including the final newline or not.  This is something you will only notice
when you have a font for this using a background color or an
over/underline.  This can cause problems with the Emacs display engine,
apparently.

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36858

  related:
https://lists.gnu.org/archive/html/emacs-devel/2019-08/msg00132.html

There is now a new variable `org-fontify-whole-block-delimiter-line',
default is t.  In the process I cleaned up the corresponding fontification
function.  Please report if with my recent commit any fontification issues
or errors start to appear.

Thank you.

Carsten

Re: [O] table, calc, reorder and protect calculation in one cell

[Carsten Dominik]

On Mon, Jun 17, 2019 at 11:08 PM Uwe Brauer  wrote:

> >>> "MB" == Michael Brand  writes:
>
> > Hi Uwe
> > On Tue, Jun 11, 2019 at 11:36 AM Uwe Brauer  wrote:
>
> >> Is this behavior possible? When I delete a row or a column, the  TBLFM
> >> is updated, could that be done for reordering?
>
> > You may want to use something like this, (I knew the syntax for ~"$1"~
> > and used the formula debugger ~C-c {~ to find the syntax for
> > ~"(Smith)"~):
>
> > | name   | C1 | C2 | Res |
> > |+++-|
> > | Smith  |  9 |  1 | 1.7 |
> > | Miller |  6 |  2 |   8 |
> > | Adams  |  5 |  5 |  10 |
>
> > #+TBLFM: $4 = if("$1" == "(Smith)", 0.1 * $2 + 0.8 * $3, $3 + $2)
>
> Ha, of course, thanks, why did that occur to me? I am bit surprised by
> the () in Smith, should "Smith" not be sufficient? But it is not indeed,
> how odd?
>

Indeed, this looks very weird.  It has to do with the fact that table
formulas usually deal with numbers and expressions and not with strings.
When replacing $1 in a calc formula, Org adds parenthesis to allow also
algebraic expressions in such formulas.  Consider the following case:

| 2 | 2+3 | 10 |
#+TBLFM: $3=$1*$2

This formula needs to be interpreted as 2 * (2+3).  Without the
parenthesis, it would be read as 2*2+3, which is 7, not 10.
Basically, we need to make sure that whatever is in the field is
interpreted as one entity and not ripped apart by the operator precedence
in calc.  And therefore, indeed, if you want to compare strings, you need
to add the odd-looking parenthesis inside the double quotes.

I guess we should document this.  For lisp formulas, I did document the
variable interpolation, but apparently not for calc syntax.
I will put this into the manual.

Carsten


>
> Anyhow, thanks a lot.
>
> Uwe
>

Re: [O] Bug: canceled capture operation results in demoted following heading when template ends with newline [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)

[Carsten Dominik]

Hi Gustavo,

I am also on Emacs 26.2, and I don't know where to look if I cannot
reproduce the problem.

It would be useful if someone else tries your minimal example and reports
back.

Carsten

On Sat, Aug 10, 2019 at 12:54 PM Gustavo Barros 
wrote:

> Hi Carsten,
>
> thank you for looking into this.
>
> On Sat, Aug 10 2019, Carsten Dominik wrote:
>
> > I tried to reproduce your example, and things worked properly
>
> I followed the described steps to the letter (except for the clear typo,
> where I should have written 'and cancel it with "C-c C-k"'). And the
> result is regularly the one described.
>
> I have no idea how I could further isolate things. Could
> '(package-initialize)' be of any relevance? The only purpose of it here
> is to load the most recent version of org, instead of the built-in
> one. In your experience, what could be the source of the difference here
> and there? (OS? WM?)
>
> Can anyone else reproduce?
>
> I'm at your disposal to test any other possible intervening
> factors. But, as it stands, I don't know where to look at.
>
> Best regards,
> Gustavo.
>

Re: [O] Bug: org-sort-entries does not preserve folded drawers [9.1.13 (9.1.13-dist @ /home/yantar92/.emacs.d/straight/build/org/)]

[Carsten Dominik]

Hi Ihor,

thank you for the report.
It would be too much work to *preserve* the visibility state of everything
in the sorting area, but you are right, the drawers at lease should be
closed.  I fixed this, the fix is in master.

Carsten

On Sat, Aug 3, 2019 at 8:22 AM Ihor Radchenko  wrote:

>
> org-sort-entries seems to unfold everything in the subtree even if no
> modification was done to the buffer during sorting.
>
> Steps to reproduce:
>
> Consider the following org file:
> #+begin_src org
> ,* a
> :PROPERTIES:
> :ID:   279e797c-f4a7-47bb-80f6-e72ac6f3ec55
> :END:
> :DRAWER:
> Blah
> :END:
>
> ,** test
> #+end_src
>
> 1. emacs -Q
> 2. Fold all the drawers and entries in the buffer
> 3a. Call M-x org-sort-entries p
> 3b. Call M-: (org-sort-entries nil ?p) RET
>
>
> Expected behaviour for 3a: Subtree is unfolded, all the property drawers
> are folded, buffer is unchanged
> Observed behaviour for 3a: Subtree is unfolded, all the property drawers
> are also unfolded, buffer is marked modified
>
> Expected behaviour for 3b: Subtree is folded, all the property drawers
> are folded, buffer is unchanged
> Observed behaviour for 3b: Subtree is unfolded, all the property drawers
> are also unfolded, buffer is marked modified
>
> Regards,
> Ihor
>
>
>
>
> Emacs  : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit)
>  of 2019-04-29
> Package: Org mode version 9.1.13 (9.1.13-dist @
> /home/yantar92/.emacs.d/straight/build/org/)
> --
> Ihor Radchenko,
> PhD,
> Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
> State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong
> University, Xi'an, China
> Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
>
>
>

Re: [O] Bug: canceled capture operation results in demoted following heading when template ends with newline [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)

[Carsten Dominik]

Hi Gustavo,

I tried to reproduce your example, and things worked properly

Carsten

On Sun, Jul 28, 2019 at 9:34 PM Gustavo Barros 
wrote:

> Hi all,
>
> When the capture template ends with a newline character and the capture
> process is canceled, the following heading gets demoted. And it
> shouldn’t.
>
>
> Consider the following scenario. We have an agenda file with the
> following content:
>
> #+name: ~/org/agenda.org
> #+begin_src org
> ,* Capture
>
> ,* Following heading
>
> #+end_src
>
> We start ~emacs -Q~, and do some basic setup:
>
> #+begin_src emacs-lisp
> (package-initialize)
> (global-set-key (kbd "C-c c") 'org-capture)
> (setq org-agenda-files
>   '("~/org/agenda.org"))
> (setq org-refile-targets
>   '((org-agenda-files :maxlevel . 2)))
> (setq org-capture-templates
>   '(("t" "TODO entry" entry
>  (file+headline "~/org/agenda.org" "Capture")
>  "* TODO %?\n")))
> #+end_src
>
> Now we start capture with "C-c c t" and cancel it with "C-c
> k". Examination of "agenda.org" will show:
>
> #+name: ~/org/agenda.org
> #+begin_src org
> ,* Capture
> ,** Following heading
>
> #+end_src
>
> Both the line between them is gone, and "* Following heading" got
> demoted, which is particularly unfortunate.
>
> I’m not sure that I found a general rule in this respect.  I had met
> this effect before in my workflow and vaguely associated it with a
> trailing "\n".  Investigating it further, I could find a recipe to
> reproduce the effect, as shown, but I don’t really know how general it
> is.
>
> This effect does not occur if "\n" is removed from the template, and I
> don’t know if its inclusion is to be considered bad practice,
> particularly as the capture templates already have a structure to handle
> empty lines.  But, if my memory does not betray me in this respect, one
> will find plenty of those laying around in folks configs.
>
>
> Best regards,
> Gustavo Barros.
>
>
>
> Emacs  : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.22.30)
>  of 2019-04-19
> Package: Org mode version 9.2.4 (9.2.4-11-g1c3eae-elpaplus @
> /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)
>
> current state:
> ==
> (setq
>  org-src-mode-hook '(org-src-babel-configure-edit-buffer
>  org-src-mode-configure-edit-buffer)
>  org-metadown-hook '(org-babel-pop-to-session-maybe)
>  org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
>  org-refile-targets '((org-agenda-files :maxlevel . 2))
>  org-agenda-files '("~/org/agenda.org")
>  org-mode-hook '(#[0 "\300\301\302\303\304$\207"
>[add-hook change-major-mode-hook org-show-all append
>local]
>5]
>  #[0 "\300\301\302\303\304$\207"
>[add-hook change-major-mode-hook
>org-babel-show-result-all
> append local]
>5]
>  org-babel-result-hide-spec org-babel-hide-all-hashes
>  org-eldoc-load)
>  org-archive-hook '(org-attach-archive-delete-maybe)
>  org-confirm-elisp-link-function 'yes-or-no-p
>  org-agenda-before-write-hook '(org-agenda-add-entry-text)
>  org-metaup-hook '(org-babel-load-in-session-maybe)
>  org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
>  "\n\n(fn ENTRY)"]
>  org-babel-pre-tangle-hook '(save-buffer)
>  org-tab-first-hook '(org-babel-hide-result-toggle-maybe
>   org-babel-header-arg-expand)
>  org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
>  . php)
>   ("C" . c) ("C++" . c++) ("asymptote" . asy)
>   ("bash" . sh) ("beamer" . latex) ("calc"
>   . fundamental)
>   ("cpp" . c++) ("ditaa" . artist) ("dot"
>   . fundamental)
>   ("elisp" . emacs-lisp) ("ocaml" . tuareg)
>   ("screen" . shell-script) ("shell" . sh)
>   ("sqlite" . sql))
>  org-occur-hook '(org-first-headline-recenter)
>  org-cycle-hook '(org-cycle-hide-archived-subtrees
>  org-cycle-show-empty-lines
>   org-optimize-window-after-visibility-change)
>  org-speed-command-hook '(org-speed-command-activate
>   org-babel-speed-command-activate)
>  org-confirm-shell-link-function 'yes-or-no-p
>  org-link-parameters '(("id" :follow org-id-open)
>("eww" :follow eww :store org-eww-store-link)
>("rmail" :follow org-rmail-open :store
> org-rmail-store-link)
>("mhe" :follow org-mhe-open :store
>org-mhe-store-link)
>("irc" :follow org-irc-visit :store
>org-irc-store-link
> :export org-irc-export)
>("info" :follow org-info-open :export
>org-info-export
>

Re: [O] Links to LaTeX equations

[Carsten Dominik]

On Fri, Jun 28, 2019 at 4:46 PM Fraga, Eric  wrote:

> On Friday, 28 Jun 2019 at 11:58, Ken Mankoff wrote:
> > Why don't you define the link in Org?
> >
> > #+NAME: eq:foo
> > \begin{equation}
>
> And why are the obvious solutions not those that come to mind (for
> me)
>
> Many thanks.  Nothing in the documentation to even suggest this
> possibility.  That's my excuse. :)
>

It kind-of is documented, in section 4.2.  Is that unclear?

Carsten


> --
> : Professor Eric S Fraga, http://www.homepages.ucl.ac.uk/~ucecesf
> : Required hieroglyphics follow: ∀ε>0,∃δ>0∋|x-x₀|<δ⇒|f(x)-f(x₀)|<ε
>

Re: [O] org-id fixups and minor changes

[Carsten Dominik]

Hi Gustav,

I can see that it feels more natural to use timestamps.  I certainly see
that relative file names are good for across-computer compatibility.

You system assumes, if I see that correctly (have not studied it yet), that
not more that one ID will be created per second.  Or do you have something
in place that will catch this, for example if someone uses the mapping API
to assign IDs to a whole bunch of entries in a short time?

You are right that this is not documented in the manual, even though it is
used for lings and for attachments.  Maybe it would be good to explain it
in an appendix to the manual?  Would you like to draft such a section,
since you have been looking into this problem?

Do you think the default setting for Org should be modified?

Carsten

On Fri, Aug 2, 2019 at 5:14 PM Gustav Wikström  wrote:

> Hi!
>
> I've pushed a couple of fixes and changes to master related to org-id.
>
> First; a fix and a (major) speedup and method-change for how the
> global caching works for ID's. The change in method is that providing
> file's as arguments to org-id-update-id-locations no longer breaks the
> existing id locations.
>
> Second; I've added a customization so one can choose to cache the
> id-locations as relative to the org-id-locations-file instead of as
> absolute links. This helps a lot when running a system mirrored on
> multiple machines where the absolute paths to ones documents might
> differ, but where it's all the same relative to the
> org-id-locations-file.
>
> Third; I've added another ID generator method. The extremists might
> say the new method is not unique enough but org-mode is a personal
> system first and foremost, so I think there is merit to this new ID
> method. It creates ID's based on current timestamp and doesn't try to
> hide the timestamp from the user. One might call the ID's "natural"
> since they are contain information in themselves. Certainly a good
> thing for some. The new method will not be active unless explicitly
> chosen by the user.
>
> As a side note, if using ID's together with attachments, try this
> new ID-generator out by setting org-id-method to ts (short for
> timestamp) and change the org-attach-id-to-path-function to
> something like "/MM/DDTHHMMSS" for more human readable
> attachment folders.
>
> Org-id is next to undocumented in the manual so I didn't find a good
> place to add this. A few lines are added to org-news though.
>
> This is the first push by me without first doing an RFC. So,
> naturally, if anything is out of order mail back and/or make changes
> directly in the repo if needed. Tests passed anyways.
>
> Kind regards
> Gustav
>
>

Re: [O] Cross reference in TeXinfo export

[Carsten Dominik]

Hi Nicolas,

thank you for that pointer.  I'll see if I can figure out what is going on
and if I can propose a solution.

Carsten

On Mon, Jul 15, 2019 at 12:10 PM Nicolas Goaziou 
wrote:

> Hello,
>
> Carsten Dominik  writes:
>
> > I noticed that the link in the following line in org-guide.org
> >
> > This document is a much compressed derivative of the
> > [[info:org][comprehensive Org mode manual]].
> >
> >
> > gets turned into this in orgguide.texi
> >
> > @ref{Top,comprehensive Org mode manual,,org,}.
> >
> >
> > The PDF version of the guide then looks like this:
> >
> > This document is a much compressed derivative of the org.
> >
> >
> > So the link description in the PDF version is just "org", the name of the
> > info node.  I think the link text should be "comprehensive Org mode
> > manual".  Is anyone familiar enough with the texinfo exporter and texinfo
> > to fix this?
>
> Actually, this is not about the Texinfo exporter (ox-texinfo.el), but
> the library responsible for handling info links (ol-info.el).
>
> Maybe we should use
>
> @ref{Top,comprehensive Org mode manual,,org,comprehensive Org mode
> manual}
>
> instead. But what should we do when a section is specified, e.g.,
>
> @ref{Section Name, description,,org,}
>
> ?
>
> Regards,
>
> --
> Nicolas Goaziou
>
>

[O] Forcing to log a TODO state change

[Carsten Dominik]

Hi everyone,

I have just pushed a change to master that makes it possible to force the
logging of a TODO state change.  I have found it often too tedious to
record a note for every state change, but sometimes I would like to keep a
note for one reason or another.

You can now use three prefix arguments to `org-todo' (i.e. you need to
press `C-u C-u C-u C-c C-t' to force taking a note when you change the todo
state.

Let me know if you find any issues with the change.

- Carsten

[O] Cross reference in TeXinfo export

[Carsten Dominik]

Hi,

I noticed that the link in the following line in org-guide.org

This document is a much compressed derivative of the
[[info:org][comprehensive Org mode manual]].


gets turned into this in orgguide.texi

@ref{Top,comprehensive Org mode manual,,org,}.


The PDF version of the guide then looks like this:

This document is a much compressed derivative of the org.


So the link description in the PDF version is just "org", the name of the
info node.  I think the link text should be "comprehensive Org mode
manual".  Is anyone familiar enough with the texinfo exporter and texinfo
to fix this?

Thanks

Carsten

Re: [O] BEGIN - END markers in manual and guide

[Carsten Dominik]

Hi Nicolas,

On Sun, Jul 14, 2019 at 10:08 AM Nicolas Goaziou 
wrote:

> Hello,
>
> Carsten Dominik  writes:
>
> > I was wondering if we should change all the #+BEGIN and #+END stuff in
> the
> > manual and in the compact guide to lower case?  This is what the
> structure
> > templates insert, and it also looks better.  I'd be willing to do it,
> just
> > wondering if there are objections.
>
> Upper case is used as a way to emphasize specific syntax in code
> snippets.
>
> Also, in typesetting conventions,
>
> - =TITLE=, =BEGIN= ... =END= ::
>
>   Keywords and blocks are written in uppercase to enhance their
>   readability, but you can use lowercase in your Org files.
>
> Therefore, I do not object to this change, but I do think it is not
> necessary.
>

Yes, OK, I leave it like it is.

Regards

Carsten


>
> Regards,
>
> --
> Nicolas Goaziou
>
>

[O] BEGIN - END markers in manual and guide

[Carsten Dominik]

Hi,

I was wondering if we should change all the #+BEGIN and #+END stuff in the
manual and in the compact guide to lower case?  This is what the structure
templates insert, and it also looks better.  I'd be willing to do it, just
wondering if there are objections.

Carsten

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

[Carsten Dominik]

On Sat, May 5, 2018 at 8:02 PM Rasmus  wrote:

> Nicolas Goaziou  writes:
>
> > 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.
>
> Nicolas, I have been wondering about something, reading all these posts,
> irrespective of whether tempo is loaded by default or not (I don’t care).
>
> Do you think org-tempo should try to detect "old" versions of
> org-structure-template-alist and give a better error if it sees one?  I
> don’t know what the "best practice" is this case...
>

Yes, it absolutely should.

Carsten


>
> Thanks,
> Rasmus
>
> --
> When in doubt, do it!
>
>
>

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

[Carsten Dominik]

Dear all,

after initial doubt about this issue, I am now siding with Nicolas on this
one.  I have started to use C-c C-,   , and it works very well.  In
particular, as Bernt says, the wrapping makes a very big difference, I have
always missed this.

Carsten

On Wed, May 2, 2018 at 10:26 PM Bernt Hansen  wrote:

> Bernt Hansen  writes:
>
> > I am not really for or against enabling org-tempo by default.  If it's
> > not enabled by default and a clear path is documented for how to achieve
> > the same thing in ORG-NEWS using yasnippet or some other expansion
> > system then that is perfectly okay with me.  If I can't use  > anymore I'll just have to retrain my fingers which have been using this
> > for 10 years now -- it's doable it will just take me some time :))
>
> So I'm changing my vote :)
> I've disabled org-tempo and am in the process of learning to use C-c C-,
> instead of 
> It wraps selected regions in the e and s templates and works great! :)
>
> Thanks Nicolas!
>
> Regards,
> Bernt
>
>

Re: [O] Alternatives to inlinetasks? [was: Problems created by inlinetasks in agenda views]

[Carsten Dominik]

Hi Nicolas,


On Mon, Apr 23, 2018 at 11:08 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Carsten Dominik <domi...@uva.nl> writes:
>
> > I would be interested to discuss a better solution.  It would be nice is
> > list items could be TODO's, but I though long and har about this back
> when,
> > and over allo those years, I could not think of anything that could be
> > implemented with reasonable effort.
>
> I think we have to make inline tasks more limited, yet still useful.
>
> One major technical drawback stems from the fact that they allow
> contents.
>
>
>   *** Foo
>   ...
>   *** END
>



>
> It means that they allow, e.g., properties (it hurts inheritance), or
> clocks that do not belong to the containing headline but to the inline
> task itself... It would be a major pain if we had to handle this
> seriously, as a core feature.
>

Yes,  I agree with this.  It is there in oder to allow fully functional
TODO entries, with scheduling and logging.  But indeed, it does
not play correctly with things like inheritance and clocking.


>
> Now, if we allow them to have no contents, it becomes much more
> manageable. It means we can still have TODO, tags, priority, but no
> clock, no properties, no log...
>
> It would also mean we would disallow SCHEDULED and DEADLINE keywords,
> but we can make an exception for those, and allow a planning line right
> after an inline task.
>
> So, basically, there would be two forms of inline tasks:
>
>   *** Foo
>
> and
>
>   *** Foo
>   SCHEDULED: <...> DEADLINE: <...>
>

Now we know why these are not properties :)


>
> With this simplification, we could manage them, probably without too
> much hassle.
>

Not a bad compromise.  It is also somewhat backward compatible,
because * END would end up being just another inline-task-like headline,
and older files would not stop working.


> If you want to associate the task some contents, you can attach, e.g.,
> some drawer below. It is not part of the inline task syntax, yet it
> could work well in practice:
>
>
>   *** TODO Foo
>   :task:
>   This is because the...
>   :end:
>
> However, there is another important drawback: they look like headlines.
> That breaks a fundamental assumption in Org: any line that doesn't start
> with an asterisk (I'm oversimplifying here) "belongs" to the first line
> starting with one above. This is simply not true with inline task, so we
> use the `org-with-limited-levels'. It kind of works, except in parts of
> Org that forgot to use it (lots of fun ahead).
>

Yes, inline task is an incomplete implementation, basically a hack.


>
> We could go further and get away from the starred syntax and the column
> 0. E.g.,
>
>   !! TODO Foo :bar:baz:
>
> The advantage is that they would integrate better with the rest of the
> document:
>
>   - Grocery list
> - Apples
> - Bread
>   !! REMINDER ...
>
> However, it would be a /lot/ more work to implement the feature shared
> with regular headlines (TODO switching, tags inheritance)... but, at
> least, they would look better.
>

What would look even better is

  - Grocery list
- Apples
- TODO Bread
  SCHEDULED: 

But I have always thought that this would be nightmarish to implement,
because the assumption that all of these special entries are nodes is
sooo deep in the code...

So I would say:

either we keep it as the hack, or use the limitation you
mention and get rid of the END line.  But I am not sure it is really
with the trouble to replace a bad hack with a slightly better hack.

Carsten




>
> Regards,
>
> --
> Nicolas Goaziou
>
>

Re: [O] Alternatives to inlinetasks? [was: Problems created by inlinetasks in agenda views]

[Carsten Dominik]

On Mon, Apr 23, 2018 at 4:21 PM, Eric S Fraga  wrote:

> On Monday, 23 Apr 2018 at 15:50, alain.coch...@unistra.fr wrote:
> > In fact, my use of inelintaks seems to me so basic (I faced the
> > problem since my day 1 with org-mode) that maybe another solution that
> > I overlooked would work for me.  I'll explain my problem in the hope
> > that someone might be able to help.
>
> From what you describe, inline tasks are indeed the way to go.  If/when
> Nicolas proposes a different syntax, we may need to make changes to our
> files, of course.
>

I would be interested to discuss a better solution.  It would be nice is
list items could be TODO's, but I though long and har about this back when,
and over allo those years, I could not think of anything that could be
implemented with reasonable effort.

Carsten


>
> Other solutions, e.g. drawers, are for different use cases that many of
> us have solved by using inline tasks for what they weren't really
> intended...
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-419-g52ba1a
>

Re: [O] Exponential numbers in latex table export

[Carsten Dominik]

Hi Nicolas,

let's make it nil.

- Carsten

On Thu, Mar 29, 2018 at 10:14 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Carsten Dominik <domi...@uva.nl> writes:
>
> > On Thu, Mar 29, 2018 at 5:51 PM, Julius Dittmar <julius.ditt...@gmx.de>
> > wrote:
> >
> >>
> >> On 29.03.2018 10:37, Carsten Dominik wrote:
> >>
> >>> I believe I ended up using this because I wanted something that is not
> >>> dependent on having math-mode in the table column.  What I would have
> >>> really preferred is "%s\times10^{%s}", but that is less stable because
> >>> you need then to know if the column will have math-mode or not.
> >>>
> >>
> >> How about \ensuremath{%s\times10^{%s}} ?
> >
> >
> > That would do the trick, yes.
>
> So, what should be the default value :
>
>   \ensuremath{%s\times10^{%s}}
>
> or
>
>   nil
>
> I don't mind either way.
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Exponential numbers in latex table export

[Carsten Dominik]

On Thu, Mar 29, 2018 at 5:51 PM, Julius Dittmar <julius.ditt...@gmx.de>
wrote:

>
> On 29.03.2018 10:37, Carsten Dominik wrote:
>
>> I believe I ended up using this because I wanted something that is not
>> dependent on having math-mode in the table column.  What I would have
>> really preferred is "%s\times10^{%s}", but that is less stable because
>> you need then to know if the column will have math-mode or not.
>>
>
> How about \ensuremath{%s\times10^{%s}} ?


That would do the trick, yes.

Carsten

>
>
> Julius
>
>

Re: [O] Exponential numbers in latex table export

[Carsten Dominik]

On Wed, Mar 28, 2018 at 1:55 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Günter Lichtenberg  writes:
>
> > I have a document with many automatically generated tables that contain
> > numbers in exponential Format, e.g. 2e09. When I export the tables to
> LaTeX
> > and pdf I get something like 2 (-09) in the pdf, if there is no character
> > after the number in the table
> >
> > Minimal Example:
> > |--|
> > | 1.2e09 (abs) |
> > |  2.3e-09 |
> > |   3.4e09 |
> > |--|
> >
> > exports to a latex table as
> >
> > \begin{center}
> > \begin{tabular}{r}
> > \hline
> > 1.2e09 (abs)\\
> > 2.3\,(-09)\\
> > 3.4\,(09)\\
> > \hline
> > \end{tabular}
> >
> > Note that in the first line the number is an exponential, the following
> 2 are
> > not. I could not find anything in the documentation. What am I missing?
> >
> > orgmode version is 9.1.4, but the same happens with emacs 25.3 built-in
> > version 8.3.
>
> See `org-latex-table-scientific-notation'. I also find the default value
> a bit surprising. I believe it is what Carsten uses.
>

Hi,

I believe I ended up using this because I wanted something that is not
dependent on having math-mode in the table column.  What I would have
really preferred is "%s\times10^{%s}", but that is less stable because you
need then to know if the column will have math-mode or not.

I agree that it is a bit odd and non-standard - so maybe using nil as
default would be fine.

Carsten


>
> Regards,
>
> --
> Nicolas Goaziou
>
>

Re: [O] Make tag inheritance explicit

[Carsten Dominik]

On Tue, Jan 23, 2018 at 11:22 AM, Karl Voit  wrote:

> Hi!
>
> Is it possible to lookup inherited tags and add them explicitly to
> the current heading?
>
> Example:
>
> * Project:ProjectX:
> ** Sub-Project   :@Joe:
> *** Task 1
> *** Task 2
>
> When I go to "Task 1" (or 2), I want to invoke a command which
> "copies" the tags ProjectX and @Joe to the heading of the task.
>
>
> Background: Org-mode has perfect tag inheritance but unfortunately
> the export methods I am using do export the tags only to the
> headings they are assigned to and not to their sub-headings via
> inheritance. So copying the inherited tags would be a viable
> workaround to me.
>

I guess this then should happen optionally during export.  Doing this in
the buffer itself makes much less sense.

Carsten


>
> Thanks!
>
> --
> get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
>> get Memacs from https://github.com/novoid/Memacs <
> Personal Information Management > http://Karl-Voit.at/tags/pim/
> Emacs-related > http://Karl-Voit.at/tags/emacs/
>
>
>

Re: [O] function for inserting a block

[Carsten Dominik]

On Thu, Nov 9, 2017 at 5:31 AM, Thomas S. Dye  wrote:

> Aloha Nicolas,
>
> Nicolas Goaziou writes:
>
> > Hello,
> >
> > Takaaki Ishikawa  writes:
> >
> >> I also support the idea of keeping " >> Please give importance to the backward compatibility in this case.
> >
> > I explained why I thought it could be removed. I also suggested
> > solutions to get an equivalent feature without implementing it in Org.
> >
> > What is wrong with Abbrev mode, skeletons, tempo.el, expand.el, all
> > bundled with Emacs, or YASnippet, in the Emacs ecosystem? It sounds like
> > NIH. Or, to put it differently: why in the world would Org implement its
> > own template system?
>
> The "why in the world" question is likely one that can be answered by
> the author of the Org template system.
>

I guess that would be me.

The reason why I implemented it was the same reason why I implemented
org-mode.  It scratched an itch that I was having, and so I implemented it
to solve this issue, without much regard for existing expansion systems -
back then, I am not sure which of them did even exist and how easy it would
have been to deal with dependencies.

The reason why the leading character is "<" lies in the fact that, at the
time, I was experimenting with HTML tags, mainly because this was how emacs
MUSE was handling markup.  I left it at that because it led to very few
conflicts and because "<" is a character that is easily typed.

I have always come down on the side of NOT breaking backward compatibility
unless we really HAVE TO in order to make progress.  The reason for this
bias is because most Org users are not reading this maling list and just
want the system to function and to continue to function the way they are
used to, while it is hopefully improving.  It will stop them from upgrading
if such breakage happens too often.

So I would support reimplement the expansion (including
org-try-structure-completion
for people who use that in custom code), if possible of course on the back
of one of the built-in expansion systems in Emacs, before pushing this
change out in a release.  I would certainly reimplement this in some way
for myself, because using these abbreviations is already hardcoded in my
spine, I think.

That does not take away from that fact that I am really happy we now can
wrap existing text into a block structure.  Very useful indeed.

Carsten


>
> > The only argument so far is "<" cannot be expanded since it not word
> > constituent. Seriously. "<" has no meaning anyway. You can use "@",
> > which is word constituent and just as meaningless. So, you can define,
> > e.g., a skeleton, that will expand "@s" to "#+begin_src\n#+end_src".
> >
> > We can even document how to do it in the manual.
>
> For me, the issue isn't about how the template system is implemented, it
> is about backwards compatibility of (org-try-structure-completion).
>
> All the best,
> Tom
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>
>

Re: [O] function for inserting a block

[Carsten Dominik]

On Mon, Oct 23, 2017 at 12:52 PM, Kaushal Modi 
wrote:

> On Fri, Oct 20, 2017, 5:43 PM Kaushal Modi  wrote:
>
>> On Fri, Oct 20, 2017 at 5:15 PM Eric Abrahamsen 
>> wrote:
>>
>>> The template really only inserts the block type, not anything specific
>>> like the source language or export backend.
>>
>>
>> Right, but based on the code you have, you can easily add "SRC org", "SRC
>> emacs-lisp" to the default value of that list. Looking at that, users can
>> also get an idea that they can add their favorite languages to that list
>> too.
>>
>>
>>> I think prompting for
>>> "second-level" information like that might be a little overkill.
>>>
>>
>> I second that. The first-level prompt also feels a bit slow, honestly,
>> compared to using easy templates like "> (just an example) to insert the, well, EXAMPLE block as usual. But *if
>> region is selected*, it does the wrapping as in your code.
>>
>> This is what I mean (GIF animation):
>>
>> https://i.imgur.com/201TISW.gifv
>>
>> I use hydra to provide those awesome hints.. but the same can be done
>> without hydras too.
>>
>
> Hello all,
>
> Above, I suggested merging the template insertion function with the
> current easy template code.
>
> With that, the easy template behavior will remain unchanged if no region
> is selected. But if a region is selected, the same template (example: " Will wrap that region with that template.
>

I Kaustal,

I am not sure I understand, at least with transient-region turned on.
Typing 
> I also have a GIF showing that behavior in action (linked in my previous
> reply).
>
> Benefits:
> - Quicker as there are no prompts.. the user simply types the template
> string as configured by them.
> - Also one doesn't need to do a context switch to use a different binding
> based on if region is selected or not.
>
> @Eric: I believe you were sort of onboard with this suggestion, just gated
> by a doubt if this actually can make into master.
>
> So, checking with Nicolas, and the thread if the proposed behavior change
> with easy templates (only when region is selected) would be accepted.
>
>> --
>
> Kaushal Modi
>

Re: [O] function for inserting a block

[Carsten Dominik]

Hi Eric,



On Wed, Oct 18, 2017 at 4:58 PM, Eric Abrahamsen <e...@ericabrahamsen.net>
wrote:

> Carsten Dominik <domi...@uva.nl> writes:
>
> > Dear all,
> >
> > this is great added functionality that I have missed a lot myself.
> Thanks for this!  Also, I like the key binding.
>
> I do too, though I also notice it conflicts with inlinetask insertion.
>


Ooops.  I overlooked that. Hmmm, that is not ideal.

Maybe then C-c C-x w would be better, w can stand for "wrap".


>
> > One improvement I can think of it to read the block type with completion
> (but still allow any word to be used).
>
> I'd be happy to do that. There would be a tiny bit of redundancy with
> `org-structure-template-alist', but nothing too terrible.
>

I agree.  You could pull it would of the alist, but I am not sure it is
worth it.

Carsten


>
> Eric
>
>
>

Re: [O] function for inserting a block

[Carsten Dominik]

Dear all,

this is great added functionality that I have missed a lot myself.  Thanks
for this!  Also, I like the key binding.

One improvement I can think of it to read the block type with completion
(but still allow any word to be used).

Carsten

On Wed, Oct 18, 2017 at 12:03 AM, Eric Abrahamsen 
wrote:

> Eric Abrahamsen  writes:
>
> > Nicolas Goaziou  writes:
> >
> >> Eric Abrahamsen  writes:
> >>
> >>> I'm still not quite seeing this. This chunk should take care of it:
> >>>
> >>> (goto-char e)
> >>> (if (bolp)
> >>> (progn
> >>>   (skip-chars-backward " \n\t")
> >>>   (forward-line))
> >>>   (end-of-line)
> >>>   (insert "\n"))
> >>>
> >>> If "e" is EOB, we do `end-of-line' and insert a newline, it should be
> >>> taken care of. I added a new clause in the test for this case, and it
> >>> seems to work fine... Am I missing anything?
> >>
> >> I don't think so. It looks correct, indeed.
> >>
> >> However, you sent the wrong patch. Could you send the updated patch
> >> again?
> >
> > Ooof, maybe I need to take a little vacation from the computer. This
> > should be the right one.
>
> Backing away from the keyboard now...
>
>

Re: [O] setting local variables

[Carsten Dominik]

Hi Nicolas,

thanks!

Carsten

On Thu, Sep 21, 2017 at 9:21 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Carsten Dominik <domi...@uva.nl> writes:
>
> > yes, I am aware that LaTeX does use unnumbered for this, but this is
> > backend specific implementation, and not an argument about the logic of
> > this approach.
>
> Fair enough. I reverted the commit.
>
> I think a :NOTOC: property to ignore headlines from TOC is an acceptable
> solution, even though it add yet another property.
>
> I also suggest to classify LaTeX issue as "wontfix".
>
> Any objection?
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] setting local variables

[Carsten Dominik]

On Thu, Sep 21, 2017 at 11:39 AM, Rasmus <ras...@gmx.us> wrote:

> Carsten Dominik <domi...@uva.nl> writes:
>
> >> I believe this change was made to fix the case of mixed numbered and
> >> unnumbered headings in the TOC.
> >>
> >> Please see the other thread[1] where I suggest supporting the "case 3"
> >> where we want TOC where all headings are numbered i.e. the case of
> num:nil.
> >
> > This would address my main concern and make it usable, yes.
> >
> > It is another question if the association of unnumbered and not
> toc-listed
> > is a useful one in general.  The cleanest would be to have properties
> like
> > NO_TOC_LISTING and NOT_NUMBERED or so to allow local control.  Conflating
> > it with the global switches I find a bit confusing.
>
> AFAIK NOT_NUMBERED is the UNNUMBERED property.
>
> To support an UNNUMBERED and "UNTOCED" entry in ox-latex /in general/, we
> would need to have something like KOMA-Script’s \addsec.  Alternatively,
> one can manually add \addcontentsline{toc}{LEVEL}{NAME}, but these are not
> indented (see https://tex.stackexchange.com/a/212439/3878).  Also, headers
> aren’t updated, though this is less of a concern.
>
> Otherwise, this can only be archived by setting the secnumdepth counter to
> a sufficiently low value (say 0 for unnumbered chapters) in which case
> everything below that number is also unnumbered.
>

Hi Rasmus,

yes, I am aware that LaTeX does use unnumbered for this, but this is
backend specific implementation, and not an argument about the logic of
this approach.

Carsten


>
> Rasmus
>
> --
> I almost cut my hair, it happened just the other day
>
>
>

Re: [O] setting local variables

[Carsten Dominik]

Hi everyone,



On Thu, Sep 21, 2017 at 1:16 AM, Kaushal Modi <kaushal.m...@gmail.com>
wrote:

> On Wed, Sep 20, 2017, 2:43 PM Scott Randby <sran...@gmail.com> wrote:
>
>>
>>
>> On 09/20/2017 12:17 PM, Carsten Dominik wrote:
>> > On Thu, Sep 7, 2017 at 5:01 PM, Eric Abrahamsen <
>> e...@ericabrahamsen.net>
>> > wrote:
>> > I do object to removing unnumbered headers from the toc.
>
>
> I believe this change was made to fix the case of mixed numbered and
> unnumbered headings in the TOC.
>
> Please see the other thread[1] where I suggest supporting the "case 3"
> where we want TOC where all headings are numbered i.e. the case of num:nil.
>

This would address my main concern and make it usable, yes.

It is another question if the association of unnumbered and not toc-listed
is a useful one in general.  The cleanest would be to have properties like
NO_TOC_LISTING and NOT_NUMBERED or so to allow local control.  Conflating
it with the global switches I find a bit confusing.

Carsten


>
>  It
>
> breaks
>> > documented and used behaviour and aI see no pressing reason to change
>> it. I
>> > find, for compact documents, it works extremely well to have a toc that
>> has
>> > no numbers - in fact, in many cases I find numbered tocs even
>> annoying.  In
>> > particular, it works really well in websites, where I use it constantly.
>>
>
> Mine is the same use case and the num:nil case covers that.
>
>  I have to agree with Carsten. I use unnumbered table of contents all the
>> time in web pages. Almost all of my Org files that generate web pages have
>> the following:
>>
>> #+options: num:nil toc:t
>>
>
> @Scott Please see that other thread[1]. I have this exact use case. And if
> the case 3 discussed in that thread is supported all should be good.
>
> [1]: http://lists.gnu.org/archive/html/emacs-orgmode/2017-09/msg00497.html
> --
>
> Kaushal Modi
>

Re: [O] setting local variables

[Carsten Dominik]

On Thu, Sep 7, 2017 at 5:01 PM, Eric Abrahamsen 
wrote:

> Nicolas Goaziou  writes:
>
>
> [...]
>
> > So, any objection to have all major back-ends ignoring unnumbered trees
> > from TOC, and make that an Org specificity?
>


Hi Nicolas,

OK, now I have read this thread.

I do object to removing unnumbered headers from the toc.  It breaks
documented and used behaviour and aI see no pressing reason to change it. I
find, for compact documents, it works extremely well to have a toc that has
no numbers - in fact, in many cases I find numbered tocs even annoying.  In
particular, it works really well in websites, where I use it constantly.

I am sorry that I did not see this earlier - but I really think this change
should be reverted.  If there is a desire to have sections that are not put
into the toc, it should be separated from the num: and toc: switches and
depend, for example on properties instead.

The fact that in LaTeX "unnumbered" is linked to the question if something
is in the toc is some kind of mistake, this behaviour is very specific to
LaTeX-like systems (including TeXInfo), but it is not a very logical system
IMO.

Carsten


>
> Sounds good!
>
>
>

Re: [O] Add ability to force-enable TOC

[Carsten Dominik]

On Tue, Sep 19, 2017 at 9:27 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Carsten Dominik <domi...@uva.nl> writes:
>
> > On Tue, Sep 19, 2017 at 4:49 PM, Kaushal Modi <kaushal.m...@gmail.com>
> > wrote:
> >
> >> Hello,
> >>
> >> I have use-cases where I don't like to see the headings numbered but
> still
> >> want the TOC to be generated.
> >>
> >> I have this in many of my Org files:
> >>
> >> #+OPTIONS: num:nil H:4
> >>
> >> But after commit bd23781[1], that has stopped working i.e. no TOC is
> >> created because of num:nil.
> >>
> >
> > I would see this as a bug - clearly it makes sense to have a TOC without
> > numbering.
> >
> > Nicolas, was this an oversight, or was this change intended?
>
> The change was intended. The idea was discussed on the ML. You may want
> to check the thread.
>
> This is on par with, e.g., what LaTeX does.
>

That may be so, but I find that unfortunate.  I am really using this
feature often.

I will go back and take a look at this thread.  Can someone tell me what
the subject line of that thread was?

Carsten


>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Add ability to force-enable TOC

[Carsten Dominik]

On Tue, Sep 19, 2017 at 4:49 PM, Kaushal Modi 
wrote:

> Hello,
>
> I have use-cases where I don't like to see the headings numbered but still
> want the TOC to be generated.
>
> I have this in many of my Org files:
>
> #+OPTIONS: num:nil H:4
>
> But after commit bd23781[1], that has stopped working i.e. no TOC is
> created because of num:nil.
>

I would see this as a bug - clearly it makes sense to have a TOC without
numbering.

Nicolas, was this an oversight, or was this change intended?

Carsten


>
> Can we enforce the TOC generation using the "toc:" option. Below does not
> work at the moment, but would like that to work.
>
> #+OPTIONS: num:nil H:4 toc:4
>
> Thanks.
>
> [1]: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=
> bd2378161e76932103c9ef1f8343ffcc0d275007
> --
>
> Kaushal Modi
>

Re: [O] mimetype for orgmode files

[Carsten Dominik]

On Tue, Sep 5, 2017 at 8:30 AM, Bastien Guerry  wrote:

> Hi Yasushi,
>
> Yasushi SHOJI  writes:
>
> > There is RFC 6648, which "deprecating the "X-" Prefix".
>
> Thanks for letting us know!
>
> > So, it might be better to use "text/org".
>
> I’m fine with "text/org".  John?  Others?
>

text/org seems to be perfect.

Carsten


>
> I’ll make the change later this week if nobody disagrees.
>
> Thanks,
>
> --
>  Bastien
>
>

Re: [O] [RFC] Remove Org Struct mode

[Carsten Dominik]

Hi Nicolas,

I have not problems with removing orgstruct-mode, it is indeed a bad hack
and I am no longer using it.

I am glad you are not planning to remove orgtbl-mode.  In particular, in
connection with radio tables, it is a feature that I use constantly, so I
would object strongly to removing it.

Carsten

On Sun, Aug 20, 2017 at 3:57 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> I would like to remove Org Struct minor mode from Org code base. Here is
> the rationale:
>
> 1. It is broken. It might look like using Org in another buffer, but it
>is not. In particular, it just cannot cope with lists, indentation,
>filling in, e.g., Message mode, as soon as we try something
>non-trivial. Really, that's a poor-man's Org mode.
>
> 2. Its implementation is very hackish. In particular, it is not modular
>at all. It rewrites some core functions according to the major mode
>in use. For example `org-fill-function' tries to handle specially
>text in a Message mode buffer, basically short-circuiting regular
>behaviour. There no support for other major modes. If we want some,
>we need to hard-code it.
>
> 3. Due to previous point, some basic Org functions are sub-optimal
>because they preserve compatibility with Org Struct mode. For example
>`org-forward-heading-same-level' must process every headline past the
>current one and check their level until an appropriate one is found.
>It would be faster to go looking for the next headline according to
>the number of stars we want.
>
> 4. It is somewhat outside Org mode's scope to provide such a feature. It
>is tempting to provide everything we can think of, but we should
>focus on the main task: handle Org files, i.e., files written in Org
>compatible syntax.
>
> 5. There are alternatives. E.g., outshine.el, outline-minor-mode, ...
>
> I _do_ use `orgstruct++-mode'. But it is broken beyond repair.
> Alternatives, which do not need to pay a technical debt, are certainly
> better, or, at least, a saner ground for improvement.
>
> I'm not opposed to an Org struct mode living in ELPA. But, as pointed
> out, it is difficult to extract from code base without rewriting it
> completely. If alternatives are serious enough, that would be
> re-inventing the wheel, too.
>
> The only thing that would be missing, AFAIK, is plain list handling.
> However, I'm quite certain it is possible to re-use most code from
> "org-list.el", using a dumbed down `org-list-struct' function. Indeed,
> currently, `org-list-struct' requires to know about inlinetasks,
> drawers, blocks... i.e., most of the Org syntax. This is not an option
> in foreign buffers. Once `org-list-struct' (and maybe `org-in-item-p')
> are simplified, other functions in "org-list.el" can be used as is.
>
> I'm not talking about OrgTbl mode (yet). OrgTbl mode is different: it
> doesn't suffer from points 1, 3 end 5. It is easier to extract it as an
> external library, which someone should ultimately do.
>
> To sum it up, I offer to remove `orgstruct-mode' (and
> `orgstruct++-mode') from the code base. I can also offer my help to
> anyone willing to extract some `list-minor-mode' and `table-minor-mode'
> from Org.
>
> WDYT?
>
>
> Regards,
>
> --
> Nicolas Goaziou0x80A93738
>
>

Re: [O] Adding single cell movement to org-table

[Carsten Dominik]

Hi Chris,

I really like this functionality, thank you!

Has there been a discussion about a possible key binding for this feature?

Carsten

On Thu, Jul 27, 2017 at 10:20 PM, Chris Kauffman 
wrote:

> Greetings from a first-time contributor. Another patch contributor, Uwe
> Brauer, recruited me after finding some code I had written to move single
> org-table cells up/down/left/right.  I found this feature to be useful in
> certain kinds of tables so wrote the functions for myself but am told that
> others might benefit from it.
>
> I have formalized that code into a git repo with a feature branch on it
> which may be found here:
>   https://github.com/kauffman77/org-mode/tree/single-cell-table-move
>
> I have included documentation in org-table.el for the new functions and
> tests for them.  If further work or documentation needs to be done, please
> let me know. I am also not sure if I got the commit messages formatted to
> the specification mentioned on the contributing page.  I am happy to
> explain more if needed.
>
> I just mailed ass...@gnu.org to get the copyright for the code resolved
> but thought I would put up this branch now so others can have a look.
>
> Cheers,
> Chris
>

Re: [O] [RFC] Slight change for the tag user interface

[Carsten Dominik]

Sounds good to me.

Carsten

On Tue, Jul 18, 2017 at 12:43 PM, Marco Wahl 
wrote:

> Hi!
>
> I just glanced at the user interface for editing tags.  It looks like
> this:
>
> [a-z..]:Toggle [SPC]:clear [RET]:accept [TAB]:free [!] no groups
> [C-c]:multi
>
> I think
>
> [a-z..]:toggle [SPC]:clear [RET]:accept [TAB]:edit [!] no groups
> [C-c]:multi
>
> would be nicer.  ("Toggle" -> "toggle", "free" -> "edit")
>
> WDYT?
>
>
> Best regards
> Marco
>
>
>
>

Re: [O] why prepend "file://" to abs paths in html output?

[Carsten Dominik]

I think it can be useful to write file: in the org-mode file, to make a
clear distinction from internal links.  But once it is clear that something
is a link to a file, I guess you are right  that it might not be needed in
HTML.  We will see what breaks.

Carsten

On Sat, Jul 8, 2017 at 4:08 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Kaushal Modi  writes:
>
> > I don't see why "file://" would be useful in html exports
>
> OK. Il remove the file:// scheme specifications then.
>
> > (or pdf, md, etc).
>
> Well, those are not related to network based protocols. Does it really
> make a difference in those cases?
>
> Regards,
>
> --
> Nicolas Goaziou
>
>

Re: [O] [bug?] org-inside-latex-fragment-p broken?

[Carsten Dominik]

On Fri, Jun 23, 2017 at 9:45 AM, Nicolas Goaziou 
wrote:

> Rasmus  writes:
>
> > Nicolas Goaziou  writes:
> >
> >> `backward-paragraph' may be a bit heavy.
> >>
> >> Anyway we shouldn't use this function at all. Why do you need it?
> >
> > It's used by a couple of org-cdlatex-* functions,
> > e.g. org-cdlatex-math-modify.
>
> Then these calls should be replaced with `org-element-context', unless
> the callers may be used in partially written LaTeX snippets.
>

Yes, these can be used in partially written fragments.

Carsten

Re: [O] org-cdlatex is driving me nuts

[Carsten Dominik]

On Thu, Jun 22, 2017 at 8:07 AM, Rasmus  wrote:

> Guy Mayraz  writes:
>
> > (ii) change the org-cdlatex math
> > symbol to something totally obscure that wouldn't interfere with my
> normal
> > work?
>
> For what it is worth, option (ii) can be archived with something like this,
>
> (with-eval-after-load 'org
>   (define-key org-cdlatex-mode-map "`" nil)
>   (org-defkey org-cdlatex-mode-map "¨" 'cdlatex-math-symbol)
>   (org-defkey org-cdlatex-mode-map "'" 'org-cdlatex-math-modify))
>
>
Yes.  Or we could make Org use cdlatex-math-symbol-prefix
and cdlatex-math-modify-prefix, if more people would like to use a
different prefix.

Carsten

Re: [O] org-capture datetree below heading?

[Carsten Dominik]

Hi Benedict,

yes, get the latest master from the git repo and read the manual for that
version.

You can also look at a recent thread with the subject

"Use of date trees in Capture has been modified"

If you cannot upgrade, just put a

 :DATE_TREE: t

property to the heading under which you want the datetree to be built.

Carsten

On Tue, May 9, 2017 at 4:46 PM, Benedikt Steindorf  wrote:

> Hi,
>
> i like to use a datetree under a headingis this somehow possible?
>
> Example:
>
> * Log
> ** 2017
> *** 2017-05
>
> My current config:
>
> (setq org-capture-templates
> '(("t" "Tasks")
>  ("tg" "Task (General)" entry (file+headline "~/org/work.org"
> "Tasks")
>"* TODO %?\n  %i\n  %a")
>  ("m" "Mehrarbeit")
>  ("mn" "Nachtschicht" entry (file+datetree+prompt
> "~/org/work.org" "Mehrarbeit")
>"** %^{Activity} :NIGHTSHIFT:")
>  ("mr" "Rufbereitschaft" entry (file+datetree+prompt
> "~/org/work.org" "Mehrarbeit")
>"** %^{Activity} :CALLOUT:")
>  ("w" "Web-Site" entry (file "~/org/web.org")
>"* TODO Review %c\n%U\n%i\n" :immediate-finish
>
>
> - Benedikt
>
>

Re: [O] [RFC] The "c" Org macro

[Carsten Dominik]

Hi,

I like the idea of these counters, and I have use-cases for them.

Here is a proposal for the manual entry

This macro implements custom counters by returning the number of times
the macro has been expanded so far while exporting the buffer.
You can create more than one counter using different @var{NAME} values.  If
@var{RESET} is non-empty, the specified counter is reset to the value
specified if it is a number, or 1 otherwise. You may leave @var{NAME}
empty to reset the default counter will be reset.

A question regarding the last sentence of this proposed manual entry:

is {{{c(,2)}}} allowed to reset the default counter?  I think is should be,
but I have
not tested this.

Carsten

On Mon, May 8, 2017 at 6:52 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Eric S Fraga  writes:
>
> > On Monday,  8 May 2017 at 15:32, Dushyant Juneja wrote:
> >> A very useful macro indeed!
> >>
> >> One suggestion: can this also be made to support nested headings. For
> instance:
> >> * Part {{{c}}}
> >> ** Part {{{c}}}.{{{c}}}
> >> * Part {{{c}}}
> >
> > I think this is what separate counters will enable but also motivates
> > need to be able to reset a counter (e.g. the sub-heading one in above
> > example if it were to be used in the second part).
>
> Good idea.
>
> Here is an updated patch, in which one can write
>
>   {{{c(sub,reset)}}}
>   {{{c(sub, 5)}}}
>
> or even, for the default macro
>
>  {{{c(,reset)}}}
>  {{{c(, 99)}}}
>
> I find the manual entry a bit awkward. Suggestions welcome.
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Push rights for repository

[Carsten Dominik]

Thank you Bastien,

indeed, it is fixed now - apparently I had cloned with

$ git clone git://orgmode.org/org-mode.git

instead of

$ git clone orgm...@orgmode.org:org-mode.git

- Carsten


On Fri, May 5, 2017 at 11:19 AM, Bastien <b...@gnu.org> wrote:

> Hi Carsten,
>
> Carsten Dominik <domi...@uva.nl> writes:
>
> > I seem to have lost my push privilege to the git repository.  Does
> > anyone know why that might be the case?
> >
> > $ git remote -v shows
> >
> > origin git://orgmode.org/org-mode.git (fetch)
> > origin git://orgmode.org/org-mode.git (push)
>
> I get
>
> origin  orgm...@orgmode.org:org-mode.git (fetch)
> origin  orgm...@orgmode.org:org-mode.git (push)
>
> It looks like you are trying to push from a read-only repo?
>
> > and I believe that my ssh settings are OK - I did push a few weeks
> > ago successfully.  Still, on a push attempt, I get
> >
> >   fatal: remote error: access denied or repository not exported:
> > /org-mode.git
>
> I confirm your key didn't change on the server.
>
> Let me know!
>
> --
>  Bastien
>

[O] Push rights for repository

[Carsten Dominik]

Hi,

I seem to have lost my push privilege to the git repository.  Does anyone
know why that might be the case?

$ git remote -v shows

origin git://orgmode.org/org-mode.git (fetch)
origin git://orgmode.org/org-mode.git (push)

and I believe that my ssh settings are OK - I did push a few weeks ago
successfully.  Still, on a push attempt, I get

  fatal: remote error: access denied or repository not exported:
/org-mode.git


Thanks!

Carsten

Re: [O] ANN: org-sticky-header

[Carsten Dominik]

On Wed, Apr 19, 2017 at 8:07 AM, Eric S Fraga  wrote:

> On Tuesday, 18 Apr 2017 at 23:53, Adam Porter wrote:
> > I was using three spaces, which looked okay on my system, but I'm sure
> > it didn't look right on everyone's.  I added an option to configure it
> > now.  It would be nice to calculate it automatically somehow, but this
> > should be an improvement.
>
> Excellent.  Thank you.
>
> One other minor issue: if there are any inline tasks, the sticky header
> shows "END" if there is such an inline task not in the window but
> between point and the previous headline.  I think that if point is not
> within an inline task, you should be skipping inline tasks (my own
> preference) or displaying the headline for the task and not the END
> line.
>

That would be hard to implement.  Skipping inline tasks entirely would
be easy enough, just truncate the list of path entries to below
org-inlinetask-min-level.

Carsten


>
> Thanks again,
> eric
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 26.0.50, Org release_9.0.5-444-g998576
>

Re: [O] ANN: org-sticky-header

[Carsten Dominik]

Hi Adam,

here is a new patch with does do this correctly.

Cheers

Carsten

On Wed, Apr 19, 2017 at 7:52 AM, Carsten Dominik <domi...@uva.nl> wrote:

> Hi Adam,
>
> and just after I send this, I now see that the faces of the headings
> in the path are now wrong - so you probably already had gone down
> this path.  Sorry for the noise, need to come up with something better.
>
> Carsten
>
> On Wed, Apr 19, 2017 at 7:46 AM, Carsten Dominik <domi...@uva.nl> wrote:
>
>> Hi Adam,
>>
>> thanks for adding the option to reverse the outline path.  Great thinking
>> about using a different separator for the reversed path!
>>
>> It mostly works - however, if the window is too narrow, the abbreviation
>> ellipses are now applied to the most recent heading instead of to the last
>> one shown.  It would be better to reverse the outline path before sending
>> it into org-format-outline-path, which also saves you the pain to split and
>> rejoin the path string.
>>
>> Please find attached a patch that makes this change.  It also removes the
>> dependence on the string library which is, I think, not by default
>> available in Emacs.
>>
>> Thanks
>>
>> On Wed, Apr 19, 2017 at 1:06 AM, Adam Porter <a...@alphapapa.net> wrote:
>>
>>> Carsten Dominik <domi...@uva.nl> writes:
>>>
>>> Hi Carsten,
>>>
>>> > I am wondering if you would consider the possibility to show on only
>>> > the most recent heading, but, space permitting, the outline path -
>>> > maybe in reverse order as to keep the sticky heading itself in the
>>> > left-most column.
>>>
>>> That's a great idea, I will add that.  Thanks.
>>>
>>>
>>>
>>
>


patch
Description: Binary data

Re: [O] ANN: org-sticky-header

[Carsten Dominik]

Hi Adam,

and just after I send this, I now see that the faces of the headings
in the path are now wrong - so you probably already had gone down
this path.  Sorry for the noise, need to come up with something better.

Carsten

On Wed, Apr 19, 2017 at 7:46 AM, Carsten Dominik <domi...@uva.nl> wrote:

> Hi Adam,
>
> thanks for adding the option to reverse the outline path.  Great thinking
> about using a different separator for the reversed path!
>
> It mostly works - however, if the window is too narrow, the abbreviation
> ellipses are now applied to the most recent heading instead of to the last
> one shown.  It would be better to reverse the outline path before sending
> it into org-format-outline-path, which also saves you the pain to split and
> rejoin the path string.
>
> Please find attached a patch that makes this change.  It also removes the
> dependence on the string library which is, I think, not by default
> available in Emacs.
>
> Thanks
>
> On Wed, Apr 19, 2017 at 1:06 AM, Adam Porter <a...@alphapapa.net> wrote:
>
>> Carsten Dominik <domi...@uva.nl> writes:
>>
>> Hi Carsten,
>>
>> > I am wondering if you would consider the possibility to show on only
>> > the most recent heading, but, space permitting, the outline path -
>> > maybe in reverse order as to keep the sticky heading itself in the
>> > left-most column.
>>
>> That's a great idea, I will add that.  Thanks.
>>
>>
>>
>

Re: [O] ANN: org-sticky-header

[Carsten Dominik]

Hi Adam,

thanks for adding the option to reverse the outline path.  Great thinking
about using a different separator for the reversed path!

It mostly works - however, if the window is too narrow, the abbreviation
ellipses are now applied to the most recent heading instead of to the last
one shown.  It would be better to reverse the outline path before sending
it into org-format-outline-path, which also saves you the pain to split and
rejoin the path string.

Please find attached a patch that makes this change.  It also removes the
dependence on the string library which is, I think, not by default
available in Emacs.

Thanks

On Wed, Apr 19, 2017 at 1:06 AM, Adam Porter <a...@alphapapa.net> wrote:

> Carsten Dominik <domi...@uva.nl> writes:
>
> Hi Carsten,
>
> > I am wondering if you would consider the possibility to show on only
> > the most recent heading, but, space permitting, the outline path -
> > maybe in reverse order as to keep the sticky heading itself in the
> > left-most column.
>
> That's a great idea, I will add that.  Thanks.
>
>
>


patch
Description: Binary data

Re: [O] ANN: org-sticky-header

[Carsten Dominik]

Hahaha, stupid me, full outline path is already implemented.

Excellent.

Carsten

On Tue, Apr 18, 2017 at 3:51 PM, John Kitchin <jkitc...@andrew.cmu.edu>
wrote:

> Indeed, very cool!
>
> The spacing seems to come in here:
>
> (defun org-sticky-header--fetch-stickyline ()
>   "Make the heading at the top of the current window sticky.
> Capture its heading line, and place it in the header line.
> If there is no heading, disable the header line."
>   (save-excursion
> (goto-char (window-start))
> (unless (org-at-heading-p)
>   (org-back-to-heading)
>   ;; TODO: 3 spaces seems to be almost right, but it's still not
>   ;; perfect, and it's probably not universally right.  Something
>   ;; related to org-indent might be good.
>   (if org-sticky-header-full-path
>   (org-format-outline-path (org-get-outline-path t) nil "   ")
> (concat "   " (buffer-substring (line-beginning-position)
>   (line-end-position)))
>
> Maybe the three spaces should be stored in a defcustom. I like no spaces
> personally.
>
> Carsten Dominik writes:
>
> > Hi Adam,
> >
> > this is great, I love it!
> >
> > I am wondering if you would consider the possibility to show on only the
> > most recent heading, but, space permitting, the outline path - maybe in
> > reverse order as to keep the sticky heading itself in the left-most
> column.
> >
> > Something like
> >
> > *** current level | ** level above | * top level
> >
> > you could use `org-get-outline-path' to get the other headings up the
> tree.
> >
> > I don't necessarily think it should be the default, but it could be an
> > option.
> >
> > Cheers
> >
> > Carsten
> >
> > P.S. I also see what Eric Fraga is seeing and would love to have this
> issue
> > solved.
> >
> >
> > On Tue, Apr 18, 2017 at 1:41 AM, Adam Porter <a...@alphapapa.net> wrote:
> >
> >> Hi friends,
> >>
> >> I've posted another package which you might find useful:
> >>
> >> https://github.com/alphapapa/org-sticky-header
> >>
> >> It's modeled on semantic-stickyfunc-mode.  When you scroll down and push
> >> an Org heading out of view, it displays that heading in the Emacs header
> >> line at the top of the window so you don't forget which heading the
> >> partially displayed entry at the top belongs to.
> >>
> >> It seems to be working well so far.  Please let me know if you have any
> >> feedback.
> >>
> >> Thanks,
> >> Adam
> >>
> >>
> >>
>
>
> --
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>

Re: [O] ANN: org-sticky-header

[Carsten Dominik]

Hi Adam,

this is great, I love it!

I am wondering if you would consider the possibility to show on only the
most recent heading, but, space permitting, the outline path - maybe in
reverse order as to keep the sticky heading itself in the left-most column.

Something like

*** current level | ** level above | * top level

you could use `org-get-outline-path' to get the other headings up the tree.

I don't necessarily think it should be the default, but it could be an
option.

Cheers

Carsten

P.S. I also see what Eric Fraga is seeing and would love to have this issue
solved.


On Tue, Apr 18, 2017 at 1:41 AM, Adam Porter  wrote:

> Hi friends,
>
> I've posted another package which you might find useful:
>
> https://github.com/alphapapa/org-sticky-header
>
> It's modeled on semantic-stickyfunc-mode.  When you scroll down and push
> an Org heading out of view, it displays that heading in the Emacs header
> line at the top of the window so you don't forget which heading the
> partially displayed entry at the top belongs to.
>
> It seems to be working well so far.  Please let me know if you have any
> feedback.
>
> Thanks,
> Adam
>
>
>

Re: [O] Creating consecutive time stamps

[Carsten Dominik]

Hi MIchael,

the automatic reset of the starting date for a second time stamp on works
if the command `org-time-stamp' is invoked twice in direct succession.  So
if you press `C-c  .'  to insert a time stamp, and then you press it
immediately again, the magic will take its course.  This is probably the
situation that you remember.

However, if you use %T in a template, then `last-command' is `org-capture',
and the time stamp command does not know that you are making a range.  I
could, by looking back and finding <...>-- , but that is not implemented.
You might be better off Using an empty template and then inserting both
time stamps with `C-c .' - which will make it easy to also directly choose
the starting date.

Carsten

On Tue, Apr 4, 2017 at 9:00 AM, Michael Welle  wrote:

> Hello,
>
> the subject is a bit fuzzy, so let me depict an example use case:
> creating an appointment for a multi-day conference. I use a capture
> template with the placeholder %T for that (I use the same template for
> single day appts, which occur more often.). Then I adjust the inserted
> time stamp, add --, press C-. and add the second time stamp.
>
> So far, good. The itching point is that the calendar view for the second
> time stamp starts today, again, not at the date of the first time stamp.
> I can dimly remember -or I think I do ;)- that that was different in the
> past, maybe with a different template. Any ideas for a 'grey ointment'
> that stops the itching?
>
> Regards
> hmw
>
>

Re: [O] Problems with opening a link

[Carsten Dominik]

Hi everyone, thank you for your input.  Matt, thanks a lot for the detailed
look into this.  Indeed there are inconsistencies on how this works in Org,
and there are things happening that are system dependent.  I thibk what is
biting me this time is the system dependence which is really weird.

When I, on my Mac, call this from a commandline in bash
$ open
https://ui.adsabs.harvard.edu/#search/q=author%3A%22Dominik%2CC%22/metrics

things work.  So I made a little perl program, myopenurl, that looks like
this:

#!/usr/bin/perl
$url = join(" ",@ARGV);
system "open \"$url\";

and that does the trick when I put it into browse-url-generic-program.
Fixed for now, but I think the entire url quoting scheme in Org might
deserve another look.

Thanks.

Carsten

On Fri, Mar 31, 2017 at 7:54 PM, Matt Lundin <m...@imapmail.org> wrote:

> Hi Carsten,
>
> Carsten Dominik <domi...@uva.nl> writes:
>
> > Hi everyone,
> >
> > I have problems opening a link in org.
> >
> > The link looks like this:
> >
> > https://ui.adsabs.harvard.edu/#search/q=author%3A%22Dominik%
> 2CC%22/metrics
> >
> > I have copied it like this from the address bar in a browser.
> >
> > If I click on it in Org-mode, the link is modified to
> >
> > https://ui.adsabs.harvard.edu/%23search/q=author:%22Dominik,C%22/metrics
> >
> > before being sent to the browser, and the browser cannot resolve it.
> > The problem seems to be that # has been turned into %23
>
> I cannot replicate this on Linux, but there do seem to be some
> inconsistencies with how Org-mode is escaping/unescaping links:
>
> AFAICT, Org-mode itself is not modifying the "#". The relevant lines of
> org-open-at-point are 10747-10748:
>
>   ((functionp (org-link-get-parameter type :follow))
> (funcall (org-link-get-parameter type :follow) path))
>
> Just simply copying and pasting the link from the browser, I found that
> `path` at the lines above is:
>
> //ui.adsabs.harvard.edu/#search/q=author:"Dominik,C"/metrics
>
> Note: the time one gets to this point, the path has already been
> unescaped (see line 10712).
>
> Meanwhile, `type` is...
>
> https
>
> ...which results in org-open-at-point calling the following:
>
> (lambda (path) (browse-url (concat "https:" path)))
>
> However, there are inconsistencies when one turns the pasted url above
> into an actual org-link (e.g., by calling org-insert-link).
>
> Then the link in org-mode looks like this (note that the escape
> percentage characters are themselves escaped, which seems a bit strange
> to me):
>
> [[https://ui.adsabs.harvard.edu/#search/q=author%253A%
> 2522Dominik%252CC%2522/metrics]]
>
> Now when you open at point, the `path` at line 10748 is:
>
> //ui.adsabs.harvard.edu/#search/q=author%3A%22Dominik%2CC%22/metrics
>
> Hope this helps in debugging.
> Matt
>

Re: [O] Problems with opening a link

[Carsten Dominik]

Hi Scott,

which system are you on?

I am using a Mac, and the "open" command in the mac as
browse-url-generic-program

Carsten

On Fri, Mar 31, 2017 at 2:22 PM, Scott Randby <sran...@gmail.com> wrote:

> On 03/31/2017 05:39 AM, Carsten Dominik wrote:
> > Hi everyone,
> >
> > I have problems opening a link in org.
> >
> > The link looks like this:
> >
> > https://ui.adsabs.harvard.edu/#search/q=author%3A%22Dominik%
> 2CC%22/metrics
> >
> > I have copied it like this from the address bar in a browser.
> >
> > If I click on it in Org-mode, the link is modified to
> >
> > https://ui.adsabs.harvard.edu/%23search/q=author:%22Dominik,C%22/metrics
> >
> > before being sent to the browser, and the browser cannot resolve it.
> > The problem seems to be that # has been turned into %23
>
> The link worked fine when I tried opening it from an Org file. I'm using
> Org 9.0.3 in Emacs 24.5.1 and my browser is Firefox.
>
> Scott Randby
>
> >
> > Where does this happen, and how can I fix this?
> >
> > Thank you.
> >
> > Carsten
>

[O] Problems with opening a link

[Carsten Dominik]

Hi everyone,

I have problems opening a link in org.

The link looks like this:

https://ui.adsabs.harvard.edu/#search/q=author%3A%22Dominik%2CC%22/metrics

I have copied it like this from the address bar in a browser.

If I click on it in Org-mode, the link is modified to

https://ui.adsabs.harvard.edu/%23search/q=author:%22Dominik,C%22/metrics

before being sent to the browser, and the browser cannot resolve it.  The
problem seems to be that # has been turned into %23

Where does this happen, and how can I fix this?

Thank you.

Carsten

Re: [O] Subject: Use of date trees in Capture has been modified

[Carsten Dominik]

Hi Alan,

the change is not formally a breaking change, because everything will
continue to work as before.

But yes, such changes are usually documented.

Carsten

On Thu, Mar 16, 2017 at 9:34 AM, Alan Schmitt <
alan.schm...@polytechnique.org> wrote:

> Hello Carsten,
>
> On 2017-03-16 08:55, Carsten Dominik <domi...@uva.nl> writes:
>
> > I have just pushed (to master) a patch that modifies the use
> > of date trees in capture templates. If you don't use them,
> > no need to read on.
>
> I can't update till this reaches maint (which I use), but I'll probably
> forget by then. I assume this change will be in NEWS, but is there a
> place where breaking changes are summarized for each release ?
>
> Thanks,
>
> Alan
>
> --
> OpenPGP Key ID : 040D0A3B4ED2E5C7
> Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-02: 406.42, 2016-02: 404.04
>

Re: [O] Subject: Use of date trees in Capture has been modified

[Carsten Dominik]

Hi Eric,



On Thu, Mar 16, 2017 at 10:39 AM, Eric S Fraga <e.fr...@ucl.ac.uk> wrote:

> On Thursday, 16 Mar 2017 at 07:55, Carsten Dominik wrote:
> > Dear all,
> >
> > I have just pushed (to master) a patch that modifies the use
> > of date trees in capture templates.
>
> [...]
>
> > For the time being, the old targets will be automatically translated
> > and used correctly. When you use customize to change
> > org-capture-templates, things will automatically be updated next time
> > you change the variable.  The recommendation is to go and update your
> > templates, in case at some time in the future, we might remove the
> > compatibility layer.
>
> Carsten,
>
> would you please post an example of the new format for those that don't
> use customize for capture templates?  An example equivalent to the
> current behaviour would be welcome.
>
> For instance, my current diary appointment capture entry looks like this:
>
>  ("d" "diary" entry
>(file+datetree "~/s/notes/diary.org")
>"* %^{Appointment} %^G\n%^{Date + time}T"
>:immediate-finish t)
>

This case turns into

("d" "diary" entry
   (file+olp+datetree "~/s/notes/diary.org")
   "* %^{Appointment} %^G\n%^{Date + time}T"
   :immediate-finish t)

so you only need to change the symbol from file+datetree to
file+olp+datetree

If you were using a week tree, the symbol you'd still use file+olp+datetree
but also set the property

:tree-type week

If you are using one of the +prompt version, you would instead set the
property

   :time-prompt t

That is all.

If you want to specify an outline path, these are just additional strings
after the file name, for example

("d" "diary" entry
   (file+olp+datetree "~/s/notes/diary.org" "Heading 1" "Subheading"
"subsubheading")
   "* %^{Appointment} %^G\n%^{Date + time}T"
   :immediate-finish t)

Does that answer your question?

Carsten

[O] Subject: Use of date trees in Capture has been modified

[Carsten Dominik]

Dear all,

I have just pushed (to master) a patch that modifies the use
of date trees in capture templates.  If you don't use them,
no need to read on.

We used to have 4 different capture targets that work with date trees:
file+datetree, file+datetree+prompt, file+weektree,
file+weektree+promt.
All these are now consolidated to a single new target,
file+olp+datetree, which also allows for the optional specification of
an outline-path to build the tree under a specific headline instead of
at top level in the target file.  In this way, you can have several
date trees in a file.  The type of tree (month or iso-week) is now
controlled with a property :tree-type, the option to force a
date/time prompt is controlled by the property :time-prompt.

For the time being, the old targets will be automatically translated
and used correctly. When you use customize to change
org-capture-templates, things will automatically be updated next time
you change the variable.  The recommendation is to go and update your
templates, in case at some time in the future, we might remove the
compatibility layer.

Let me know if any issues arise.

Carsten

[O] Question about running the tests

[Carsten Dominik]

Hi,

I am trying to run the test suite (never tried before) and I am running
into problems.
Can anyone see what is going wrong here?

Thanks

Carsten

[org-mode] Sir? make EMACS=/Applications/Emacs.app/Contents/MacOS/Emacs
test-dirty

install -m 755 -d
/var/folders/82/xcvgb4057p7fj72g12rdxvsmgp/T//tmp-orgtest

TMPDIR=/var/folders/82/xcvgb4057p7fj72g12rdxvsmgp/T//tmp-orgtest
/Applications/Emacs.app/Contents/MacOS/Emacs  -Q -batch --eval '(setq
vc-handled-backends nil org-startup-folded nil)'  --eval '(add-to-list
'"'"'load-path (concat default-directory "lisp"))' --eval '(add-to-list
'"'"'load-path (concat default-directory "testing"))'  -l
org-batch-test-init --eval '(setq org-batch-test t org-babel-load-languages
(quote ( (awk . t)  (C . t)  (fortran . t)  (maxima . t)  (lilypond . t)
(octave . t)  (python . t)  (sh . t)  (perl . t)  (emacs-lisp . t)  (shell
. t)  (org . t))) org-test-select-re "\\(org\\|ob\\)" )' -l org-loaddefs.el
-l cl -l testing/org-test.el -l ert -l org -l ox  --eval
'(org-test-run-batch-tests org-test-select-re)'

Cannot open load file: no such file or directory, ob-sh

make: *** [test-dirty] Error 255

Re: [O] Allowing multiple date trees in a single file

[Carsten Dominik]

Hi Nicolas,

thank you for taking the time to look at the proposed changes in detail.
My replies and comments are below.

On Sat, Feb 4, 2017 at 1:48 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Carsten Dominik <domi...@uva.nl> writes:
>
> > Attached is a patch that does the following:
> >
> > It consolidates all four different org-capture target types that have to
> do
> > with
> > date/week trees into a single one, called `file+olp+datetree'.  This
> target
> > allows for an optional outline path specification to tell capture to
> build
> > the
> > datetree under a specific headline.  To switch to a week tree, or to
> force
> > a date prompt is now the matter of setting one of the properties in the
> > org-capture-template variable.
>
> It sounds good. Thank you.
>

Allright.


>
> > Everything works transparently, so users can update the way they
> > write their datetree captures, but they don't have to - the old syntax
> > remains
> > supported and will automatically switched when one uses customize to
> change
> > the variable.
>
> I am a bit worried by this compatibility layer. I mean, it is good to
> preserve compatibility with old templates, but it ought to be an
> ephemeral solution. I.e., no more
> `org-table--error-on-old-row-references' lingering around for ages.
>
> We could, for example, generate a deprecation warning when old templates
> are used. Then we will be able to remove this unnecessary piece of code
> in next major release.
>

We do disagree here a bit.  This little bit of extra work just keeps the
existing templates working.  We do not introduce a really different
structure of the org-capture-templates.  Rather, the code introduces a new
target type, and it makes some older target types be implemented as special
versions of the new ones.  The old targets are no longer in the manual, any
customize user will be switched automatically.  What remains is a small bit
of code that makes sure that the setup of user who might have been using
that for a long time continues to work.

In my eyes, this is worth it.  Breaking something in a new version is no
big deal for people who use Org regularly, but I am sure there are a lot of
users out there who have not changed their setup for a long time, have not
followed the discussions here and would be frustrated if their setup breaks
after getting a new version of Emacs, for example.  So we can shoot a
warning, but I would vote for just keeping this piece of code indefinitely.


>
> See for example the end of `org-open-file', although it is a bit more
> drastic (it raises an error, not a warning).
>
> > After a bit more testing, I'd like to apply this patch.  Please let me
> know
> > if you agree. And additional testers would be useful.  Anyone?  Make sure
> > to backup your capture templates if something goes wrong.
>
> Some comments follow.
>
> > -@item (file+weektree+prompt "path/to/file")
> > -Will create a heading in a week tree, but will prompt for the date.
> > +one matched.}.  If the optional outline path is given, the tree will be
> built
> > +under the node it is pointing to. Check out the @code{:time-prompt} and
>
> There's a missing space above.
>

I will fix that in the next patch.


>
> > +(defun org-capture-upgrade-templates (templates)
> > +  "Update the template list to the new format.
> > +The new format unifies all the date/week tree targets into one that
> > +also allows for an optional outline path to specify a target."
> > +  (let (target props)
> > +(mapcar
> > + (lambda (ee)
> > +   (setq target (car (nth 3 ee)))
> > +   (when (memq target '(file+datetree file+datetree+prompt
> > +   file+weektree
> file+weektree+prompt))
> > +  (setq target (symbol-name target) props nil)
> > +  (if (string-match "prompt" target) (setq props '(:time-prompt t)))
> > +  (if (string-match "week" target)
> > +  (setq props (append '(:tree-type week) props)))
> > +  (setcar (nth 3 ee) 'file+olp+datetree)
> > +  (setcdr (nthcdr 4 ee) (append props (nthcdr 5 ee
> > +   ee)
> > + templates)))
>
> I suggest the following. Less `setq', `setcar', `setcdr' makes Org
> a better place.
>
> (defun org-capture-upgrade-templates (templates)
>   "Update the template list to the new format.
> TEMPLATES is a template list, as in `org-capture-templates'. The
> new format unifies all the date/week tree targets into one that
> also allows for an optional outline path to specify a target."
>   (mapcar
>(lambda