From: Christopher Dimech <dimech@gmx.com>
To: Emanuel Berg <incal@dataswamp.org>
Cc: emacs-devel@gnu.org
Subject: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)
Date: Wed, 7 Aug 2024 13:26:04 +0200 [thread overview]
Message-ID: <trinity-396ecc84-f60f-400b-8296-ae4b2f9e89be-1723029964412@3c-app-mailcom-bs15> (raw)
In-Reply-To: <87frrg6b1q.fsf@dataswamp.org>
> Sent: Wednesday, August 07, 2024 at 7:34 PM
> From: "Emanuel Berg" <incal@dataswamp.org>
> To: emacs-devel@gnu.org
> Subject: Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)
>
> Abraham S.A.H." via "Emacs development discussions. wrote:
>
> >> Moving point around
> >
> > I thought it's the strengh point of Emacs.
>
> When programming, half the time is moving around in the buffer
> instead of solving the actual problem.
>
> Not only that, moving around in the buffer is difficult and
> error-prone as you don't know how it will look at the point of
> code execution, and also moving around and of course
> especially _editing_ it inside it changes it, so it is a crazy
> situation to encourage.
>
> > Why "Everything being a buffer" is bad?
>
> Because one would like to separate data, data retrieval, data
> processing, and how data is displayed.
>
> This is possible to do in Elisp but people have not payed
> attention to it which is why many program including such in
> core Emacs are very long programs with a lot of moving around
> buffers endlessly and this code is all intermixed with
> everything else.
>
> Very ugly, boring to write, difficult to read, error-prone
> to maintain.
How the latex and tex modes have been written is an example.
> --
> underground experts united
> https://dataswamp.org/~incal
>
>
>
next prev parent reply other threads:[~2024-08-07 11:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.47.1722960050.16997.emacs-devel@gnu.org>
2024-08-06 16:59 ` 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) Abraham S.A.H. via Emacs development discussions.
2024-08-07 7:34 ` Emanuel Berg
2024-08-07 11:26 ` Christopher Dimech [this message]
2024-08-06 17:05 Abraham S.A.H. via Emacs development discussions.
-- strict thread matches above, loose matches on Subject: below --
2024-08-04 22:27 Emacs website, Lisp, and other Jeremy Bryant
2024-08-04 22:55 ` Emanuel Berg
2024-08-05 9:23 ` Christopher Dimech
2024-08-05 12:28 ` Eli Zaretskii
2024-08-05 16:27 ` 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) Emanuel Berg
2024-08-05 16:38 ` Eli Zaretskii
2024-08-05 17:03 ` Emanuel Berg
2024-08-05 18:58 ` Christopher Dimech
2024-08-05 17:13 ` Yuri Khan
2024-08-06 6:39 ` Emanuel Berg
2024-08-06 11:16 ` Richard Stallman
2024-08-06 22:08 ` Emanuel Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=trinity-396ecc84-f60f-400b-8296-ae4b2f9e89be-1723029964412@3c-app-mailcom-bs15 \
--to=dimech@gmx.com \
--cc=emacs-devel@gnu.org \
--cc=incal@dataswamp.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).