Re: [O] Curious as to message in echo area

[Nick Dokos]

Charles Millar  writes:

> Hello,
>
> I have always concerned myself that a table column formula returns what is 
> expected.and is correct.
>
> However I never paid attention to the echo area and I just noticed that it 
> displays the following message
>
> "cells in region copied, use M-x org-table-paste-rectangle to paste them in a 
> table"
>
> when I C-c C-c on the formula in the following table
>
> | 1 |
> | 2 |
> | 3 |
> |   |
> #+tblfm: @>$>=vsum(@1..@>>)
>
> The correct result is returned.
>
> Have I been ignoring something for the past several years, i.e. has the above 
> message always been displayed?
>

No, it was added recently:

,
| $ git blame -L 1868,1870 -- org-table.el
| 5c8cb1e733 (Bastien 2018-04-28 12:52:20 +0200 1868) (setq 
org-table-clip (nreverse region))
| 5c8cb1e733 (Bastien 2018-04-28 12:52:20 +0200 1869) (message 
(substitute-command-keys "Cells in the region copied, use 
\\[org-table-paste-rectangle] to paste them in a table."
| fe939ecb95 (Carsten Dominik 2008-03-22 16:52:18 +0100 1870) 
| $ git show 5c8cb1e733
| commit 5c8cb1e7332a9fd8ba71cd0a5fe7bdf5d19d09fd
| Author: Bastien 
| Date:   Sat Apr 28 12:52:20 2018 +0200
| 
| Add messages for `org-table-copy-region' and `org-copy-visible'
| 
| * lisp/org-table.el (org-table-copy-region):
| * lisp/org.el (org-copy-visible): Add a message.
`

> Just wondering.
>
> Charlie Millar
>
>  
>

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

[O] Curious as to message in echo area

[Charles Millar]

Hello,

I have always concerned myself that a table column formula returns what 
is expected.and is correct.


However I never paid attention to the echo area and I just noticed that 
it displays the following message


"cells in region copied, use M-x org-table-paste-rectangle to paste them 
in a table"


when I C-c C-c on the formula in the following table

| 1 |
| 2 |
| 3 |
|   |
#+tblfm: @>$>=vsum(@1..@>>)

The correct result is returned.

Have I been ignoring something for the past several years, i.e. has the 
above message always been displayed?


Just wondering.

Charlie Millar

Re: [O] Make org-fill-paragraph behave as Emacs 26.1 fill-paragraph

[Nicolas Goaziou]

Hello,

Vicente Vera  writes:

> The 'next' branch will be merged with 'master' for Org 9.2 release?

No. "next" will be merged with master after Org 9.2 release. So it's
really for Org 9.3.

Regards,

-- 
Nicolas Goaziou

Re: [O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode

[Eli Zaretskii]

> From: ST 
> Cc: m...@nicolasgoaziou.fr, Emacs-orgmode@gnu.org
> Date: Sun, 17 Jun 2018 19:47:31 +0300
> 
> > I agree with (1) and (2), but your conclusion doesn't follow from
> > that.  The value nil means that the base directionality of
> > _each_paragraph_ is determined dynamically.  It does NOT mean that the
> > whole buffer will have the same directionality for all of its
> > paragraphs.  With nil, some paragraphs could have RTL direction, and
> > others LTR.  Worse, headings could have one direction and their bodies
> > another.  A single character at the beginning of a paragraph might
> > change that paragraph's base direction.  You don't want that with your
> > users.
> 
> All troubles that you describe here are relevant only for mixed ltr/rtl
> texts ("a single character" is an ltr character inside an rtl text,
> isn't it?), but we have agreed to exclude those as per (1). Can you give
> an example of pure rtl text with the issues mentioned above?

See the original problem description, the URL that was cited
up-thread.  It describes slow scrolling that happened in a pure LTR
Org buffer, and was solved by the setting I proposed.

> > Users of RTL languages should have bidi-paragraph-direction in Org
> > buffers set to right-to-left, not to nil.  The value of nil will
> > sometimes cause the heading to appear at the left while the body
> > appears on the right, or vice versa, which is the worst of all worlds.
> 
> Again, only for mixed ltr/rtl texts, until you prove (by example)
> otherwise.

The current default is better because it covers also those mixed
examples.

> If you don't have a counter-example, nil is better since that way you
> have one default setting for ALL buffers and you can work with BOTH ltr
> and rtl texts with the same config without the need to change anything.
> Contrary to mixed ltr/rtl texts - working with pure ltr texts is common
> also for rtl people.

We are going in rounds, and you don't convince me.  IME, such disputes
about defaults are rarely useful or constructive, because it is easy
to change the default, like I already said.

> >   That's what MS-Word users do all the time, right?
> 
> Yes, but they are used to buttons_check-boxes stuff, not lisp config
> files.

I suggested earlier to set up a site-wide init file, so that your
users won't have to be bothered by the problem.

Re: [O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode

[ST]

On Sun, 2018-06-17 at 16:10 +0300, Eli Zaretskii wrote:
> > From: ST 
> > Cc: Nicolas Goaziou , Emacs-orgmode@gnu.org
> > Date: Sun, 17 Jun 2018 15:29:58 +0300
> > 
> > 1. Do you agree that the vast majority of all the documents in human
> > history were/are EITHER ltr OR rtl? Meaning that mixed ltr/rtl texts are
> > minority that we should not take care of...
> > 2. Do you agree that for pure ltr texts org headings should appear to
> > the left and for pure rtl texts org headings should appear to the right?
> > 
> > If you agree with both (1) and (2) - we should put nil as default value,
> > as this will enable (2).
> 
> I agree with (1) and (2), but your conclusion doesn't follow from
> that.  The value nil means that the base directionality of
> _each_paragraph_ is determined dynamically.  It does NOT mean that the
> whole buffer will have the same directionality for all of its
> paragraphs.  With nil, some paragraphs could have RTL direction, and
> others LTR.  Worse, headings could have one direction and their bodies
> another.  A single character at the beginning of a paragraph might
> change that paragraph's base direction.  You don't want that with your
> users.

All troubles that you describe here are relevant only for mixed ltr/rtl
texts ("a single character" is an ltr character inside an rtl text,
isn't it?), but we have agreed to exclude those as per (1). Can you give
an example of pure rtl text with the issues mentioned above?

> 
> > I'm so eager to change the defaults because we start a project where we
> > have many non_technically_savvy Windows-people who need to edit rtl org
> > files in Emacs (which is a challenge on its own). So we want the
> > experience to be as smooth as possible, but right now rtl users are
> > disadvantaged for no reason (as with nil - BOTH ltr AND rtl views can be
> > achieved).
> 
> Users of RTL languages should have bidi-paragraph-direction in Org
> buffers set to right-to-left, not to nil.  The value of nil will
> sometimes cause the heading to appear at the left while the body
> appears on the right, or vice versa, which is the worst of all worlds.

Again, only for mixed ltr/rtl texts, until you prove (by example)
otherwise.

> I see no reason why non-technically-savvy people couldn't learn that
> they need to set a variable when they start editing text of a known
> directionality.

If you don't have a counter-example, nil is better since that way you
have one default setting for ALL buffers and you can work with BOTH ltr
and rtl texts with the same config without the need to change anything.
Contrary to mixed ltr/rtl texts - working with pure ltr texts is common
also for rtl people.

>   That's what MS-Word users do all the time, right?

Yes, but they are used to buttons_check-boxes stuff, not lisp config
files.

Thanks!

Re: [O] Make org-fill-paragraph behave as Emacs 26.1 fill-paragraph

[Vicente Vera]

Nice, thanks.
The 'next' branch will be merged with 'master' for Org 9.2 release?

El jue, jun 14, 2018 16:07, Nicolas Goaziou 
escribió:

> Hello,
>
> Vicente Vera  writes:
>
> > Since Emacs 26.1 ‘fill-paragraph’ doesn't change the buffer contents
> > if no filling is needed on the current paragraph. It would be nice if
> > ‘org-fill-paragraph’ worked the same way.
> >
> > Not a very relevant change to make, really, but still. Just to avoid
> > those pesky false-positive asteriks!
>
> Implemented in "next" branch. Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode

[Eli Zaretskii]

> From: ST 
> Cc: Nicolas Goaziou , Emacs-orgmode@gnu.org
> Date: Sun, 17 Jun 2018 15:29:58 +0300
> 
> 1. Do you agree that the vast majority of all the documents in human
> history were/are EITHER ltr OR rtl? Meaning that mixed ltr/rtl texts are
> minority that we should not take care of...
> 2. Do you agree that for pure ltr texts org headings should appear to
> the left and for pure rtl texts org headings should appear to the right?
> 
> If you agree with both (1) and (2) - we should put nil as default value,
> as this will enable (2).

I agree with (1) and (2), but your conclusion doesn't follow from
that.  The value nil means that the base directionality of
_each_paragraph_ is determined dynamically.  It does NOT mean that the
whole buffer will have the same directionality for all of its
paragraphs.  With nil, some paragraphs could have RTL direction, and
others LTR.  Worse, headings could have one direction and their bodies
another.  A single character at the beginning of a paragraph might
change that paragraph's base direction.  You don't want that with your
users.

> I'm so eager to change the defaults because we start a project where we
> have many non_technically_savvy Windows-people who need to edit rtl org
> files in Emacs (which is a challenge on its own). So we want the
> experience to be as smooth as possible, but right now rtl users are
> disadvantaged for no reason (as with nil - BOTH ltr AND rtl views can be
> achieved).

Users of RTL languages should have bidi-paragraph-direction in Org
buffers set to right-to-left, not to nil.  The value of nil will
sometimes cause the heading to appear at the left while the body
appears on the right, or vice versa, which is the worst of all worlds.

I see no reason why non-technically-savvy people couldn't learn that
they need to set a variable when they start editing text of a known
directionality.  That's what MS-Word users do all the time, right?
And if you want to make it even easier for them, make a site-wide init
file they will all use.

Re: [O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode

[ST]

On Sun, 2018-06-17 at 09:12 +0300, Eli Zaretskii wrote:
> > From: Nicolas Goaziou 
> > Cc: Emacs-orgmode@gnu.org
> > Date: Fri, 15 Jun 2018 16:05:37 +0200
> > 
> > ST  writes:
> > 
> > > Please leave the Emacs' default value of "bidi-paragraph-direction"
> > > which is "nil" in orgmode as well. Right now orgmode seems to force
> > > "left-to-right", thus blocking "right-to-left". With "nil" it is
> > > dynamic, which means both directions work well out-of-the box.
> > >
> > > Right now I'm forced to add this to my config:
> > >
> > > (add-hook 'org-mode-hook 
> > >   (lambda ()
> > > (setq bidi-paragraph-direction nil)))
> > >
> > > It took me a lot of time to figure out, which makes the first Org steps
> > > for RTL-newbies quite frustrating...
> > 
> > It may not be as obvious as you think. See
> > 
> > for details.
> 
> For the record: The change to the current default was my suggestion,
> and I still stand by that advice.  I think the current default is
> correct out of the box for more people than the previous nil value.
> And I see no catastrophe in a mode hook that overrides the default for
> those who don't like this default.  The defaults cannot possibly DTRT
> for everyone, only for the majority.

That's exactly what I want to achieve - reasonable defaults for the
majority. Let's clarify:

1. Do you agree that the vast majority of all the documents in human
history were/are EITHER ltr OR rtl? Meaning that mixed ltr/rtl texts are
minority that we should not take care of...
2. Do you agree that for pure ltr texts org headings should appear to
the left and for pure rtl texts org headings should appear to the right?

If you agree with both (1) and (2) - we should put nil as default value,
as this will enable (2).

I'm so eager to change the defaults because we start a project where we
have many non_technically_savvy Windows-people who need to edit rtl org
files in Emacs (which is a challenge on its own). So we want the
experience to be as smooth as possible, but right now rtl users are
disadvantaged for no reason (as with nil - BOTH ltr AND rtl views can be
achieved).

Thank you!

Re: [O] [PATCH] No completion when querying for property value in capture template

[Eric Danan]

Indeed it works now, thanks!
On Sat, Jun 16, 2018 at 11:24 PM Nicolas Goaziou  wrote:
>
> Eric Danan  writes:
>
> > I did some testing and it seems towork except in one case: if the
> > template target is of type "file+headline" (I guess "file+olp" etc as
> > well), the target file has an in-buffer setting "#+PROPERTY PROP_ALL
> > AAA BBB", and the target entry has a property ":PROP_ALL:  CCC DDD"
> > overriding the in-buffer setting, then completion is done on "AAA BBB"
> > whereas it would make more sense to me to do it on "CCC DDD".
>
> I think this is now fixed. Thank you.

Re: [O] ox-texinfo: use an Org section as Info Top node

[Nicolas Goaziou]

Hello,

Jonas Bernoulli  writes:

> Currently ox-texinfo uses the text before the first Org section as the
> "Top" Info node.  That is fine for manuals like org-manual.org where
> that part of the document only consists of a few lines.  In my manuals
> there are up to 40 lines before the first heading, which makes it
> desirable to make that part of the document collapsible.

You can use a drawer for that:

:PREAMBLE:
...
:END:

> It is already possible to set the section whose content is to be used
> on the copyright page (and which can be inserted elsewhere using
> "#+texinfo: @insertcopying") using the COPYING property.
>
> Could you please implement something similar for the "Top" node, using
> a property such as TOP?

This sounds awkward, e.g., what would become the text before the first
heading? AFAIU, there no really need for it, isn't it?

Regards,

-- 
Nicolas Goaziou