From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.devel Subject: Re: we need *modularity* [last problem] (was: Re: as for Calc and the math library) Date: Fri, 16 Aug 2024 09:57:25 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_DU2PR02MB1010994F54448C7B21CADA8F896812DU2PR02MB10109eu_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32171"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" To: Emanuel Berg Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 16 12:46:12 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1seuTD-00084r-N8 for ged-emacs-devel@m.gmane-mx.org; Fri, 16 Aug 2024 12:46:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1seuSJ-0007bv-2x; Fri, 16 Aug 2024 06:45:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1seti9-0003Y9-23 for emacs-devel@gnu.org; Fri, 16 Aug 2024 05:57:33 -0400 Original-Received: from mail-northeuropeazolkn19011021.outbound.protection.outlook.com ([52.103.32.21] helo=DB3PR0202CU003.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1seti5-00008g-UE for emacs-devel@gnu.org; Fri, 16 Aug 2024 05:57:32 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MwCfw3/zAdMdYOUD5MiFtkNGBWz7nj6+ROc3KsbsYGzeqJNyy97O3Xy3dd3dUH+h2pPXMUi3kyxd/FhE0AdT2pN3EyH6EosNnxjI+Lpws2pe59KzWROPCJT7onSG7wgQI+leAv8AgrZ+O4Nn0MLAfwR49LO82uIkOdzWxwOHwbF83GiTn++hQNeNhvPXEhOEMP3SXbk88RNqX60MP1kMVQTOElcF55zSNlsgxt0574eBo2Z7gx9tsOx0CICcajtKnHeUZaf16kCrreHHiiuYkcW75tm8DKuf5jpFsAQhYkdl9/ttrDqch33t/FbRb/W+1XS10aV6ECzDVaysqWKXNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=u9SO/CxxQTsACcidbfLNxrHehiZPotq4YbUeTM8wdhY=; b=Q1TKNDAoUzMUm1vWMcADBJC9ZmT/a5jAU25I8zGR6aYK18mG4WSX09qCA4OGtwLzQ1wGSHdp9K2+Fj5MB0e4YPPUJcMCDqYMBGV9JhlL4xUsrLHX1QeE0dQFdkyVLsNK+Qv42QQBhR/NznmIxO1HxRmDajAU3vhAc98mWmo6u8PJjCMZGnpP3l/EROKwG4bSlSNYAErB1OqzCwOxy2VEm2nZ6Qr0+rJ/AvW1EKZVzwDjs2MvmW1gb1qcMi5b52ZjP9oDCKw3xVJ/XZuHtJkVwlsCgeqWZJm6jc4jV6cv8eJPs+8vIXFkvrbW1UfVLyooSTsAa2rH75nmt3e+SYTu4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u9SO/CxxQTsACcidbfLNxrHehiZPotq4YbUeTM8wdhY=; b=GDaY9AvAC2UIfgwnbywJNmHq31a+LQdjtUmjaJ0hgdKsO0ukVfLplHEgssLcrQZkESRixtYfNpMcNvtyMUL8eszMnyyLJ2h2wlNW4Znl16AHSIuiAZ925bMzmVBePX+X4E58Q/O5hFIyadpV5O0TJm9CZE5hpCAdK4QyhAZfQGInfpSqUV8b4kKxdGnxnihBlyJsF/PZ8Zl7O4k7hUU9azFZQlUO4SSuUEZJHKijegu0TqZJWt4GFJYBmCTgMirPoMxJ4yHVLyrrLsUh1vAbHF/wzIq9osTTOcZZt7ApZxMuiFeC/zHNcGGSchn4SBo6aW4rY/aGlm0N+jjgNDNcpA== Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) by DU0PR02MB8522.eurprd02.prod.outlook.com (2603:10a6:10:3e5::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7875.17; Fri, 16 Aug 2024 09:57:26 +0000 Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::f3c9:d4cb:290:d487]) by DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::f3c9:d4cb:290:d487%4]) with mapi id 15.20.7875.016; Fri, 16 Aug 2024 09:57:26 +0000 Thread-Topic: we need *modularity* [last problem] (was: Re: as for Calc and the math library) Thread-Index: AQHa78HU8ilKvq4/lEG8VisFLY9B+w== Accept-Language: sv-SE, en-US Content-Language: sv-SE x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [2BwNlaewihHF5199fCEIn/fOZvMRWklC] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU2PR02MB10109:EE_|DU0PR02MB8522:EE_ x-ms-office365-filtering-correlation-id: 7f9e41c4-6db1-429e-f3a8-08dcbdd9d515 x-microsoft-antispam: BCL:0; ARA:14566002|461199028|19110799003|15030799003|15080799003|8060799006|440099028|4302099013|3412199025|102099032|56899033|1602099012; x-microsoft-antispam-message-info: t58ieZTrDLYwgOe4VFTt1Sj9N9I1eafeLhy5BDo+0C3xWmpv5cfPS2FRmYGE6FSKhcfWjrmFRZzYfygg/uqBY7oICda9XbzfPCJvuh1GYeTja+ZIVwWsRvO8u1lTVyRKqgNzQ646+IyUdlIissuL9WR/SVNBIM3qpdLjo64Glemqs1xs2ejqXyIZJe+9ESaI4NWHXL55VmezKXqRu1Qb90DrEXlJlpnbOWQK+A4PLEBB41KAAeFLnIFI2q5mHFGWK6OCOkoaCqdAbgdbr3tM/ZK62pzZ8I8NJDWQR+FrUxUfYKnb40hMFiFYCneyf0uWgq8TB8YXf//y7Bmrz9ObRmttEefNfZ/uUgKf0HEhWzU82KZkz//bmEXlpI4aAgQJ/ECUpnh8aSXDZbF3VSyEE7JbhYBattrHqhv3DkpS/q8LjDGM63zry2sqXZIxvQnmggy2LV0hZhF7w6WoBb7ZldFOMPc2wG5LWFMpANpzw42S0hT2xHnMDtoMH+UJFF4L4MTX7mE6QCHMdT4R0b5fLvVTAZqVYXPHVVZ4TuiuBRDevjBtYYEA4LU4U66GkeL3pozXQI0YlvIcpQAVyviGzpKzz8kxIXBeD3DTsPqQJ4dLu6h0pMCNWTq2H40s/fT2HdrXnN5BCa69cGxMnbA+RaBURpT4x0LnJ4Rc/myejEfTxtxCNrGOx9M3JxE4VOZT6SB/x2Wt5YllNg8QBMyf3+Dit7I2DBi1WsUxEYvBGGIOZ9grJb+sKp4ITJ9kW 8z9hY4NUkrBZIMePnLe2BVNJbMSvQBJPX9roZAwJYaXtjwKbgW5p6+8BUxE674F53H0WRCWkr1dGrVtgKFuygCogii3SK5bIvx x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?WbJJp7LFm3Wo0a/8dGkQFUpewYxkKIMH1Wym9bebWK/mTWM3nWeI/1LIyd?= =?iso-8859-1?Q?Kozi8MTCX88Kk1iLTAl9ZB8nCwoJqeA8H8wQtGu/6C6xiaYxWynb93CeKF?= =?iso-8859-1?Q?3zfEgeZ7BBEJxB8crTruvktMLC9XyjBqmXqqTK+EnV1zWL4UKNLk59w8rH?= =?iso-8859-1?Q?r/t+nk2hmFwrS9TBtpfeRjpKpfYHfCKy7FvhyVnvY08LnG5W7KFT/mhnJO?= =?iso-8859-1?Q?P9DYra8fqQwaqdpH/RLdVMcui6lXRUnJ4FF6QGIF41w9dGR5cBL4efWuKk?= =?iso-8859-1?Q?/nquGp8f+BzqgtxWLR9cKa9DH0wJ61KpkYtwLIGvNz+qnBUPUZyoT+MWFh?= =?iso-8859-1?Q?8cCWBbAQFAv/Y0lNZXl5HNadkXXtpakv50RIVkVGEzYTO8XE+Q4RyBtDzK?= =?iso-8859-1?Q?ra9xPx4YaiHNqMWrPrDdeLDjS9GFygMOXEkWsINufh00WvBAdpaRTEBk3P?= =?iso-8859-1?Q?JLrFQYD7WpfgZ/qQysB9bttL7zKeGqiz/AMNWwNPdXZccT4ger4xecNu4m?= =?iso-8859-1?Q?Ay4DkTpCr//nNa7CA6WKlpoPwIeOFkVw1VL1Hx8Imx4mB2fO9dqWKpLSMs?= =?iso-8859-1?Q?F+PDwR0+LgpiMZfgSv83ai0IKaOKu6ARitozVLr9HEOtdkEpQfzofgaYsG?= =?iso-8859-1?Q? X-OriginatorOrg: sct-15-20-7828-19-msonline-outlook-12d23.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10109.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 7f9e41c4-6db1-429e-f3a8-08dcbdd9d515 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2024 09:57:25.9743 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR02MB8522 Received-SPF: pass client-ip=52.103.32.21; envelope-from=arthur.miller@live.com; helo=DB3PR0202CU003.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 16 Aug 2024 06:45:12 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322801 Archived-At: --_000_DU2PR02MB1010994F54448C7B21CADA8F896812DU2PR02MB10109eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> I have seen your previous answers to others, and I do >> understand the point you make, but I think the argument >> fails because a module can be just a proxy to >> a non-free library. > >Emacs is notoriously not modular. Everything is everywhere, >you seem to have everything but if fact you have nothing. >There is so much stuff you can't find the basics stuff that >isn't there. > >Here take a look: what does this name say? > > cl--defalias > >Ah, that's a local function in the Common Lisp package, right? > >Well, YES, but ... > >It is actually an Elisp defun. And that prefix isn't really >a package qualifier, it is just a convention, part of >the name. And the double dash, likewise just a convention, we >don't have package modularity or any of that kind of data >hiding, abstraction, encapsulation ... what is it more called? >Well, modularity! > >In Emacs everything is intermixed, Elisp-Emacs, >non-interactive/interactive, data/data processing/the >interface (buffer, buffer, and buffer), what is a file, what >is a package, what is a library, and what is a program - no >one can tell. > >Emacs Lisp isn't is fun, but absolutely not any kind >of powerhouse. It is inconsistent in itself and on top of that >all those zillion interfaces, cl-, seq-, slime- (yes, had to >use that today, for `slime-transpose-lists'). > >It is pretty fast to get something going but complexity >skyrockets. > >What we should do, in general: modularity! clear divisions, in >particular, libraries for everything, including those that provide basic >stuff in a complete and consistent way. > >We should get real package modularity, transform the prefixes >into real package qualifiers, and throw away the ugly >local ones. > >With Elisp, optimize everything for development speed and >convenience, have consistent interfaces as much as possible, >acknowledge that Elisp was underpowered, which is why all the >interfaces came, now, core Elisp and the interfaces should >make peace, one should identify what it is exactly, what are >the to 10 things that people use with cl-, pcase-, seq- etc, >and bring them into a new core Elisp, and the few CL experts >can still use all the rest. > >Now, with native compilation we have speed - we have power >with the interfaces if one could harvest it, which one >currently - well, it is very slow and difficult, anyway - the >very, very last spet into maturity and getting out of the >Elisp ghetto (and getting visitors!) are modularity, modern >software principles - by modularity I mean real modularity, >based on technology - not silly conventions - I forgot where >I was - the last step is modularity in general, and libraries >in particular. > >Clear cut interfaces. Get away with the ugly prefixes and >error--prone conventions that don't even do anything. > >Elisp 3.0! \o/ > >PS. This is the problem. This series is completed, I said > I would write 10, I wrote 4. Here are the other parts. > It is all based on the same theme. Modularity, > consistency, libraries, modern software practises. > > https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00154.html > https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00380.html > https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00388.html > >PPS. So who is working on real modularity based on the package > with real public and local functions as we speak? I know > there are always some guy - at least - working on such > a basic idea. I know some way. And I know some day. Emacs Lisp like all other programming languages has its problems. I am not = sure though all the things you have taken up in those mails are problems. I have= n't answered on previous ones, more than a cursory suggestion about adding some explanation to the manual in one mail about FFI which seem to be just ingor= ed. IMO, we have to understand Emacs as application and what it has to do to achieve its goal of an interactive text editor, in addition to be also a Li= sp implementation. At low level, there is the central idiom, buffer, implemented as a gap buff= er, which has to be manipulated in some way. IMO, something like "goto-char", s= ounds much better than "move-gap" in the context of text editing. They need to ha= ve some low-level primitives on which to implement the higher level ones. Comp= are to some other editors, like VSC or whichever. They are all in pretty simila= r situation, since very few programming languages do have a "text" data struc= ture built into the language. They need some sort of "assembly" to build on. As discussed in the mentione= d mail from yesterday or the day before, I think it could be added to the man= ual about the programming model used in low-level text and buffer management: m= ake an object current, and than act upon it. This is not so uncommon, stack-bas= ed procedural approach. PostScript and OpenGL are two notable languages/API th= at use similar approach. There are probably others I am not familiar with. I d= on't know if that was popular programming model during 80's when Emacs was desig= ned or not, but Emacs Lisp is not alone in its design. I don't know what is a better alternative? Look at Xlib and numerous argume= nts their functions take. Win32 uses structures to pass arguments, which leads = to less function arguments passed around, but one has to setup structures befo= re they are passed to a function. It is also ads verbosity. Yuri mentioned iterators, but I think iterators would have similar problem as markers: one= has to update all iterators into a buffer if one of them writes to the buffer. = I am not sure, but iterator could be seen as "functional marker", i.e. a functio= nal interface to markers? Since Emacs Lisp does not have doted notation for functions that work on objects, like some other languages that use iterator= s extensively (C++, Java), I think iterators and markers are basically the sa= me thing in EmacsLisp? I haven't think of it too much, so I might be wrong. So, I don't know, while yes, you are correct that the programmatic interfac= e is a low-level, I don't think it is a bad one, or that they had so much more c= hoice there. There is though nothing that forbids anyone to make a higher-level interface on top of the low-level one. I think, as someone mentioned in som= e earlier mail, org-mode, or perhaps font-lock, regular expressions, or vario= us programming modes could be seen as a higher level interfaces. At least conceptually? They could be implemented on top of goto-char, char-before/af= ter and point, but for the performance reasons are not (just my guess). Also Emacs has to implement its own command loop and renderer, and since mo= st of us would like some control over those from Lisp, they need to expose those = parts to Lisp as well. I don't think that that Emacs rendering and text processin= g is all very entangled in some bad way. Emacs does implement a console-like (character) renderer. The design is (somehwat) similar to other similar projects. For example MS console API implements a similar design, a 2d matr= ix of characters, with text properties describing colors and other rendering attributes for characters. There is a long comment by Gerd in xdisp.c expla= ining the design in Emacs. I will definitely agree with you that Emacs needs modular development, but = now you are opening another can of worms into an already unwelcome discussion := ). I also agree with you that EmacsLisp and C core could get a big cleanup, th= e API surface is big, especially now when Lisp can be compiled to machine code vi= a GCC. There also seem to be some dissonance with the manual, as seen from my other mail about subrs and some other functions (which I hope will get an answer), so I definitely also agree that Elisp manual could get a facelift = too. I actually wrote this explanation, including a small CL program ~100 sloc, = that implements toy version of Emacs text processing API for the illustrative pu= rpose days before, on your first mail about goto-char, but never sent because of explicitly not spending time of maintainers on the discussion that they pro= bably don't care much of, so not to waste their time and understanding that the t= opic, while interesting is probably unwelcome, and yet, Eli accused me of delibar= ately wasting maintainers time and energy. Personally, I think it is interesting = to talk about low-level implementation details, at least to check and further = my own udnerstanding, but it is probably best to continue the discussion via P= M if you are interested. best regards /a --_000_DU2PR02MB1010994F54448C7B21CADA8F896812DU2PR02MB10109eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>> I have seen your previous answers to others, and I do
>> understand the point you make, but I think the argument
>> fails because a module can be just a proxy to
>> a non-free library.
>
>Emacs is notoriously not modular. Everything is everywhere,
>you seem to have everything but if fact you have nothing.
>There is so much stuff you can't find the basics stuff that
>isn't there.
>
>Here take a look: what does this name say?
>
>  cl--defalias
>
>Ah, that's a local function in the Common Lisp package, right?
>
>Well, YES, but ...
>
>It is actually an Elisp defun. And that prefix isn't really
>a package qualifier, it is just a convention, part of
>the name. And the double dash, likewise just a convention, we
>don't have package modularity or any of that kind of data
>hiding, abstraction, encapsulation ... what is it more called?
>Well, modularity!
>
>In Emacs everything is intermixed, Elisp-Emacs,
>non-interactive/interactive, data/data processing/the
>interface (buffer, buffer, and buffer), what is a file, what
>is a package, what is a library, and what is a program - no
>one can tell.
>
>Emacs Lisp isn't is fun, but absolutely not any kind
>of powerhouse. It is inconsistent in itself and on top of that
>all those zillion interfaces, cl-, seq-, slime- (yes, had to
>use that today, for `slime-transpose-lists').
>
>It is pretty fast to get something going but complexity
>skyrockets.
>
>What we should do, in general: modularity! clear divisions, in
>particular, libraries for everything, including those that provide basi= c
>stuff in a complete and consistent way.
>
>We should get real package modularity, transform the prefixes
>into real package qualifiers, and throw away the ugly
>local ones.
>
>With Elisp, optimize everything for development speed and
>convenience, have consistent interfaces as much as possible,
>acknowledge that Elisp was underpowered, which is why all the
>interfaces came, now, core Elisp and the interfaces should
>make peace, one should identify what it is exactly, what are
>the to 10 things that people use with cl-, pcase-, seq- etc,
>and bring them into a new core Elisp, and the few CL experts
>can still use all the rest.
>
>Now, with native compilation we have speed - we have power
>with the interfaces if one could harvest it, which one
>currently - well, it is very slow and difficult, anyway - the
>very, very last spet into maturity and getting out of the
>Elisp ghetto (and getting visitors!) are modularity, modern
>software principles - by modularity I mean real modularity,
>based on technology - not silly conventions - I forgot where
>I was - the last step is modularity in general, and libraries
>in particular.
>
>Clear cut interfaces. Get away with the ugly prefixes and
>error--prone conventions that don't even do anything.
>
>Elisp 3.0! \o/
>
>PS. This is the problem. This series is completed, I said
>    I would write 10, I wrote 4. Here are the other parts.
>    It is all based on the same theme. Modularity,
>    consistency, libraries, modern software practises.
>    
>    https://lists.gnu.org/archive/html/emacs-devel/2024-08/ms= g00154.html
>    https://lists.gnu.org/archive/html/emacs-devel/2024-08/ms= g00380.html
>    https://lists.gnu.org/archive/html/emacs-devel/2024-08/ms= g00388.html
>
>PPS. So who is working on real modularity based on the package
>     with real public and local functions as we speak? I know=
>     there are always some guy - at least - working on such
>     a basic idea. I know some way. And I know some day.

Emacs Lisp like all other programming languages has its problems. I am not = sure
though all the things you have taken up in those mails are problems. I have= n't
answered on previous ones, more than a cursory suggestion about adding some=
explanation to the manual in one mail about FFI which seem to be just ingor= ed.
IMO, we have to understand Emacs as application and what it has to do to
achieve its goal of an interactive text editor, in addition to be also a Li= sp
implementation.

At low level, there is the central idiom, buffer, implemented as a gap buff= er,
which has to be manipulated in some way. IMO, something like "goto-cha= r", sounds
much better than "move-gap" in the context of text editing. They = need to have
some low-level primitives on which to implement the higher level ones. Comp= are
to some other editors, like VSC or whichever. They are all in pretty simila= r
situation, since very few programming languages do have a "text" = data structure
built into the language.

They need some sort of "assembly" to build on. As discussed in th= e mentioned
mail from yesterday or the day before, I think it could be added to the man= ual
about the programming model used in low-level text and buffer management: m= ake
an object current, and than act upon it. This is not so uncommon, stack-bas= ed
procedural approach. PostScript and OpenGL are two notable languages/API th= at
use similar approach. There are probably others I am not familiar with. I d= on't
know if that was popular programming model during 80's when Emacs was desig= ned
or not, but Emacs Lisp is not alone in its design.

I don't know what is a better alternative? Look at Xlib and numerous argume= nts
their functions take. Win32 uses structures to pass arguments, which leads = to
less function arguments passed around, but one has to setup structures befo= re
they are passed to a function. It is also ads verbosity. Yuri mentioned
iterators, but I think iterators would have similar problem as markers: one= has
to update all iterators into a buffer if one of them writes to the buffer. = I am
not sure, but iterator could be seen as "functional marker", i.e.= a functional
interface to markers? Since Emacs Lisp does not have doted notation for
functions that work on objects, like some other languages that use iterator= s
extensively (C++, Java), I think iterators and markers are basically the sa= me
thing in EmacsLisp? I haven't think of it too much, so I might be wrong.

So, I don't know, while yes, you are correct that the programmatic interfac= e is
a low-level, I don't think it is a bad one, or that they had so much more c= hoice
there. There is though nothing that forbids anyone to make a higher-level
interface on top of the low-level one. I think, as someone mentioned in som= e
earlier mail, org-mode, or perhaps font-lock, regular expressions, or vario= us
programming modes could be seen as a higher level interfaces. At least
conceptually? They could be implemented on top of goto-char, char-before/af= ter
and point, but for the performance reasons are not (just my guess).

Also Emacs has to implement its own command loop and renderer, and since mo= st of
us would like some control over those from Lisp, they need to expose those = parts
to Lisp as well. I don't think that that Emacs rendering and text processin= g is
all very entangled in some bad way. Emacs does implement a console-like
(character) renderer. The design is (somehwat) similar to other similar
projects. For example MS console API implements a similar design, a 2d matr= ix
of characters, with text properties describing colors and other rendering
attributes for characters. There is a long comment by Gerd in xdisp.c expla= ining
the design in Emacs.

I will definitely agree with you that Emacs needs modular development, but = now
you are opening another can of worms into an already unwelcome discussion := ).

I also agree with you that EmacsLisp and C core could get a big cleanup, th= e API
surface is big, especially now when Lisp can be compiled to machine code vi= a
GCC. There also seem to be some dissonance with the manual, as seen from my=
other mail about subrs and some other functions (which I hope will get an
answer), so I definitely also agree that Elisp manual could get a facelift = too.

I actually wrote this explanation, including a small CL program ~100 sloc, = that
implements toy version of Emacs text processing API for the illustrative pu= rpose
days before, on your first mail about goto-char, but never sent because of<= /div>
explicitly not spending time of maintainers on the discussion that they pro= bably
don't care much of, so not to waste their time and understanding that the t= opic,
while interesting is probably unwelcome, and yet, Eli accused me of delibar= ately
wasting maintainers time and energy. Personally, I think it is interesting = to
talk about low-level implementation details, at least to check and further = my
own udnerstanding, but it is probably best to continue the discussion via P= M if
you are interested.

best regards
/a
--_000_DU2PR02MB1010994F54448C7B21CADA8F896812DU2PR02MB10109eu_--