On Sun, Feb 17, 2019 at 1:59 PM Philippe Verdy wrote:
> Resist this idea, I've not been impolite.
I didn't say a word about you being impolite. I said I might be
impolite for not wishing to continue this discussion in that
direction.
> I just want to show you that terminals are legacy
Le ven. 8 févr. 2019 à 13:56, Egmont Koblinger a écrit :
> Philippe, I hate do say it, but at the risk of being impolite, I just
> have to.
>
Resist this idea, I've not been impolite. I just want to show you that
terminals are legacy environments that are far behind what is needed for
proper
Le mar. 12 févr. 2019 à 14:16, Egmont Koblinger via Unicode <
unicode@unicode.org> a écrit :
> > There is nothing magic about the grid of cells, and once you introduce
> new escape sequences, you might as well truly modernise the terminal.
>
> The magic about the grid of cells is all the software
On Tue, Feb 12, 2019 at 9:35 PM Richard Wordingham via Unicode
wrote:
> Bash already seems to handle proportional fonts quite well when run
> under Emacs 'M-x shell',
Having never used bash inside Emacs's shell, here's my experience
after about a minute of trying it:
Cursor keys allow you to
On Tue, 12 Feb 2019 13:50:00 +0100
Egmont Koblinger via Unicode wrote:
> For
> starter, I'd love to see a shell with interactive line editing (like
> bash, zsh),...
Bash already seems to handle proportional fonts quite well when run
under Emacs 'M-x shell', which is more than can be said for
Hi Elias,
> For all the willingness to come up with ways to modernise the terminal,
> you've only spoken about trying to showhorn rtl text in to the vt102 basic
> terminal.
Yes, addressing BiDi was the exact thing that I did now. What's wrong with that?
I can't address all the imperfectnesses
Hi Philippe,
> The monospace restriction is a strong limitator: but then I don't see why a
> "terminal" could not handle fonts with variable metrics, and why it must be
> modeled only as a regular grid of rectangular cells (all of equal size)
> containing only one "character" (or cluster?).
On Sun, 10 Feb 2019, 18:39 Egmont Koblinger via Unicode On Sun, Feb 10, 2019 at 2:57 AM Richard Wordingham via Unicode
> wrote:
>
> > Which side do you align RTL cells on?
>
> It's out of the scope of my docs.
>
> In the current work-in-progress implementation I align them to the
> left, but
On Sun, 10 Feb 2019 14:54:39 +0100
Philippe Verdy via Unicode wrote:
> Le sam. 9 févr. 2019 à 20:55, Egmont Koblinger via Unicode <
> unicode@unicode.org> a écrit :
>
> > Hi Asmus,
> >
> > > On quick reading this appears to be a strong argument why such
> > > emulators
> > will
> > >
Le sam. 9 févr. 2019 à 20:55, Egmont Koblinger via Unicode <
unicode@unicode.org> a écrit :
> Hi Asmus,
>
> > On quick reading this appears to be a strong argument why such emulators
> will
> > never be able to be used for certain scripts. Effectively, the model
> described works
> > well with
On Sun, Feb 10, 2019 at 2:57 AM Richard Wordingham via Unicode
wrote:
> Which side do you align RTL cells on?
It's out of the scope of my docs.
In the current work-in-progress implementation I align them to the
left, but there's a TODO entry to align them to the right instead (or
maybe center
On Sun, 10 Feb 2019 00:59:46 +0100
Egmont Koblinger via Unicode wrote:
> Is there such a monospace font obeying wcwidth (that is: double wide
> character for when a spacing mark is combined) for Devanagari?
For CV, that would correspond to a Hindi typewriter, so the odds look
good. The
On Sat, 9 Feb 2019 18:42:52 +0100
Egmont Koblinger via Unicode wrote:
> The
> problem that I don't know how to address is: What if harfbuzz tells us
> that the overall width for rendering a particular grapheme cluster is
> significantly different from its designated area (the number of
>
On Sat, 9 Feb 2019 22:29:31 +0100
Adam Borowski via Unicode wrote:
> On Sat, Feb 09, 2019 at 10:01:21PM +0200, Eli Zaretskii via Unicode
> wrote:
> > I don't know. Maybe it keeps a database of character combinations
> > that need shaping, each one with the maximum width on display the
> >
Hi,
On Sun, Feb 10, 2019 at 12:52 AM Richard Wordingham via Unicode
wrote:
> This is an example of where one needs a font designed for terminal
> emulators.
Definitely, this is another approach I forgot to mention in my mail,
rather than VTE switching to harfbuzz and figuring out all the
On Sat, 9 Feb 2019 22:31:37 +0100
Egmont Koblinger via Unicode wrote:
> Let's take the Devanagari improvement of the other day. Until now,
> there were plenty of dotted circles shown, and combining spacing marks
> that should've been placed before the letter were placed after the
> letter,
On Sat, 9 Feb 2019 13:02:55 -0800
"Asmus Freytag \(c\) via Unicode" wrote:
> To force Hindi crosswords mode you need to segment the string into
> syllables,
> each having a variable number of characters, and then assign a single
> display
> position to them. Now some syllables are wider than
On 2/9/2019 1:40 PM, Egmont Koblinger wrote:
On Sat, Feb 9, 2019 at 10:10 PM Asmus Freytag via Unicode
wrote:
I hope though that all the scripts can be supported with more or less
compromises, e.g. like it would appear in a crossword. But maybe not.
See other messages: not.
For the
On Sat, Feb 9, 2019 at 10:10 PM Asmus Freytag via Unicode
wrote:
> > I hope though that all the scripts can be supported with more or less
> > compromises, e.g. like it would appear in a crossword. But maybe not.
>
> See other messages: not.
For the crossword analogy, I can see why it's not
Hi Asmus,
On Sat, Feb 9, 2019 at 10:02 PM Asmus Freytag (c) wrote:
> are you excluding CJK because of the difficulty handling a large
> repertoire with mechanical means?
No, I excluded CJK because they're pretty well solved in terminals,
and nowhere near along the lines of how they work with
On Sat, Feb 09, 2019 at 10:01:21PM +0200, Eli Zaretskii via Unicode wrote:
> > From: Egmont Koblinger
> > Date: Sat, 9 Feb 2019 20:36:50 +0100
> > Cc: Richard Wordingham ,
> > unicode Unicode Discussion
> >
> > On Sat, Feb 9, 2019 at 8:13 PM Eli Zaretskii wrote:
> >
> > > That's the
On 2/9/2019 11:48 AM, Egmont Koblinger wrote:
Hi Asmus,
On quick reading this appears to be a strong argument why such emulators will
never be able to be used for certain scripts. Effectively, the model described
works
well with any scripts where characters are laid out (or can be laid out)
On 2/9/2019 12:07 PM, Egmont Koblinger
via Unicode wrote:
On Sat, Feb 9, 2019 at 9:01 PM Eli Zaretskii wrote:
then what you say is that some scripts
can never be supported by text terminals.
I'm not familiar at all with all the
Egmont,
On 2/9/2019 11:48 AM, Egmont Koblinger via Unicode wrote:
Are there any (non-CJK) scripts for which crossword puzzles don't exist?
There are crossword puzzles for Hindi (in the Devanagari script). Just
do an image search for "Hindi crossword puzzle".
But the conventions for these
Hi Ken,
> There are crossword puzzles for Hindi (in the Devanagari script). Just
> do an image search for "Hindi crossword puzzle".
It's easy to confirm the existence by an image search, it's hard to
confirm the non-existence ;)
> The existence proof of techniques to cut up text into syllables
On Sat, Feb 9, 2019 at 9:01 PM Eli Zaretskii wrote:
> then what you say is that some scripts
> can never be supported by text terminals.
I'm not familiar at all with all the scripts and their requirements,
but yes, basically this is what I'm saying. I'm afraid some scripts
can never be
> From: Egmont Koblinger
> Date: Sat, 9 Feb 2019 20:36:50 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> On Sat, Feb 9, 2019 at 8:13 PM Eli Zaretskii wrote:
>
> > That's the application's problem, not the terminal's. An application
> > that wants its column to line
Hi Asmus,
> On quick reading this appears to be a strong argument why such emulators will
> never be able to be used for certain scripts. Effectively, the model
> described works
> well with any scripts where characters are laid out (or can be laid out) in
> fixed
> width cells that are
On Sat, Feb 9, 2019 at 8:13 PM Eli Zaretskii wrote:
> That's the application's problem, not the terminal's. An application
> that wants its column to line up _and_ wants to support complex text
> scripts will need to move cursor to certain coordinates, not to assume
> that 7 codepoints always
> From: Egmont Koblinger
> Date: Sat, 9 Feb 2019 20:03:21 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> Let's suppose a utility outputs these two lines of text:
> abcdefg|
> complex|
>
> whereas "abcdefg" are these English letters themselves, but "complex"
> is a
On quick reading this appears to be a
strong argument why such emulators will
never be able to be used for certain
scripts. Effectively, the model described works
well with any scripts where characters
are laid out (or can be laid out) in fixed
width cells
On Sat, Feb 9, 2019 at 7:56 PM Eli Zaretskii wrote:
> I'm probably missing something, because I don't see the grave problems
> you hint at. Any width provided back by a shaper can be rounded to
> the nearest integral character cell, so your canvas can still remain
> rectangular.
Let's suppose
> From: Egmont Koblinger
> Date: Sat, 9 Feb 2019 19:25:08 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> > You need to use what HarfBuzz tells you _instead_ of wcswidth. It is
> > in general wrong to use wcswidth or anything similar when you use a
> > shaping engine
On Sat, Feb 9, 2019 at 7:07 PM Eli Zaretskii wrote:
> You need to use what HarfBuzz tells you _instead_ of wcswidth. It is
> in general wrong to use wcswidth or anything similar when you use a
> shaping engine and support complex script shaping.
This approach is not viable at all.
Terminal
> Date: Sat, 9 Feb 2019 18:42:52 +0100
> Cc: unicode Unicode Discussion
> From: Egmont Koblinger via Unicode
>
> What if harfbuzz tells us that the overall width for rendering a
> particular grapheme cluster is significantly different from its
> designated area (the number of character cells
Hi Richard,
On Sat, Feb 9, 2019 at 3:08 PM Richard Wordingham via Unicode
wrote:
> It would be good to be able to access a maintained statement of the
> VTE rules for allocating characters to a cell, or group of cells, as
> appropriate.
What VTE did, up to a couple of days ago:
It opens the
On Sat, 09 Feb 2019 09:42:09 +0200
Eli Zaretskii via Unicode wrote:
> > Date: Sat, 9 Feb 2019 00:18:14 +
> > From: Richard Wordingham via Unicode
> >
> > > For character composition, you must have a shaping engine to talk
> > > to, and the shaper should tell you the width of each
> From: Elias Mårtenson
> Date: Sat, 9 Feb 2019 13:33:49 +0800
> Cc: Egmont Koblinger , unicode
>
> Moreover, emitting the control sequences that set the mode is in
> itself a complication, because if the terminal doesn't support them,
> the result could be corrupted display. You will need
> Date: Sat, 9 Feb 2019 00:18:14 +
> From: Richard Wordingham via Unicode
>
> > For character composition, you must have a shaping engine to talk to,
> > and the shaper should tell you the width of each grapheme cluster it
> > returns.
>
> (a) What defines the grapheme clusters? The
On Wed, 6 Feb 2019, 00:09 Eli Zaretskii via Unicode
> Moreover, emitting the control sequences that set the mode is in
> itself a complication, because if the terminal doesn't support them,
> the result could be corrupted display. You will need methods of
> detecting the support, and those
On Sat, 09 Feb 2019 00:16:30 +0200
Eli Zaretskii via Unicode wrote:
> > Date: Fri, 8 Feb 2019 21:55:58 +
> > From: Richard Wordingham via Unicode
> > I will give a concrete application. If I want to make a font that
> > is interpretable for Tai Tham and maximally usable with VTE, what
> >
> Date: Fri, 8 Feb 2019 21:55:58 +
> From: Richard Wordingham via Unicode
>
> > > What's the sledgehammer for Windows?
>
> > Not sure what you meant. "M-x term" doesn't work on Windows.
>
> So my question is, 'What do I use on Windows?' The application may be
> disproportionate to the
On Fri, 08 Feb 2019 11:34:29 +0200
Eli Zaretskii via Unicode wrote:
> > Date: Fri, 8 Feb 2019 06:40:44 +
> > From: Richard Wordingham via Unicode
> >
> > > I, for one, am not to the slightest bit interested in abandoning
> > > the character grid and allowing for proportional fonts. This
On Fri, Feb 8, 2019 at 10:36 PM Eli Zaretskii wrote:
> No one in their right minds will run Emacs inside the Emacs terminal
> emulator. And even for other applications, disabling bidi will almost
> always needed only for full-screen programs, which use curses-like
> libraries to address the
> From: Egmont Koblinger
> Date: Fri, 8 Feb 2019 17:44:53 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> For certain apps, one of the modes is required (e.g. for cat it's the
> implicit mode). For other tasks it's the other mode (e.g. for emacs
> the explicit mode).
On Fri, 08 Feb 2019 15:45:15 +0200
Eli Zaretskii via Unicode wrote:
> > From: Egmont Koblinger
> > Date: Fri, 8 Feb 2019 13:30:42 +0100
> > Cc: Richard Wordingham ,
> > unicode Unicode Discussion
> >
> > Hi Eli,
> >
> > > Not sure why. There are terminal emulators out there which
> >
Hi Eli,
> Why would they want to toggle it back and forth? What are the use
> cases where it makes sense to mix both modes? IME, you either need
> one or the other, never both.
(Back to the basics, which are mentioned pretty clearly in my
specification, I believe, and I've also described here
> From: Egmont Koblinger
> Date: Fri, 8 Feb 2019 15:42:51 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> On Fri, Feb 8, 2019 at 3:28 PM Eli Zaretskii wrote:
>
> > You can have what you call the "explicit mode" if you set the variable
> > bidi-display-reordering to
On Fri, Feb 8, 2019 at 3:28 PM Eli Zaretskii wrote:
> You can have what you call the "explicit mode" if you set the variable
> bidi-display-reordering to nil.
So, if someone is running a mixture of applications requiring implicit
vs. explicit modes, they'll have to continuously toggle the
> From: Egmont Koblinger
> Date: Fri, 8 Feb 2019 14:57:56 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> According to the description you give, Emacs's terminal always applies
> the BiDi algorithm, therefore by its design only implements what I
> call "implicit mode",
Hi Eli,
> Emacs implements the latest UBA from Unicode 11; and the Emacs
> terminal emulator inserts all the text into a "normal" Emacs buffer,
> and displays that buffer as any other buffer. So yes, you have there
> full UBA support.
One of the essentials of my work is that there's much more
> From: Egmont Koblinger
> Date: Fri, 8 Feb 2019 13:30:42 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> Hi Eli,
>
> > Not sure why. There are terminal emulators out there which support
> > proportional fonts.
>
> Well, of course, a terminal emulator can load any
Hi Philippe,
> Adding a single bit of protection in cell attributes to indicate they are
> either protected or become transparent (and the rest of the
> attributes/character field indicates the id of another terminal grid or
> rendering plugin crfeating its own layer and having its own
Hi Eli,
> Not sure why. There are terminal emulators out there which support
> proportional fonts.
Well, of course, a terminal emulator can load any font, even
proportional, but as it places them in the grid, it will look ugly as
hell (like this one: https://askubuntu.com/q/781327/398785 ).
> Date: Fri, 8 Feb 2019 06:40:44 +
> From: Richard Wordingham via Unicode
>
> > I, for one, am not to the slightest bit interested in abandoning the
> > character grid and allowing for proportional fonts. This would just
> > break a gazillion of things.
>
> The message I take from that and
> Date: Thu, 7 Feb 2019 22:35:23 +
> From: Richard Wordingham via Unicode
>
> > > Do you mean you aim to maintain a regex that matches everyone's
> > > prompt in the world, without a significant amount of false positive
> > > matches on non-prompt lines?
>
> > Yes.
>
> Wow! You'll do
On Fri, 8 Feb 2019 00:38:24 +0100
Egmont Koblinger via Unicode wrote:
> I, for one, am not to the slightest bit interested in abandoning the
> character grid and allowing for proportional fonts. This would just
> break a gazillion of things.
The message I take from that and this thread in
Adding a single bit of protection in cell attributes to indicate they are
either protected or become transparent (and the rest of the
attributes/character field indicates the id of another terminal grid or
rendering plugin crfeating its own layer and having its own scrolling state
and dimensions)
Hi Philippe,
> I have never said anything about your work because I don't know where you
> spoke about it or where you made some proposals. I must have missed one of
> your messages (did it reach this list?).
This entire conversation started by me announcing here my work, aiming
to bring
On Thu, 07 Feb 2019 22:00:20 +0200
Eli Zaretskii via Unicode wrote:
> > From: Egmont Koblinger
> > Date: Thu, 7 Feb 2019 19:01:33 +0100
> > On Thu, Feb 7, 2019 at 6:53 PM Eli Zaretskii wrote:
> > > No, it needs no interaction. Unless the regexp doesn't work for
> > > you, which you should
Le jeu. 7 févr. 2019 à 19:38, Egmont Koblinger a écrit :
> As you can see from previous discussions, there's a whole lot of
> confusion about the terminology.
And it was exactly the subject of my first message sent to this thread !
you probably missed it.
> Philippe, with all due respect, I
> From: Egmont Koblinger
> Date: Thu, 7 Feb 2019 19:01:33 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> On Thu, Feb 7, 2019 at 6:53 PM Eli Zaretskii wrote:
>
> > No, it needs no interaction. Unless the regexp doesn't work for you,
> > which you should then report
Hi Philippe,
On Thu, Feb 7, 2019 at 3:21 PM Philippe Verdy wrote:
> "Rules" are not formally written, they are just a sense of best practices.
When it comes to BiDi in terminals, I haven't seen anything that I
consider reasonably okay, let alone "best practice". It's a mess.
That's why I
On Thu, Feb 7, 2019 at 6:53 PM Eli Zaretskii wrote:
> No, it needs no interaction. Unless the regexp doesn't work for you,
> which you should then report as a bug in Emacs.
Do you mean you aim to maintain a regex that matches everyone's prompt
in the world, without a significant amount of
> From: Egmont Koblinger
> Date: Thu, 7 Feb 2019 18:20:02 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> > It uses a regular expression, see term-prompt-regexp.
>
> So, it's not automatic, needs user interaction
No, it needs no interaction. Unless the regexp doesn't
On Thu, Feb 7, 2019 at 6:33 PM Eli Zaretskii wrote:
> Well, let's just say that Emacs uses the HL1 rule, and determines the
> base direction for the entire chunk of text between empty lines.
Exactly!
Now it's my turn to figure out how to add this behavior to terminals,
preferably stopping
> From: Egmont Koblinger
> Date: Thu, 7 Feb 2019 18:12:37 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> I believe it's not my mental model that's weird, but your use of
> terminology that doesn't match UBA's that confused me.
Well, let's just say that Emacs uses the
Hi,
On Thu, Feb 7, 2019 at 3:27 PM Eli Zaretskii wrote:
> It uses a regular expression, see term-prompt-regexp.
So, it's not automatic, needs user interaction, and for that reason,
may not have worked for me. (I have other weird things in my prompt,
like 256-color sequences that Emacs didn't
On Thu, Feb 7, 2019 at 3:14 PM Eli Zaretskii wrote:
> Not a bug, a feature. Emacs doesn't remove the bidi controls from
> display (that's another deviation allowed by the UBA, see section
> 5.2). On GUI displays, these controls are displayed as thin 1-pixel
> spaces, but on text-mode terminals
> Date: Thu, 7 Feb 2019 00:45:55 +0100
> Cc: unicode Unicode Discussion
> From: Egmont Koblinger via Unicode
>
> > Not necessarily. One could allow the first strong character in the
> > prompt to determine the paragraph directions
>
> How does Emacs know what's a prompt? How can it tell it
> Date: Wed, 6 Feb 2019 23:32:43 +
> From: Richard Wordingham via Unicode
>
> > You define paragraphs as emptyline-separated blocks on which you
> > perform autodetection of the paragraph direction. This is great! As
> > I've mentioned, I'd love to have such a mode in terminals, but it's
> >
Le jeu. 7 févr. 2019 à 13:29, Egmont Koblinger a écrit :
> Hi Philippe,
>
> > There's some rules for correct display including with Bidi:
>
> In what sense are these "rules"? Where are these written, in what kind
> of specification or existing practice?
>
"Rules" are not formally written, they
> From: Egmont Koblinger
> Date: Wed, 6 Feb 2019 22:01:59 +0100
> Cc: Richard Wordingham , unicode@unicode.org
>
> - Emacs running in a terminal shows an underscore wherever there's a
> BiDi control in the source file – while the graphical one doesn't.
> This looks like a simple bug to me,
Hi Philippe,
> There's some rules for correct display including with Bidi:
In what sense are these "rules"? Where are these written, in what kind
of specification or existing practice?
> - Separate paragraphs that need a different default Bidi by double newlines
> (to force a hard break)
On Thu, 7 Feb 2019 00:45:55 +0100
Egmont Koblinger via Unicode wrote:
> Hi Richard,
>
> > Not necessarily. One could allow the first strong character in the
> > prompt to determine the paragraph directions
>
> How does Emacs know what's a prompt? How can it tell it from the
> previous and
I read your email, you spoke for example about how a typical Unix/Linux
tool shows its usage option (e.g. "anycommand --help") with a leading line
then syntaxes and tabulated lists of options followed by translated help on
the same line.
There's some rules for correct display including with Bidi:
Hi Richard,
> Not necessarily. One could allow the first strong character in the
> prompt to determine the paragraph directions
How does Emacs know what's a prompt? How can it tell it from the
previous and next command's output?
Whatever it does to know where the prompt is, can it be made into
On Wed, 6 Feb 2019 22:01:59 +0100
Egmont Koblinger via Unicode wrote:
> Hi Eli,
>
> (I'm getting lost where to reply, and how the subject gets mangled and
> the thread split into different ones.)
>
>
> I've thought about it a lot, experimented with Emacs's behavior, and
> I've arrived at the
Hi,
I was loose with my terminology once again, which is not a wise thing
when you're trying to clarify misunderstandings :)
> But once you have
> decided on a direction, each _line_ within that data is passed
> separately to the BiDi algorithm to get reshuffled; this is what Emacs
> does, this
Hi Philippe,
Thanks a lot for your input!
Another fundamental difficulty with terminal emulators is: These
controls (CR, LF...) are control instructions that move the cursor in
some ways, and then are forgotten. You cannot do BiDi on the
instructions the terminal receives. You can only do BiDi
Hi Eli,
(I'm getting lost where to reply, and how the subject gets mangled and
the thread split into different ones.)
I've thought about it a lot, experimented with Emacs's behavior, and
I've arrived at the conclusion that we are actually much closer to
each other than I had thought. Probably
I think that before making any decision we must make some decision about
what we mean by "newlines". There are in fact 3 different functions:
- (1) soft line breaks (which are used to enforce a maximum display width
between paragraph margins): these are equivalent to breakable and
compressible
> From: Egmont Koblinger
> Date: Tue, 5 Feb 2019 02:28:50 +0100
> Cc: unicode@unicode.org
>
> I have to admit, I'm not an Emacs user, I only have some vague ideas
> how powerful a tool it is. But in its very core I still believe it's a
> text editor – is it fair to say this? It could be used for
> From: Egmont Koblinger
> Date: Tue, 5 Feb 2019 01:32:34 +0100
> Cc: unicode@unicode.org
>
> On the other hand, it's not unreasonable for higher level stuff (e.g.
> shell scripts, or tools like "zip") to use such control characters.
Yes, but most of them won't ever do that.
> > No, this
> Date: Tue, 5 Feb 2019 00:05:47 +
> From: Richard Wordingham via Unicode
>
> > > Actually, UAX#9 defines "paragraph" as the chunk of text delimited
> > > by paragraph separator characters. This means characters whose bidi
> > > category is B, which includes Newline, the CR-LF pair on
> From: Egmont Koblinger
> Date: Tue, 5 Feb 2019 00:08:10 +0100
> Cc: unicode@unicode.org
>
> every single newline character starts a new paragraph. The result of
> printf "Hello\nWorld\n" > world.txt
> is a text file consisting of two paragraphs, with 5 characters in each.
> Correct?
Yes.
>
On Mon, 4 Feb 2019 22:27:39 +0100
Egmont Koblinger via Unicode wrote:
> Hi Richard,
>
> > The concept appears to exist in the form of the fields of the
> > fifth edition of ECMA-48. Have you digested this ambitious
> > standard?
>
> To be honest: No, I haven't. And I have no idea what those
Hi Eli,
> IME, this is a grave mistake. I hope I explained why; it is now up to
> you to decide what to do about that.
Let me share one more thought.
I have to admit, I'm not an Emacs user, I only have some vague ideas
how powerful a tool it is. But in its very core I still believe it's a
text
Hi Eli,
> I think it's unreasonable and impractical to expect 'echo', 'cat', and
> its ilk to emit bidi controls (or any other controls) to force
> paragraph direction. For starters, they won't know what direction to
> force, because they don't understand the text they are processing.
I agree,
On Tue, 5 Feb 2019 00:08:10 +0100
Egmont Koblinger via Unicode wrote:
> Hi Eli,
>
> > Actually, UAX#9 defines "paragraph" as the chunk of text delimited
> > by paragraph separator characters. This means characters whose bidi
> > category is B, which includes Newline, the CR-LF pair on Windows,
Hi Eli,
> Actually, UAX#9 defines "paragraph" as the chunk of text delimited by
> paragraph separator characters. This means characters whose bidi
> category is B, which includes Newline, the CR-LF pair on Windows,
> U+0085 NEL, and U+2029 PARAGRAPH SEPARATOR.
Indeed, this was an oversight on
On Mon, 04 Feb 2019 22:39:07 +0200
Eli Zaretskii via Unicode wrote:
> > Date: Mon, 4 Feb 2019 19:45:13 +
> > From: Richard Wordingham via Unicode
> >
> > Yes. If one has a text composed of LTR and RTL paragraphs, one has
> > to choose how far apart their starting margins are. I think
> > Yes. If one has a text composed of LTR and RTL paragraphs, one has to
> > choose how far apart their starting margins are. I think that could
> > get complicated for plain text if the terminal has unbounded width.
>
> But no real-life terminal does. The width is always bounded.
Allegedly
Hi Richard,
> That split is wrong if you want the non-HTML text to lay out reasonably
> well in anything but a higher order protocol forcing RTL. You need to
> it split as:
>
> lorem ipsum ABC
> <[ DEF foobar
Okay, so you should use LRMs or other similar tricks when wrapping a
human-perceived
Hi Richard,
> The concept appears to exist in the form of the fields of the
> fifth edition of ECMA-48. Have you digested this ambitious standard?
To be honest: No, I haven't. And I have no idea what those "fields" are.
I spent (read: wasted) way too much time studying ECMA TR/53 to get to
> Date: Mon, 4 Feb 2019 19:45:13 +
> From: Richard Wordingham via Unicode
>
> Yes. If one has a text composed of LTR and RTL paragraphs, one has to
> choose how far apart their starting margins are. I think that could
> get complicated for plain text if the terminal has unbounded width.
On Mon, 04 Feb 2019 18:53:22 +0200
Eli Zaretskii via Unicode wrote:
> Date: Mon, 4 Feb 2019 01:19:21 +
> From: Richard Wordingham via Unicode
>> If you look at it in Notepad, all
>> lines will be LTR or all lines will be RTL.
> That's because Notepad implements _only_ the higher-level
> Date: Mon, 4 Feb 2019 01:19:21 +
> From: Richard Wordingham via Unicode
>
> On Sun, 03 Feb 2019 19:50:50 +0200
> Eli Zaretskii via Unicode wrote:
>
> > Do you see how this is carefully formatted to avoid overflowing an
> > 80-column line of a typical terminal? Now suppose this is
> From: Egmont Koblinger
> Date: Mon, 4 Feb 2019 00:36:23 +0100
> Cc: unicode@unicode.org
>
> The Unicode BiDi algorithm states that it operates on paragraphs of
> text, and leaves it up to a higher protocol to define what a paragraph
> exactly is.
>
> What's the definition of "paragraph" in
On Mon, 4 Feb 2019 00:36:23 +0100
Egmont Koblinger via Unicode wrote:
> Now, back to terminals.
>
> The smallest possible viable definition of a "paragraph" in terminal
> emulators is stuff between one newline and the next one.
>
> It would require a hell lot of work, redesigning
1 - 100 of 106 matches
Mail list logo
