Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #149611 > unrolled thread

Unicode in C Sources

Back to article view | Back to comp.lang.c

Contents

  Unicode in C Sources F Russell <fr@random.info> - 2020-02-01 17:12 +0000
    Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-01 17:37 +0000
      Re: Unicode in C Sources Anton Shepelev <anton.txt@gmail.com> - 2020-02-01 20:43 +0300
        Re: Unicode in C Sources Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-01 10:57 -0800
          Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 16:58 +0100
            Re: Unicode in C Sources F Russell <fr@random.info> - 2020-02-02 17:05 +0000
              Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 19:52 +0100
                Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-02 19:20 +0000
              Re: Unicode in C Sources Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-03 12:38 +0000
                Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 09:16 -0500
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 15:32 +0100
                    Re: Unicode in C Sources Öö Tiib <ootiib@hot.ee> - 2020-02-03 09:01 -0800
                    Re: Unicode in C Sources Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-03 21:15 +0000
                Re: Unicode in C Sources F Russell <fr@random.info> - 2020-02-04 02:06 +0000
                Re: Unicode in C Sources F Russell <fr@random.info> - 2020-02-04 02:19 +0000
                  Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-04 02:50 +0000
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-04 08:16 +0100
      Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-01 18:10 +0000
        Re: Unicode in C Sources Richard Damon <Richard@Damon-Family.org> - 2020-02-01 15:19 -0500
          Re: Unicode in C Sources Manfred <invalid@add.invalid> - 2020-02-02 00:13 +0100
            Re: Unicode in C Sources Manfred <invalid@add.invalid> - 2020-02-02 00:46 +0100
              Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-02 00:24 +0000
            Re: Unicode in C Sources Richard Damon <Richard@Damon-Family.org> - 2020-02-02 08:14 -0500
              Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-02 17:59 +0100
                Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 14:44 -0500
                  Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-02 21:49 +0100
                    Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 16:58 -0500
                      Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-03 15:33 +0100
                        Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-03 15:38 +0100
                        Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 10:25 -0500
                          Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-03 19:11 +0100
                            Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 15:59 -0500
                              Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-04 16:51 +0100
                                Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-04 16:05 -0500
                                Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-19 12:17 -0800
        Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 17:09 +0100
          Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 14:46 -0500
            Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 21:39 +0100
              Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 17:07 -0500
                Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 13:12 +0100
                  Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-03 16:46 +0100
                  Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-03 16:47 +0000
                    Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 13:36 -0800
                      Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 23:56 +0100
                  Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 13:06 -0500
                    Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 22:25 +0100
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 13:29 -0800
                        Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-19 12:30 -0800
                          Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-19 14:19 -0800
                            Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:50 -0700
                              Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:16 -0700
                      Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-03 22:33 +0000
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 23:05 -0500
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 23:10 -0500
                    Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-04 18:05 +0100
                      Re: Unicode in C Sources already5chosen@yahoo.com - 2020-02-04 09:38 -0800
                        Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-04 18:46 +0100
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-04 16:07 -0500
              Re: Unicode in C Sources Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-02 14:54 -0800
        Re: Unicode in C Sources Siri Cruise <chine.bleu@yahoo.com> - 2020-02-03 15:10 -0800
    Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-03 07:47 +0100
      Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 14:00 +0100
        Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-03 16:45 +0100
          Re: Unicode in C Sources Guillaume <message@bottle.org> - 2020-02-03 17:54 +0100
          Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 22:36 +0100
            Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-04 16:33 +0100
              Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-04 16:45 +0100
                Re: Unicode in C Sources Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-04 13:02 -0800
                  Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-04 23:18 +0100
                    Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 11:07 +0100
                      Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-05 14:49 +0100
                        Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 06:23 -0800
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 10:54 +0100
                Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-05 14:51 +0100
                  Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-05 14:03 +0000
                    Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 16:31 +0100
                      Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-05 15:59 +0000
                        Re: Unicode in C Sources scott@slp53.sl.home (Scott Lurndal) - 2020-02-05 16:02 +0000
                          Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 16:59 +0000
                            Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-05 18:02 +0000
                              Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-05 19:37 +0100
                              Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-05 19:37 +0100
                                Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-05 21:02 +0100
                                  Re: Unicode in C Sources Ian Collins <ian-news@hotmail.com> - 2020-02-06 10:34 +1300
                                  Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 23:10 +0000
                                    Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-06 13:53 +0100
                                      Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-06 13:26 +0000
                                  Re: Unicode in C Sources Richard Damon <Richard@Damon-Family.org> - 2020-02-06 07:27 -0500
                                Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 23:03 +0000
                                  Re: Unicode in C Sources Mikko Rauhala <mjr@iki.fi> - 2020-02-06 10:46 +0000
                              Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 21:47 +0100
                              Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 22:50 +0000
                            Re: Unicode in C Sources scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 00:25 +0000
                              Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 02:07 +0000
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 16:26 +0100
        Re: Unicode in C Sources antispam@math.uni.wroc.pl - 2020-04-18 03:58 +0000

Page 1 of 5  [1] 2 3 4 5  Next page →

#149611 — Unicode in C Sources

Should it be possible to write C source files in Unicode?

Now, only former-ASCII characters are allowed but it would
be nice to be able to write:

cos(φ) * ω2 - sin(θ) * ω3

rather than:

cos(phi) * omega2 - sin(theta) * omega3

It would seem that this should be a top priority with
the standards committee.

[toc] | [next] | [standalone]

#149616

F Russell <fr@random.info> writes:

> Should it be possible to write C source files in Unicode?
>
> Now, only former-ASCII characters are allowed but it would
> be nice to be able to write:

No, it is allowed now:

$ cat t.c
#include <stdio.h>
#include <math.h>

int main()
{
     double φ = 0.5, ω2 = 0.2, θ = -0.5, ω3 = 0.1;
     printf("%g\n", cos(φ) * ω2 - sin(θ) * ω3);
}
$ clang t.c -lm
$ ./a.out
0.223459

> cos(φ) * ω2 - sin(θ) * ω3
>
> rather than:
>
> cos(phi) * omega2 - sin(theta) * omega3

but, often, names that describe a purpose are even better.

  sin(angle_subtended_by_arc)

might be clearer than either sin(theta) or sin(θ).

> It would seem that this should be a top priority with
> the standards committee.

It's been permitted for some time.  If you mean making it a required
part of the C language, I can't see why you think it should be a top
priority.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#149618

Ben Bacarisse:

> but, often, names that describe a purpose are even better.
>
>   sin(angle_subtended_by_arc)
>
> might be clearer than either sin(theta) or sin(θ).

Although I stronly object non-ASCII sources and allow 8-bit
encoding in string literals as an exception for non-English
programs, I dislike your proposal never-the-less because it
will heavy formulae plactically unreadable.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#149621

On Saturday, 1 February 2020 17:43:49 UTC, Anton Shepelev  wrote:
> Ben Bacarisse:
> 
> > but, often, names that describe a purpose are even better.
> >
> >   sin(angle_subtended_by_arc)
> >
> > might be clearer than either sin(theta) or sin(θ).
> 
> Although I stronly object non-ASCII sources and allow 8-bit
> encoding in string literals as an exception for non-English
> programs, I dislike your proposal never-the-less because it
> will heavy formulae plactically unreadable.
> 
Mathematical convention is to use single characters as identifiers,
resorting to Greek and sometimes even other languages when Latin
runs out. But most parts of most programs aren't very mathematical
in nature.

[toc] | [prev] | [next] | [standalone]

#149636

On 01/02/2020 19:57, Malcolm McLean wrote:
> On Saturday, 1 February 2020 17:43:49 UTC, Anton Shepelev  wrote:
>> Ben Bacarisse:
>>
>>> but, often, names that describe a purpose are even better.
>>>
>>>    sin(angle_subtended_by_arc)
>>>
>>> might be clearer than either sin(theta) or sin(θ).
>>
>> Although I stronly object non-ASCII sources and allow 8-bit
>> encoding in string literals as an exception for non-English
>> programs, I dislike your proposal never-the-less because it
>> will heavy formulae plactically unreadable.
>>
> Mathematical convention is to use single characters as identifiers,
> resorting to Greek and sometimes even other languages when Latin
> runs out. But most parts of most programs aren't very mathematical
> in nature.
> 

It also quickly becomes much more difficult in programming for several 
reasons:

Maths uses all sorts of other notation, of which Greek letters are only 
a small part.  You would want identifiers like x₁, x₂, ẍ, x', x₃ which 
are getting increasingly difficult to handle.

Then there is the problem of typing them.  How do you type θ ?  I can 
type π, µ, and a fair number of other symbols and letters, but there are 
many that most people can't conveniently enter.

There are lots of symbols that look similar, or even identical, but 
would have different Unicode numbers.  That is going to lead to endless 
misunderstandings.

Then there are issues with fonts supporting only some symbols, or people 
using different character encodings with different results.

[toc] | [prev] | [next] | [standalone]

#149641

On Sun, 02 Feb 2020 16:58:32 +0100, David Brown wrote:

> 
> Then there is the problem of typing them.  How do you type θ ?  I can 
> type π, µ, and a fair number of other symbols and letters, but there are 
> many that most people can't conveniently enter.
> 

There is a problem only if one relies on the standard keyboard.
But there are many specialized keyboards available that can
be configured to facilitate Unicode character entry.

I am continually amazed, given the importance of Unicode, at
the lack of progress in implementing new types of keyboards.

[toc] | [prev] | [next] | [standalone]

#149643

On 02/02/2020 18:05, F Russell wrote:
> On Sun, 02 Feb 2020 16:58:32 +0100, David Brown wrote:
> 
>>
>> Then there is the problem of typing them.  How do you type θ ?  I can
>> type π, µ, and a fair number of other symbols and letters, but there are
>> many that most people can't conveniently enter.
>>
> 
> There is a problem only if one relies on the standard keyboard.
> But there are many specialized keyboards available that can
> be configured to facilitate Unicode character entry.
> 
> I am continually amazed, given the importance of Unicode, at
> the lack of progress in implementing new types of keyboards.
> 

No keyboard has enough keys (or space on keys for alternative symbols) 
to cover even a substantial fraction of what people might want.  And no 
one wants to have specialist keyboards for anything other than the one 
or two languages they write regularly.

There are, I think, three sensible options to getting a fair number of 
extra symbols or letters from other alphabets.  One is to switch 
keyboard layout.  That works for changing language, if you either have a 
dual language keyboard or are a fairly good touch typist in both 
layouts.  People use that to swap between Latin and Cyrillic alphabets, 
for example.  Another is to provide extra symbols via "Alt-Gr" and/or 
"Compose" keys.  That is common on *nix systems, and is what I use.  So 
if I want to write the Polish letter Ł, I press "compose", "/", "L". 
And if I want µ, I use AltGr + m.  If I had particularly regular need of 
some other symbols that are not in the keymap, I could add them.  But it 
would be painful for a whole different alphabet.

The final method is with on-screen keyboards.  An even better variant is 
to use a pad for the on-screen keyboard, attached to the PC.

[toc] | [prev] | [next] | [standalone]

#149646

On 02/02/2020 18:52, David Brown wrote:
> On 02/02/2020 18:05, F Russell wrote:
>> On Sun, 02 Feb 2020 16:58:32 +0100, David Brown wrote:
>>
>>>
>>> Then there is the problem of typing them.  How do you type θ ?  I can
>>> type π, µ, and a fair number of other symbols and letters, but there are
>>> many that most people can't conveniently enter.
>>>
>>
>> There is a problem only if one relies on the standard keyboard.
>> But there are many specialized keyboards available that can
>> be configured to facilitate Unicode character entry.
>>
>> I am continually amazed, given the importance of Unicode, at
>> the lack of progress in implementing new types of keyboards.
>>
> 
> No keyboard has enough keys (or space on keys for alternative symbols) 
> to cover even a substantial fraction of what people might want.  And no 
> one wants to have specialist keyboards for anything other than the one 
> or two languages they write regularly.
> 
> There are, I think, three sensible options to getting a fair number of 
> extra symbols or letters from other alphabets.  One is to switch 
> keyboard layout.  That works for changing language, if you either have a 
> dual language keyboard or are a fairly good touch typist in both 
> layouts.  People use that to swap between Latin and Cyrillic alphabets, 
> for example.  Another is to provide extra symbols via "Alt-Gr" and/or 
> "Compose" keys.  That is common on *nix systems, and is what I use.  So 
> if I want to write the Polish letter Ł, I press "compose", "/", "L". And 
> if I want µ, I use AltGr + m.  If I had particularly regular need of 
> some other symbols that are not in the keymap, I could add them.  But it 
> would be painful for a whole different alphabet.
> 
> The final method is with on-screen keyboards.  An even better variant is 
> to use a pad for the on-screen keyboard, attached to the PC.
> 

The software I was creating in the 80s and 90s worked with digitizing 
tablets. There, you can could use a menu overlay on the tablet, 
including a keyboard that could be more flexible that a physical one 
with extra provision for foreign characters.

(We needed to support French, German, Dutch and a couple of Scandinavian 
languages IIRC.)

Although this was mainly for adding annotation; I wouldn't have liked to 
use it for entering source code.

So, a little ahead of its time as a technique for entering different 
alphabets, but probably now superceded by touch-screens (peripheral ones 
if I understood your remark, with their own screens).

[toc] | [prev] | [next] | [standalone]

#149667

On Sun, 2020-02-02, F Russell wrote:
> On Sun, 02 Feb 2020 16:58:32 +0100, David Brown wrote:
>
>> 
>> Then there is the problem of typing them.  How do you type θ ?  I can 
>> type π, µ, and a fair number of other symbols and letters, but there are 
>> many that most people can't conveniently enter.
>
> There is a problem only if one relies on the standard keyboard.

Which everyone does, so that's like objecting "it's a problem only in
Earth gravity".

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#149670

On 2/3/20 7:38 AM, Jorgen Grahn wrote:
> On Sun, 2020-02-02, F Russell wrote:
>> On Sun, 02 Feb 2020 16:58:32 +0100, David Brown wrote:
>>
>>>
>>> Then there is the problem of typing them.  How do you type θ ?  I can 
>>> type π, µ, and a fair number of other symbols and letters, but there are 
>>> many that most people can't conveniently enter.
>>
>> There is a problem only if one relies on the standard keyboard.
> 
> Which everyone does, so that's like objecting "it's a problem only in
> Earth gravity".

European posters to this newsgroup have frequently mentioned using
keyboards that are set up to support different character sets than the
one he was probably referring to as the "standard keyboard".

[toc] | [prev] | [next] | [standalone]

#149671

On 03/02/2020 15:16, James Kuyper wrote:
> On 2/3/20 7:38 AM, Jorgen Grahn wrote:
>> On Sun, 2020-02-02, F Russell wrote:
>>> On Sun, 02 Feb 2020 16:58:32 +0100, David Brown wrote:
>>>
>>>>
>>>> Then there is the problem of typing them.  How do you type θ ?  I can 
>>>> type π, µ, and a fair number of other symbols and letters, but there are 
>>>> many that most people can't conveniently enter.
>>>
>>> There is a problem only if one relies on the standard keyboard.
>>
>> Which everyone does, so that's like objecting "it's a problem only in
>> Earth gravity".
> 
> European posters to this newsgroup have frequently mentioned using
> keyboards that are set up to support different character sets than the
> one he was probably referring to as the "standard keyboard".
> 

I know that some people in international forums think that the world
consists entirely of the USA, a quaint old-fashioned place with funny
spelling called "England", and some other ignorant barbarian countries
with incomprehensible languages and no little relevance to the modern world.

But since I know nothing about "F Russell", I am inclined to give him or
her the benefit of the doubt here, and assume "standard keyboard" means
"PC keyboard with around 103 - 105 keys, and approximately qwerty layout
or equivalent in other language".  I took "new types of keyboard" to
mean something with a lot more keys, or more complex entry methods, or
programmable keys, or keyboards with little screens on each key.  (These
later do exist - but are unpleasantly expensive.)

[toc] | [prev] | [next] | [standalone]

#149685

On Monday, 3 February 2020 16:32:44 UTC+2, David Brown  wrote:
> On 03/02/2020 15:16, James Kuyper wrote:
> > On 2/3/20 7:38 AM, Jorgen Grahn wrote:
> >> On Sun, 2020-02-02, F Russell wrote:
> >>> On Sun, 02 Feb 2020 16:58:32 +0100, David Brown wrote:
> >>>
> >>>>
> >>>> Then there is the problem of typing them.  How do you type θ ?  I can 
> >>>> type π, µ, and a fair number of other symbols and letters, but there are 
> >>>> many that most people can't conveniently enter.
> >>>
> >>> There is a problem only if one relies on the standard keyboard.
> >>
> >> Which everyone does, so that's like objecting "it's a problem only in
> >> Earth gravity".
> > 
> > European posters to this newsgroup have frequently mentioned using
> > keyboards that are set up to support different character sets than the
> > one he was probably referring to as the "standard keyboard".
> > 
> 
> I know that some people in international forums think that the world
> consists entirely of the USA, a quaint old-fashioned place with funny
> spelling called "England", and some other ignorant barbarian countries
> with incomprehensible languages and no little relevance to the modern world.
> 
> But since I know nothing about "F Russell", I am inclined to give him or
> her the benefit of the doubt here, and assume "standard keyboard" means
> "PC keyboard with around 103 - 105 keys, and approximately qwerty layout
> or equivalent in other language".  I took "new types of keyboard" to
> mean something with a lot more keys, or more complex entry methods, or
> programmable keys, or keyboards with little screens on each key.  (These
> later do exist - but are unpleasantly expensive.)

Touch-screens have strongly entered the scene of our industry. Piles of
smartphones and Pads plus there are numerous laptops (Dell XPS 13,
HP Envy x360, HP Spectre x360, Samsung Chromebook Pro, Lenovo Yoga C930
and C630, ThinkPad X1 Extreme Mobile Workstation just some I've seen).
So each self-respecting operating system therefore has virtual keyboards.

[toc] | [prev] | [next] | [standalone]

#149694

On Mon, 2020-02-03, David Brown wrote:
> On 03/02/2020 15:16, James Kuyper wrote:
>> On 2/3/20 7:38 AM, Jorgen Grahn wrote:
>>> On Sun, 2020-02-02, F Russell wrote:
>>>> On Sun, 02 Feb 2020 16:58:32 +0100, David Brown wrote:
>>>>
>>>>>
>>>>> Then there is the problem of typing them.  How do you type θ ?  I can 
>>>>> type π, µ, and a fair number of other symbols and letters, but there are 
>>>>> many that most people can't conveniently enter.
>>>>
>>>> There is a problem only if one relies on the standard keyboard.
>>>
>>> Which everyone does, so that's like objecting "it's a problem only in
>>> Earth gravity".
>> 
>> European posters to this newsgroup have frequently mentioned using
>> keyboards that are set up to support different character sets than the
>> one he was probably referring to as the "standard keyboard".
>> 
>
> I know that some people in international forums think that the world
> consists entirely of the USA, a quaint old-fashioned place with funny
> spelling called "England", and some other ignorant barbarian countries
> with incomprehensible languages and no little relevance to the modern world.
>
> But since I know nothing about "F Russell", I am inclined to give him or
> her the benefit of the doubt here, and assume "standard keyboard" means
> "PC keyboard with around 103 - 105 keys, and approximately qwerty layout
> or equivalent in other language".

And that was my assumption, too.

For programming languages with their own keyboards, see APL.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#149703

On Mon, 03 Feb 2020 12:38:56 +0000, Jorgen Grahn wrote:

>>
>> There is a problem only if one relies on the standard keyboard.
> 
> Which everyone does, so that's like objecting "it's a problem only in
> Earth gravity".
> 

There are programmable accessory keyboards available:

https://www.fentek-ind.com/kp80xkusb.htm#xk-80

Such keyboards can include most of the common Unicode
math symbols, for example.

[toc] | [prev] | [next] | [standalone]

#149704

On Mon, 03 Feb 2020 12:38:56 +0000, Jorgen Grahn wrote:

>>
>> There is a problem only if one relies on the standard keyboard.
> 
> Which everyone does, so that's like objecting "it's a problem only in
> Earth gravity".
> 

Here is an example of a 128-key programmable accessory keyboard:

https://www.dvestore.com/x-keys-xk-128-customizable-usb-keyboard/

What physicist or engineer would not find this useful for entering
Unicode characters?

[toc] | [prev] | [next] | [standalone]

#149705

F Russell <fr@random.info> writes:

> On Mon, 03 Feb 2020 12:38:56 +0000, Jorgen Grahn wrote:
>
>>>
>>> There is a problem only if one relies on the standard keyboard.
>> 
>> Which everyone does, so that's like objecting "it's a problem only in
>> Earth gravity".
>> 
>
> Here is an example of a 128-key programmable accessory keyboard:
>
> https://www.dvestore.com/x-keys-xk-128-customizable-usb-keyboard/
>
> What physicist or engineer would not find this useful for entering
> Unicode characters?

A physicist or engineer who has to work on a laptop?

Hardware solutions have not really caught on because software can make
things simple enough even if they can't make it as simple as hitting a
key with a → on it to get an arrow.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#149713

On 04/02/2020 03:19, F Russell wrote:
> On Mon, 03 Feb 2020 12:38:56 +0000, Jorgen Grahn wrote:
> 
>>>
>>> There is a problem only if one relies on the standard keyboard.
>>
>> Which everyone does, so that's like objecting "it's a problem only in
>> Earth gravity".
>>
> 
> Here is an example of a 128-key programmable accessory keyboard:
> 
> https://www.dvestore.com/x-keys-xk-128-customizable-usb-keyboard/
> 
> What physicist or engineer would not find this useful for entering
> Unicode characters?
> 
> 

Me.

The symbols I need often are on the keyboard already.  If I am writing 
maths, I'll usually do so in LaTeX - symbols are not enough on their 
own.  And if I need a symbol I use rarely, I'd need a far bigger 
selection than just 128 keys - it is vastly simpler to select it with a 
character applet in software.

Even these young folks with their "emoticons" would find 128 keys too few.


People who regularly switch between different languages with different 
alphabets might find some use in it.  But at that price you could have 
twenty different PC-105 keyboards with different symbols and very much 
faster and simpler typing (albeit at a bigger cost in cupboard space).

[toc] | [prev] | [next] | [standalone]

#149620

On 01/02/2020 17:37, Ben Bacarisse wrote:
> F Russell <fr@random.info> writes:
> 
>> Should it be possible to write C source files in Unicode?
>>
>> Now, only former-ASCII characters are allowed but it would
>> be nice to be able to write:
> 
> No, it is allowed now:
> 
> $ cat t.c
> #include <stdio.h>
> #include <math.h>
> 
> int main()
> {
>       double φ = 0.5, ω2 = 0.2, θ = -0.5, ω3 = 0.1;
>       printf("%g\n", cos(φ) * ω2 - sin(θ) * ω3);
> }
> $ clang t.c -lm
> $ ./a.out
> 0.223459

That works with clang on rextester.com, but not with gcc? (Same with 
bcc, where the problem is the first byte of the phi character when using 
utf8.)

Doesn't C restrict identifier names to [A-Z a-z 0-9 _] ?

If not, then what /is/ allowed, as there could be hundreds of thousands 
of allowable characters?

[toc] | [prev] | [next] | [standalone]

#149624

On 2/1/20 1:10 PM, Bart wrote:
> On 01/02/2020 17:37, Ben Bacarisse wrote:
>> F Russell <fr@random.info> writes:
>>
>>> Should it be possible to write C source files in Unicode?
>>>
>>> Now, only former-ASCII characters are allowed but it would
>>> be nice to be able to write:
>>
>> No, it is allowed now:
>>
>> $ cat t.c
>> #include <stdio.h>
>> #include <math.h>
>>
>> int main()
>> {
>>       double φ = 0.5, ω2 = 0.2, θ = -0.5, ω3 = 0.1;
>>       printf("%g\n", cos(φ) * ω2 - sin(θ) * ω3);
>> }
>> $ clang t.c -lm
>> $ ./a.out
>> 0.223459
> 
> That works with clang on rextester.com, but not with gcc? (Same with 
> bcc, where the problem is the first byte of the phi character when using 
> utf8.)
> 
> Doesn't C restrict identifier names to [A-Z a-z 0-9 _] ?
> 
> If not, then what /is/ allowed, as there could be hundreds of thousands 
> of allowable characters?

The C standard allows the implementation to define what set of 
characters it allows in the source of a program. The basic character set 
includes those characters you list as allowed to be in identifiers.

The Standard also allows the implementation to allow additional 
characters in an extended character set (which can easily be all of 
Unicode if desired).

The Standard also defines Universal Characters (using \u9999 or 
\U00012345 notation) which basically allow unicode values to be 
specified, and defines a list of which of these must and must not be 
allowed in identifier names. If the implementation allows general 
Unicode characters in its character set, then those match ranges should 
probably be allowed / disallowed.

The ranges of explicitly allowed codes:
00A8, 00AA, 00AD, 00AF, 00B2–00B5, 00B7–00BA, 00BC–00BE, 00C0–00D6, 
00D8–00F6, 00F8–00FF, 0100–167F, 1681–180D, 180F–1FFF, 200B–200D, 
202A–202E, 203F–2040, 2054, 2060–206F, 2070–218F, 2460–24FF, 2776–2793, 
2C00–2DFF, 2E80–2FFF, 3004–3007, 3021–302F, 3031–303F, 3040–D7FF, 
F900–FD3D, FD40–FDCF, FDF0–FE44, FE47–FFFD, 10000–1FFFD, 20000–2FFFD, 
30000–3FFFD, 40000–4FFFD, 50000–5FFFD, 60000–6FFFD, 70000– 7FFFD, 
80000–8FFFD, 90000–9FFFD, A0000–AFFFD, B0000–BFFFD, C0000–CFFFD, 
D0000–DFFFD, E0000–EFFFD

The ranges of explicitly disallowed codes:
0300–036F, 1DC0–1DFF, 20D0–20FF, FE20–FE2F

Note the codes D800-DFFF (the UTF-16 Surrogates) are explicitly not 
allowed as characters.

Codes not mentioned I suppose are implementation dependent. I would have 
to check carefully, but many of the gaps are unassigned (or assigned as 
not characters) in Unicode.

[toc] | [prev] | [next] | [standalone]

#149627

On 2/1/20 9:19 PM, Richard Damon wrote:
> On 2/1/20 1:10 PM, Bart wrote:
>> On 01/02/2020 17:37, Ben Bacarisse wrote:
>>> F Russell <fr@random.info> writes:
>>>
>>>> Should it be possible to write C source files in Unicode?
>>>>
>>>> Now, only former-ASCII characters are allowed but it would
>>>> be nice to be able to write:
>>>
>>> No, it is allowed now:
>>>
>>> $ cat t.c
>>> #include <stdio.h>
>>> #include <math.h>
>>>
>>> int main()
>>> {
>>>       double φ = 0.5, ω2 = 0.2, θ = -0.5, ω3 = 0.1;
>>>       printf("%g\n", cos(φ) * ω2 - sin(θ) * ω3);
>>> }
>>> $ clang t.c -lm
>>> $ ./a.out
>>> 0.223459
>>
>> That works with clang on rextester.com, but not with gcc? (Same with 
>> bcc, where the problem is the first byte of the phi character when 
>> using utf8.)
>>
>> Doesn't C restrict identifier names to [A-Z a-z 0-9 _] ?
>>
>> If not, then what /is/ allowed, as there could be hundreds of 
>> thousands of allowable characters?
> 
> The C standard allows the implementation to define what set of 
> characters it allows in the source of a program. The basic character set 
> includes those characters you list as allowed to be in identifiers.
> 
> The Standard also allows the implementation to allow additional 
> characters in an extended character set (which can easily be all of 
> Unicode if desired).
> 
> The Standard also defines Universal Characters (using \u9999 or 
> \U00012345 notation) which basically allow unicode values to be 
> specified, and defines a list of which of these must and must not be 
> allowed in identifier names. If the implementation allows general 
> Unicode characters in its character set, then those match ranges should 
> probably be allowed / disallowed.
> 
> The ranges of explicitly allowed codes:
> 00A8, 00AA, 00AD, 00AF, 00B2–00B5, 00B7–00BA, 00BC–00BE, 00C0–00D6, 
> 00D8–00F6, 00F8–00FF, 0100–167F, 1681–180D, 180F–1FFF, 200B–200D, 
> 202A–202E, 203F–2040, 2054, 2060–206F, 2070–218F, 2460–24FF, 2776–2793, 
> 2C00–2DFF, 2E80–2FFF, 3004–3007, 3021–302F, 3031–303F, 3040–D7FF, 
> F900–FD3D, FD40–FDCF, FDF0–FE44, FE47–FFFD, 10000–1FFFD, 20000–2FFFD, 
> 30000–3FFFD, 40000–4FFFD, 50000–5FFFD, 60000–6FFFD, 70000– 7FFFD, 
> 80000–8FFFD, 90000–9FFFD, A0000–AFFFD, B0000–BFFFD, C0000–CFFFD, 
> D0000–DFFFD, E0000–EFFFD
> 
> The ranges of explicitly disallowed codes:
> 0300–036F, 1DC0–1DFF, 20D0–20FF, FE20–FE2F
> 
> Note the codes D800-DFFF (the UTF-16 Surrogates) are explicitly not 
> allowed as characters.
> 
> Codes not mentioned I suppose are implementation dependent. I would have 
> to check carefully, but many of the gaps are unassigned (or assigned as 
> not characters) in Unicode.

This is in n1570 6.4.2, D.1 and D.2, but it does not explain why gcc 
refuses this code: the Greek characters span 0370-03FF, which fall in 
the 0100–167F range of allowed universal character names.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web