Re: [O] setting local variables

2017-09-21 Thread Kaushal Modi
On Thu, Sep 21, 2017 at 3:23 PM Nicolas Goaziou 
wrote:

> Fair enough. I reverted the commit.
>

Thanks!


> I think a :NOTOC: property to ignore headlines from TOC is an acceptable
> solution, even though it add yet another property.
>

+1 for :NOTOC:
With that it will be very clear what to expect in the exported formats.


> I also suggest to classify LaTeX issue as "wontfix".
> Any objection?
>

I don't use LaTeX exporter that heavily. If I do, I keep all headings
numbered and also in TOC. So I cannot yet grasp the LaTeX issue.
-- 

Kaushal Modi


Re: [O] [PATCH] Implement Org pdfview

2017-09-21 Thread Oscar Najera
>> That package is also based on docview, and has some more history. Which
>> is the convenience of having this in org?
>
> Because it's not easy to find (at least for me).  Could we include
> Markus package in Org or Org contrib?

I'm not so sure about that legal status of things.

> Or maybe is a better way to include org-pdfview to pdfview package?

Maybe you can push forward on that. Although, I do prefer just having
many packages on MELPA.


> I CC your reply to emacs-orgmode@gnu.org list.  Is it OK for you?

Yes, I just missed to hit reply all. Everything shall go into the
mailing list. I'm just new to this.



Re: [O] setting local variables

2017-09-21 Thread Nicolas Goaziou
Hello,

Carsten Dominik  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] Doc bug: Publishing "Simple Example" is missing publishing function

2017-09-21 Thread Nicolas Goaziou
Hello,

Nick Dokos  writes:

> I tried to publish the project described in
>
>   (info "(org) Simple example")
>
> and I got the complaint
>
> ,
> | ~$ emacs -batch -l foo.el --eval '(org-publish "org")'
> | No publishing function chosen
> `
>
> I attach a patch to fix the doc.

Applied. Thank you.

Regards,

-- 
Nicolas Goaziou



Re: [O] Capture broken with org-plus-contrib-20170917

2017-09-21 Thread N. Jackson
Hi Josiah,

At 09:48 -0700 on Thursday 2017-09-21, Josiah Schwab wrote:

> Have you looked at the incompatible changes described in the
> release notes?

No, I hadn't. This is the downside of having the convenience of a
package manager in Emacs rather than installing things manually --
one neglects to read the release notes!

> I believe this change (and the migration) are described in
> "org-capture-templates no longer accepts S-expressions as file
> names".

Indeed. You are quite right, that explains the problem exactly.

> Hope that helps,

Yes it did, thank you. Thanks for the quick answer.

I have now bitten the bullet and "fixed" all my capture templates.
One advantage of this is that they are now slightly easier to
read!

N.




Re: [O] Capture broken with org-plus-contrib-20170917

2017-09-21 Thread Josiah Schwab
Hi N.,

> Is this problem a new bug in Org, or is it simply that my capture
> templates are wrong and that they've only worked all these years
> by some accident?

Have you looked at the incompatible changes described in the release
notes?  I believe this change (and the migration) are described in
"org-capture-templates no longer accepts S-expressions as file names".

http://orgmode.org/Changes.html

Hope that helps,
Josiah



[O] Capture broken with org-plus-contrib-20170917

2017-09-21 Thread N. Jackson
After an Emacs package update a few days ago, my Org captures no
longer work. This is with org-plus-contib-20170917 from
http://orgmode.org/elpa/.

After I select a capture template to run, I get the error message

  Invalid file location: nil

and setting debug-on-error I see this:

  Debugger entered--Lisp error: (error "Invalid file location: nil")
signal(error ("Invalid file location: nil"))
error("Invalid file location: %S" nil)
org-capture-expand-file((concat org-directory "/notes.org"))
org-capture-target-buffer((concat org-directory "/notes.org"))
org-capture-set-target-location()
org-capture(nil)
funcall-interactively(org-capture nil)
call-interactively(org-capture nil nil)
command-execute(org-capture)

. Checking the value returned by the concat,

  M-: (concat org-directory "/notes.org")

the correct value

  "/data/org/notes.org"

is returned. This is the correct file and it exists etc..

There have been no changes to my org configuration since June of
2016 and I have had no problem with my captures until the latest
Emacs package update.

An example of the capture templates that are suddenly failing is
this one:

  (setq org-capture-templates
  '(
  ("n"
   "Note"
   ;; This one is a bit ugly. I see the guts of the template while the 
prompt is displayed. Also the PROPERTIES drawer is after the LOGBOOK instead of 
before.
   entry (file (concat org-directory "/notes.org"))
   "* %^{Enter Note Title}%^g\n   :PROPERTIES:\n   :Created:  %U\n  
 :END:\n\n%?\n%i\n"
   :kill-buffer t :empty-lines 1 :clock-in t :clock-resume t)
  )
  )

I found a work-around, in that if I change the `entry' line of the
capture template to read

  entry (file "notes.org")

the capture works again (taking advantage of what I assume must be
a new(ish) feature that org-directory is automatically used when
the file name in the capture template is unqualified).

Is this problem a new bug in Org, or is it simply that my capture
templates are wrong and that they've only worked all these years
by some accident?

If my capture templates are valid, then I would much rather see
Org put back the way it was so that they work, rather than have to
go through the error-prone process of having to edit them all (I
have dozens of them).

Thank you and best regards,
N.





Re: [O] setting local variables

2017-09-21 Thread Scott Randby
On 09/20/2017 07:16 PM, Kaushal Modi wrote:
>  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
> 

Okay, I don't really understand the issue being discussed in the thread, but if 
num:nil gives me an unnumbered table of contents after HTML export, I'm good. I 
also export to LaTeX, but I recognize that there are issues with LaTeX table of 
contents and I just work around them.

I need to sit down and read the Org manual. For years, I've been using toc:t 
and getting more in the table of contents than I wanted. Discovering that I can 
use something like toc:1 was exactly what I needed a long time ago. I know 
there are other things in Org that I want now and just don't know about. There 
are disadvantages to my haphazard approach to Org.

Scott



Re: [O] [PATCH] Implement Org pdfview

2017-09-21 Thread Oleg Pykhalov
Hello Oscar,

Oscar Najera  writes:

>> Oleg Pykhalov  writes:
>> I prepared pdf-view based on doc-view for org-capture.
>
> I'm already using org-pdfview from
> https://github.com/markus1189/org-pdfview
> which is also available on MELPA.

Oh, didn't see this.  Thanks for notice.

> That package is also based on docview, and has some more history. Which
> is the convenience of having this in org?

Because it's not easy to find (at least for me).  Could we include
Markus package in Org or Org contrib?

Or maybe is a better way to include org-pdfview to pdfview package?

I CC your reply to emacs-orgmode@gnu.org list.  Is it OK for you?

Thanks.



Re: [O] setting local variables

2017-09-21 Thread Carsten Dominik
On Thu, Sep 21, 2017 at 11:39 AM, Rasmus  wrote:

> Carsten Dominik  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

2017-09-21 Thread Rasmus
Carsten Dominik  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.

Rasmus

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




Re: [O] setting local variables

2017-09-21 Thread Carsten Dominik
Hi everyone,



On Thu, Sep 21, 2017 at 1:16 AM, Kaushal Modi 
wrote:

> On Wed, Sep 20, 2017, 2:43 PM Scott Randby  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

2017-09-21 Thread Eric S Fraga
On Wednesday, 20 Sep 2017 at 14:42, Scott Randby wrote:

[...]

> 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

Ditto.  I find a short TOC for web pages very useful and could not
figure out why such tables had disappeared from my web pages!

>
> The change should be reverted. I wish I had paid attention to this
> thread. I thought it was about something else.

I also hadn't been following this thread and hadn't realised it had
morphed into a discussion about toc.  

Thanks,
eric

-- 
: Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-573-g09e612


signature.asc
Description: PGP signature