emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Leo Ufimtsev
Subject: [O] bug#18870: bug#18870: \emsp and alignment in org clock report
Date: Wed, 18 Mar 2015 17:10:20 -0400 (EDT)

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" <address@hidden>
To: "Ben Finney" <address@hidden>
Cc: address@hidden
Sent: Tuesday, March 17, 2015 6:07:03 PM
Subject: [O] bug#18870: \emsp and alignment in org clock report

Ben Finney <address@hidden> 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,








reply via email to

[Prev in Thread] Current Thread [Next in Thread]