> Date: Mon, 4 Feb 2019 21:00:55 +
> From: Richard Wordingham via Unicode
>
> > The definition is trivial: the order of characters on
> > display, from left to right. The only possible reason to split hairs
> > here could be when some characters don't appear on display, like
> > control
Hi,
> To me, 'visual order' means in the dominant order of the script.
This is not a definition I've come across anywhere else, nor matches
my intuition of "visual order" : the exact visual order (recursive
definition, yay!) of how you see the glyphs being displayed in the
row.
> So,
> if one
On 2/4/2019 1:00 PM, Richard Wordingham
via Unicode wrote:
To me, 'visual order' means in the dominant order of the script.
Visual order is a term of art, meaning the characters are ordered
in memory in the same order as they are displayed on the
On Sun, 3 Feb 2019 20:50:03 +
Richard Wordingham via Unicode wrote:
> On Sun, 03 Feb 2019 20:07:51 +0200
> Eli Zaretskii via Unicode wrote:
> Which is why I try to remember to issue the emacs command 'M-x shell'
> command and issue grep commands from the buffer created thereby. The
>
On Sun, 03 Feb 2019 18:03:37 +0200
Eli Zaretskii via Unicode wrote:
> > Date: Sun, 3 Feb 2019 03:02:13 +0100
> > Cc: unicode@unicode.org
> > From: Egmont Koblinger via Unicode
> >
> > > All I am saying is that your proposal should define what it means
> > > by visual order.
> >
> > Are
> Date: Mon, 04 Feb 2019 05:25:43 +0200
> Cc: unicode@unicode.org
> From: Eli Zaretskii via Unicode
>
> Try customizing scroll-conservatively, it sounds like you want that.
Ignore me: I misunderstood what you were looking for. You are right:
Emacs doesn't support such scrolling method.
> Date: Sun, 3 Feb 2019 20:35:18 +
> From: Richard Wordingham via Unicode
>
> > What is "screen overwriting" in this context?
>
> When instead of adding lines to the bottom, new lines are added on top
> of and replace existing lines. I prefer the scrollable terminal
> behaviour to the
On Sun, 03 Feb 2019 18:13:06 +0200
Eli Zaretskii via Unicode wrote:
> Actually, you pass the characters to be shaped in logical order, and
> then display the produced grapheme clusters in visual order.
Some early systems supporting computerised Hebrew script did pass
characters in left-to-right
On Sun, 03 Feb 2019 20:07:51 +0200
Eli Zaretskii via Unicode wrote:
> > Date: Sun, 3 Feb 2019 17:45:06 +
> > From: Richard Wordingham via Unicode
> >
> > > > So, what do you recommend I run grep from for Hebrew or Tai
> > > > Lue?
> > >
> > > Inside Emacs, of course: "M-x grep RET"
On Sun, 03 Feb 2019 18:05:49 +0200
Eli Zaretskii via Unicode wrote:
> > Date: Sat, 2 Feb 2019 21:49:40 +
> > From: Richard Wordingham via Unicode
> >
> > Eli will probably tell me I'm behind the times, but there are a few
> > places where a Gnome-terminal is better than an Emacs GUI
> Date: Sun, 3 Feb 2019 17:45:06 +
> From: Richard Wordingham via Unicode
>
> > > So, what do you recommend I run grep from for Hebrew or Tai Lue?
> >
> > Inside Emacs, of course: "M-x grep RET" etc.
>
> That assumes you like using bindings for all the commands; I don't.
What bindings?
On Sun, 03 Feb 2019 18:14:53 +0200
Eli Zaretskii via Unicode wrote:
> > Date: Sun, 3 Feb 2019 02:43:06 +
> > Cc: Kent Karlsson
> > From: Richard Wordingham via Unicode
> >
> > So, what do you recommend I run grep from for Hebrew or Tai Lue?
>
> Inside Emacs, of course: "M-x grep RET"
> Date: Sun, 3 Feb 2019 02:43:06 +
> Cc: Kent Karlsson
> From: Richard Wordingham via Unicode
>
> So, what do you recommend I run grep from for Hebrew or Tai Lue?
Inside Emacs, of course: "M-x grep RET" etc.
> Date: Sun, 3 Feb 2019 01:30:26 +
> From: Richard Wordingham via Unicode
>
> Shaping for RTL scripts happens on strings stored in logical order.
> These are then laid out right to left, though the dominant usage of
> the term 'advance width' for right-to-left glyph sequences feels
>
> Date: Sat, 2 Feb 2019 23:02:10 +0100
> Cc: unicode@unicode.org
> From: Egmont Koblinger via Unicode
>
> On top of this, I make the clarification that combining marks need to
> be reordered to be sent out to the terminal emulator _after_ their
> base letter
That is true in general regarding
> Date: Sat, 2 Feb 2019 21:49:40 +
> From: Richard Wordingham via Unicode
>
> Eli will probably tell me I'm behind the times, but there are a few
> places where a Gnome-terminal is better than an Emacs GUI window. One
> is colour highlighting of text found by grep.
??? The Emacs 'grep'
> Date: Sun, 3 Feb 2019 03:02:13 +0100
> Cc: unicode@unicode.org
> From: Egmont Koblinger via Unicode
>
> > All I am saying is that your proposal should define what it means by
> > visual order.
>
> Are you nitpicking on me not giving a precise definition on the
> otherwise IMO freaking obvious
On Sun, 03 Feb 2019 02:01:18 +0100
Kent Karlsson via Unicode wrote:
> Den 2019-02-02 16:12, skrev "Richard Wordingham via Unicode"
> :
> > Doesn't Jerusalem in biblical Hebrew sometime have 3 marks below the
> > lamedh? The depth then is the maximum depth, not the sum of the
> > depths.
>
Hi Richard,
On Sun, Feb 3, 2019 at 2:32 AM Richard Wordingham via Unicode
wrote:
> That first reference doesn't even use the word 'visual'.
The Unicode BiDi algorithm does speak about "visual positions for
display", "reordering for display" etc.
> All I am saying is that your proposal should
On Sat, 2 Feb 2019 23:02:10 +0100
Egmont Koblinger via Unicode wrote:
> Hi Richard,
>
> On Sat, Feb 2, 2019 at 9:57 PM Richard Wordingham
> wrote:
>
> > Seriously, you need to give a definition of 'visual order' for this
> > context. Not everyone shares your chiralist view.
>
> When I
Den 2019-02-02 16:12, skrev "Richard Wordingham via Unicode"
:
> On Sat, 02 Feb 2019 14:01:46 +0100
> Kent Karlsson via Unicode wrote:
>
>> Well, I guess you may need to put some (practical) limit to the number
>> of non-spacing marks (like max two above + max one below; overstrikes
>> are an
Hi Richard,
> Benjamin Riefenstahl wrote:
>> the severe limitations of that environment.
Richard Wordingham writes:
> Eli will probably tell me I'm behind the times, but there are a few
> places where a Gnome-terminal is better than an Emacs GUI window. One
> is colour highlighting of text
Hi Richard,
> My main interest in this, though, is in improving the general run of
> Indic terminal cell editors. If we can get Gnome-terminal working for
> Kharoshthi, things should improve for LTR Indic. Even working on the
> false assumption that Indic scripts are like Devanagari would be an
Hi Richard,
On Sat, Feb 2, 2019 at 9:57 PM Richard Wordingham
wrote:
> Seriously, you need to give a definition of 'visual order' for this
> context. Not everyone shares your chiralist view.
When I look at the Unicode BiDi algorithm, or go to an online demo at
On Sat, 2 Feb 2019 12:54:16 +0100
Egmont Koblinger via Unicode wrote:
> Hi Richard,
>
> > > Are they okay to be present in visual order (the terminal's
> > > explicit mode, what we're discussing now) too?
> >
> > Where do you define the order for explicit mode?
>
> In explicit mode, the
Richard Wordingham wrote:
> Unicode may not deprecate the tag characters, but the characters of
> Plane 14 are widely deplored, despised or abhorred. That is why I
> think of it as the deprecated plane.
Think of it as the deplored plane, then, or the despised plane or the abhorred
plane or the
Philippe Verdy wrote:
> Actually not all U+E0020 through U+E007E are "un-deprecated" for this
> use.
Characters in Unicode are not "deprecated" for some purposes and not for
others. "Deprecated" is a clearly defined property in Unicode. The only
reference that matters here is in PropList.txt:
Hi Egmont, hi all,
This is a interesting discussion here. If only because I would have
thought that there is only minimal interest by the actual target
audience in supporting these scripts in a terminal, given the severe
limitations of that environment. The most important limitation seems to
On Sat, 2 Feb 2019 13:18:03 +0100
Egmont Koblinger via Unicode wrote:
> Hi Richard,
>
> On Sat, Feb 2, 2019 at 12:43 PM Richard Wordingham via Unicode
> wrote:
>
> > I'm not conversant with the details of terminal controls and I
> > haven't used fields. However, where I spoke of lines above,
On Sat, 02 Feb 2019 14:01:46 +0100
Kent Karlsson via Unicode wrote:
> Den 2019-02-02 12:17, skrev "Egmont Koblinger" :
> > Most terminal emulators handle non-spacing combining marks, it's a
> > piece of cake. (Spacing marks are more problematic.)
> Well, I guess you may need to put some
Actually not all U+E0020 through U+E007E are "un-deprecated" for this use.
For now emoji flags only use:
- U+E0041 through U+E005A (mapping to ASCII letters A through Z used in
2-letter ISO3166-1 codes). These are usable in pairs, without requiring any
modifier (and only for ISO3166-1 registered
Den 2019-02-02 12:17, skrev "Egmont Koblinger" :
> the font. It's taken from EastAsianWidth (or other means, which we're
> working on: https://gitlab.freedesktop.org/terminal-wg/specifications/issues/9
Yes, that too:
FE0F ? VARIATION SELECTOR-16 = emoji variation selector
But the issue you
Hi Richard,
On Sat, Feb 2, 2019 at 12:43 PM Richard Wordingham via Unicode
wrote:
> I'm not conversant with the details of terminal controls and I haven't
> used fields. However, where I spoke of lines above, I believe you can
> simply translate it to fields. I don't know how one best handles
Hi Richard,
> Not all terminal emulators can deal with non-spacing combining
> characters.
Both Hebrew and Arabic seem to use non-spacing combining characters,
presumably other Arabic-like scripts too.
I forgot to state explicitly in my docs, but let's just say that
handling non-spacing
Hi Richard,
> > Are they okay to be present in visual order (the terminal's explicit
> > mode, what we're discussing now) too?
>
> Where do you define the order for explicit mode?
In explicit mode, the application (Emacs, Vim, whatever) reorders the
characters, and passes visual order (left to
On Fri, 1 Feb 2019 15:15:53 +0100
Egmont Koblinger via Unicode wrote:
> Hi Richard,
>
> On Fri, Feb 1, 2019 at 12:19 AM Richard Wordingham via Unicode
> wrote:
>
> > Cropped why? If the problem is the truncation of lines, one can
> > simple store the next character.
>
> Yup, trancation of
Hi Kent,
On Sat, Feb 2, 2019 at 12:41 AM Kent Karlsson via Unicode
wrote:
> [...] neither of which
> should directly consult the font [...]
> But terminals
> (read terminal emulators) can deal with mixed single width and double
> width characters (which is, IIUC, the motivation for the datafile
On Fri, 1 Feb 2019 15:15:53 +0100
Egmont Koblinger via Unicode wrote:
> Hi Richard,
>
> On Fri, Feb 1, 2019 at 12:19 AM Richard Wordingham via Unicode
> wrote:
>
> > Cropped why? If the problem is the truncation of lines, one can
> > simple store the next character.
>
> Yup, trancation of
On Sat, 02 Feb 2019 00:38:04 +0100
Kent Karlsson via Unicode wrote:
> Den 2019-02-01 19:57, skrev "Richard Wordingham via Unicode"
> :
> "Monospaced font" is really a concept with modification. Even for
> "plain old ASCII" there are two advance widths, not just one: 0 for
> control characters
On Fri, 01 Feb 2019 15:18:13 -0700
Doug Ewell via Unicode wrote:
> Richard Wordingham wrote:
>
> > Language tagging is already available in Unicode, via the tag
> > characters in the deprecated plane.
>
> Plane 14 isn't deprecated -- that isn't a property of planes -- and
> the tag
On Fri, Feb 01, 2019 at 06:57:43PM +, Richard Wordingham via Unicode wrote:
> On Fri, 1 Feb 2019 13:02:45 +0200
> Khaled Hosny via Unicode wrote:
>
> > On Thu, Jan 31, 2019 at 11:17:19PM +, Richard Wordingham via
> > Unicode wrote:
> > > On Thu, 31 Jan 2019 12:46:48 +0100
> > > Egmont
Den 2019-02-01 19:57, skrev "Richard Wordingham via Unicode"
:
> On Fri, 1 Feb 2019 13:02:45 +0200
> Khaled Hosny via Unicode wrote:
>
>> On Thu, Jan 31, 2019 at 11:17:19PM +, Richard Wordingham via
>> Unicode wrote:
>>> On Thu, 31 Jan 2019 12:46:48 +0100
>>> Egmont Koblinger wrote:
>>>
Richard,
On 2/1/2019 1:30 PM, Richard Wordingham via Unicode wrote:
Language tagging is already available in Unicode, via the tag characters
in the deprecated plane.
Recte:
1. Plane 14 is not a "deprecated plane".
2. The tag characters in Tag Character block (U+E..U+E007F) are not
On Fri, 1 Feb 2019 at 22:20, Doug Ewell via Unicode wrote:
>
> Richard Wordingham wrote:
>
> > Language tagging is already available in Unicode, via the tag
> > characters in the deprecated plane.
>
> Plane 14 isn't deprecated -- that isn't a property of planes -- and the
> tag characters U+E0020
Richard Wordingham wrote:
> Language tagging is already available in Unicode, via the tag
> characters in the deprecated plane.
Plane 14 isn't deprecated -- that isn't a property of planes -- and the
tag characters U+E0020 through U+E007E have been un-deprecated for use
with emoji flags. Only
On Fri, 1 Feb 2019 14:47:22 +0100
Egmont Koblinger via Unicode wrote:
> Hi Ken,
>
> > [language tag]
> > That is a complete non-starter for the Unicode Standard.
>
> Thanks for your input!
>
> (I hope it was clear that I just started throwing in random ideas, as
> in a brainstorming
On Fri, 1 Feb 2019 13:02:45 +0200
Khaled Hosny via Unicode wrote:
> On Thu, Jan 31, 2019 at 11:17:19PM +, Richard Wordingham via
> Unicode wrote:
> > On Thu, 31 Jan 2019 12:46:48 +0100
> > Egmont Koblinger wrote:
> >
> > No. How many cells do CJK ideographs occupy? We've had a strong
> >
Hi,
I'm trying to respond to every question, but I'm having a hard time
keeping up :-)
Thanks a lot for all the precious input about shaping!
Here's my suggestion, for version 0.2 of the recommendation:
- No longer encourage any use of presentation form characters.
- State that it's the
> From: Egmont Koblinger
> Date: Fri, 1 Feb 2019 14:35:35 +0100
> Cc: Frédéric Grosshans ,
> unicode@unicode.org
>
> > You could do that, but it will require a lot of non-trivial processing
> > from the applications. Text-mode applications don't want any complex
> > tinkering, they want
Hi Richard,
On Fri, Feb 1, 2019 at 12:19 AM Richard Wordingham via Unicode
wrote:
> Cropped why? If the problem is the truncation of lines, one can simple
> store the next character.
Yup, trancation of line for example.
I agree that one could "store the next character". We could extend the
Hi Ken,
> [language tag]
> That is a complete non-starter for the Unicode Standard.
Thanks for your input!
(I hope it was clear that I just started throwing in random ideas, as
in a brainstorming session. This one is ruled out, then.)
cheers,
egmont
On Thu, Jan 31, 2019 at 4:26 PM Eli Zaretskii wrote:
> > Yes, I do argue that emacs will need to print a new escape sequence.
> > Which is much-much-much-much-much better than having to tell users to
> > go into the settings of their macOS Terminal / Konsole /
> > gnome-terminal etc. and disable
> From: Egmont Koblinger
> Date: Fri, 1 Feb 2019 14:16:03 +0100
> Cc: Adam Borowski , unicode@unicode.org
>
> There's absolutely no way we could reorder first, and then handle
> TAB's cursor movement. TAB's cursor movement happens in the lower
> layer, reordering happens in the upper one.
But
Hi,
On Thu, Jan 31, 2019 at 4:14 PM Eli Zaretskii wrote:>
> I suggest that you show the result to someone who does read Arabic.
I contacted one guy who is pretty knowledgeable in Arabic scripts, as
well as terminal emulation, I sent out an early unpublished version of
the proposal to him, but
> From: Egmont Koblinger
> Date: Fri, 1 Feb 2019 13:54:02 +0100
> Cc: Adam Borowski , unicode@unicode.org
>
> For this behavior, the only feature you need from a terminal emulator
> is to have a mode where it doesn't shuffle the characters. Currently
> every emulator I'm aware of has such a
> From: Egmont Koblinger
> Date: Fri, 1 Feb 2019 13:40:48 +0100
> Cc: unicode@unicode.org
>
> I now understand that presentation forms isn't an ideal possible
> approach, and the recommendation should be improved here.
>
> Until it happens, I'm uncertain whether using presentation form
>
Hi,
On Thu, Jan 31, 2019 at 4:10 PM Eli Zaretskii wrote:
> The reordering happens before TABs are converted to cursor motion,
> does it not?
No, not at all.
You cannot "mix" handling the input and reordering, since the input is
not available as a single step but arrives continuously in a
Hi Eli,
> So we will some day have one such terminal emulator. That's good, but
> a text-mode application that needs to support bidi cannot rely on its
> users all having access to that single terminal.
No. A text-mode application that needs to support BiDi must do the
BiDi itself and pass
Hi Eli,
> Arabic presentation forms are more like an exception than a rule, I
> hope you understand this by now. Most languages/scripts don't have
> such forms, and even for Arabic they cover only a part of what needs
> to be done to present correctly shaped text. Complex script shaping
> is
On Thu, Jan 31, 2019 at 11:17:19PM +, Richard Wordingham via Unicode wrote:
> On Thu, 31 Jan 2019 12:46:48 +0100
> Egmont Koblinger wrote:
>
> No. How many cells do CJK ideographs occupy? We've had a strong hint
> that a medial BEH should occupy one cell, while an isolated BEH should
>
> Date: Thu, 31 Jan 2019 23:17:19 +
> From: Richard Wordingham via Unicode
>
> Emacs needs a lot of help - I can't write a generic Tai Tham
> OpenType .flt file :-(
Which is why Emacs is migrating towards HarfBuzz.
On Thu, 31 Jan 2019 12:46:48 +0100
Egmont Koblinger wrote:
> Hi Richard,
>
> > Basic Arabic shaping, at the level of a typewriter, is
> > straightforward enough to leave to a terminal emulator, as Eli has
> > suggested.
>
> What is "basic" Arabic shaping exactly?
Just using initial, medial
On Thu, 31 Jan 2019 08:28:41 +
Martin J. Dürst via Unicode wrote:
> > Basic Arabic shaping, at the level of a typewriter, is
> > straightforward enough to leave to a terminal emulator, as Eli has
> > suggested. Lam-alif would be trickier - one cell or two?
>
> Same for other characters.
Egmont Koblinger wrote:
> "Basic Arabic shaping, at the level of a typewriter, is
> straightforward enough to be implemented in the application, using
> presentation form characters, as I suggest". Could you please point
> out the problems with this statement?
As multiple people have pointed
On 1/31/2019 1:41 AM, Egmont Koblinger via Unicode wrote:
I mean, for
example we can introduce control characters that specify the language.
That is a complete non-starter for the Unicode Standard. And if the
terminal implementation introduces such as one-off hacks, they will fail
> Date: Thu, 31 Jan 2019 10:58:54 +0100
> Cc: unicode@unicode.org
> From: Egmont Koblinger via Unicode
>
> Yes, I do argue that emacs will need to print a new escape sequence.
> Which is much-much-much-much-much better than having to tell users to
> go into the settings of their macOS Terminal /
> From: Egmont Koblinger
> Date: Thu, 31 Jan 2019 10:41:02 +0100
> Cc: Frédéric Grosshans ,
> unicode@unicode.org
>
> > Personally, I think we should simply assume that complex script
> > shaping is left to the terminal, and if the terminal cannot do that,
> > then that's a restriction of
> From: Egmont Koblinger
> Date: Thu, 31 Jan 2019 10:28:27 +0100
> Cc: Adam Borowski , unicode@unicode.org
>
> On Wed, Jan 30, 2019 at 5:10 PM Eli Zaretskii wrote:
>
> > I think the application could use TAB characters to get to the next
> > cell, then simplistic reordering would also work.
>
> From: Egmont Koblinger
> Date: Thu, 31 Jan 2019 10:21:52 +0100
> Cc: Adam Borowski , unicode@unicode.org
>
> > Does anyone know of a terminal emulator which supports isolates?
>
> GNOME Terminal's (VTE's) current work-in-progress implementation does
> remember BiDi control characters just
> From: Egmont Koblinger
> Date: Thu, 31 Jan 2019 10:11:22 +0100
> Cc: unicode@unicode.org
>
> > It doesn't do _any_ shaping. Complex script shaping is left to the
> > terminal, because it's impossible to do shaping in any reasonable way
> > [...]
>
> Partially, you are right. On the other
Le 31/01/2019 à 10:41, Egmont Koblinger a écrit :
Hi,
Personally, I think we should simply assume that complex script
shaping is left to the terminal, and if the terminal cannot do that,
then that's a restriction of working on a text terminal.
I cannot read any of the Arabic, Syriac etc.
Hi Richard,
> Basic Arabic shaping, at the level of a typewriter, is straightforward
> enough to leave to a terminal emulator, as Eli has suggested.
What is "basic" Arabic shaping exactly?
I can see problems with leaving it to a terminal. It's not aware of
the neighboring character if the
On Thu, Jan 31, 2019 at 10:05 AM Richard Wordingham via Unicode
wrote:
> > How will "ls -l" possibly work? This is an example of the "table"
> > layout you were already discussing.
>
> I think the answer is that it will use the same trickery as with a
> default setting for the --color argument.
Hi,
> > And if you argue "so make emacs print your
> > new code to disable formatting", so do thousands of other programs that are
> > less sophisticated than emacs.
>
> Yes, I do argue that emacs will need to print a new escape sequence.
> Which is much-much-much-much-much better than having to
Hi,
> Arabic terminals and terminal emulators existed at the time of Unicode 1.0.
I haven't found any mention of them, let alone any documentation about them.
> If you are trying to emulate those services, for example so that older
> software can run, you would need to look at how these
Hi,
On Wed, Jan 30, 2019 at 5:31 PM Adam Borowski wrote:
> The program (emacs in this case) can do arbitrary reordering of characters
> on the grid, it also has lots of information the terminal doesn't. For
> example, what are you going to do when there's a line longer than what fits
> on the
Hi,
> Personally, I think we should simply assume that complex script
> shaping is left to the terminal, and if the terminal cannot do that,
> then that's a restriction of working on a text terminal.
I cannot read any of the Arabic, Syriac etc. scripts, but I did lots
of experimenting with
Hi Eli,
On Wed, Jan 30, 2019 at 5:10 PM Eli Zaretskii wrote:
> I think the application could use TAB characters to get to the next
> cell, then simplistic reordering would also work.
TAB handling is extremely complicated, because in terminal emulation
TAB is not a character, TAB is a control
Hi Eli,
> Does anyone know of a terminal emulator which supports isolates?
GNOME Terminal's (VTE's) current work-in-progress implementation does
remember BiDi control characters just like it remembers combining
accents, that is, tied to the preceding letter's cell. It uses FriBidi
1.0 for the
Hi Eli,
> It doesn't do _any_ shaping. Complex script shaping is left to the
> terminal, because it's impossible to do shaping in any reasonable way
> [...]
Partially, you are right. On the other hand, as far as I know, shaping
should take into account the neighboring glyphs even if those are
On Wed, 30 Jan 2019 20:35:36 -0500
"Mark E. Shoulson via Unicode" wrote:
> On 1/30/19 8:58 AM, Egmont Koblinger via Unicode wrote:
> > There's another side to the entire BiDi story, though. Simple
> > utilities like "echo", "cat", "ls", "grep" and so on, line editing
> > experience of your
On 2019/01/31 07:02, Richard Wordingham via Unicode wrote:
> On Wed, 30 Jan 2019 15:33:38 +0100
> Frédéric Grosshans via Unicode wrote:
>
>> Le 30/01/2019 à 14:36, Egmont Koblinger via Unicode a écrit :
>>> - It doesn't do Arabic shaping. In my recommendation I'm arguing
>>> that in this mode,
On 1/30/19 8:58 AM, Egmont Koblinger via Unicode wrote:
There's another side to the entire BiDi story, though. Simple
utilities like "echo", "cat", "ls", "grep" and so on, line editing
experience of your shell, these kinds. It's absolutely not feasible to
add BiDi support to these utilities.
Arabic terminals and terminal emulators
existed at the time of Unicode 1.0. If you are trying to emulate
those services, for example so that older software can run, you
would need to look at how these programs expected to be fed their
data.
I see
On Wed, 30 Jan 2019 15:33:38 +0100
Frédéric Grosshans via Unicode wrote:
> Le 30/01/2019 à 14:36, Egmont Koblinger via Unicode a écrit :
> > - It doesn't do Arabic shaping. In my recommendation I'm arguing
> > that in this mode, where shuffling the characters is the task of
> > the text editor
On Wed, Jan 30, 2019 at 05:56:00PM +0200, Eli Zaretskii via Unicode wrote:
> > - It doesn't do Arabic shaping.
>
> It doesn't do _any_ shaping. Complex script shaping is left to the
> terminal, because it's impossible to do shaping in any reasonable way
> without controlling the fonts being used
> Date: Wed, 30 Jan 2019 15:49:34 +0100
> Cc: unicode@unicode.org
> From: Egmont Koblinger via Unicode
>
> I outline in the document problems that arise from the terminal
> emulator performing shaping on its contents in "explicit" mode, which
> is to be used by Emacs and others. The terminal
> Date: Wed, 30 Jan 2019 15:25:32 +0100
> Cc: unicode@unicode.org
> From: Egmont Koblinger via Unicode
>
> > ╒═══╤══╕
> > │ filename1 │ 123 │
> > │ FILENAME2 │ 17 │
> > └───┴──┘
> >
> > I'm afraid there's no good way to do BiDi without support from individual
> >
> Date: Wed, 30 Jan 2019 15:07:22 +0100
> Cc: unicode@unicode.org
> From: Egmont Koblinger via Unicode
>
> Another possible approach is to leave the terminal doing BiDi, but
> embed all the text fragments in FSI...PDI blocks.
Does anyone know of a terminal emulator which supports isolates?
> From: Egmont Koblinger
> Date: Wed, 30 Jan 2019 14:36:42 +0100
> Cc: unicode@unicode.org
>
> - GNU Emacs reshuffles the characters according to the BiDi algorithm,
> expecting that the terminal emulator doesn't do any BiDi.
Yes, users are told to disable bidi reordering of the terminal, if
> A formatted table is pretty unsuitable for automated processing, and
> obviously meant for human display.
Could you please clarify how exactly that data looks like? Maybe a
tiny hexdump of an example?
Is the RTL piece of text already stored in visual order, that is,
beginning with the leftmost
On Wed, Jan 30, 2019 at 03:43:10PM +0100, Egmont Koblinger via Unicode wrote:
> On Wed, Jan 30, 2019 at 3:32 PM Adam Borowski wrote:
>
> > > > ╒═══╤══╕
> > > > │ filename1 │ 123 │
> > > > │ FILENAME2 │ 17 │
> > > > └───┴──┘
>
> > That's possible only if the program in
Hi Frédéric,
> I guess Arabic shaping is doable through presentation form characters,
> because the latter are character inherited from legacy standards using
> them in such solutions. But if you want to support other “arabic like”
> scripts (like Syriac, N’ko), or even some LTR complex scripts,
On Wed, Jan 30, 2019 at 3:32 PM Adam Borowski wrote:
> > > ╒═══╤══╕
> > > │ filename1 │ 123 │
> > > │ FILENAME2 │ 17 │
> > > └───┴──┘
> That's possible only if the program in question is running directly attached
> to the tty. That's not an option if the output is
Le 30/01/2019 à 14:36, Egmont Koblinger via Unicode a écrit :
- It doesn't do Arabic shaping. In my recommendation I'm arguing that
in this mode, where shuffling the characters is the task of the text
editor and not the terminal, so should it be for Arabic shaping using
presentation form
On Wed, Jan 30, 2019 at 03:25:32PM +0100, Egmont Koblinger via Unicode wrote:
> One more note, to hopefully clarify:
> > ╒═══╤══╕
> > │ filename1 │ 123 │
> > │ FILENAME2 │ 17 │
> > └───┴──┘
> >
> > I'm afraid there's no good way to do BiDi without support from individual
Hi Adam,
One more note, to hopefully clarify:
> ╒═══╤══╕
> │ filename1 │ 123 │
> │ FILENAME2 │ 17 │
> └───┴──┘
>
> I'm afraid there's no good way to do BiDi without support from individual
> programs.
In this particular example, when the output consists of RTL text in
Hi Adam,
> Even a line is way too big a piece to be safely reordered by the terminal.
> What you propose will break every full-screen program that uses line-drawing
> characters:
Certain terminal emulators already perform BiDi on their lines. They
already break every full-screen program with
Hi Eli,
> My personal experience with bringing BiDi to Emacs led me to a firm
> conclusion that BiDi support by terminal emulators cannot be relied on
> by sophisticated text editing and display applications that are
> BiDi-aware. The terminal emulator can never be smart enough to do
> what the
Hi Eli,
> > In turn, vim, emacs and friends stand there clueless, not knowing
> > how to do BiDi in terminals.
>
> This is inaccurate: [...]
I have to admit, I was somewhat sloppy in the phrasing of this
announcement. My bad, apologies.
Currently some terminal emulators shuffle the characters
1 - 100 of 103 matches
Mail list logo
