[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2017-12-04 Thread Ben Finney
On 04-Dec-2017, Nicolas Goaziou wrote:
> Any 9.X version certainly contains the fix.

Using this version of ‘org-mode’:

Org mode version 9.1.2 (9.1.2-dist @ 
/usr/share/emacs/25.2/site-lisp/elpa/org-9.0.9/)

I confirm that the display of the report is much better:

| Headline| Time   |  |  |
|-++--+--|
| *Total time*| *0:20* |  |  |
|-++--+--|
| Lorem ipsum, dolor sit amet | 0:20   |  |  |
| \_  Suscipit sint quod  || 0:13 |  |
| \_  Ab facilis nulla|| 0:07 |  |
| \_Dolore laborum||  | 0:07 |

Thank you to the Org developers for resolving this bug.

-- 
 \  “A thing moderately good is not so good as it ought to be. |
  `\Moderation in temper is always a virtue; but moderation in |
_o__)   principle is always a vice.” —Thomas Paine |
Ben Finney 


signature.asc
Description: PGP signature


[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2017-12-04 Thread Nicolas Goaziou
Hello,

Ben Finney  writes:

> On 04-Dec-2017, Nicolas Goaziou wrote:
>> Ben Finney  writes:
>> > How can we test the change, to know whether this bug is resolved?
>> 
>> You can test the latest ELPA release, scheduled for today
>
> Please state the exact version string, so that we can compare to see
> whether we're using one that meets your description.

We are talking about a 2 years old fix, so exact release doesn't really
matter, really. Any 9.X version certainly contains the fix.

Regards,

-- 
Nicolas Goaziou





[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2017-12-04 Thread Ben Finney
On 04-Dec-2017, Nicolas Goaziou wrote:
> Ben Finney  writes:
> > How can we test the change, to know whether this bug is resolved?
> 
> You can test the latest ELPA release, scheduled for today

Please state the exact version string, so that we can compare to see
whether we're using one that meets your description.

-- 
 \   “We must find our way to a time when faith, without evidence, |
  `\disgraces anyone who would claim it.” —Sam Harris, _The End of |
_o__) Faith_, 2004 |
Ben Finney 


signature.asc
Description: PGP signature


[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2017-12-03 Thread Nicolas Goaziou
Hello,

Ben Finney  writes:

> On 22-Aug-2016, Nicolas Goaziou wrote:
>> The display for clock reports has been changed some months ago in
>> development version.
>
> Which version contains this change?
>
>> I think this bug can be closed.
>
> How can we test the change, to know whether this bug is resolved?

You can test the latest ELPA release, scheduled for today (the current
ELPA release also contains the bug but has a nasty fontification bug
too).

You can also test Org bundled with Emacs 26.0.50.

Regards,

-- 
Nicolas Goaziou





[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2017-12-03 Thread Ben Finney
On 22-Aug-2016, Nicolas Goaziou wrote:
> The display for clock reports has been changed some months ago in
> development version.

Which version contains this change?

> I think this bug can be closed.

How can we test the change, to know whether this bug is resolved?

-- 
 \   “Instead of having ‘answers’ on a math test, they should just |
  `\   call them ‘impressions’, and if you got a different |
_o__)   ‘impression’, so what, can't we all be brothers?” —Jack Handey |
Ben Finney 


signature.asc
Description: PGP signature


[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2017-12-01 Thread Nicolas Goaziou
Nicolas Goaziou  writes:

> Nicolas Goaziou  writes:
>
>> The trick could be to use an Org entity which is as large as its
>> overlay. Even better if that entity is readable without that overlay.
>> I'll look into it soon.
>
> This should now be fixed. The markup used is more readable and doesn't
> alter table alignment.

Could this bug be marked as done? Thank you.

Regards,





[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2017-12-01 Thread Glenn Morris
Nicolas Goaziou wrote:

> Could this bug be marked as done? Thank you.

Anyone can close any bug by sending mail to eg 18870-done at debbugs.

(Thanks for looking at these reports.)





[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2017-12-01 Thread Nicolas Goaziou
Hello,

Glenn Morris  writes:

> Nicolas Goaziou wrote:
>
>> Could this bug be marked as done? Thank you.
>
> Anyone can close any bug by sending mail to eg 18870-done at debbugs.

Indeed! Closing it right now. Thank you.

> (Thanks for looking at these reports.)

(You're welcome.)

Regards,

-- 
Nicolas Goaziou0x80A93738





[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2016-08-22 Thread Nicolas Goaziou
Hello,

Sriram Karra  writes:

> I find the above reasoning completely broken. Why is the above choice
> considered the right tradeoff when there is no easy way to get something
> sensible (with or without configuration) for display? Do more people export
> rather than view?

The display for clock reports has been changed some months ago in
development version. I think this bug can be closed.

Regards,

-- 
Nicolas Goaziou





[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2016-08-22 Thread Sriram Karra
On Wed, Mar 18, 2015 at 2:39 AM, Nicolas Goaziou 
wrote:

> Hello,
>
> Ben Finney  writes:
>

 [...]

> The "\emsp" should be space characters (of some kind; either U+0020 SPC
> > or U+2003 EM SPACE) with correct alignment for the character width.
> > Displaying literal "\emsp" is a regression and should not happen.
>
> This is not a regression. This change favors a correct export over
> a correct display.
>

I recently upgraded to a new machine and got the updated org-mode (8.2.10)
with Aquamacs 3.2 and ran into this problem

I find the above reasoning completely broken. Why is the above choice
considered the right tradeoff when there is no easy way to get something
sensible (with or without configuration) for display? Do more people export
rather than view?


Re: [O] bug#18870: bug#18870: \emsp and alignment in org clock report

2015-03-23 Thread J. David Boyd
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 The trick could be to use an Org entity which is as large as its
 overlay. Even better if that entity is readable without that overlay.
 I'll look into it soon.

 This should now be fixed. The markup used is more readable and doesn't
 alter table alignment.

Thanks very much, I feel this is much better.  I can read the columns ok, and
they export fine too.

Thanks for all your efforts in Org-mode!

Dave in Hudson, FL




[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2015-03-22 Thread Nicolas Goaziou
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 The trick could be to use an Org entity which is as large as its
 overlay. Even better if that entity is readable without that overlay.
 I'll look into it soon.

This should now be fixed. The markup used is more readable and doesn't
alter table alignment.





[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2015-03-21 Thread Nicolas Goaziou
Leo Ufimtsev lufim...@redhat.com writes:

 Interesting, I didn't know that. Thank you for pointing it out.

 Maybe then just go along with the variable that would give people the choice, 
 (I wouldn't mind '\emsp' being the default, so long as it can be
 changed to something else).

Having a variable to choose in which way Org should be broken doesn't
sound great to me.

The trick could be to use an Org entity which is as large as its
overlay. Even better if that entity is readable without that overlay.
I'll look into it soon.


Regards,





[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2015-03-19 Thread Leo Ufimtsev
Interesting, I didn't know that. Thank you for pointing it out.

Maybe then just go along with the variable that would give people the choice, 
(I wouldn't mind '\emsp' being the default, so long as it can be changed to 
something else).

Thoughts?

Leo Ufimtsev | Intern Software Engineer @ Eclipse Team

- Original Message -
From: Subhan Michael Tindall subh...@familycareinc.org
To: Leo Ufimtsev lufim...@redhat.com, Nicolas Goaziou 
m...@nicolasgoaziou.fr
Cc: Ben Finney ben+em...@benfinney.id.au, 18...@debbugs.gnu.org
Sent: Thursday, March 19, 2015 12:48:40 PM
Subject: [O] bug#18870: \emsp and alignment in org clock report

Agendas can  do get exported.  Current agenda buffer can be exported using 
org-agenda-write to several formats. Custom agendas can be assigned file 
name(s) and automatically export to one or more file types. 

See: http://orgmode.org/manual/Exporting-Agenda-Views.html


 -Original Message-
 From: emacs-orgmode-bounces+subhant=familycareinc@gnu.org
 [mailto:emacs-orgmode-bounces+subhant=familycareinc@gnu.org] On
 Behalf Of Leo Ufimtsev
 Sent: Wednesday, March 18, 2015 2:10 PM
 To: Nicolas Goaziou
 Cc: Ben Finney; 18...@debbugs.gnu.org
 Subject: [O] bug#18870: bug#18870: \emsp and alignment in org clock report
 
 I can't speak for the technical details,
 
 but I get the sense that \emsp isn't the right thing to be displayed on an
 *agenda clock report* because agenda clock reports don't get exported
 (afaik).
 
 Even \__ is more preffered than an \emsp, as \emsp is not 'easy to read' per
 se.
 
 Since there are clearly difference in opinions, maybe a solution is to have a
 variable like 'org-clockreport-indentation-character' which defaults to \emsp
 for correct export, but could be changed to spaces or '\__' by the user. This
 would give people the choice between better export or better text-buffer
 display.
 
 Thoughts?
 
 Leo Ufimtsev | Intern Software Engineer @ Eclipse Team
 
 - Original Message -
 From: Nicolas Goaziou m...@nicolasgoaziou.fr
 To: Ben Finney ben+em...@benfinney.id.au
 Cc: 18...@debbugs.gnu.org
 Sent: Tuesday, March 17, 2015 6:07:03 PM
 Subject: [O] bug#18870: \emsp and alignment in org clock report
 
 Ben Finney ben+em...@benfinney.id.au writes:
 
  The behaviour described – displaying “\emsp” instead of space
  characters – is a regression. That's what is being reported in this
  bug.
 
 There wasn't space characters in the first place, but \___ constructs.
 See commit bacfe5b4f7244eaf151f4e26a1d94dd8f66c1d19.
 
 Also, the bug is about table alignment when `org-pretty-entities' is used.
 
  Having some space character is not desirable as it would just move
  the problem the other way around (i.e., indentation would not appear
  during export)
 
  So the U+2003 EM SPACE character should be translated *during export*,
  and not be literally in the displayed text.
 
 No, because it means this character should be treated specially by Org (e.g.,
 LaTeX just ignores it so it needs to be turned into a space there).
 
 This is not a good idea, especially considering it is an invisible character.
 
  IS the above suggestion an acceptable solution?
 
 No, it isn't.
 
 An acceptable solution would be a character or a string that looks decent
 both in the buffer and in an exported document, without further processing.
 
  Note that this is not LaTeX-specific markup. This is called an
  entity, and is correctly exported in various back-ends.
 
  But not for display, which is the bug to be fixed here.
 
 Actually, it works more or less correctly for display on GUI with a non-nil 
 `org-
 pretty-entities', or calling `org-toggle-pretty-entities'.
 
 Regards,
 
 
 
 
 


This message is intended for the sole use of the individual and entity to which 
it is addressed and may contain information that is privileged, confidential 
and exempt from disclosure under applicable law. If you are not the intended 
addressee, nor authorized to receive for the intended addressee, you are hereby 
notified that you may not use, copy, disclose or distribute to anyone the 
message or any information contained in the message. If you have received this 
message in error, please immediately advise the sender by reply email and 
delete the message.  Thank you.





[O] bug#18870: bug#18870: \emsp and alignment in org clock report

2015-03-18 Thread Leo Ufimtsev
I can't speak for the technical details, 

but I get the sense that \emsp isn't the right thing to be displayed on an 
*agenda clock report* because 
agenda clock reports don't get exported (afaik). 

Even \__ is more preffered than an \emsp, as \emsp is not 'easy to read' per se.

Since there are clearly difference in opinions, maybe a solution is to have a 
variable like 'org-clockreport-indentation-character' which defaults to \emsp 
for correct export, but could be changed to spaces or '\__' by the user. This 
would give people the choice between better export or better text-buffer 
display.

Thoughts?

Leo Ufimtsev | Intern Software Engineer @ Eclipse Team

- Original Message -
From: Nicolas Goaziou m...@nicolasgoaziou.fr
To: Ben Finney ben+em...@benfinney.id.au
Cc: 18...@debbugs.gnu.org
Sent: Tuesday, March 17, 2015 6:07:03 PM
Subject: [O] bug#18870: \emsp and alignment in org clock report

Ben Finney ben+em...@benfinney.id.au writes:

 The behaviour described – displaying “\emsp” instead of space
 characters – is a regression. That's what is being reported in this
 bug.

There wasn't space characters in the first place, but \___ constructs.
See commit bacfe5b4f7244eaf151f4e26a1d94dd8f66c1d19. 

Also, the bug is about table alignment when `org-pretty-entities' is
used.

 Having some space character is not desirable as it would just move
 the problem the other way around (i.e., indentation would not appear
 during export)

 So the U+2003 EM SPACE character should be translated *during export*,
 and not be literally in the displayed text.

No, because it means this character should be treated specially by Org
(e.g., LaTeX just ignores it so it needs to be turned into a space
there). 

This is not a good idea, especially considering it is an invisible
character.

 IS the above suggestion an acceptable solution?

No, it isn't. 

An acceptable solution would be a character or a string that looks
decent both in the buffer and in an exported document, without further
processing.

 Note that this is not LaTeX-specific markup. This is called an entity,
 and is correctly exported in various back-ends.

 But not for display, which is the bug to be fixed here.

Actually, it works more or less correctly for display on GUI with
a non-nil `org-pretty-entities', or calling
`org-toggle-pretty-entities'.

Regards,