Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #51954 > unrolled thread
| Started by | "F. W." <me@home.invalid> |
|---|---|
| First post | 2025-09-04 10:26 +0200 |
| Last post | 2025-09-12 11:47 +0200 |
| Articles | 20 on this page of 187 — 17 participants |
Back to article view | Back to de.alt.folklore.computer
Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-04 10:26 +0200
Re: Pascal auf Nr. 10 ;-) Andreas Bockelmann <xotzil@gmx.de> - 2025-09-04 11:41 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-04 15:14 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-04 17:07 +0200
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-04 16:12 +0000
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-04 19:19 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:22 +0200
Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-05 06:41 +0000
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:55 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 11:41 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 11:48 +0200
Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-05 10:27 +0000
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 09:54 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-08 10:33 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 11:14 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-08 19:48 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:38 +0200
Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-09 08:52 +0000
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 12:01 +0200
Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-09 12:27 +0000
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 15:04 +0200
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-05 14:31 +0000
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 17:24 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 17:25 +0200
Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-11 17:15 +0000
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-12 03:19 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 09:56 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-08 10:45 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-04 19:45 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:27 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-05 10:09 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 11:50 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 07:08 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-08 10:50 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 11:16 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-08 17:32 +0200
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-08 18:27 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:23 +0200
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-09 18:48 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-11 13:34 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-11 19:09 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 08:59 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-12 09:41 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 16:20 +0200
Re: Pascal auf Nr. 10 ;-) Andreas Karrer <ak-5a@gmx.ch> - 2025-09-08 09:55 +0000
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 16:57 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-08 17:34 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:24 +0200
Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-09 09:07 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 10:16 +0200
Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-09 13:29 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 15:13 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-08 19:06 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-09 04:43 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:29 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:28 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-09 19:26 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-10 14:21 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-10 18:11 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-11 07:20 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-11 08:15 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-11 18:56 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 07:27 +0200
Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-12 07:21 +0000
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 11:38 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 15:51 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 15:47 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-15 07:16 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-15 09:02 +0200
Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-15 07:49 +0000
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-15 12:25 +0200
Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-15 12:28 +0000
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-15 19:17 +0200
Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-11 09:46 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-11 10:38 +0200
Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-05 11:45 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-05 17:14 +0200
Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 10:58 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-06 12:23 +0200
Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 12:35 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-06 14:40 +0200
Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 15:01 +0200
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-06 11:41 +0000
Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-06 14:20 +0200
Re: Pascal auf Nr. 10 ;-) Alexander Schreiber <als@usenet.thangorodrim.de> - 2025-09-06 21:56 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-06 15:58 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-07 19:09 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-06 14:12 +0200
Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 14:16 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 09:04 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-12 10:26 +0200
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-06 11:26 +0000
Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 13:39 +0200
Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-06 14:19 +0200
Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 14:34 +0200
Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 11:40 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-06 13:59 +0200
Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 14:02 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-06 15:17 +0200
Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 15:36 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:18 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 08:41 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:56 +0200
Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-12 05:51 +0000
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 15:59 +0200
Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-12 15:12 +0000
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:19 +0200
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-04 18:55 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:33 +0200
Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-05 09:12 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 11:52 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 13:48 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 07:17 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-08 19:33 +0200
Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-05 14:52 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 07:22 +0200
Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-08 08:55 +0200
Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-12 06:06 +0000
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 08:56 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 16:17 +0200
Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-12 15:13 +0000
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-12 18:13 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 20:27 +0200
Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-12 21:58 +0000
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-13 00:13 +0200
Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-13 09:07 +0000
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-13 13:47 +0200
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-14 12:14 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-15 20:22 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-16 06:51 +0200
Re: Pascal auf Nr. 10 ;-) Andreas Eder <a_eder_muc@web.de> - 2025-10-03 11:08 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-10-03 13:17 +0200
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-10-03 13:48 +0000
Re: Pascal auf Nr. 10 ;-) Andreas Eder <a_eder_muc@web.de> - 2025-10-04 12:57 +0200
Re: Pascal auf Nr. 10 ;-) Andreas Eder <a_eder_muc@web.de> - 2025-10-04 12:44 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-10-04 17:34 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-10-03 16:30 +0200
Re: Pascal auf Nr. 10 ;-) Christian Weisgerber <naddy@mips.inka.de> - 2025-10-05 21:35 +0000
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-10-06 08:29 +0200
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-10-06 19:07 +0200
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-10-06 19:18 +0000
Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-10-07 08:15 +0000
Re: Pascal auf Nr. 10 ;-) Christian Corti <use@reply.to> - 2025-10-07 14:46 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-10-07 17:32 +0200
Re: Editor (was: Pascal auf Nr. 10 ;-) ) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-10-07 14:53 +0200
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-10-07 18:38 +0200
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-10-08 14:17 +0000
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-10-08 19:18 +0200
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-10-08 17:57 +0000
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-10-09 17:55 +0200
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-10-09 19:47 +0000
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-16 18:34 +0200
Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-16 16:58 +0000
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-16 21:12 +0200
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-17 17:52 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-13 10:07 +0200
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-13 10:34 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-13 13:34 +0200
Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-05 18:46 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-04 19:33 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:53 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-05 10:45 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 12:01 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-05 17:33 +0200
Re: Pascal auf Nr. 10 ;-) "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-09-09 13:45 +0200
Re: Pascal auf Nr. 10 ;-) Andreas Dau <dev.null@andreasdau.com> - 2025-09-09 16:33 +0200
Re: Pascal auf Nr. 10 ;-) Andreas Dau <dev.null@andreasdau.com> - 2025-09-09 16:36 +0200
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-09 19:22 +0000
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-10 05:57 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-15 13:05 +0200
Re: Pascal auf Nr. 10 ;-) Andreas Karrer <ak-5a@gmx.ch> - 2025-09-07 01:18 +0000
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-07 16:25 +0000
Re: Pascal auf Nr. 10 ;-) Andreas Karrer <ak-5a@gmx.ch> - 2025-09-28 00:06 +0000
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-07 19:19 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 07:37 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-08 19:42 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:34 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-09 19:46 +0200
Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-09 19:29 +0000
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-10 06:27 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-10 18:16 +0200
Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-19 21:09 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-22 07:19 +0200
Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-11 17:26 +0000
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 07:29 +0200
Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-12 10:34 +0200
Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 11:47 +0200
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2025-10-06 19:18 +0000 |
| Message-ID | <10c14lu$kpso$1@solani.org> |
| In reply to | #52343 |
Am Mon, 06 Oct 2025 19:07:08 +0200 schrieb Stefan Reuther: > Am 05.10.2025 um 23:35 schrieb Christian Weisgerber: >> On 2025-10-03, Peter J. Holzer <hjp-usenet4@hjp.at> wrote: >>> PS: Ich habe mich vor 30+ Jahren ein bisschen mit Lisp gespielt, aber >>> es hat nicht geklickt und als Nicht-Emacs-User hatte ich keine >>> externe Motivation, mich weiter damit zu beschäftigen. >> >> Ich habe dreimal angefangen, mich in Lisp einzuarbeiten, einmal sogar >> einen Uni-Schein für Programmieren in Common Lisp gemacht, und jedes >> Mal ist das mangels Anwendung prompt wieder eingeschlafen und in >> Vergessenheit geraten. :-( > > Emacs benutzen ist eine gute Motivation. > > Mein Grund, bei Emacs gelandet zu sein: als on-topic'ne Systeme der > heiße Scheiß waren, war (a) XEmacs die einzige Möglichkeit, > Syntax-Highlighting auf der Linux-Konsole zu bekommen, Argument a. dürfte heute nicht mehr gelten. Gibt genug SyntaxColouring auch woanders. > und (b) NTEmacs die einzige Möglichkeit, unter Windows 95 einen > Kommandozeileninterpreter mit mehr als 80x25 Fenstergröße zu bekommen. Vermutlich - kann das gerade nicht beweisen ... ;) - wird es auf Windows mittlerweile auch schon mehr als 80x25 Zeichen in der Anzeige geben. > Und von da ist das dann eskaliert. Ich vermute (insgeheim), daß auch ein wenig so ein Art "Elitezugehörigkeit" ein große Motivation sein kann, einen Emacs (oder Vim) zu benutzen. Denn: die ganz Großen in dem Bereich hatten ja schließlich alle sowas. Und wenn man es dann mal gelernt hat, wird es auch noch so ein paar schöne Extras haben, die man woanders nur mit hakeliger Bedienung hinbekommt. Dagegen ist eine einmal gelernte kryptische Tastenkombination dann immer die gleiche und das auf allen Systemen, für die es so ein Programm gibt.
[toc] | [prev] | [next] | [standalone]
| From | Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) |
|---|---|
| Date | 2025-10-07 08:15 +0000 |
| Message-ID | <5t68e4cb1ci31733n3e8%sfroehli@Froehlich.Priv.at> |
| In reply to | #52344 |
On Mon, 06 Oct 2025 21:18:22 Sebastian Barthel wrote: > Ich vermute (insgeheim), daß auch ein wenig so ein Art > "Elitezugehörigkeit" ein große Motivation sein kann, einen Emacs > (oder Vim) zu benutzen. Was hätte ich davon? Es ist meine Lebenszeit und es sind meine Nerven, die ich schone (oder halt nicht). Und hier hat diese Frage der vim gegen den Emacs vor langer Zeit für sich entschieden (alles andere ist sowieso nur unter ferner liefen). Hat mit der Art zu tun, wie mein Gehirn arbeitet, bei anderen sieht das anders aus. > Dagegen ist eine einmal gelernte kryptische Tastenkombination dann > immer die gleiche und das auf allen Systemen, für die es so ein > Programm gibt. Auf allen Systemen, aber auch für alle Einsatzbereiche. Das ist der erste Punkt: Ein brauchbarer Editor muss universell sein, vom Newsreader bis zur Softwareentwicklung; gut, das ist eher eine Einschränkung für die verwendete Software, als für den Editor. Der zweite ist (bei mir), dass die Tastenkombinationen nicht kryptisch sein dürfen, und hier gewinnt der vim mit logischer Herleitung sehr vieler Befehle. Servus, Stefan -- http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich Offizieller Erstbesucher(TM) von mmeike Stefan: ein starker Partner! (Sloganizer)
[toc] | [prev] | [next] | [standalone]
| From | Christian Corti <use@reply.to> |
|---|---|
| Date | 2025-10-07 14:46 +0200 |
| Message-ID | <vlefrl-8ul.ln1@news.informatik.uni-stuttgart.de> |
| In reply to | #52364 |
Stefan Froehlich <Stefan+Usenet@froehlich.priv.at> wrote: > Was hätte ich davon? Es ist meine Lebenszeit und es sind meine > Nerven, die ich schone (oder halt nicht). Und hier hat diese Frage > der vim gegen den Emacs vor langer Zeit für sich entschieden (alles > andere ist sowieso nur unter ferner liefen). Hat mit der Art zu tun, > wie mein Gehirn arbeitet, bei anderen sieht das anders aus. So ist es bei mir auch. Vi(m) als Haupteditor, und wenn es "bunt" bzw. mit einer guten GUI sein soll, NEdit. Der hat leider immer noch Probleme mit UTF, aber ich brauche das für meinen Code nicht. Er kann dafür alles andere, das ich brauche. > Einschränkung für die verwendete Software, als für den Editor. Der > zweite ist (bei mir), dass die Tastenkombinationen nicht kryptisch > sein dürfen, und hier gewinnt der vim mit logischer Herleitung sehr > vieler Befehle. EMACS war mir deswegen auch immer ein Graus. Ctrl in einer Kombination gedrückt halten oder nicht? Und ähnliche Späße ;-) Christian
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2025-10-07 17:32 +0200 |
| Message-ID | <mkkq57FibdqU1@mid.individual.net> |
| In reply to | #52368 |
Am 07.10.25 um 14:46 schrieb Christian Corti:
> Stefan Froehlich <Stefan+Usenet@froehlich.priv.at> wrote:
>> Was hätte ich davon? Es ist meine Lebenszeit und es sind meine
>> Nerven, die ich schone (oder halt nicht). Und hier hat diese Frage
>> der vim gegen den Emacs vor langer Zeit für sich entschieden (alles
>> andere ist sowieso nur unter ferner liefen). Hat mit der Art zu tun,
>> wie mein Gehirn arbeitet, bei anderen sieht das anders aus.
>
> So ist es bei mir auch. Vi(m) als Haupteditor, und wenn es "bunt" bzw.
> mit einer guten GUI sein soll, NEdit. Der hat leider immer noch
> Probleme mit UTF, aber ich brauche das für meinen Code nicht. Er kann
> dafür alles andere, das ich brauche.
>
>> Einschränkung für die verwendete Software, als für den Editor. Der
>> zweite ist (bei mir), dass die Tastenkombinationen nicht kryptisch
>> sein dürfen, und hier gewinnt der vim mit logischer Herleitung sehr
>> vieler Befehle.
>
> EMACS war mir deswegen auch immer ein Graus. Ctrl in einer Kombination
> gedrückt halten oder nicht? Und ähnliche Späße ;-)
Bei emacs verwende ich praktisch keine Crtl-Taste.
Als mir das 3 byte rechts links schieben mit emacs
zu kompliziert war, habe ich ein kleines Python
geschrieben, wo ich mit einfügen von
#$ und weiteres ab Spalte 0 deartige Schieberei mache.
Seit einiger Zeit ärgert mich emacs mit automatischen
einfügen von Leerzeichen am Zeilenanfang einiger .html Dateien.
Und mit automatischer Zeilentrennung.
Mein .emacs Anhang:
;;; Kofler
(setq inhibit-startup-message t)
(line-number-mode 1)
(column-number-mode 1)
(setq-default transient-mark-mode t)
(setq-default indent-tabs-mode nil)
(global-font-lock-mode t)
(setq python-indent-offset 3)
(setq sgml-basic-offset 0)
(setq c-basic-offset 3)
(setq lisp-indent-offset 3)
(setq js-indent-level 3)
(setq indent-tab-mode nil)
(add-hook 'html-mode-hook 'turn-off-auto-fill)
(set-face-attribute 'region nil :background "#D0D0D0")
(turn-off-auto-fill)
(custom-set-faces
'(default ((t (:foreground "black" :background "#F0F0F0" :bold nil
:family "DejaVu Sans Mono" :foundry "unknown" :slant normal :weight
bold :height 98 :width normal))) t))
--
<http://www.hermann-riemann.de> bzw.:
<https://www.hermann-riemann.eu/de>
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2025-10-07 14:53 +0200 |
| Subject | Re: Editor (was: Pascal auf Nr. 10 ;-) ) |
| Message-ID | <mkkgq3FgppfU1@mid.individual.net> |
| In reply to | #52344 |
Am 06.10.25 um 21:18 schrieb Sebastian Barthel: > Ich vermute (insgeheim), daß auch ein wenig so ein Art > "Elitezugehörigkeit" ein große Motivation sein kann, einen Emacs (oder > Vim) zu benutzen. Denn: die ganz Großen in dem Bereich hatten ja > schließlich alle sowas. Ich sehe das pragmatisch, ich nehme den Editor der für mich momemtan am praktischsten erscheint. Derzeit wechsele ich je nach Anwendung zwischen kate, emacs und vi. Wobei vi vermutlich vim ist wegen Positioniertasten. Unterwindows ( im Betrieb ) war xemacs mein bevorzugter Editor. vi(m?) verwende ich, wenn ich in eine Datei nur anschauen will, ( :q! lässt alle versehentliche Änderungen verschwinden ) oder ein Kleinigkeit ändern will. -- <http://www.hermann-riemann.de> bzw.: <https://www.hermann-riemann.eu/de>
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-10-07 18:38 +0200 |
| Message-ID | <10c3mns.1cs.1@stefan.msgid.phost.de> |
| In reply to | #52344 |
Am 06.10.2025 um 21:18 schrieb Sebastian Barthel: > Am Mon, 06 Oct 2025 19:07:08 +0200 schrieb Stefan Reuther: >> Am 05.10.2025 um 23:35 schrieb Christian Weisgerber: >>> Ich habe dreimal angefangen, mich in Lisp einzuarbeiten, einmal sogar >>> einen Uni-Schein für Programmieren in Common Lisp gemacht, und jedes >>> Mal ist das mangels Anwendung prompt wieder eingeschlafen und in >>> Vergessenheit geraten. :-( >> >> Emacs benutzen ist eine gute Motivation. >> >> Mein Grund, bei Emacs gelandet zu sein: als on-topic'ne Systeme der >> heiße Scheiß waren, war (a) XEmacs die einzige Möglichkeit, >> Syntax-Highlighting auf der Linux-Konsole zu bekommen, > > Argument a. dürfte heute nicht mehr gelten. Gibt genug SyntaxColouring > auch woanders. *Jetzt* ja. 1997 hieß es XEmacs oder irgendwas unter X11 (XEmacs, GNU Emacs, NEdit). Oder irgendwas unter Windows (z.B. Borland-Produkte). >> und (b) NTEmacs die einzige Möglichkeit, unter Windows 95 einen >> Kommandozeileninterpreter mit mehr als 80x25 Fenstergröße zu bekommen. > > Vermutlich - kann das gerade nicht beweisen ... ;) - wird es auf Windows > mittlerweile auch schon mehr als 80x25 Zeichen in der Anzeige geben. Windows ist auch nicht mehr Windows 95. Unter Windows 95 war der Kommandozeileninterpreter (command.com) ein DOS-Programm, das in einen virtualisierten oder realen Framebuffer schreiben wollte. Wenn man das Fenster maximiert, wird der VGA-Textmodus mit dem realen Framebuffer aktiviert. Zum Glück waren sie so klever, tatsächlich eine Sonderbehandlung dafür vorzusehen, dass die Eingabe nicht von einer richtigen Konsole kommt, sondern eben z.B. vom Emacs. >> Und von da ist das dann eskaliert. > > Ich vermute (insgeheim), daß auch ein wenig so ein Art > "Elitezugehörigkeit" ein große Motivation sein kann, einen Emacs (oder > Vim) zu benutzen. Denn: die ganz Großen in dem Bereich hatten ja > schließlich alle sowas. > > Und wenn man es dann mal gelernt hat, wird es auch noch so ein paar > schöne Extras haben, die man woanders nur mit hakeliger Bedienung > hinbekommt. Das ist der Punkt. Ich habe inzwischen ~100k .emacs angehäuft. Und wenn ich das mit dem Kollegen vergleiche, ist das nicht mal besonders viel oder besonders komplex. Aber so elementare Dinge wie M-x sort-lines oder M-x shell-command-on-region gibt es insbesondere in den typischen GUI-Editoren nicht. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2025-10-08 14:17 +0000 |
| Message-ID | <10c5rqh$ncl3$3@solani.org> |
| In reply to | #52373 |
Am Tue, 07 Oct 2025 18:38:52 +0200 schrieb Stefan Reuther: > Am 06.10.2025 um 21:18 schrieb Sebastian Barthel: >> Am Mon, 06 Oct 2025 19:07:08 +0200 schrieb Stefan Reuther: >>> Am 05.10.2025 um 23:35 schrieb Christian Weisgerber: >>>> Ich habe dreimal angefangen, mich in Lisp einzuarbeiten, einmal sogar >>>> einen Uni-Schein für Programmieren in Common Lisp gemacht, und jedes >>>> Mal ist das mangels Anwendung prompt wieder eingeschlafen und in >>>> Vergessenheit geraten. :-( >>> >>> Emacs benutzen ist eine gute Motivation. >>> >>> Mein Grund, bei Emacs gelandet zu sein: als on-topic'ne Systeme der >>> heiße Scheiß waren, war (a) XEmacs die einzige Möglichkeit, >>> Syntax-Highlighting auf der Linux-Konsole zu bekommen, >> >> Argument a. dürfte heute nicht mehr gelten. Gibt genug SyntaxColouring >> auch woanders. > > *Jetzt* ja. 1997 hieß es XEmacs oder irgendwas unter X11 (XEmacs, GNU > Emacs, NEdit). Oder irgendwas unter Windows (z.B. Borland-Produkte). Was mir bei den ganzen WindowsEditoren immer gefehlt hat, ist ein "Blockmode", womit man einen beliebigen Bereich des Bildschirms als Rechteck markieren kann und dann kopieren, pasten, verschicken etc. >> Und wenn man es dann mal gelernt hat, wird es auch noch so ein paar >> schöne Extras haben, die man woanders nur mit hakeliger Bedienung >> hinbekommt. > > Das ist der Punkt. Ich habe inzwischen ~100k .emacs angehäuft. Und wenn > ich das mit dem Kollegen vergleiche, ist das nicht mal besonders viel > oder besonders komplex. Gibt es solche Sammlungen eigentlich auch irgendwo im Netz (Privatewebseite, github Sammlung, FTP) ? Wäre ja eigentlich wirklich sinnvoll, wenn es da einen Standard von "hochgeschätzten" Modulen gäbe. > Aber so elementare Dinge wie M-x sort-lines oder M-x > shell-command-on-region gibt es insbesondere in den typischen > GUI-Editoren nicht. Manche lassen sich erweitern, dann baut man sowas aber i.a. selbst.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-10-08 19:18 +0200 |
| Message-ID | <10c6ddi.4ec.1@stefan.msgid.phost.de> |
| In reply to | #52393 |
Am 08.10.2025 um 16:17 schrieb Sebastian Barthel:
> Am Tue, 07 Oct 2025 18:38:52 +0200 schrieb Stefan Reuther:
>> Am 06.10.2025 um 21:18 schrieb Sebastian Barthel:
>>> Und wenn man es dann mal gelernt hat, wird es auch noch so ein paar
>>> schöne Extras haben, die man woanders nur mit hakeliger Bedienung
>>> hinbekommt.
>>
>> Das ist der Punkt. Ich habe inzwischen ~100k .emacs angehäuft. Und wenn
>> ich das mit dem Kollegen vergleiche, ist das nicht mal besonders viel
>> oder besonders komplex.
>
> Gibt es solche Sammlungen eigentlich auch irgendwo im Netz
> (Privatewebseite, github Sammlung, FTP) ? Wäre ja eigentlich wirklich
> sinnvoll, wenn es da einen Standard von "hochgeschätzten" Modulen gäbe.
Manche laden ihren Kram auf github hoch. Hab ich mit meiner .emacs noch
nicht gemacht, nachher melden sich Leute noch mit Problemen :)
(Gerade vor ein paar Wochen ein vor 23 Jahren zuletzt angefasstes
Projekt hochgeladen, nachdem tatsächlich jemand das noch benutzt und was
geändert haben wollte.)
>> Aber so elementare Dinge wie M-x sort-lines oder M-x
>> shell-command-on-region gibt es insbesondere in den typischen
>> GUI-Editoren nicht.
>
> Manche lassen sich erweitern, dann baut man sowas aber i.a. selbst.
Erweiterbarkeit war für mich, unter DOS einen Editor namens "E!" zu
benutzen, für den konnte man Plugins schreiben.
Außerdem sowohl unter DOS, als auch unter Linux und X11 Makros über den
Tastaturtreiber (z.B. LWin = "\", RWin = "{", Menu = "}"). Wird in
Wayland langsam schwieriger...
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2025-10-08 17:57 +0000 |
| Message-ID | <10c68m2$noqj$1@solani.org> |
| In reply to | #52399 |
Am Wed, 08 Oct 2025 19:18:10 +0200 schrieb Stefan Reuther:
> Am 08.10.2025 um 16:17 schrieb Sebastian Barthel:
>> Am Tue, 07 Oct 2025 18:38:52 +0200 schrieb Stefan Reuther:
>>> Am 06.10.2025 um 21:18 schrieb Sebastian Barthel:
>>>> Und wenn man es dann mal gelernt hat, wird es auch noch so ein paar
>>>> schöne Extras haben, die man woanders nur mit hakeliger Bedienung
>>>> hinbekommt.
>>>
>>> Das ist der Punkt. Ich habe inzwischen ~100k .emacs angehäuft. Und
>>> wenn ich das mit dem Kollegen vergleiche, ist das nicht mal besonders
>>> viel oder besonders komplex.
>>
>> Gibt es solche Sammlungen eigentlich auch irgendwo im Netz
>> (Privatewebseite, github Sammlung, FTP) ? Wäre ja eigentlich wirklich
>> sinnvoll, wenn es da einen Standard von "hochgeschätzten" Modulen gäbe.
>
> Manche laden ihren Kram auf github hoch. Hab ich mit meiner .emacs noch
> nicht gemacht, nachher melden sich Leute noch mit Problemen :)
>
> (Gerade vor ein paar Wochen ein vor 23 Jahren zuletzt angefasstes
> Projekt hochgeladen, nachdem tatsächlich jemand das noch benutzt und was
> geändert haben wollte.)
Na ja - dann muß man einfach dazuschreiben, daß das nicht "gewartet" wird.
Aber es ist schon aus vielerlei Gründen nett, wenn die Leute da ihre
Sourcen öffentlich stellen.
>>> Aber so elementare Dinge wie M-x sort-lines oder M-x
>>> shell-command-on-region gibt es insbesondere in den typischen
>>> GUI-Editoren nicht.
>>
>> Manche lassen sich erweitern, dann baut man sowas aber i.a. selbst.
>
> Erweiterbarkeit war für mich, unter DOS einen Editor namens "E!" zu
> benutzen, für den konnte man Plugins schreiben.
Den werd ich mal suchen . ... Da ist ja schon der Name witzig.
> Außerdem sowohl unter DOS, als auch unter Linux und X11 Makros über den
> Tastaturtreiber (z.B. LWin = "\", RWin = "{", Menu = "}"). Wird in
> Wayland langsam schwieriger...
Ist auch irgendwie suboptimal.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-10-09 17:55 +0200 |
| Message-ID | <10c8sum.1kc.1@stefan.msgid.phost.de> |
| In reply to | #52400 |
Am 08.10.2025 um 19:57 schrieb Sebastian Barthel: > Am Wed, 08 Oct 2025 19:18:10 +0200 schrieb Stefan Reuther: >>>> Aber so elementare Dinge wie M-x sort-lines oder M-x >>>> shell-command-on-region gibt es insbesondere in den typischen >>>> GUI-Editoren nicht. >>> >>> Manche lassen sich erweitern, dann baut man sowas aber i.a. selbst. >> >> Erweiterbarkeit war für mich, unter DOS einen Editor namens "E!" zu >> benutzen, für den konnte man Plugins schreiben. > > Den werd ich mal suchen . ... Da ist ja schon der Name witzig. Ausgangspunkt für die Suche: <https://texteditors.org/cgi-bin/wiki.pl?EBang> Wenn es wirklich ernst ist, such ich in meinem digitalen Vorgarten nach dem Original-Archiv. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2025-10-09 19:47 +0000 |
| Message-ID | <10c93g2$pjjk$1@solani.org> |
| In reply to | #52424 |
Am Thu, 09 Oct 2025 17:55:33 +0200 schrieb Stefan Reuther: > Am 08.10.2025 um 19:57 schrieb Sebastian Barthel: >> Am Wed, 08 Oct 2025 19:18:10 +0200 schrieb Stefan Reuther: >>>>> Aber so elementare Dinge wie M-x sort-lines oder M-x >>>>> shell-command-on-region gibt es insbesondere in den typischen >>>>> GUI-Editoren nicht. >>>> >>>> Manche lassen sich erweitern, dann baut man sowas aber i.a. selbst. >>> >>> Erweiterbarkeit war für mich, unter DOS einen Editor namens "E!" zu >>> benutzen, für den konnte man Plugins schreiben. >> >> Den werd ich mal suchen . ... Da ist ja schon der Name witzig. > > Ausgangspunkt für die Suche: > <https://texteditors.org/cgi-bin/wiki.pl?EBang> > > Wenn es wirklich ernst ist, such ich in meinem digitalen Vorgarten nach > dem Original-Archiv. Danke - nicht nötig. Habs gefunden (auf einer simtel CD). Schaut brauchbar aus, auch wenn die Bedienung ein wenig unüblich ist. Daneben gab es auch noch ein QEdit , was ähnlich benutzbar war. Beide für ihre Zeit ganz ordentlich.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-09-16 18:34 +0200 |
| Message-ID | <10acajb.3mg.1@stefan.msgid.phost.de> |
| In reply to | #52137 |
Am 15.09.2025 um 20:22 schrieb Peter J. Holzer: > On 2025-09-14 12:14, Stefan Reuther <stefan.news@arcor.de> wrote: >> Am 13.09.2025 um 13:47 schrieb Peter J. Holzer: >>> while not eof(f) >>> [...] >>> Hier muss das eof() versuchen, zu lesen, um herauszufinden, ob das Ende >>> des Files erreicht ist. Das wird bei einem Terminal, einer Pipe, etc. >>> blockieren. prepare_something() wird also erst ausgeführt, nachdem >>> mindestens ein Zeichen (eher eine ganze Zeile) eingegeben wurde. >> >> Wobei man da aber auch sagen muss: zu der Zeit, als Pascal am >> populärsten war, waren auch Betriebssysteme populär, in denen das kein >> Problem war. Unter DOS bzw. CP/M gibt es entweder Dateien, wo man die >> EOF-Bedingung problemlos durch Vergleich von Dateiposition und -größe >> feststellen kann bzw. wo Vorauslesen harmlos ist, oder es gibt Devices >> (Konsole, COM, LPT), die niemals EOF melden. > > Irgendwie muss man das Ende der Eingabe auch auf der Konsole signalieren > können. Muss man das wirklich? Oder ist das in erster Linie die Erwartungshaltung von Leuten, die von Unix kommen, wo das eben möglich ist? > Unter CP/M und DOS gab es da die Konvention, Ctrl-Z zu tippen. > Ob das vom Device oder vom Runtime-System interpretiert wird, ist dabei > zweitrangig, in jedem Fall muss bei obigem Code bereits das eof() darauf > reagieren, obwohl es der User erst beim readln() tippt, was ohne > Fluxkompensator schwierig zu erreichen ist. Die CP/M-Syscalls zur Eingabe von der Konsole und deren MS-DOS-Äquivalente können kein EOF signalisieren (Funktion 1 = Console input = getc(), Funktion 10 = Buffered console input = gets()). Erst als MS-DOS die File-Handle-Funktionen von Unix geerbt hat (Funktion 0x3F = Read file or device) war "EOF auf stdin" ein reales Problem, und das hat halt niemand je ernsthaft behoben. Die Ctrl-Z-Konvention kommt ja wenigstens auch daher, dass CP/M Dateigrößen nicht byteexakt speichern konnte, man Textdateien also mit einem Dummy-Zeichen auffüllen musste, und da Ctrl-Z gewählt hat. Das Programm würde also auf Syscall-Ebene das Ctrl-Z direkt als ASCII 26 lesen und nicht als EOF-Bedingung. >> Eine verbreitete Sprache mit Pascal-Syntax und C++-Features wäre schon >> knorke, aber die Geschichte hat sich halt anders entschieden. > > Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die > Features. Welche denn? Features, die C++ auszeichnen, sind die Möglichkeit, automatisch Ressourcen zu managen (Destruktoren) und die automatisch instanziierten Templates; die machen jetzt keine Probleme. Features wie die Möglichkeit, auf freigegebene Pointer zuzugreifen, sind kein Alleinstellungsmerkmal von C++ (kann man aber mit Sprachmitteln recht gut in den Griff bekommen). Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-09-16 16:58 +0000 |
| Message-ID | <10ac507$2n52m$1@dont-email.me> |
| In reply to | #52139 |
Stefan Reuther <stefan.news@arcor.de> schrieb: > Am 15.09.2025 um 20:22 schrieb Peter J. Holzer: >> Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die >> Features. > > Welche denn? Zu viele davon. "It's not feature creep, it's a feature stampede." -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-09-16 21:12 +0200 |
| Message-ID | <slrn10cjdkm.2111c.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #52139 |
On 2025-09-16 18:34, Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 15.09.2025 um 20:22 schrieb Peter J. Holzer:
>> On 2025-09-14 12:14, Stefan Reuther <stefan.news@arcor.de> wrote:
>>> Am 13.09.2025 um 13:47 schrieb Peter J. Holzer:
>>>> while not eof(f)
>>>> [...]
>>>> Hier muss das eof() versuchen, zu lesen, um herauszufinden, ob das Ende
>>>> des Files erreicht ist. Das wird bei einem Terminal, einer Pipe, etc.
>>>> blockieren. prepare_something() wird also erst ausgeführt, nachdem
>>>> mindestens ein Zeichen (eher eine ganze Zeile) eingegeben wurde.
>>>
>>> Wobei man da aber auch sagen muss: zu der Zeit, als Pascal am
>>> populärsten war, waren auch Betriebssysteme populär, in denen das kein
>>> Problem war. Unter DOS bzw. CP/M gibt es entweder Dateien, wo man die
>>> EOF-Bedingung problemlos durch Vergleich von Dateiposition und -größe
>>> feststellen kann bzw. wo Vorauslesen harmlos ist, oder es gibt Devices
>>> (Konsole, COM, LPT), die niemals EOF melden.
>>
>> Irgendwie muss man das Ende der Eingabe auch auf der Konsole signalieren
>> können.
>
> Muss man das wirklich? Oder ist das in erster Linie die
> Erwartungshaltung von Leuten, die von Unix kommen, wo das eben möglich ist?
Naja, »input« unter Pascal kann eine Konsole sein, bzw. ist das sogar
per default (meine Pascal-Erfahrungen stammen hauptsächlich vom Apple
II. Unter DOS bin ich dann sehr schnell auf C gewechselt). Und man kann
eof(input) aufrufen, und viele Beispielprogramme aus den frühen
80er-Jahren (die vermutlich nicht sehr von Unix beeinflusst waren) haben
das auch gemacht.
>> Unter CP/M und DOS gab es da die Konvention, Ctrl-Z zu tippen.
>> Ob das vom Device oder vom Runtime-System interpretiert wird, ist dabei
>> zweitrangig, in jedem Fall muss bei obigem Code bereits das eof() darauf
>> reagieren, obwohl es der User erst beim readln() tippt, was ohne
>> Fluxkompensator schwierig zu erreichen ist.
>
> Die CP/M-Syscalls zur Eingabe von der Konsole und deren
> MS-DOS-Äquivalente können kein EOF signalisieren
Wie gesagt, es ist für ein Pascal-Program nicht relevant, ob das EOF vom
Betriebssystem oder der Runtime-Umgebung von Pascal kommt. Relevant ist
nur, dass eof() true zurückliefert.
>>> Eine verbreitete Sprache mit Pascal-Syntax und C++-Features wäre schon
>>> knorke, aber die Geschichte hat sich halt anders entschieden.
>>
>> Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die
>> Features.
>
> Welche denn?
Wie Thomas schon geschrieben hat: Nicht einzelne, sondern die
Gesamtheit. C++ ist halt eine Sprache, die 30 Jahre Design by Committee
hinter sich hat.
Aber wichtige noch ist IMHO, dass eine etwas andere Syntax eine Sprache
nicht magisch einfacher macht. Der absolute Noob mag BEGIN/END
lesbarbarer finden als geschwungene Klammern und selbst der etwas
Fortgeschrittene wird komplexe Variablendeklarationen in Pascal leichter
lesen können als in C(++), aber das sind Oberflächlichkeiten. Das
wirklich Problem ist, die Semantik zu verstehen.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-09-17 17:52 +0200 |
| Message-ID | <10aesh0.ek.1@stefan.msgid.phost.de> |
| In reply to | #52141 |
Am 16.09.2025 um 21:12 schrieb Peter J. Holzer:
> On 2025-09-16 18:34, Stefan Reuther <stefan.news@arcor.de> wrote:
>> Am 15.09.2025 um 20:22 schrieb Peter J. Holzer:
>>> On 2025-09-14 12:14, Stefan Reuther <stefan.news@arcor.de> wrote:
>>> Unter CP/M und DOS gab es da die Konvention, Ctrl-Z zu tippen.
>>> Ob das vom Device oder vom Runtime-System interpretiert wird, ist dabei
>>> zweitrangig, in jedem Fall muss bei obigem Code bereits das eof() darauf
>>> reagieren, obwohl es der User erst beim readln() tippt, was ohne
>>> Fluxkompensator schwierig zu erreichen ist.
>>
>> Die CP/M-Syscalls zur Eingabe von der Konsole und deren
>> MS-DOS-Äquivalente können kein EOF signalisieren
>
> Wie gesagt, es ist für ein Pascal-Program nicht relevant, ob das EOF vom
> Betriebssystem oder der Runtime-Umgebung von Pascal kommt. Relevant ist
> nur, dass eof() true zurückliefert.
Würde ich Pascal für CP/M implementieren, würde ich EOF(Input) halt
einfach hartkodiert FALSE liefern lassen.
>>>> Eine verbreitete Sprache mit Pascal-Syntax und C++-Features wäre schon
>>>> knorke, aber die Geschichte hat sich halt anders entschieden.
>>>
>>> Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die
>>> Features.
>>
>> Welche denn?
>
> Wie Thomas schon geschrieben hat: Nicht einzelne, sondern die
> Gesamtheit. C++ ist halt eine Sprache, die 30 Jahre Design by Committee
> hinter sich hat.
Das ist halt besser als eine wild evolvierte Sprache wie Pascal, wo
keine zwei Compiler den Dialekt des jeweils anderen verstehen.
Damit sind wir dann bei "es gibt zwei Sorten Programmiersprachen: die,
über die jeder schimpft, und die, die keiner benutzt".
> Aber wichtige noch ist IMHO, dass eine etwas andere Syntax eine Sprache
> nicht magisch einfacher macht. Der absolute Noob mag BEGIN/END
> lesbarbarer finden als geschwungene Klammern und selbst der etwas
> Fortgeschrittene wird komplexe Variablendeklarationen in Pascal leichter
> lesen können als in C(++), aber das sind Oberflächlichkeiten. Das
> wirklich Problem ist, die Semantik zu verstehen.
Sowas wie ein hypothetisches
LAMBDA (x:INTEGER, y:INTEGER) BIND z, @p BEGIN ... END
hätte zumindest mehr Schlüsselworte, die man in eine Suchfunktion
stecken kann als [z,&p](int x, int y) { ... }.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2025-09-13 10:07 +0200 |
| Message-ID | <mikn2lFna09U1@mid.individual.net> |
| In reply to | #52120 |
Am 12.09.25 um 20:27 schrieb Peter J. Holzer: > Das betrifft genau den Fall mit dem Prompt. Der Prompt wird auf stdout > ausgegeben. stdout ist auf einem Terminal (normalerweise) line-buffered, > somit würde der Prompt nicht geflusht. Dann wird eine Input-Funktion > aufgerufen, die von stdin lesen soll. stdin ist normalerweise auch > line-buffered, aber zu dem Zeitpunkt ist der Buffer leer (der User hat > noch nichts eingegeben, weil er den Prompt ja noch gar nicht gesehen > hat). Bevor nun tatsächlich vom "host environment" Daten angefordert > werden, werden alle Output-Streams geflusht, somit auch stdout. Der User > sieht den Prompt und kann etwas eingeben. > > Das ist zugegeben eine Holzhammer-Methode. Es würde reichen, nur stdout > zu flushen, aber offensichtlich wollten sie stdin und stdout da nicht > besonders behandeln und eine "Verknüpfung" von verschiedenen Streams > kennt die C-Library nicht. Einfach alles zu flushen löst das Problem auf > bequeme Art und Performance ist bei interaktiven Eingaben eher kein > Problem. Einlesen über stdin habe ich bisher vermieden. stdout geht bei mir über printf. Alles andere außer GUI ist mir zu kompliziert. Für Einzelbuchstabe Eingabe und Ausgabe nehme ich sdl. Oder Editor mit save. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-09-13 10:34 +0200 |
| Message-ID | <10a3hb7.340.1@stefan.msgid.phost.de> |
| In reply to | #52120 |
Am 12.09.2025 um 20:27 schrieb Peter J. Holzer: > On 2025-09-12 18:13, Stefan Reuther <stefan.news@arcor.de> wrote: >> man konfiguriert einen Modus (unbuffered, line buffered, fully >> buffered) und im line buffered Modus parsed die Standardbibliothek die >> Daten, um zu ermitteln, wo sie ein flush einfügen muss. Ganz schön >> viel, was da passiert, bevor wir beim write() ankommen. > > Damit ist schon eine PDP-11 zurechtgekommen. Konzeptionell läuft > jeglicher Output auf Aufrufe von fputc() hinaus. Ja, praktisch will man aber aus einem 'fwrite(buf, 1, 100000, fp)' möglichst schnell ein 'write(fp->fh, buf, 100000)' machen und nicht 100000x fputc. > | Furthermore, characters are intended to be transmitted as a block to > | the host environment when a buffer is filled, when input is requested > | on an unbuffered stream, or when input is requested on a line buffered > | stream that requires the transmission of characters from the host > | environment. > Zitiert aus ISO/IEC 9899:201x, aber unverändert seit C89. > > Das betrifft genau den Fall mit dem Prompt. Der Prompt wird auf > stdout ausgegeben. [...] Bevor nun tatsächlich vom "host > environment" Daten angefordert werden, werden alle Output-Streams > geflusht, somit auch stdout. Der User sieht den Prompt und kann etwas > eingeben. Das lese ich da nicht raus. Ich lese da: wenn zwischen Schreiben und Lesen *innerhalb eines Streams* gewechselt wird, wird *dieser Stream* beim Wechsel geflushed. Dass der Prompt erst nach der Eingabe erscheint ist zumindest kein neues Problem (z.B. https://stackoverflow.com/questions/56089143/). >> und außerdem std::endl erfunden, so dass man die C++-Programme >> unerfahrener Programmierer an der schlechten Performance in Pipes >> erkennen kann. >> >> Ich hab hier eine ISO-10206-1990.pdf "Extended Pascal". > > Ich auch (hat Deine Version auch kein Inhaltsverzeichnis?). Ja. >> Das einzige Vorkommen von 'interactive' in dem Dokument ist: "In order >> to facilitate interactive terminal input and output, the procedure get >> (and other input procedures) should be performed at the latest >> opportunity, and the procedure put (and other output procedures) should >> be performed at the first opportunity. This technique has been called >> 'lazy I/O'.". [...] > Ich würde das so interpretieren: > > "Performed" verstehe ich als "hat einen Effekt außerhalb des Programms". > Denn dass eine Prozedur dann ausgeführt wird, wenn sie aufgerufen wird, > ist IMHO bei einer imperativen Programmiersprache wie Pascal > selbstverständlich. > [...] > Der Extremfall des umgekehrten Verhaltens wäre, dass das Programm gleich > beim Start input bis zum EOF in einen internen Buffer liest, und output > erst bei Programmende flusht. Das wäre vielleicht für Batch-Betrieb > effizient, aber für interaktiven Betrieb vollkommen ungeeignet. > Ich glaube aber, dass so eine Implementation standard-konform wäre > (erstens weil in der Note nur "should" steht und nicht "shall" und > zweitens, weil Notes in Standards meistens ohnehin nicht normativ sind ok. > (allerdings steht das dann meistens auch im Standard, was hier nicht der > Fall ist)). Die meisten Standards beginnen aber auch nicht mit "The standard is written in English. If you have trouble understanding a particular section, read it again and again and again... Sit up straight. Eat your vegetables. Do not mumble." Wobei ich bei Pascal eigentlich "Eat your quiche" erwartet hätte. Stefan
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-09-13 13:34 +0200 |
| Message-ID | <slrn10call9.32pdi.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #52125 |
On 2025-09-13 10:34, Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 12.09.2025 um 20:27 schrieb Peter J. Holzer:
>> On 2025-09-12 18:13, Stefan Reuther <stefan.news@arcor.de> wrote:
>>> man konfiguriert einen Modus (unbuffered, line buffered, fully
>>> buffered) und im line buffered Modus parsed die Standardbibliothek die
>>> Daten, um zu ermitteln, wo sie ein flush einfügen muss. Ganz schön
>>> viel, was da passiert, bevor wir beim write() ankommen.
>>
>> Damit ist schon eine PDP-11 zurechtgekommen. Konzeptionell läuft
>> jeglicher Output auf Aufrufe von fputc() hinaus.
>
> Ja, praktisch will man aber aus einem 'fwrite(buf, 1, 100000, fp)'
> möglichst schnell ein 'write(fp->fh, buf, 100000)' machen und nicht
> 100000x fputc.
In dem Teil, den Du gerade weggeschnitten hast, habe ich geschrieben,
dass man das in der Praxis etwas optimieren will.
>> | Furthermore, characters are intended to be transmitted as a block to
>> | the host environment when a buffer is filled, when input is requested
>> | on an unbuffered stream, or when input is requested on a line buffered
>> | stream that requires the transmission of characters from the host
>> | environment.
>> Zitiert aus ISO/IEC 9899:201x, aber unverändert seit C89.
>>
>> Das betrifft genau den Fall mit dem Prompt. Der Prompt wird auf
>> stdout ausgegeben. [...] Bevor nun tatsächlich vom "host
>> environment" Daten angefordert werden, werden alle Output-Streams
>> geflusht, somit auch stdout. Der User sieht den Prompt und kann etwas
>> eingeben.
> Das lese ich da nicht raus. Ich lese da: wenn zwischen Schreiben und
> Lesen *innerhalb eines Streams* gewechselt wird, wird *dieser Stream*
> beim Wechsel geflushed.
Das wäre unsinnig. Denn hier wird "an unbuffered stream" stream erwähnt,
und da gibt es zu diesem Zeitpunkt keine characters, die "transmitted as
a block to the host environment" werden könnten, weil alle, die vorher
geschrieben wurden, mangels Buffer bereits transmittet wurden.
Ich stelle allerdings fest, dass sich zumindest die glibc nicht so
verhält, wie ich das interpretiere. Die flusht beim Lesen von stdin zwar
stdout (zumindest, wenn beide auf dasselbe Terminal gehen) aber nicht
andere Streams.
> Dass der Prompt erst nach der Eingabe erscheint ist zumindest kein neues
> Problem (z.B. https://stackoverflow.com/questions/56089143/).
Ja, da ist allerdings stdout offensichtlich fully buffered, die Annahme,
dass stdin auch fully buffered sei, liegt also nahe. In dem Fall wäre
der Absatz oben gegenstandslos.
>> (allerdings steht das dann meistens auch im Standard, was hier nicht der
>> Fall ist)).
>
> Die meisten Standards beginnen aber auch nicht mit "The standard is
> written in English.
Welche Teil eines Standards normativ sind und welche nicht, ist aber
schon wichtige Information. Ich halte es *nicht* für selbstverständlich,
dass Notes, Fußnoten oder Beispiele nicht normativ sind. Ich weiß, dass
das oft so ist, aber ich finde das seltsam, und es führt zu seltsamen
Argumenten wie "ja, das steht im Standard, aber nur in einer
Fußnote, also gilt es nicht" - "Es steht in einer Fußnote, also war es
klar von den Autoren beabsichtigt, daher muss dieser Satz im Text so
interpretiert werden, dass er zur Fußnote passt", etc.).
hjp
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-09-05 18:46 +0200 |
| Message-ID | <109fb6m.258.1@stefan.msgid.phost.de> |
| In reply to | #51968 |
Am 05.09.2025 um 08:33 schrieb F. W.: > Am 04.09.2025 um 18:55 schrieb Stefan Reuther: >>> Es gibt ja nicht mal case für Strings in C. >> >> In Pascal auch nicht, schon gar nicht "damals". Genauer gesagt gab es >> in Pascal "damals" nicht mal ernsthafte Strings. > > Och, PACKED ARRAY OF CHAR finde ich aber aussagekräftig. Das ist das gleiche wie 'char[]'. >>> Die klassische Form für Menüs damals. Von den unklaren >>> Parameterübergaben an Funktionen mal ganz zu schweigen. By reference? >>> By value? Egal. War alles erlaubt. Und alles dazwischen auch. >>> Erkannte man sowieso nicht auf Anhieb. >> >> In C ist das einfach. Es ist *immer* by value. In Pascal muss ich >> hingegen den Funktionskopf anschauen, ob der Parameter als VAR >> übergeben wird oder nicht. > > Aber man kann es erkennen. In C auch, nur einfacher. Wenn eine Adresse übergeben wird, erkennbar am Datentyp oder dem '&'-Operator, möchte wohl jemand den Wert verändern. C++ hingegen.... ist an der Stelle wie Pascal. Man muss den Funktionskopf anschauen, um zu wissen, was passiert. >>> Außerdem konnte man jahrelang in Speicher schreiben, der nicht >>> alloziert wurde. Oder man überschrieb einfach die Null-Termination >>> bei Strings und landete im gepflegten Nirgendwo. > >> Die "damals" üblichen Pascal-Dialekte von Borland haben Pascal >> erweitert. Zum einen um Strings, die zugegebenermaßen sehr bequem sind >> (allerdings mit ihrer Schallmauer von 255 Zeichen auch sehr limitiert >> und unflexibel). Zum anderen um allerlei Typcasts usw., damit man die >> ganzen Pointer-Fehler, die man in C machen kann, in Pascal endlich >> auch machen kann. Nimmt sich also am Ende nichts. > > Diesen Teil von Pascal versuche ich zu meiden. Besonders das Typecasting > geht bei mir zu 90 % irgendwie in die Hose. Pointer gehen noch so. NEW > und ^ sind verständlich. ...und damit ist der Funktionsumfang identisch zu dem von C. >> Und jemand, der sich Gedanken darüber macht, wie man eine >> Programmiersprache sinnvoll benutzt, ist mir tausendmal lieber als >> jemand, der religiös runterbetet "nehmt Sprache X, dann seid ihr alle >> Probleme los". Denn, Spoiler: seid ihr nicht. Use-after-free oder >> out-of-bounds-access oder null-pointer-dereference kannst du in Pascal >> genauso einfach bauen wie in C. Und die Mittel, es zu vermeiden, sind >> genau die gleichen. > > Der Trick bei Pascal u. a. ist, dass man das machen kann, es aber auch > bleiben lassen kann. Vor allem verkettete Listen oder Bäume kann man in > Pascal bauen. Man kann aber auch ohne sie gut leben. In C auch. Und dann hat man die Vorteile einer umfangreichen Infrastruktur. Ein nichttriviales Pascal-Programm von einem Compiler auf einen anderen zu übertragen ist ein Projekt. Gescheites C ist eine Sache von "einfach neu compilieren". Zumindest ist die Teilmenge der von allen C-Compilern unterstützten Funktionen deutlich größer als bei Pascal. OK, es gibt FreePascal. Für x86 und ARM. Was ist mit PIC? Xtensa? M32R? Was ist mit Betriebssystemen außerhalb der großen *ixe? QNX? FreeRTOS? Integrity? Eine Sprache mit C++-Features aber Pascal-Syntax wäre nett gewesen. Aber der Zug ist halt abgefahren. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2025-09-04 19:33 +0200 |
| Message-ID | <mhu0qvFsac3U1@mid.individual.net> |
| In reply to | #51957 |
Am 04.09.25 um 17:07 schrieb F. W.:
> Am 04.09.2025 um 15:14 schrieb Hermann Riemann:
>> Am 04.09.25 um 11:41 schrieb Andreas Bockelmann:
>>> F. W. schrieb:
>>>> ...wie auch immer: Pascal ist derzeit auf Platz 10 im T-Index der
>>>> beliebtesten Programmiersprachen.
>>>>
>>>> https://youtu.be/dwnaR0687iI?si=6PnmaYyF2Ce5WI6X
>>>>
>>>> Den alten Wirth hätte das wohl gefreut.
>>>>
>>>> Mich auch. Ich nutze seit Apple Pascal diese schöne Sprache.
>>
>>> Seit zig Jahren habe ich es nur noch mit SQL zu tun, aber Pascal habe
>>> ich geliebt.
>>
>> Ich habe mich gefreut, als ich auf Atari ST ST Pascal durch Borland
>> ANSI C ersetzt hatte.
>>
>> Pascal habe ich nie vermisst, In C programmiere ich noch gelegentlich.
>>
>
> Ich will zwar keinen Flamewar ohne Ergebnis anfeuern, aber...wenn Du
> schon anfängst, muss man der Öffentlichkeit etwas mitteilen. In C habe
> ich so etwa ab 1989 programmiert.
ANSI oder K&R ?
> Von den unklaren Parameterübergaben an Funktionen mal ganz
> zu schweigen. By reference? By value?
By Value. By reference geht über Verwendung von pointer.
> Egal. War alles erlaubt.
Nein, aber es war mehr erlaubt als in Pascal.
Z.B. Datenlayout in struct abzubilden. Zwar nicht offiziell, aber..
> Außerdem konnte man jahrelang in Speicher schreiben, der nicht alloziert
> wurde.
In anderen Sprachen macht man das mit array Grenzen Überschreitung.
Ein Test auf array Grenzen macht code langsamer.
> Oder man überschrieb einfach die Null-Termination bei Strings und
> landete im gepflegten Nirgendwo.
Dafür war ich bei Pascal mit array Grenzen eingeschränkt
Ich erinner mich noch an die Mühen,
Strings mit variablen Grenzen über eine Struktur mit variant zu basteln.
> Heute sind das natürlich nach 30 Jahren keine Probleme mehr.
Eher nahzu.
> Meine Hassliebe ging so weit, dass ich nicht mal Produkte kaufte, die in
> C geschrieben waren.
Und wie hast Du das bei binär Dateien geprüft?
> Unsere Finanzbuchhaltung beispielsweise, die lief
> erst nach 5 Jahren ohne Absturz.
Die Sicherheit eine Programmes hängt weit mehr
vom Programmiermethode ab, als von der Sprache.
Beruflich beschäftigte ich mich in der meisten Zeit
mit finden von Fehler und deren Behebung.
> So mancher Runtime-Error war nie zu
> finden, geschweige denn zu beheben.
Ich würde mir immer noch zutrauen,
jeden reproduzierbaren Fehler zu finden.
> Die C-Programmierer hatten ihr
> eigenes Programm nicht mehr verstanden.
Das hängt von der Programmierart und der Größe des Programmes ab.
> Mein Vorschlag, doch eine geeignetere Sprache zu wählen, wurde nicht
> erhört. Stattdessen gab man mir hinter meinem Rücken Tiernamen und
> verstand das Grundproblem nicht. Aber wenigstens war man hip und modern
> und swinging...ich wählte dann eine FiBu, die nachweislich nicht in C
> geschrieben wurde und die lief vom ersten Tag an.
Ob das an C lag ist nur ein Verdacht.
Chaotischer Gebrauch von pointer oder Variablen
kann man mit Quelltext lesen kaum beheben.
Ich habe oft Maschinencode trace verwendet.
In C habe ich zur Fehlersuche viel *printf verwendet.
> Jeder soll programmieren in der Sprache, die er für gut hält.
Geht bei größeren Projekten, bei denen mehrere am gleichen
Projekt arbeiten, meist nicht.
Der Programmwechsel von Strukturen zwischen Pascal und C..
> Aber bezahlen würde ich C-Projekte nicht mehr freiwillig.
Wie bezahlen?
Bist Du sicher das windows nicht in C geschrieben ist?
> Da haben sogar BASIC und COBOL bei mir bessere Chancen.
Privat werde habe ich COBOL ( und Java und Ada und ..)
zu den, nur wenn es nicht anders geht, eingeschätzt,
BASIC und Pascal ( und Forth und .. ) zu den
"wenn ich zu viel Zeit habe, nochmal damit spielen"
> Ich wette, die NASA wäre mit C nie ins All gekommen.
Eine Abschätzung.
Mit Assembler passieren mehr Fehler.
> Assembler war nicht umsonst die erste Wahl.
Damals waren die Programme auch sehr klein
und mussten in wenig Kernspeicher ablaufen.
> Das ist klar und sauber.
Geht etwas in C, was in Assembler nicht geht?
C basiert auf PDP11 Assembler
> Nee, ich bin froh, dass ich wieder auf Pascal wechseln konnte.
Und ich bin froh, dass ich für das, was ich programmiere,
kein Pascal mehr brauche.
> Bei C muss man sich mehr um das Werkzeug kümmern, als um das Werkstück.
Das kann vielleicht davon abhängen, was Du programmierst.
C ist etwas unhandlich bei string Bearbeitung.
> C mache ich nur noch auf Linux, wenn es um Systemprogrammierung geht.
Systemprogrammierung in Linux mache ich eher selten.
> Und wenn ich C++ sehe, möchte ich das gar nicht erst verstehen.
Einen Nutzen von C++ im privaten Bereich habe ich bisher nicht gefunden.
Viele C++ Eigenschaften habe ich anderweitig erreicht.
Module ( getrennte Quelltext Dateien ) statt Klassen,
einige mit #define.
> Da ist ja Java lesbarer und das will schon was heißen.
Ein Großteil von Programme wie arithmethische Ausdrücke
( z.B. x:=(7*y)+14; )
ist in den meisten Programmiersprachen sehr ähnlich.
Das Gleiche gilt bei Steuerungen wie if else Schleifen.
Bei Texten gibt es bei der Formulierung Unterschiede,
aber wie sie beim programmieren gedacht werden, eher nicht.
> Wer unlesbare Programme schreibt,
> der bringt die Menschheit um seine Erkenntnisse.
Wer will die haben? :-)
> Ich hatte immer den Verdacht,
> dass C- und Java-Programmierer genau das schätzen.
Man kann in jeder Programmiersprache schwer lesbare Programme schreiben.
Als echter Programmierer verwendet man LABEL mit ASSIGN GOTO.
Das sähe in Pascal in etwa so aus:
integer Label_nr unterprogramm_name
( integer Label_nr, structur(Lokale_Variable_vom_Rufer);
while(TRUE):
case: Label_nr;
100: irgendein_code;
RETURN Label_nr
..
im irgendein_code
kann über Zuweisung an Label_nr
die Steuerung übernommen werden
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web