[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs as word processor / Text Properties
From: |
Jambunathan K |
Subject: |
Re: Emacs as word processor / Text Properties |
Date: |
Fri, 29 Nov 2013 15:21:27 +0530 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
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
- RE: Emacs as word processor / Text Properties, (continued)
- Re: Emacs as word processor / Text Properties, Jambunathan K, 2013/11/29
- Re: Emacs as word processor / Text Properties, Jambunathan K, 2013/11/29
- Re: Emacs as word processor / Text Properties, Bastien, 2013/11/29
- Re: Emacs as word processor / Text Properties, Jambunathan K, 2013/11/29
- Re: Emacs as word processor / Text Properties, Bastien, 2013/11/29
- Re: Emacs as word processor / Text Properties, Eli Zaretskii, 2013/11/29
- Re: Emacs as word processor / Text Properties,
Jambunathan K <=
- Re: Emacs as word processor / Text Properties, Eli Zaretskii, 2013/11/29
- Re: Emacs as word processor / Text Properties, Jambunathan K, 2013/11/29
- Re: Emacs as word processor / Text Properties, Eli Zaretskii, 2013/11/29
- Re: Emacs as word processor / Text Properties, Jambunathan K, 2013/11/29
- Re: Emacs as word processor / Text Properties, Eli Zaretskii, 2013/11/29
- Re: Emacs as word processor / Text Properties, Jambunathan K, 2013/11/29
- Re: Emacs as word processor / Text Properties, Eli Zaretskii, 2013/11/29
- Re: Emacs as word processor / Text Properties, Andreas Röhler, 2013/11/29
- Re: Emacs as word processor / Text Properties, Jambunathan K, 2013/11/29
- Re: Emacs as word processor / Text Properties, Richard Stallman, 2013/11/29