Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #401667 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-09-06 15:45 +0200 |
| Last post | 2026-10-05 04:32 +0200 |
| Articles | 20 on this page of 496 — 24 participants |
Back to article view | Back to comp.lang.c
Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-06 15:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-06 15:52 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-06 16:52 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-06 21:41 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 09:37 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 11:35 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 13:15 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 13:55 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:24 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 15:33 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 16:34 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-08 00:50 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 00:35 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-07 17:43 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-07 16:52 -0700
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 15:24 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 10:18 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 20:16 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 14:31 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 14:37 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 21:37 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-18 09:38 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-18 17:42 +0800
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-08 03:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-08 16:40 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 20:08 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:35 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:18 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 12:32 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 14:30 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:09 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 16:58 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 18:34 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 18:37 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 20:12 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 22:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 21:15 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:37 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 21:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 21:39 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:07 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 14:41 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 23:31 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:10 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 09:25 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:59 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:35 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 11:35 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 14:43 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-10 14:08 -0700
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-10 14:14 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-11 09:16 +0200
Re: Official list of top C annoyances Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-14 19:14 +0000
Re: Official list of top C annoyances Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 08:29 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 02:45 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 15:07 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:14 -0600
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 15:31 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:41 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 15:58 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 08:05 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:13 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 16:29 -0700
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 10:23 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:19 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 17:02 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:11 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 08:25 -0600
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:53 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 17:42 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 17:53 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:03 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:19 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:49 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 19:16 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:48 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 18:38 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:04 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 17:12 +0200
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-09 23:59 +0800
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:30 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 06:50 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:13 -0700
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-09 15:16 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:43 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 07:16 +0200
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-08 00:02 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 12:47 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-09 01:59 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 10:26 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 19:12 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-09 21:01 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 21:45 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 21:18 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:32 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:26 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 23:30 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 08:45 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 13:09 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 14:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:11 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:28 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 14:33 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:51 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:03 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 15:27 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:59 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 16:57 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:18 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 01:04 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:54 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 17:06 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 17:15 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 18:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:21 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 18:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:56 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:20 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 20:19 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 20:25 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:17 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-11 09:21 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 12:46 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 14:13 +0200
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-11 13:41 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 14:55 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:04 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:08 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:13 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:17 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 21:02 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 21:59 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:41 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:48 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 00:06 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 23:48 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 15:52 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-11 00:48 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 17:11 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-12 08:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 08:20 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 09:09 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 12:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 12:40 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 11:55 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 14:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 14:49 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:00 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 14:24 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:44 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:53 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 16:05 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 16:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 17:20 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 17:08 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 10:53 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:23 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 18:58 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:46 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:49 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 22:16 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 15:40 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:27 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 10:30 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 11:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 11:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 11:26 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:55 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 13:11 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-13 05:29 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 13:43 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-13 14:00 -0700
Re: Official list of top C annoyances Ike Naar <ike@sdf.org> - 2026-09-13 10:53 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 13:46 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 15:21 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 15:31 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 16:34 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 16:58 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 18:01 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 21:14 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:17 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:23 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:27 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-13 17:06 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 15:01 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 18:11 +0200
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-14 20:21 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 22:54 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-14 23:56 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 09:07 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 09:41 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 10:22 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 11:51 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 12:53 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-18 09:10 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 11:37 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:03 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 13:01 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-05 01:57 +0000
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 18:54 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 22:55 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 21:03 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 00:33 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-13 10:50 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:32 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:34 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:39 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:23 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 07:45 -0600
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-11 00:37 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-13 18:55 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 01:44 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-14 07:41 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 14:01 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 14:09 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 02:42 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 23:41 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 01:48 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 07:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-15 11:28 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 14:54 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-15 21:56 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 21:34 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 00:36 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 02:21 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 09:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 11:21 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 13:47 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 15:20 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 17:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 00:36 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-16 16:59 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 01:49 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-16 19:43 -0700
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 09:24 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 11:29 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:06 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 02:04 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 18:19 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 11:27 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:21 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 13:17 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:44 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:16 +0200
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-18 12:55 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 17:53 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:47 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 21:22 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:58 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 21:06 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:04 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-22 21:07 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:41 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:34 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 12:52 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 13:15 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 15:16 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 15:25 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 17:05 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 16:46 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 20:22 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 20:19 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:55 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 23:47 +0000
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 20:54 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:44 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 23:48 +0000
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-18 00:04 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 01:34 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 17:50 -0700
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 17:45 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:28 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 18:34 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 18:08 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:26 -0700
Re: Official list of top C annoyances gazelle@shell.xmission.com (Kenny McCormack) - 2026-09-18 20:39 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 13:10 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 13:20 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 17:30 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:38 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 21:00 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 10:17 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 11:29 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 12:52 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-10-06 01:06 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-20 15:58 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:55 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 20:41 +0300
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-22 01:53 +0800
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-22 11:28 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-22 11:34 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:00 +0000
Re: Official list of top C annoyances Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-09-22 14:22 +0000
Re: Official list of top C annoyances Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-09-22 15:04 +0000
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 16:38 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:28 +0000
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-10-06 01:29 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 22:01 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 20:28 +0000
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-18 05:42 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-18 08:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 10:23 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:24 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 16:31 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:29 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 20:14 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 12:42 -0700
Re: Official list of top C annoyances Jim Jackson <jj@franjam.org.uk> - 2026-09-19 13:39 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 16:24 +0100
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-19 00:19 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 02:06 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 20:20 -0700
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-19 03:26 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:56 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 11:08 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-19 13:25 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 10:45 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-19 15:09 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 16:17 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:45 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 13:11 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 14:03 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 17:24 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:06 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 20:07 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 12:26 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 22:57 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 17:27 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 20:09 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 12:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 12:42 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 15:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 14:22 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 14:54 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 23:24 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-21 15:06 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-21 16:36 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-21 17:45 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 20:54 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:02 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-22 21:02 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 15:58 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 15:19 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 23:49 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 16:17 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:49 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 15:18 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:41 +0000
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 21:05 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 14:38 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 17:15 +0200
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 16:33 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 20:26 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-17 13:26 -0700
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-17 13:25 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 12:36 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 13:03 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 14:51 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 14:32 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:17 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:24 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 09:06 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 02:08 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:01 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 03:05 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:13 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 17:33 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 19:19 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 18:34 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 20:21 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 13:16 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 15:26 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 15:58 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 19:13 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 18:30 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 20:30 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 21:16 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 02:56 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:32 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-29 19:58 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-05 02:15 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:22 +0000
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 09:49 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 11:27 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 16:03 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 16:15 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 23:27 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-23 01:01 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-23 23:38 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 02:00 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-24 02:41 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-23 20:23 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 11:27 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-24 23:54 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 01:23 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-25 03:47 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 11:38 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-26 02:49 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 11:44 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 14:03 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-28 00:05 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 00:56 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-29 14:27 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:02 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-30 11:18 +0100
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-30 13:37 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-30 17:17 +0300
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-30 14:39 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 22:39 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-01 15:23 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-02 02:38 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-10-02 09:17 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-25 12:17 +0300
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 11:31 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-26 02:34 +0000
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-24 08:50 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-24 11:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 11:29 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-25 21:09 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 11:59 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-29 04:06 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 04:47 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-29 23:49 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-30 12:19 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 10:13 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:38 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 11:40 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 12:05 +0200
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-09 15:23 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:07 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:52 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 01:00 +0200
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 10:17 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-18 09:29 +0200
Re: Official list of top C annoyances Jim Jackson <jj@franjam.org.uk> - 2026-09-19 13:46 +0000
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-25 09:15 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 06:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 14:38 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:36 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 10:11 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 00:48 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:18 +0000
Re: Official list of top C annoyances Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 12:58 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 23:21 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-08 12:47 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:20 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 09:53 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-07 23:59 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-07 16:04 -0600
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-07 04:06 -0700
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-07 20:05 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:32 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 12:59 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 13:09 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 14:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 14:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 14:49 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 16:05 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 16:18 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 09:45 -0600
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 20:41 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-08 12:39 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 15:55 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 18:02 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 17:39 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 18:47 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 18:19 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 19:24 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 19:26 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 03:25 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:13 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:38 -0600
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-09 22:16 +0800
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:02 +0200
Re: Official list of top C annoyances Jan van den Broek <balglaas@dds.nl> - 2026-09-09 12:50 +0000
And then we reached C# (was Re: Official list of top C annoyances) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 08:51 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 14:54 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 16:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-25 14:22 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-10-05 04:32 +0200
Page 9 of 25 — ← Prev page 1 … 7 8 [9] 10 11 … 25 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-12 17:20 +0200 |
| Message-ID | <1183qjm$3s31m$1@dont-email.me> |
| In reply to | #401997 |
fir pisze: > fir pisze: >> >> F a+b -1 sin c > > this second minus is in fact needed so normally > > this above is f a+b-2 sin(c) > > unicode as usually instead of having something cruciallu usful provides > soem weirdos here > > this above with -2 not subtraction would be f a+b ˗2 sin(c) > > but meybe somethin could be find note (1) imo you should not look if its easy for human to resolve it only if compiler can resolve it human can add some spaces and () "eventually" so what the problem more over trained people would understand it as they understand present c which is also quite cryptic if you dont understand it and note (2) id compiler is to understod given formula it had definitions so he knows if given ab c d e if function variable type or something else as it need be defined (if its not defined he recgognizes it too - as undefined symbol mor eto say thse comples syntaxes are in fact rare imo, most common is pure stuf like print "abjhabj", drawline x y p q 0x777 so most impoortant it has this especially clean (as i got) second more common is probbaly setpixel x*b+c y*g+h rand_color 0x889977 0xaabbcc imo its also clean if you know what setpixel and rand_color take set pixel takes 3 and randcolor2 so its not any ambiguity for compiler and human may add () in many places here setpixel(x*b+c y*g+ (rand_color(0x889977 0xaabbcc)) though this traditional form im not sure imo its probably clearer to write setpixel x*b+c y*g+h (rand_color 0x889977 0xaabbc) than traditional setpixel (x*b+c y*g+h rand_color(0x889977 0xaabbc)) this is becouse (f a a) is one thing where f(a a) is one things and (a a) is liek lESS one thing, but probbaly this form can be allowed for tradition (though im not sure as it seems bad)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-12 17:08 +0100 |
| Message-ID | <1183tdg$3tbf3$1@dont-email.me> |
| In reply to | #401994 |
On 12/09/2026 14:44, fir wrote:
> bart pisze:
>> On 12/09/2026 13:37, fir wrote:
>>> bart pisze:
>>>> * Mostly semicolon-free syntax (newline terminates statements
>>>> unless they clearly continue onto the next line)
>>>
>>> make it also ,-free becouse most (if not strictly any) , is not
>>> needed as space is a separtor ...
>>
>> Removing intra-line commas is not really practical. Even if
>> technically some code can be parsed without it, humans have difficulty.
>>
>> Some structure is needed. Take this parameter list with commas:
>>
>> (a b c, d e)
>>
>> 'a' and 'd' are types; b, c, e are parameter names. Without the commas
>> it would just be:
>>
>> (a b c d e)
>>
>
> its becouse you give examples with not know what it mean if it would be
>
> int b c float e its more clear (fully clear imo
Sure, but what happens when someone /wants/ to have user-define types?
So in general it is ambiguous.
In C you can also have a parameter list which has only types, no
parameter names. If that is still a feature, then:
(a, b, c, d);
can be assumed (by the reader) to be all types. But this:
(a b c d)
is more ambiguous; how many parameters are there: is it 4 (abcd are all
types); 3 (a is a type, bcd are names), or 2 (ac are types, bd are
names)? Other combinations may be possible.
>
> though im was not saying on this case - as i said , works in a place
> of ; (its a "logical line" seperator so it work like ";" in c where the
> c usages of "," are ust removed
>
> i mean , removed
> ; replaced by ,
>
>
>
>> (In my language, user-defined types are not resolved into types until
>> after parsing. The parser relies on structure to determine which names
>> are types.)
>>
>> While a function call like F(a + b, -1, sin c) ('sin' is an operator),
>> would become:
>>
>> F(a + b -1 sin c)
>>
>
> F a+b -1 sin c
Significant white space now? Come pm, what sort of crazy language is
this going to be?!
But since this is a fantasy language anyway that is never going to be
implemented, then sure, leave out whatever you want. But it will be a
terrible language to work with.
> is clear imo 9though better is to use separate - sign for neg values
> not subtraction)
>
> in above i mean probably its good to take you baf write
>
> foo arg arg arg foo arg arg
Users can make their own identifiers so it could be this:
arg foo foo foo arg foo foo
In general a compiler will see:
a b c d e f g
Seven consecutive identifiers.
> i mean "only one function acll in logical line so you would need
>
> foo arg arg arg, foo arg arg
>
> to satisfy this rule so if
>
> you see this
>
> F a+b -1 sin c
>
> you know its one function call thus sin c is argument
I'm sorry, but this stuff needs to be COMPLETELY AMBIGUOUS. Someone
should INSTANTLY be able to know what is intended, rather than waste
time trying to infer it. This is supposed to be the source code of some
program, not a puzzle!
You can make it unambiguous by using commas and parentheses, and
EVERYONE will understand what is being expressed.
What exactly are trying to achieve here: saving a few seconds of typing
but then spending ten times as long trying to understand the code, or
1000 times as long trying to debug all the subtle bugs that have crept in?
I know this is a fantasy, but aren't you interested in practicalities at
all?
>>> i just like removed , and
>>> turned :: into , (as it was fee and better lookin)
>>
>>
>
> sorry i meant ; not :: (shift didnt worked )
std;cout isn't much better! Both "::" and "." are commonly used for this
purpose.
> im not sure if allowing print(a b c) could not cause slight collisions
> if so some slight changes there would need be here but in worst case
> it would be disalowed but probably i would prefer in worst case
> doing meaningful space it is not eventually allowing
>
> print (a b c)
How sure are you that two user identifiers can never be adjacent?
What about operators that can be both unary and binary? A further example:
a b * c * d
Is this a(b * c * d), or a(b, *c * d), or (b, *c, *d) etc?
Please don't say that you have to work it out by hunting for the
definitions; as I said this should not be a puzzle.
[toc] | [prev] | [next] | [standalone]
| From | Lane W <cactus_DAC@yahoo.com> |
|---|---|
| Date | 2026-09-12 10:53 -0600 |
| Message-ID | <118402e$3ubi4$1@dont-email.me> |
| In reply to | #402000 |
bart wrote: > What exactly are trying to achieve here: saving a few seconds of typing > but then spending ten times as long trying to understand the code, or > 1000 times as long trying to debug all the subtle bugs that have crept in? That's the spirit! fir is trying to achieve a nonsensical language, just like your line here (which I guess is missing the word 'you'). Playing along, I see you are typing nonsense to placate him!
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-12 19:23 +0200 |
| Message-ID | <11841pv$3v1vu$1@dont-email.me> |
| In reply to | #402000 |
bart pisze:
> On 12/09/2026 14:44, fir wrote:
>> bart pisze:
>>> On 12/09/2026 13:37, fir wrote:
>>>> bart pisze:
>>>>> * Mostly semicolon-free syntax (newline terminates statements
>>>>> unless they clearly continue onto the next line)
>>>>
>>>> make it also ,-free becouse most (if not strictly any) , is not
>>>> needed as space is a separtor ...
>>>
>>> Removing intra-line commas is not really practical. Even if
>>> technically some code can be parsed without it, humans have difficulty.
>>>
>>> Some structure is needed. Take this parameter list with commas:
>>>
>>> (a b c, d e)
>>>
>>> 'a' and 'd' are types; b, c, e are parameter names. Without the
>>> commas it would just be:
>>>
>>> (a b c d e)
>>>
>>
>> its becouse you give examples with not know what it mean if it would be
>>
>> int b c float e its more clear (fully clear imo
>
> Sure, but what happens when someone /wants/ to have user-define types?
> So in general it is ambiguous.
>
> In C you can also have a parameter list which has only types, no
> parameter names. If that is still a feature, then:
>
> (a, b, c, d);
>
> can be assumed (by the reader) to be all types. But this:
>
> (a b c d)
>
> is more ambiguous; how many parameters are there: is it 4 (abcd are all
> types); 3 (a is a type, bcd are names), or 2 (ac are types, bd are
> names)? Other combinations may be possible.
>
>>
>> though im was not saying on this case - as i said , works in a place
>> of ; (its a "logical line" seperator so it work like ";" in c where
>> the c usages of "," are ust removed
>>
>> i mean , removed
>> ; replaced by ,
>>
>>
>>
>>> (In my language, user-defined types are not resolved into types until
>>> after parsing. The parser relies on structure to determine which
>>> names are types.)
>>>
>>> While a function call like F(a + b, -1, sin c) ('sin' is an
>>> operator), would become:
>>>
>>> F(a + b -1 sin c)
>>>
>>
>> F a+b -1 sin c
>
>
> Significant white space now? Come pm, what sort of crazy language is
> this going to be?!
>
> But since this is a fantasy language anyway that is never going to be
> implemented, then sure, leave out whatever you want. But it will be a
> terrible language to work with.
>
>> is clear imo 9though better is to use separate - sign for neg values
>> not subtraction)
>>
>> in above i mean probably its good to take you baf write
>>
>> foo arg arg arg foo arg arg
>
> Users can make their own identifiers so it could be this:
>
> arg foo foo foo arg foo foo
>
> In general a compiler will see:
>
> a b c d e f g
>
this is your very serious problem here that you assume 'unlearned' human
should understand it, compiler must understand it... Im not sure hovever
how to explain it to you that this your dogmate is wrong
you know what you talk also fits to c you also neeeded to learn what
given construction mean here its just the same jus construction have
less ,,, () stuf
kompiler knows what given symbols are..if it make sense it will compile
it if not he will not if you make some complex stuff with a net of
functions like
f1 a f2 f3 f4 a a f5 f6
compiler know which function takes how many arguments
and will resolve it to fit
im not sure if there is any disimbiguity here or none
if you know one tell me and i will tell a rule to resolve it
(as it may be resolved by some rule
if yu worry on humen radibilit y you just add parentheses and you
end up at worst in your initial form..but there is simply a form to
do it much cleaner and many use will use the clean lightweight 'naked'
form (no gothic clothes)
> Seven consecutive identifiers.
>
>> i mean "only one function acll in logical line so you would need
>>
>> foo arg arg arg, foo arg arg
>>
>> to satisfy this rule so if
>>
>> you see this
>>
>> F a+b -1 sin c
>>
>> you know its one function call thus sin c is argument
>
>
> I'm sorry, but this stuff needs to be COMPLETELY AMBIGUOUS. Someone
> should INSTANTLY be able to know what is intended, rather than waste
> time trying to infer it. This is supposed to be the source code of some
> program, not a puzzle!
>
it is totally ambigious , one confusion is only related to the problem
that -2 uses the same sign as 4-2 (this is in fact nonstandable that
mean you need give unicode sign (and in worse case if comeone couldnt
probbaly something like this meaningful space here but that would be
bad ofc in that case - though generally spaces are meningfull its not
that you can skipp all spaces in c... in fact in my version they are
more meaningfull than in c becouse you cant delete much more of them but
this kind of meaningfulnes as 4-2 against 4 -2 is obviously wrong
(but some other better probably may exist)
when i see this its totally clear to me
F a+b -1 sin c
F tahes 2 args a+b-1 and sin c its only badly written like
F (a +b -1 , sin( c ) )
you may also badly write
> You can make it unambiguous by using commas and parentheses, and
> EVERYONE will understand what is being expressed.
>
> What exactly are trying to achieve here: saving a few seconds of typing
> but then spending ten times as long trying to understand the code, or
> 1000 times as long trying to debug all the subtle bugs that have crept in?
>
imo it is both faster to read and type arso cleaner
> I know this is a fantasy, but aren't you interested in practicalities at
> all?
>
its not a fantasy language this is just scientific outcome on possible
language syntax so it so much fantasy as 2+2=4
its not a fantasy its a RESULT
(such things name is RESULTS (rezultaty in polish), outcome
>
>>>> i just like removed , and
>>>> turned :: into , (as it was fee and better lookin)
>>>
>>>
>>
>> sorry i meant ; not :: (shift didnt worked )
>
> std;cout isn't much better! Both "::" and "." are commonly used for this
> purpose.
>> im not sure if allowing print(a b c) could not cause slight collisions
>> if so some slight changes there would need be here but in worst case
>> it would be disalowed but probably i would prefer in worst case
>> doing meaningful space it is not eventually allowing
>>
>> print (a b c)
> How sure are you that two user identifiers can never be adjacent?
>
> What about operators that can be both unary and binary? A further example:
>
> a b * c * d
>
> Is this a(b * c * d), or a(b, *c * d), or (b, *c, *d) etc?
>
> Please don't say that you have to work it out by hunting for the
> definitions; as I said this should not be a puzzle.
>
no worry , definitions wouldnt help here
this above is obviously non possible you cant have unary and binary
here (as far as it seems, i may be maybe wrong)
a*b must be binary if *b would be unary then it mean you have
a *b so its ambiguity , so there some additional rule would need to be
used at least
rule can be
a*b // is binary
a(*b) //is unary
(a*)b //is unary
this touches some problem becouse it blocks a(b) syntax which eventually
could be usefull, but it eventually may be seen not much usefull
as i see () more like separators not 'calling' operator
(it only be blocked for those types of ab though not necessary for
fiunction calls
there is also option to use this space as a seperator ..this kind of
mmeaningfull spaces i use here all time for example in a b c d
apaces are meaningfull coz its not ab c d
so a *b wouldnt be considered good idea but a (*b) being different than
a(*b) may be (but VERY eventually)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-12 18:58 +0100 |
| Message-ID | <11843r8$3vq6i$1@dont-email.me> |
| In reply to | #402002 |
On 12/09/2026 18:23, fir wrote:
> bart pisze:
>> In general a compiler will see:
>>
>> a b c d e f g
>>
> this is your very serious problem here that you assume 'unlearned' human
> should understand it, compiler must understand it...
This is the problem: a compiler might not understand it.
To do so, first requires that those symbols have been previously
defined, and here, that they have also been resolved /while parsing/.
This is the case for C as it is now. But remember you were annoyed at
having to declare things in advance? So it might be that 'a' is a
function that is defined later on.
In that case, it won't know how to parse this properly. It will need to
build a tentative AST (perhaps a concrete syntax tree or 'CST'), and
later transform into a proper AST.
But that still leaves the problem of any reader of the code being
bamboozled.
It might worth remembering that a HLL is supposed to be easier to write
and read than assembly or machine code. Having this extra burden for
virtually no benefit is pointless.
> you know what you talk also fits to c you also neeeded to learn what
> given construction mean here its just the same jus construction have
> less ,,, () stuf
Well, we don't know the rest of your language. I mentioned one point above.
C itself still has structure: you will never see 7 user identifiers
together (unless someone goes overboard with macros, and that would be
very poor too).
>
>
>
> kompiler knows what given symbols are..if it make sense it will compile
> it if not he will not if you make some complex stuff with a net of
> functions like
>
> f1 a f2 f3 f4 a a f5 f6
> compiler know which function takes how many arguments
> and will resolve it to fit
OK, a compiler might be able to do so if:
* There are no variadic functions
* The languages doesn't have default argument values (BTW this feature
would be a million times more useful than being able to leave out all
punctuation)
* The function doesn't use an unspecified parameter list (this was a
feature of C but C23 may have deprecated that)
* You sort out the clashes between unary and binary operators.
* All names have either been previously defined, or whole extras has
been done for this purpose.
But that is not the point: a human reader does not want that extra burden.
> im not sure if there is any disimbiguity here or none
>
>
> if you know one tell me and i will tell a rule to resolve it
> (as it may be resolved by some rule
>
> if yu worry on humen radibilit y you just add parentheses and you
> end up at worst in your initial form
It's not that simple; if you see:
a ( ... )
does that '(' mean the whole argument list is contained, or just the
first argument of several? How much lookahead is needed to make it work?
..but there is simply a form to
> do it much cleaner and many use will use the clean lightweight 'naked'
> form (no gothic clothes)
> when i see this its totally clear to me
OK, here is a fragment of code by itself:
a b c d
Tell me what it means. You don't have access to the rest of the program,
or you haven't got time to hunt for the definitions in 100,000 lines of
code spread across 28 headers in 12 folders.
Now here is the same fragment but with those 'useless' commas and
parentheses:
a(b(c, d))
Does that help?
Yes, there might technically be redundancy, but that is a useful feature
in a programming language: it can catch mistakes.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-12 20:35 +0200 |
| Message-ID | <118461q$lk4$1@dont-email.me> |
| In reply to | #402005 |
bart pisze:> > a(b(c, d)) > > Does that help? not much honestly - if youre so much in hole you can find definitions..as you say you are two terrible mistakes you do 1) you somewhat assume that definitions are not pesent - all definitions are present - if definitions are not present it would not compile 2) you talk about this human reader its not a problem you may add those parenthesis optionally... and if someone not added it blame him though as i said i would add the () different way not a(b(c, d)) but a (b c d) you anyway should use meaningdull names in this examples becouse names carry an information and with this examples you compare obfuscated code context - in which by chance my form also wins (which is fortunate) im not saying this is no more cryptic i just say its not cryptic if you know what it is and know the rules this form is simpler a(b(c, d)) than mine a b c d becouse in mine form this a b c d may be just more things than in this a(b(c, d)) in your form a can be a variable or type b also c cant be a function d cant be a function its very bad becouse in my form it can (note i not yet call about all thos syntaxes as i mosly only chosen the function call form (also nested) and simple expresions like a=b+3 eben for such simple expresions ike int a b c or int a b c float e d f alos not fully resolved finction headers im not yet sure so some things are potentially open, yet BUT IM RATHER COMPLETELY SURE that this form DrawLine x y p q color for basic function call IS TOO GOD TO NOT TAKE IT - co this is FIXED..its offical, as someone could say you cant just not take such good things (saying you as a mode of speach, i mean someone, its too good to not take it)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-12 20:46 +0200 |
| Message-ID | <11846m4$sm6$1@dont-email.me> |
| In reply to | #402007 |
fir pisze: > a (b c d) this btw ilustrates some problem a (b c d) probably must be allowed here but you CANT ASSUME that a (b c d) is function cal generally YOU MAY ASSUME in there newline after that but if there is oor example x after that a (b c d) x this part a (b c d) dont mean its function call - if a takes one argument its function call but if two a (b c d) x is function call so not always a ( b c d) is function call could probably enforce that a(b c d) may be function call but im not sure if its good idea i dont see a problem with this crazy helps to reader like he would have no brain, btter use meaningfull names to know what is what combination of 4 not meaningful names in programing is not usual i would say
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-12 20:49 +0200 |
| Message-ID | <11846sv$sm6$2@dont-email.me> |
| In reply to | #402008 |
fir pisze: > > combination of 4 not meaningful names in programing is not usual i would > say > i think i need to break this conversation as for at least till monday (coz i get a bit weary)..could eventuall add something but not necessary, but longer discusion of this type at least after some break
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-12 22:16 +0100 |
| Message-ID | <1184ffh$3t0g$1@dont-email.me> |
| In reply to | #402007 |
On 12/09/2026 19:35, fir wrote:
> bart pisze:>
> > a(b(c, d))
> >
> > Does that help?
>
> not much honestly - if youre so much in hole you can find
> definitions..as you say you are
>
> two terrible mistakes you do
>
> 1) you somewhat assume that definitions are not pesent - all definitions
> are present - if definitions are not present it would not compile
>
>
> 2) you talk about this human reader its not a problem
>
> you may add those parenthesis optionally... and if someone not added it
> blame him
>
> though as i said i would add the () different way
>
> not a(b(c, d))
>
> but
>
> a (b c d)
>
>
>
> you anyway should use meaningdull names in this examples becouse names
> carry an information
You want to design a language that /depends/ on the user devising
suitable names in order to deduce the /shape/ of the code? That is the
whole point of using a structured HLL in the first place!
Try this experiment: take a C source file and eliminate all ()s and
commas. Replace with a space if necessary to separate alphanumeric tokens.
Compare with the original and see which one is easier to work with.
(With C, missing () will give problems with macro definitions and casts,
among other things.)
Note that the code will still have braces. I suggest a better aim is to
eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.
In fact, if C is the start point, there is a huge amount that can be
done to end up with a cleaner language while not doing away with useful
redundancy.
This is a C program:
#include <stdio.h>
#include <math.h>
int main() {
for (int i = 1; i <= 10; ++i) {
printf("%d %f\n", i, sqrt(i));
puts("----------");
}
}
A little contrived, but no matter because the same contrivance is here
in my systems language:
proc main =
for i to 10 do
println i, sqrt i
println "----------"
end
end
The C has 53 tokens (58 if you include all that gubbins inside the first
string).
My version has only 17 tokens, nearly 70% fewer. And yet it still uses
the parentheses and commas that you're trying to eliminate (not many in
this example, but that is part of my point).
Of C's 53/58 tokens, 16 are parentheses, colons and semicolons. Removing
those would still leave 37/42 tokens. If you also disregard those
'#includes', a one-time cost, it would still be 23/27! (And would result
in ambiguous code unless you add lots of new rules.)
So I think you're going about this the wrong way: getting rid of
/useful/ punctuation symbols while still keeping the useless ones,
resulting in a more restricted language with new rules.
> DrawLine x y p q color
>
> for basic function call IS TOO GOD TO NOT TAKE IT -
This will break as soon as you try something more complicated.
If you want that, then try a PostScript-style stack language:
x y p q colour DrawLine
Here, parentheses and commas are not needed.
The problem is you don't want to write 10s of 1000s of lines in this
style; you want a conventional syntax which is easier to follow.
BTW here is a draw-line routine in my scripting language:
proc gxline(w, x, y, ?x2, ?y2) ...
It takes either one point or two. It is these optional args that would
make it hard to figure out a call like this:
gxline w a b c d
Is this gxline(w, a, b, c, d), or is it gxline(w, a, b(c, d))? In this
dynamic language, b might be a variable containing a function reference.
[toc] | [prev] | [next] | [standalone]
| From | Lane W <cactus_DAC@yahoo.com> |
|---|---|
| Date | 2026-09-12 15:40 -0600 |
| Message-ID | <1184gt8$4bne$1@dont-email.me> |
| In reply to | #402010 |
bart wrote: > BTW here is a draw-line routine in my scripting language: > > proc gxline(w, x, y, ?x2, ?y2) ... > > It takes either one point or two. It is these optional args that would > make it hard to figure out a call like this: > > gxline w a b c d > > Is this gxline(w, a, b, c, d), or is it gxline(w, a, b(c, d))? In this > dynamic language, b might be a variable containing a function reference. > > Why don't you ask Keith? He will tell you a cat was medium size, and so it is gxline(w,a,b(c,d)). Finally, the man has a use. Can you build a compiler with Keith at its center to make these disambiguations? Rumor has it there is an AI which is one person answering questions, but has quite a backlog. Speed may be an issue.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 10:15 +0200 |
| Message-ID | <1185m4a$eoe1$1@dont-email.me> |
| In reply to | #402010 |
bart pisze: > A little contrived, but no matter because the same contrivance is here > in my systems language: > > proc main = > for i to 10 do > println i, sqrt i > println "----------" > end > end () and ; removed which is good but you alsoe need to remove keywords and this one ' and it will be ok
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 10:27 +0200 |
| Message-ID | <1185mpg$f0k5$1@dont-email.me> |
| In reply to | #402014 |
fir pisze:
> bart pisze:
>> A little contrived, but no matter because the same contrivance is here
>> in my systems language:
>>
>> proc main =
>> for i to 10 do
>> println i, sqrt i
>> println "----------"
>> end
>> end
>
> () and ; removed which is good but you alsoe need to remove keywords
> and this one ' and it will be ok
>
something like - you need a billet to mark definitions ..next one may be
used by another definition but may also put empty one
○ main
𝒙10
println 𝒙 sqrt 𝒙
println "----------"
○
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 10:39 +0200 |
| Message-ID | <1185ng0$f79a$1@dont-email.me> |
| In reply to | #402015 |
fir pisze: > fir pisze: >> bart pisze: >>> A little contrived, but no matter because the same contrivance is >>> here in my systems language: >>> >>> proc main = >>> for i to 10 do >>> println i, sqrt i >>> println "----------" >>> end >>> end >> >> () and ; removed which is good but you alsoe need to remove keywords >> and this one ' and it will be ok >> > > > something like - you need a billet to mark definitions ..next one may be > used by another definition but may also put empty one > > > ○ main > 𝒙10 > println 𝒙 sqrt 𝒙 > println "----------" > > ○ > > btw i asked ai about years of languages dont need ";" at the endo of line (as i said ai is not totally reliable but out of curiosity) a od jak dawna w jezykach programowanie jest to ze mozna ominac koncowy ; ktory np w c jest wymagany To zależy od języka, bo pomijanie końcowego ; pojawiało się już bardzo wcześnie. Najciekawsza chronologia: Język Rok Jak to działa Python 1991 ; w ogóle nie jest potrzebny do końca instrukcji — koniec linii ją kończy Visual Basic 1991 brak ; na końcu instrukcji Ruby 1995 koniec linii zwykle kończy instrukcję JavaScript 1995 automatyczne wstawianie średnika (ASI) Go 2009 kompilator automatycznie wstawia ; w określonych miejscach Swift 2014 ; opcjonalny Kotlin 2016 ; opcjonalny Rust 2010/2015 ; ma znaczenie składniowe i często jest wymagany, więc to inny przypadek
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-13 10:30 +0100 |
| Message-ID | <1185qgj$g83b$1@dont-email.me> |
| In reply to | #402014 |
On 13/09/2026 09:15, fir wrote:
> bart pisze:
>> A little contrived, but no matter because the same contrivance is here
>> in my systems language:
>>
>> proc main =
>> for i to 10 do
>> println i, sqrt i
>> println "----------"
>> end
>> end
>
> () and ; removed which is good but you alsoe need to remove keywords
> and this one ' and it will be ok
The same code runs as-is in my scripting language, but that also allows
this version:
for i to 10 do
? i, √i
? "-"*10
od
Any better? (The "-"*10 works above too but it was two extra tokens! The
'√' is an alias for 'sqrt' and was added for fun.)
There used to be a compact form of loop too which may have looked like this:
(i:10 || ?i, √i; "-"*10)
That's great. But now imagine 1000 lines full of such gobbledygook.
It sounds like your ideal language would be APL, if is not 'clean' and
'clear' that you're after, but 'minimal' and 'cryptic'.
The first version above is the best balance in my view. You /want/ some
mixture of keywords and symbols.
In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 11:47 +0200 |
| Message-ID | <1185rgd$gibv$1@dont-email.me> |
| In reply to | #402019 |
bart pisze: > On 13/09/2026 09:15, fir wrote: >> bart pisze: >>> A little contrived, but no matter because the same contrivance is >>> here in my systems language: >>> >>> proc main = >>> for i to 10 do >>> println i, sqrt i >>> println "----------" >>> end >>> end >> >> () and ; removed which is good but you alsoe need to remove keywords >> and this one ' and it will be ok > The same code runs as-is in my scripting language, but that also allows > this version: > > for i to 10 do > ? i, √i > ? "-"*10 > od > > Any better? (The "-"*10 works above too but it was two extra tokens! The > '√' is an alias for 'sqrt' and was added for fun.) > > There used to be a compact form of loop too which may have looked like > this: > > (i:10 || ?i, √i; "-"*10) > > That's great. But now imagine 1000 lines full of such gobbledygook. > > It sounds like your ideal language would be APL, if is not 'clean' and > 'clear' that you're after, but 'minimal' and 'cryptic'. > > The first version above is the best balance in my view. You /want/ some > mixture of keywords and symbols. > > In any case, in a typical program, only 1/3 of alphanumerics of > keywords; the rest will still be user-identifiers. i gave you example - its only cryptic if you dont know what it means
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 11:53 +0200 |
| Message-ID | <1185rs0$glro$1@dont-email.me> |
| In reply to | #402020 |
fir pisze: > bart pisze: >> On 13/09/2026 09:15, fir wrote: >>> bart pisze: >>>> A little contrived, but no matter because the same contrivance is >>>> here in my systems language: >>>> >>>> proc main = >>>> for i to 10 do >>>> println i, sqrt i >>>> println "----------" >>>> end >>>> end >>> >>> () and ; removed which is good but you alsoe need to remove keywords >>> and this one ' and it will be ok >> The same code runs as-is in my scripting language, but that also >> allows this version: >> >> for i to 10 do >> ? i, √i >> ? "-"*10 >> od >> >> Any better? (The "-"*10 works above too but it was two extra tokens! >> The '√' is an alias for 'sqrt' and was added for fun.) >> >> There used to be a compact form of loop too which may have looked like >> this: >> >> (i:10 || ?i, √i; "-"*10) >> >> That's great. But now imagine 1000 lines full of such gobbledygook. >> >> It sounds like your ideal language would be APL, if is not 'clean' and >> 'clear' that you're after, but 'minimal' and 'cryptic'. >> >> The first version above is the best balance in my view. You /want/ >> some mixture of keywords and symbols. >> >> In any case, in a typical program, only 1/3 of alphanumerics of >> keywords; the rest will still be user-identifiers. > > > i gave you example - its only cryptic if you dont know what it means > > consider for example french or polish language its totally cryptic until you will learn it... not to say you want to understand it without definitions overally this discussin ended i think at least as for few months, cant continue becouse you repeat the same things which i got the same answer (ori talk tehe sama and you rpeat with the same answer) repeating is not necassary ;c
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-13 11:26 +0100 |
| Message-ID | <1185tpi$haq6$1@dont-email.me> |
| In reply to | #402021 |
On 13/09/2026 10:53, fir wrote: > fir pisze: >> bart pisze: >>> It sounds like your ideal language would be APL, if is not 'clean' >>> and 'clear' that you're after, but 'minimal' and 'cryptic'. >>> >>> The first version above is the best balance in my view. You /want/ >>> some mixture of keywords and symbols. >>> >>> In any case, in a typical program, only 1/3 of alphanumerics of >>> keywords; the rest will still be user-identifiers. >> >> >> i gave you example - its only cryptic if you dont know what it means >> >> > consider for example french or polish language its totally cryptic until > you will learn it... That is not your aim. That appears to be to start with a language that you know perfectly well, but remove all punctuation, capitalisation and structure, and half the words. But to what purpose; because you're too lazy to type? not to say you want to understand it without > definitions So an APL (or J or K) program is never cryptic because all you have to do is learn it? If only I'd thought of that! The same applies to Assembly I guess. And machine code? > > overally this discussin ended i think at least as for few months, > cant continue becouse you repeat the same things And you keep repeating the same nonsense. What is your endpoint: a program that can be expressed in one byte?
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 12:37 +0200 |
| Message-ID | <1185uef$hhon$1@dont-email.me> |
| In reply to | #402022 |
bart pisze: > On 13/09/2026 10:53, fir wrote: >> fir pisze: >>> bart pisze: > >>>> It sounds like your ideal language would be APL, if is not 'clean' >>>> and 'clear' that you're after, but 'minimal' and 'cryptic'. >>>> >>>> The first version above is the best balance in my view. You /want/ >>>> some mixture of keywords and symbols. >>>> >>>> In any case, in a typical program, only 1/3 of alphanumerics of >>>> keywords; the rest will still be user-identifiers. >>> >>> >>> i gave you example - its only cryptic if you dont know what it means >>> >>> >> consider for example french or polish language its totally cryptic >> until you will learn it... > > > That is not your aim. That appears to be to start with a language that > you know perfectly well, but remove all punctuation, capitalisation and > structure, and half the words. But to what purpose; because you're too > lazy to type? > > not to say you want to understand it without >> definitions > > So an APL (or J or K) program is never cryptic because all you have to > do is learn it? If only I'd thought of that! > > The same applies to Assembly I guess. And machine code? > apl i dont know but ofc it applies to assembly but x86 assembly is terribly flawed x86 assembly is like c++ >> >> overally this discussin ended i think at least as for few months, >> cant continue becouse you repeat the same things > > And you keep repeating the same nonsense. What is your endpoint: a > program that can be expressed in one byte? > my goal is to make it cleanest possible and also make thsi sintax more powerfull - it is "carrying" a lot more "weight" (semantic weight).. i men where short sentences may expres much meaning
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 12:47 +0200 |
| Message-ID | <1185v01$hne0$1@dont-email.me> |
| In reply to | #402024 |
fir pisze:
> bart pisze:
>> On 13/09/2026 10:53, fir wrote:
>>> fir pisze:
>>>> bart pisze:
>>
>>>>> It sounds like your ideal language would be APL, if is not 'clean'
>>>>> and 'clear' that you're after, but 'minimal' and 'cryptic'.
>>>>>
>>>>> The first version above is the best balance in my view. You /want/
>>>>> some mixture of keywords and symbols.
>>>>>
>>>>> In any case, in a typical program, only 1/3 of alphanumerics of
>>>>> keywords; the rest will still be user-identifiers.
>>>>
>>>>
>>>> i gave you example - its only cryptic if you dont know what it means
>>>>
>>>>
>>> consider for example french or polish language its totally cryptic
>>> until you will learn it...
>>
>>
>> That is not your aim. That appears to be to start with a language that
>> you know perfectly well, but remove all punctuation, capitalisation
>> and structure, and half the words. But to what purpose; because you're
>> too lazy to type?
>>
>> not to say you want to understand it without
>>> definitions
>>
>> So an APL (or J or K) program is never cryptic because all you have to
>> do is learn it? If only I'd thought of that!
>>
>> The same applies to Assembly I guess. And machine code?
>>
>
> apl i dont know but ofc it applies to assembly but x86 assembly is
> terribly flawed
> x86 assembly is like c++
>
>>>
>>> overally this discussin ended i think at least as for few months,
>>> cant continue becouse you repeat the same things
>>
>> And you keep repeating the same nonsense. What is your endpoint: a
>> program that can be expressed in one byte?
>>
>
> my goal is to make it cleanest possible
> and also make thsi sintax more powerfull - it is "carrying" a lot more
> "weight" (semantic weight).. i men where short sentences may expres much
> meaning
this example is quite clean and weighty
○ main
𝒙10
println 𝒙 sqrt 𝒙
println "----------"
○
esp this 𝒙10 is clean and weighty i got a lot of problems with this
becouse x10 eventually worked but has terrible disadwantage xa is not
standable (a is variable value say 100) but unicode resolves a lot of
problems coz 𝒙a work
NOTE this all now seem obvious but before discovering this what seems
obvious LATER BEFORE this all conclusions was VERY FAR form obvious
im saying this becouse i thing that people will take some outcome and
not adress its orygination..all this conclusion i take are oryginal at
least in a sense it is not copied from someo other source (except the
most common typical knowledge base)
(not saying that some solutions i use by chance were already invented
but often in some different contextes and not fully)
even seint the fact some just should take unicode was not obvious not to
mention many other things
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 12:55 +0200 |
| Message-ID | <1185vfg$hrb9$1@dont-email.me> |
| In reply to | #402025 |
fir pisze: > fir pisze: >> bart pisze: >>> On 13/09/2026 10:53, fir wrote: >>>> fir pisze: >>>>> bart pisze: >>> >>>>>> It sounds like your ideal language would be APL, if is not 'clean' >>>>>> and 'clear' that you're after, but 'minimal' and 'cryptic'. >>>>>> >>>>>> The first version above is the best balance in my view. You /want/ >>>>>> some mixture of keywords and symbols. >>>>>> >>>>>> In any case, in a typical program, only 1/3 of alphanumerics of >>>>>> keywords; the rest will still be user-identifiers. >>>>> >>>>> >>>>> i gave you example - its only cryptic if you dont know what it means >>>>> >>>>> >>>> consider for example french or polish language its totally cryptic >>>> until you will learn it... >>> >>> >>> That is not your aim. That appears to be to start with a language >>> that you know perfectly well, but remove all punctuation, >>> capitalisation and structure, and half the words. But to what >>> purpose; because you're too lazy to type? >>> >>> not to say you want to understand it without >>>> definitions >>> >>> So an APL (or J or K) program is never cryptic because all you have >>> to do is learn it? If only I'd thought of that! >>> >>> The same applies to Assembly I guess. And machine code? >>> >> >> apl i dont know but ofc it applies to assembly but x86 assembly is >> terribly flawed >> x86 assembly is like c++ >> >>>> >>>> overally this discussin ended i think at least as for few months, >>>> cant continue becouse you repeat the same things >>> >>> And you keep repeating the same nonsense. What is your endpoint: a >>> program that can be expressed in one byte? >>> >> >> my goal is to make it cleanest possible >> and also make thsi sintax more powerfull - it is "carrying" a lot more >> "weight" (semantic weight).. i men where short sentences may expres >> much meaning > > this example is quite clean and weighty > > ○ main > 𝒙10 > println 𝒙 sqrt 𝒙 > println "----------" > > ○ > its not fully resolved yet as questions may ofc arise and need answer for example if i use 𝒙 as an index then 𝒙 as ana infinite loop is taken? maybe yes maybe not (need answer) also it rises question is tab𝒙=10 okay as an array acces tab[x]=10 also if to allow spaces and so on 𝒙 tab_size tab 𝒙 = 10 but i know such things may be resolved more or less so it not deny such clean base > esp this 𝒙10 is clean and weighty i got a lot of problems with this > becouse x10 eventually worked but has terrible disadwantage xa is not > standable (a is variable value say 100) but unicode resolves a lot of > problems coz 𝒙a work > > NOTE this all now seem obvious but before discovering this what seems > obvious LATER BEFORE this all conclusions was VERY FAR form obvious > > im saying this becouse i thing that people will take some outcome and > not adress its orygination..all this conclusion i take are oryginal at > least in a sense it is not copied from someo other source (except the > most common typical knowledge base) > > (not saying that some solutions i use by chance were already invented > but often in some different contextes and not fully) > > even seint the fact some just should take unicode was not obvious not to > mention many other things > > > >
[toc] | [prev] | [next] | [standalone]
Page 9 of 25 — ← Prev page 1 … 7 8 [9] 10 11 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web