Re: Emacs as word processor / Text Properties

[Jambunathan K]

Eli Zaretskii <address@hidden> writes:

>> From: Jambunathan K <address@hidden>
>> Date: Fri, 29 Nov 2013 14:14:31 +0530
>> Cc: "Pascal J. Bourguignon" <address@hidden>,
>>      Drew Adams <address@hidden>, address@hidden
>> 
>> How about documents that have multiple scripts and one MAY have to
>> fiddle with bidi-settings on a per-element basis.
>
> I must confess I have no idea what you are talking about here: what
> "bidi settings"?

I have a vague understanding of Bidi based on what I read here:

   
https://web.archive.org/web/20130917205858/http://dotancohen.com/howto/rtl_right_to_left.html

>From that link:

,----
| Word Processor documents
| 
| In OpenOffice Writer, pages can be configured as RTL in Format → Page →
| Page → Text Direction. Paragraphs can be configured to RTL in Format →
| Paragraph → Alignment → Text Direction.
`----

,----
| HTML code
| 
| HTML is fairly straightforward to configure for RTL. Like word
| processors documents, entire pages or individual paragraphs can be set
| to RTL.
`----

Let me ask you a question back:

What if I want a bidi-paragraph-direction where the "directionality is
UNLIKE the first strong directional character".

Emacs cannot do that.

ps: When I ask this question, I assume that the people who wrote the
standards have good enough reasons to introduce tag paragraph
"explicitly".

,----
| bidi-paragraph-direction is a variable defined in `C source code'.
| Its value is nil
| 
|   Automatically becomes buffer-local when set.
|   This variable is safe as a file local variable if its value
|   satisfies the predicate which is a byte-compiled expression.
| 
| Documentation:
| If non-nil, forces directionality of text paragraphs in the buffer.
| 
| If this is nil (the default), the direction of each paragraph is
| determined by the first strong directional character of its text.
| The values of `right-to-left' and `left-to-right' override that.
| Any other value is treated as nil.
| 
`----

>> (Things like Bidi are not only about aesthetics but also tied
>> directly to the "content".)
>
> Again, if this is a real issue, please elaborate.  Bidi is neither
> about aesthetics nor about "content", it's about displaying certain
> scripts as their readers require.  To understand that, imagine that
> you need to read English text where the order of the characters was
> reversed.  I guess you won't be amused.

I was responding to Raman and merely noting that word-processing mode
cannot be discerned just in terms of aesthetics or content alone.
Directonality is neither about aesthetic nor about content but about
convention.  It falls in a no-man land.

>> Now if you want to have Tables with Bidi-text then Orgmode is
>> practically useless.
>
> "Practically useless" is a wild exaggeration.  I use it just fine.

This is not a criticism of Bidi.  This thread is about why an
word-processing mode would make sense INSPITE of powerfulness of
Org-mode.


Currently, in Org-mode, one cannot have multi-paragraph tables.
Assuming that in near future, it does support such tables, how would one
go about fixing the directionality.

> But yes, there are several features of the UBA that Emacs supports
> which can improve this.  Org Mode should use those features when
> appropriate.  Unfortunately, too many Emacs modes, Org included, still
> treat text as a unidirectional stream of characters that will keep
> their logical order on display, and don't cater enough to the needs of
> bidirectional scripts.  I expect Org users who work with those scripts
> to submit bug reports with specific use cases, and ask the Org
> maintainers to use the above-mentioned features.

Bottom line is this:

Org-mode is useful in practice but it falls way short of being a
"complete" system.  It is here that a word-processing mode will be
extremely useful.

Let me re-iterate, I am responding to Raman whose comment vaguely
implied that the coupling between content and display is loose enough to
the point of being non-existent and that content with a very lightweight
markup would serve "complete" set of needs.

Here is a case of Chinese user saying that Org's notion of emphasis
markers is in conflict with the realities of his language.

http://lists.gnu.org/archive/html/emacs-orgmode/2012-11/msg00564.html