Re: [O] [RFC] Could we get rid of Org specific "mark ring"

[Allen Li]

I was not aware Org had its own mark ring, and I see no use for it
personally when Emacs's mark ring exists.

On Mon, Jan 29, 2018 at 3:21 PM, Nicolas Goaziou  wrote:
> Hello,
>
> As the title suggests, I'm wondering if we could remove Org's own
> implementation of the mark ring, for some reasons :
>
> - Emacs already provides two of them: the local one and the global one.
>   This feels like re-inventing the wheel;
>
> - Org mark ring and Emacs mark ring are sometimes out of sync, hence bug
>   #23745;
>
> - `org-mark-ring-goto' binding (C-c &) conflicts with some minor modes
>   (e.g., Yasnippet).
>
> So, could we simply remove this part of Org and use Emacs facilities,
> with their standard bindings (C-u C- and C-x C-) and behaviour
> instead?
>
> For hard-core Org users, it might be possible to create a function that
> cycles among Org buffers only in the Emacs' mark ring. I don't think
> this is necessary, tho.
>
> Thoughts?
>
> Regards,
>
> --
> Nicolas Goaziou0x80A93738
>

Re: [O] BUG report [Was: computing the size of a tikz to png image during export]

[Berry, Charles]

> On Jan 28, 2018, at 11:49 PM, Fabrice Popineau 
>  wrote:
> 
> You should have a look at commit  38be85124551083d269.
> It prevents evaluation of the by-backend form in parameters.
> 

You are right.

I do not see a clean way to do what `by-backend' would have done prior to that 
commit.

Maybe :file-ext can help for the tikz case.

Chuck

 

[O] [RFC] Could we get rid of Org specific "mark ring"

[Nicolas Goaziou]

Hello,

As the title suggests, I'm wondering if we could remove Org's own
implementation of the mark ring, for some reasons :

- Emacs already provides two of them: the local one and the global one.
  This feels like re-inventing the wheel;

- Org mark ring and Emacs mark ring are sometimes out of sync, hence bug
  #23745;

- `org-mark-ring-goto' binding (C-c &) conflicts with some minor modes
  (e.g., Yasnippet).

So, could we simply remove this part of Org and use Emacs facilities,
with their standard bindings (C-u C- and C-x C-) and behaviour
instead?

For hard-core Org users, it might be possible to create a function that
cycles among Org buffers only in the Emacs' mark ring. I don't think
this is necessary, tho.

Thoughts?

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] Unexpected behaviour from capture-template

[Nicolas Goaziou]

Hello,

Brian J Hoskins  writes:

> Everything works except for the property, which for some reason gets
> inserted above the symptom line, even though it is prompted for last.
> This is what the capture template looks like after finishing:
>
> --
>
> * Test Health Journal:HEADACHE:
>   [2018-01-29 Mon 22:52]
> ** SYMPTOMS
> :PROPERTIES:
> :SEVERITY: 2
> :END:
> My symptoms...
>
> --
>
>
> Am I doing something wrong or is there a bug here?

The properties drawer must be located right below the headline, barring
some planning info line. So the output looks perfectly valid.

Regards,

-- 
Nicolas Goaziou

[O] Unexpected behaviour from capture-template

[Brian J Hoskins]

I have set up a capture template as follows (shortened for sake of brevity):

("h" "Health" entry (file+datetree "~/health.org")
 "* %? %^g\n%U\n** SYMPTOMS\n%^{SYMPTOMS}\n%^{SEVERITY}p\n")


This capture template (should) do the following according to my
understanding:

* Make a journal entry
* Prompt for tags
* Insert an inactive timestamp on a new line
* Prompt for symptoms, insert on new line heading 2
* Prompt for severity property, insert on new line
* Put the cursor back on the heading 1 line.


Everything works except for the property, which for some reason gets
inserted above the symptom line, even though it is prompted for last.
This is what the capture template looks like after finishing:

--

* Test Health Journal:HEADACHE:
  [2018-01-29 Mon 22:52]
** SYMPTOMS
:PROPERTIES:
:SEVERITY: 2
:END:
My symptoms...

--


Am I doing something wrong or is there a bug here?

Many thanks in advance, fellow org-moders!

Cheers,

Brian.

Re: [O] [RFC] Moving "manual.org" into core

[Nicolas Goaziou]

Hello,

Yasushi SHOJI  writes:

> Do you see this on your env?  Or, is it just me?

I don't see anything like this.

> I'd like to have the formatter and `fill-paragraph` work in a coherent way.
> But, if you, who know org much better than me, don't know, I don't think
> I can help.  Though, just in case, can you elaborate a bit?

The formatter doesn't call `fill-paragraph' at all. No wonder both do
not work in a way you would expect. 

The newline characters introduced in the output of the formatter were
present already in the original text. However, some objects ignore white
spaces on purpose. For example, [[foo bar]] and [[foo bar]] and [[foo\n
bar]] are equivalent, so the parser does not retain the distinction
between them. Hence links are always formatted on a single line.

Now, I'm not sure the formatter should call `fill-paragraph', for some
reasons:

- the original document could be using `visual-line-mode' so there's
  could be nothing to fill without Org knowing about it;

- Calling `fill-paragraph' requires full fontification, so `org-mode'
  would be initialised at every paragraph to fill;

- `fill-paragraph' depends heavily on user's configuration (custom link
  types, `org-fontify-emphasized-text', `org-hide-emphasis-markers',
  `org-pretty-entities'...) whereas the formatter is expected to be more
  neutral.

We could however, un-fill everything. But the output would be very
different. So, TRTD is not obvious.

> Since you fixed the big ones, I can see another issue.  This is also 
> indentation
> issue, but with a macro replacement .  Somehow, macro replacement
> gets extra indentation.  Like this:

>   a numeric prefix, check that many days.  For example, {{{kbd(C-1
> - C-c / d)}}} shows all deadlines due tomorrow.
> +  C-c / d)}}} shows all deadlines due tomorrow.

This is related to the explanation above. Macros did the opposite of
links. The parser didn't remove meaningless spaces upon parsing macros.
So those would be inserted twice. I fixed this. Now macros show the same
behaviour as links: even multi-lines macros are inserted as a single
line.

Regards,

-- 
Nicolas Goaziou

Re: [O] computing the size of a tikz to png image during export

[Alan Schmitt]

On 2018-01-28 16:37, Fabrice Popineau  writes:

> I jump on this example to ask: does this by-backend trick still work with
> Org 9.1.6?

It works here. I did not provide the definition, here it is:

(defmacro by-backend ( body)
  `(cl-case org-export-current-backend ,@body))

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-12: 406.82, 2016-12: 404.42


signature.asc
Description: PGP signature

Re: [O] Bug: iCal export does not respect :noexport: tag [9.1.6 (9.1.6-31-gffa5f3-elpa @ /Users/kdm/.emacs.d/elpa/org-20180122/)]

[Ken Mankoff]

Hi Nicolas,

I figured it out!

On Mon, Jan 29, 2018 at 12:48 AM, Nicolas Goaziou 
wrote:

> Ken Mankoff  writes:
>
> I cannot reproduce it. My minimal config is:
>
>   (setq org-export-async-init-file "~/dev/mini-init.el")
>
>
I didn't realize that async spawned a new emacs process and/or didn't have
access to the current config. Once I set up my own async-init-file, it
works.

Thank you!

   -k.