Re: Seeking identical output for export

2020-01-07 Thread Diego Zamboni
Hi Wesley,

Can you post a small org file that reproduces these problems? Without
looking at the entire file it's hard to figure out what's going on.

For example, AFAIK the {{{date}}} macro does not magically expand the
current date, rather it refers to the #+DATE property of the document. If
this is for some reason not included in your standalone export command,
maybe this is the reason why it's not being expanded.

As for the others, I think orgX is the default auto-generated reference
format, so my guess would be that something else in your main Emacs config
is enabling the human-readable labels, and which is not being loaded in the
script command. I do not really understand the third point about the
periods. Again, a self-contained example would help.

Best,
--Diego


On Tue, Jan 7, 2020 at 7:22 PM  wrote:

> Hello:
>
> I am seeking to find the right way to obtain identical output when
> exporting an Org file into texinfo using the export menu from within the
> Org file as well as from a Makefile using an Emacs batch script.
>
> Currently I am using (org-export-to-file ‘texinfo “”) from
> within a Makefile.  This produces a file that has a few differences from
> that produced by using the export menu 'C-c C-e i t’.
>
> The batch script is:
>
>  emacs -Q --batch --eval '\
>   (progn \
> (require '\''org) \
> (require '\''ob) \
> (require '\''ox-texinfo) \
> (require '\''ob-shell) \
> (setq org-confirm-babel-evaluate nil) \
> (find-file "$(ORG)") \
> (org-export-to-file '\''texinfo "$(TEXI)"))'
>
> The differences include:
> - the {{{date}}} macro is empty when created with the Makefile
>   e.g. subtitle Version 0.0.0
>  versus
>  subtitle Version 0.0.0 2020-01-07 10:05
>
> The Org source is:
> #+subtitle {{{version}}} {{{date}}}
> #+macro:version Version 0.0.0
>
> The version macro is expanded but not the date macro.
>
> - references are random strings rather than similar to the #+name when
> created with the Makefile
>   e.g. float Listing,orge1fba27
>  versus
>  float Listing,get-org-filename
>
> - periods at the end of variable references
>   e.g. ... exists: $NEWDIR.
>  versus
>  ...exists: $NEWDIR@.
>
> Thank you for any suggestions.
>
> Wesley
>


Re: excluding noweb references completely from exports

2020-01-07 Thread Samuel Wales
On 1/6/20, Fraga, Eric  wrote:
> Tangling is for extracting code(s) from a document; exporting is for
> presentation or dissemination of that document.

actually i wasn't intending to ask for the difference.  :)  instead, i
was intending to say that i thuoght it was reasonable for a beginner
to be confused.

i think a beginner can reasonably think tangling is like exporting,
just a bit different.  not orthogonal.  so it's like "um, why both?"
i use both btw.

that probably soudns crazy so let me elaborate.  if extracting uses
subsetting, that can be done by the :noexport: tag and perhaps similar
things in babel.  if extracting is putting stuff in source code files,
that can be done by exporting to files.

so i think a newcomer can reasonably get confused.  maybe just me and
idk if i have derailed the thread.  in which case, never mind!

-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.



Re: Possible orgalist issue

2020-01-07 Thread Tim Cross


Josiah Schwab  writes:

> Hi Tim,
>
> On Tue, Jan 7, 2020 at 1:37 AM Nicolas Goaziou  wrote:
>
>> It rings a bell. I think someone recently reported something like this.
>
> There was this thread from a ~year ago:
> https://lists.gnu.org/archive/html/emacs-orgmode/2018-09/msg00053.html
>
> You don't mention other packages, so I don't know if this is related
> to your issue.
>
> I adopted Nicholas' suggestion of disabling Yasnippet, then enabling
> Orgalist, and eventually enabling Yasnippet again.  (I am using mu4e
> 1.3.6 and emacs 26.3.)  My init has
>
> (defun jws/orgalist-yas-workaround ()
>   (progn
> (yas-minor-mode -1)
> (orgalist-mode 1)
> (yas-minor-mode)))
>
> (add-hook 'mu4e-compose-mode-hook 'jws/orgalist-yas-workaround 'append)
>
> I haven't hit this issue since.
>
> Josiah

thanks Josiah, that is useful information. I will check to see if it
helps (I am using yasnippets).

-- 
Tim Cross



Seeking identical output for export

2020-01-07 Thread wlharvey4
Hello:

I am seeking to find the right way to obtain identical output when exporting an 
Org file into texinfo using the export menu from within the Org file as well as 
from a Makefile using an Emacs batch script.

Currently I am using (org-export-to-file ‘texinfo “”) from within a 
Makefile.  This produces a file that has a few differences from that produced 
by using the export menu 'C-c C-e i t’.

The batch script is:

 emacs -Q --batch --eval '\
  (progn \
(require '\''org) \
(require '\''ob) \
(require '\''ox-texinfo) \
(require '\''ob-shell) \
(setq org-confirm-babel-evaluate nil) \
(find-file "$(ORG)") \
(org-export-to-file '\''texinfo "$(TEXI)"))'

The differences include:
- the {{{date}}} macro is empty when created with the Makefile
  e.g. subtitle Version 0.0.0 
 versus
 subtitle Version 0.0.0 2020-01-07 10:05

The Org source is:
#+subtitle {{{version}}} {{{date}}}
#+macro:version Version 0.0.0

The version macro is expanded but not the date macro.

- references are random strings rather than similar to the #+name when created 
with the Makefile
  e.g. float Listing,orge1fba27
 versus 
 float Listing,get-org-filename

- periods at the end of variable references
  e.g. ... exists: $NEWDIR.
 versus 
 ...exists: $NEWDIR@.

Thank you for any suggestions.

Wesley


Re: Possible orgalist issue

2020-01-07 Thread Josiah Schwab
Hi Tim,

On Tue, Jan 7, 2020 at 1:37 AM Nicolas Goaziou  wrote:

> It rings a bell. I think someone recently reported something like this.

There was this thread from a ~year ago:
https://lists.gnu.org/archive/html/emacs-orgmode/2018-09/msg00053.html

You don't mention other packages, so I don't know if this is related
to your issue.

I adopted Nicholas' suggestion of disabling Yasnippet, then enabling
Orgalist, and eventually enabling Yasnippet again.  (I am using mu4e
1.3.6 and emacs 26.3.)  My init has

(defun jws/orgalist-yas-workaround ()
  (progn
(yas-minor-mode -1)
(orgalist-mode 1)
(yas-minor-mode)))

(add-hook 'mu4e-compose-mode-hook 'jws/orgalist-yas-workaround 'append)

I haven't hit this issue since.

Josiah



Re: Possible orgalist issue

2020-01-07 Thread Tim Cross


Nicolas Goaziou  writes:

> Hello,
>
> Tim Cross  writes:
>
>> Questions:
>>
>> 1. anyone else seeing this who is using Emacs 27.0.60
>
> It rings a bell. I think someone recently reported something like this.
> Unfortunately, I'm not able to reproduce it on Emacs 27.0.50 in Message
> mode (which isn't your setup anyway).
>
>> 2. am I loading orgalist correctly?
>
> Probably. I don't think there is a wrong way to load Orgalist package.
> It is a very simple library that consists of a single file. Just make
> sure you're using latest 1.11 release.
>
>> 3. anyone running latest mu4e (dev version) seeing this?
>>
>> My suspicion is that it is related to the latest mu4e version, but
>> that is really just a guess.
>

thanks Nicolas, I will dig further.

Just FYI the newest version of mu4e is now using the gnus message mode
for composing new messages (mu4e-compose is derived from message
mode). It is quite likely there is an issue with how this is being done
(I have encountered other issues previously).




-- 
Tim Cross



Re: excluding noweb references completely from exports

2020-01-07 Thread Tim Cross


Fraga, Eric  writes:

> On Monday,  6 Jan 2020 at 14:35, Samuel Wales wrote:
>> fyi i dimly recall that in babel's infancy, as a user new to lp and
>> using babel infrequently, i got confused about the difference while
>> reading the manual.  in fact, i wondered if the two features could be
>> the same thing but refactored.
>
> Tangling is for extracting code(s) from a document; exporting is for
> presentation or dissemination of that document.

Yes, that is how I have always thought of it. Exporting is about
exporting the document into a new format (PDF, HTML, Markdown etc). This
isn't really related to LP (it could be seen as a bit like 'weave' in LP
jargon I guess). Even without Babel, you would still want export in
order to publish your org documents in different formats.

Tangle on the other hand is the guts of LP. It is what extracts the code
in the source blocks into 'raw' code files i.e. *.c, *.java, *.py etc
and adds things like noweb references to enable you to build complete
source files from multiple separate source blocks (with references
etc). In addition, it provides the powerful feature of being able to
generate 'new' (results) content from your source blocks and insert
them back into the document which can then be exported, providing a
mechanism to create more dynamic documents, which I find very useful for
documenting a workflow process where the document becomes a log of the
process as well as documentation on exactly what the process is/does.

A good example of this is https://www.youtube.com/watch?v=dljNabciEGg

-- 
Tim Cross



Re: Format of Effort estimates should be mentioned in its Info node

2020-01-07 Thread Nicolas Goaziou
Hello,

Jean-Christophe Helary 
writes:

>> On Jan 4, 2020, at 14:20, Kisaragi Hiu  wrote:
>> 
>> It didn't work for me because I gave it "10m" which actually means 10 
>> months, I've realized.
>> 
>> Still, Durations as defined by org-duration.el should be described in the 
>> manual like how Timestamps are.
>
> This does look like a potential contribution to the package.

I'm not sure would be pertinent to create a whole section for duration
format: these are not quite as ubiquitous as timestamps. However, they
are used here and there so it may be better to add a few words in the
appropriate sections, the main one being obviously "Effort Estimates".

Anyway, patches welcome! :)


Regards,

-- 
Nicolas Goaziou



Re: Possible orgalist issue

2020-01-07 Thread Nicolas Goaziou
Hello,

Tim Cross  writes:

> Questions:
>
> 1. anyone else seeing this who is using Emacs 27.0.60

It rings a bell. I think someone recently reported something like this.
Unfortunately, I'm not able to reproduce it on Emacs 27.0.50 in Message
mode (which isn't your setup anyway).

> 2. am I loading orgalist correctly?

Probably. I don't think there is a wrong way to load Orgalist package.
It is a very simple library that consists of a single file. Just make
sure you're using latest 1.11 release.

> 3. anyone running latest mu4e (dev version) seeing this?
>
> My suspicion is that it is related to the latest mu4e version, but
> that is really just a guess.

Maybe the backtrace would help understanding the issue.

Regards,

-- 
Nicolas Goaziou



Re: Add a new link type for video files

2020-01-07 Thread Nicolas Goaziou
Hello,

stardiviner  writes:

> I write a patch to add new link type:
>
> #+begin_example
> [[video:/path/to/file.mp4::00:13:20]]
> #+end_example

Thank you.

> This will open video file in specific timestamp. And it is possible to add 
> more
> options in link. Like video player arguments.
>
> I want to ask should I add this patch to Org Mode built-in?

I don't have a strong opinion on this, but considering Emacs does not
provide any way to play videos out of the box, I think there is no point
in shipping this with Emacs.

It can be a useful extension in ELPA, though. I suggest to add export
facilities, too.

WDYT?

Regards,

-- 
Nicolas Goaziou



Re: [PATCH] restore window configuration after org-edit-src-exit

2020-01-07 Thread Nicolas Goaziou
Hello,

Jack Kamm  writes:

> Attached is a patch to restore the window configuration after exiting an
> org source buffer, when org-src-window-setup is one of reorganize-frame,
> split-window-below, or split-window-right.

Thank you for the patch! Some comments follow.

> @@ -156,8 +156,7 @@ split-window-right Show edit buffer to the right of the 
> current window,
> keeping all other windows.
>  other-window   Use `switch-to-buffer-other-window' to display edit 
> buffer.
>  reorganize-frame   Show only two windows on the current frame, the current
> -   window and the edit buffer.  When exiting the edit buffer,
> -   return to one window.
> +   window and the edit buffer.
>  other-frameUse `switch-to-buffer-other-frame' to display edit buffer.
> Also, when exiting the edit buffer, kill that
> frame."

It would be useful to also explain what happens when the value is
`reorganize-frame', `split-window-right', or `split-window-right', e.g.,
that previous window configuration is restored.

> +(when org-src--saved-temp-window-config
> +  (set-window-configuration org-src--saved-temp-window-config)
> +  (setq org-src--saved-temp-window-config nil

It may be useful to wrap `set-window-configuration' within
`unwind-protect' so we can still reset the
`org-src--saved-temp-window-config' variable even though something went
wrong.

WDYT?

Regards,

-- 
Nicolas Goaziou



Re: specify time of day for org-resolve-clocks, not number of minutes

2020-01-07 Thread Nicolas Goaziou
Hello,

Dan Drake  writes:

> Instead, I want to specify a *time*, since usually that's what I remember
> ("my coworker stopped to ask a question at 10:45"). I'd like a way to get
> the K functionality, but instead of doing the math to figure out a number
> of minutes, I want to just type in a time of day.
>
> Is there a way to do this already?

I don't think so.

> Or would this require a new clock resolution command -- perhaps "t",
> for "time": it would effectively just be a wrapper around "k" that
> parses the provided time, looks at the current clocked-in task,
> computes the appropriate number of minutes, and then just does
> whatever "k" (or "K") does.

This is a good idea. It might be useful to provide a date somehow, e.g.,
if you want to rewind to yesterday at 11:00pm. I'm not sure what a good
interface would be, though. `org-read-date' is pretty much future
oriented.

WDYT?

Regards,

-- 
Nicolas Goaziou



Re: Issue with internal directory links

2020-01-07 Thread Nicolas Goaziou
Hello,

Jonathan Fox  writes:

> Here's a link I'm using:
>
> [[./templates][Templates]]
>
> I think the issue I'm having arises within the `org-open-file' function at
> the following variable assignment inside a let* expression:
>
> (command (mailcap-mime-info mime-type))
>
> In 26.1, the value assigned is `view-mode'. In 27.0.50, the value assigned
> is "less '%s'".

I still cannot reproduce it, so your .mailcap file is different than
mine. Anyway, you can tweak `org-file-apps' variable to use whatever you
want to open the file.

HTH,

-- 
Nicolas Goaziou