On 2/13/2019 5:19 PM, Mark E. Shoulson
via Unicode wrote:
And
again, all this is before we even consider other issues; I can't
shake the feeling that there security nightmares lurking inside
this idea.
Default ignorables are bad juju.
A./
On 2/12/19 12:05 PM, Kent Karlsson via Unicode wrote:
Den 2019-02-12 03:20, skrev "Mark E. Shoulson via Unicode"
:
On 2/11/19 5:46 PM, Kent Karlsson via Unicode wrote:
Continuing too look deep into the crystal ball, doing some more
hand swirls...
...
...
The scheme quoted (far) b
Philippe Verdy replied to my post, including quoting me.
WJGO >> Thinking about this further, for this application copies of the
glyphs could be redesigned so as to be square and could be emoji-style
and the meanings of the characters specifying which colour component is
to be set could be ch
James Kass wrote:
Nobody disagreed and I think it’s a splendid suggestion. If anyone is
discussing drafting a proposal to accomplish this, please include me
in the “cc”.
I too would like to receive copies of any discussions please.
In relation to the proposal, I opine that the facility shou
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:
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 m
Oh, the crystal ball is pure solid state, no moving or hot parts.
A magic 8-ball on the other hand can easily get jammed...
(Now, enough of that...)
/K
Den 2019-02-12 02:57, skrev "James Kass via Unicode" :
>
> On 2019-02-11 6:42 PM, Kent Karlsson wrote:
>
>> Usin
Den 2019-02-12 03:20, skrev "Mark E. Shoulson via Unicode"
:
> On 2/11/19 5:46 PM, Kent Karlsson via Unicode wrote:
>> Continuing too look deep into the crystal ball, doing some more
>> hand swirls...
>>
>> ...
>>
>> ...
>>
>> The
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?).
Be
On 2019-01-24 Andrew West wrote,
> The ESC and UTC do an appallingly bad job at regulating emoji, and I
> would like to see the Emoji Subcommittee disbanded, and decisions on
> new emoji taken away from the UTC, and handed over to a consortium or
> committee of vendors who would be given a dedi
Philippe Verdy wrote,
>>> case mappings,
>>
>> Adjust them as needed.
>
> Not so easy: case mappings cannot be fixed. They are stabilized in
Unicode.
> You would need special casing rules under a specific "locale" for maths.
In BabelPad, I can select a string of text and convert it to math
On 2/11/19 5:46 PM, Kent Karlsson via Unicode wrote:
Continuing too look deep into the crystal ball, doing some more
hand swirls...
...
...
The scheme quoted (far) below (from wjgo_10009), or anything like it,
will NEVER be part of Unicode!
Not in Unicode, but I have to say I'm intrigu
On 2019-02-11 6:42 PM, Kent Karlsson wrote:
> Using a VS to get italics, or anything like that approach, will
> NEVER be a part of Unicode!
Maybe the crystal ball is jammed. This can happen, especially on the
older models which use vacuum tubes.
Wanting a second opinion, I asked the magic
Continuing too look deep into the crystal ball, doing some more
hand swirls...
...
...
The scheme quoted (far) below (from wjgo_10009), or anything like it,
will NEVER be part of Unicode!
---
But I do like colour (and bold and italic) also for otherwise "plain"
text. And having thos
Den 2019-02-11 10:55, skrev "wjgo_10...@btinternet.com via Unicode"
:
> Doug Ewell wrote:
>
>> , just as next to nobody is using the proposed VS14 mechanism
>
> Well, of course not because use of VS14 in a plain text document to
> record a request for an ita
Doug Ewell wrote:
…, just as next to nobody is using the proposed VS14 mechanism …
Well, of course not because use of VS14 in a plain text document to
record a request for an italic glyph version is not at the present time
an official part of Unicode. The next scheduled Unicode Technical
Co
Le dim. 10 févr. 2019 à 02:33, wjgo_10...@btinternet.com via Unicode <
unicode@unicode.org> a écrit :
> Previously I wrote:
>
> > A stateful method, though which might be useful for plain text streams
> > in some applications, would be to encode as characters some of the
&
Le dim. 10 févr. 2019 à 16:42, James Kass via Unicode
a écrit :
>
> Philippe Verdy wrote,
>
> >> ...[one font file having both italic and roman]...
> > The only case where it happens in real fonts is for the mapping of
> > Mathematical Symbols which hav
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
Den 2019-02-10 16:31, skrev "James Kass via Unicode" :
>
> Philippe Verdy wrote,
>
>>> ...[one font file having both italic and roman]...
For OpenType fonts, there is a "design axis" called "ital". Value 0 on that
axis would be roman (uprig
Egmont Koblinger wrote:
> There are a lot of problems with these escape sequences, and if you go
> for a potentially new standard, you might not want to carry these
> problems.
As others have pointed out, I am suggesting the use of some profile of ISO 6429
within plain text to implement these fe
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
Philippe Verdy wrote,
>> ...[one font file having both italic and roman]...
> The only case where it happens in real fonts is for the mapping of
> Mathematical Symbols which have a distinct encoding for some
> variants ...
William Overington made a proof-of-concept font using the VS14 characte
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
>
Le dim. 10 févr. 2019 à 05:34, James Kass via Unicode
a écrit :
>
> Martin J. Dürst wrote,
>
> >> Isn't that already the case if one uses variation sequences to choose
> >> between Chinese and Japanese glyphs?
> >
> > Well, not necessarily. Ther
On Sat, Feb 9, 2019 at 6:23 AM Richard Wordingham via Unicode <
unicode@unicode.org> wrote:
> On Sat, 9 Feb 2019 04:52:30 -0800
> David Starner via Unicode wrote:
>
> > Note that this is actually the only thing that stands out to me in
> > Unicode not supporting older
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
Martin J. Dürst wrote,
>> Isn't that already the case if one uses variation sequences to choose
>> between Chinese and Japanese glyphs?
>
> Well, not necessarily. There's nothing prohibiting a font that includes
> both Chinese and Japanese glyph variants.
Just as there’s nothing prohibiting a
On 2019/02/09 19:58, Richard Wordingham via Unicode wrote:
> On Fri, 8 Feb 2019 18:08:34 -0800
> Asmus Freytag via Unicode wrote:
>> Under the implicit assumptions bandied about here, the VS approach
>> thus reveals itself as a true rich-text solution (font switching)
>&
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
goo
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 ar
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 maxim
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 a
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
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
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 ca
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 ty
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 Zar
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) in
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 al
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 conven
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 t
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 perfectly
> 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 u
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 linearly
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 ta
> 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 word
hopeless to
attempt to cover all of Unicode's scripts
on that premise.
A./
On 2/9/2019 10:25 AM, Egmont Koblinger
via Unicode wrote:
On Sat, Feb 9, 2019 at 7:07 PM Eli Zaretskii wrote:
You
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 a
> 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 an
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 emu
> 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 numb
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
Egmont Koblinger wrote:
Should this scheme be extended for colors, too? What to do with the
legacy 8/16 as well as the 256-color extensions wrt. the color
palette? Should Unicode go into the business of defining a fixed set
of colors, or allow to alter the palette colors using the OSC 4 and
fri
Previously I wrote:
A stateful method, though which might be useful for plain text streams
in some applications, would be to encode as characters some of the
glyphs for indicating colours and the digit characters to go with them
from page 5 and from page 3 of the following publication.
http
On Sat, 9 Feb 2019 04:52:30 -0800
David Starner via Unicode wrote:
> Note that this is actually the only thing that stands out to me in
> Unicode not supporting older character sets; in PETSCII (Commodore
> 64), the high-bit character characters were the reverse (in this
> sense) of
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 shap
On Sat, Feb 9, 2019 at 4:58 AM David Starner via Unicode <
unicode@unicode.org> wrote:
>
> On Sat, Feb 9, 2019 at 3:59 AM Kent Karlsson via Unicode <
> unicode@unicode.org> wrote:
>
>>
>> Den 2019-02-08 21:53, skrev "Doug Ewell via Unicode" > >
On Sat, Feb 9, 2019 at 3:59 AM Kent Karlsson via Unicode <
unicode@unicode.org> wrote:
>
> Den 2019-02-08 21:53, skrev "Doug Ewell via Unicode" >:
> > • Reverse on: ESC [7m
> > • Reverse off: ESC [27m
>
> "Reverse" = "switch background
Den 2019-02-08 21:53, skrev "Doug Ewell via Unicode" :
> I'd like to propose encoding italics and similar display attributes in
> plain text using the following stateful mechanism:
Note that these do NOT nest (no stack...), just state changes for the
relevant PART of the
Den 2019-02-08 22:29, skrev "Egmont Koblinger via Unicode"
:
> (Mind you, I don't find it a good idea to add italic and whatnot
> formatting support to Unicode at all... but let's put aside that now.)
I don't think Doug mean to "add it to the Unicode standar
On Fri, 8 Feb 2019 18:08:34 -0800
Asmus Freytag via Unicode wrote:
> On 2/8/2019 5:42 PM, James Kass via Unicode wrote:
> You are still making the assumption that selecting a different glyph
> for the base character would automatically lead to the selection of a
> different g
> 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 m
> 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 de
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 s
Asmus Freytag wrote,
> You are still making the assumption that selecting a different glyph for
> the base character would automatically lead to the selection of a
different
> glyph for the combining mark that follows. That's an iffy assumption
> because "italics" can be realized by choosing
On 2/8/2019 5:42 PM, James Kass via
Unicode wrote:
William,
Rather than having the user insert the VS14 after every character,
the editor might allow the user to select a span of text for
italicization. Then it would be up to
William,
Rather than having the user insert the VS14 after every character, the
editor might allow the user to select a span of text for italicization.
Then it would be up to the editor/app to insert the VS14s where appropriate.
For Andrew’s example of “fête”, the user would either type th
On Fri, 8 Feb 2019 14:26:28 -0800
Asmus Freytag via Unicode wrote:
> On 2/8/2019 2:08 PM, Richard Wordingham via Unicode wrote:
> On Fri, 8 Feb 2019 17:16:09 + (GMT)
> "wjgo_10...@btinternet.com via Unicode" wrote:
>
> Andrew West wrote:
>
> Just reminding
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 maximal
On 2/8/2019 2:08 PM, Richard Wordingham
via Unicode wrote:
On Fri, 8 Feb 2019 17:16:09 + (GMT)
"wjgo_10...@btinternet.com via Unicode" wrote:
Andrew West wrote:
Just reminding you that &q
On Fri, 8 Feb 2019 22:29:57 +0100
Egmont Koblinger via Unicode wrote:
> Some terminal emulators have made up some new SGR modes, e.g. ESC[4:3m
> for curly underline. What to do with them? Where to draw the line what
> to add to Unicode and what not to? Will Unicode possibly be a
> b
> 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 W
On Fri, 8 Feb 2019 17:16:09 + (GMT)
"wjgo_10...@btinternet.com via Unicode" wrote:
> Andrew West wrote:
>> Just reminding you that "The initial character in a variation
>> sequence
>> is never a nonspacing combining mark (gc=Mn) or a canonical
>
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 a
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 enti
> 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).
No
ode goes for something
brand new, something clean, easily parseable, and it remains the job
of specific applications to serve as a bridge between the two worlds.
Or, if it wants to adopt some already existing technology, I find
HTML/CSS a much better starting point.
regards,
egmont
On Fri, Feb 8, 20
+∞
-- Rebecca Bettencourt
On Fri, Feb 8, 2019 at 12:55 PM Doug Ewell via Unicode
wrote:
> I'd like to propose encoding italics and similar display attributes in
> plain text using the following stateful mechanism:
>
> • Italics on: ESC [3m
> • Italics off: ESC
I'd like to propose encoding italics and similar display attributes in
plain text using the following stateful mechanism:
• Italics on: ESC [3m
• Italics off: ESC [23m
• Bold on: ESC [1m
• Bold off: ESC [22m
• Underline on: ESC [4m
• Underline off: ESC [24m
•
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
Andrew West wrote:
Just reminding you that "The initial character in a variation sequence
is never a nonspacing combining mark (gc=Mn) or a canonical
decomposable character" (The Unicode Standard 11.0 §23.4). This means
that a variation sequence cannot be defined for any precomposed
letters and
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 m
> 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 nil
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 settin
> 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", a
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 to
> 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 fon
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 scrollin
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 ). Sure
These were proposed with others in 13-237 (
http://unicode.org/L2/L2013/13237-punctuation.txt) and were declined (
https://www.unicode.org/L2/L2014/14101-closed-ai.html). The proposal
presented them as Russian punctuation marks.
On Thu, 7 Feb 2019, 16:08 Serik Serikbay 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 would just
> > break a gazillion of things.
>
>
> 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
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
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) c
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 usable
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
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 h
601 - 700 of 3287 matches
Mail list logo
