* 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) [not found] <mailman.47.1722960050.16997.emacs-devel@gnu.org> @ 2024-08-06 16:59 ` Abraham S.A.H. via Emacs development discussions. 2024-08-07 7:34 ` Emanuel Berg 0 siblings, 1 reply; 12+ messages in thread From: Abraham S.A.H. via Emacs development discussions. @ 2024-08-06 16:59 UTC (permalink / raw) To: Emacs Devel > Moving point around I thought it's the strengh point of Emacs. Why “Everything being a buffer” is bad? Other than being tired of it? Sounds like people who talk about their frustration with Unix's “everything is a file” concept. Can you explain this with more logics and examples? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) 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 0 siblings, 1 reply; 12+ messages in thread From: Emanuel Berg @ 2024-08-07 7:34 UTC (permalink / raw) To: emacs-devel 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. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 12+ messages in thread
* 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) 2024-08-07 7:34 ` Emanuel Berg @ 2024-08-07 11:26 ` Christopher Dimech 0 siblings, 0 replies; 12+ messages in thread From: Christopher Dimech @ 2024-08-07 11:26 UTC (permalink / raw) To: Emanuel Berg; +Cc: emacs-devel > 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 > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)
@ 2024-08-06 17:05 Abraham S.A.H. via Emacs development discussions.
0 siblings, 0 replies; 12+ messages in thread
From: Abraham S.A.H. via Emacs development discussions. @ 2024-08-06 17:05 UTC (permalink / raw)
To: Emacs Devel
> Since Python has had enormous success
Just in being popular you mean right?
I would not learn it otherwise.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Emacs website, Lisp, and other
@ 2024-08-04 22:27 Jeremy Bryant
2024-08-04 22:55 ` Emanuel Berg
0 siblings, 1 reply; 12+ messages in thread
From: Jeremy Bryant @ 2024-08-04 22:27 UTC (permalink / raw)
To: emacs-devel, Eli Zaretskii, Richard Stallman
Reviewing the Emacs website, and previous discussions on this list below
(admittedly not recent, but still relevant). It seems important to add
some text on Lisp which is not currently there, as per ideas of RMS and
Eli summarised below.
Where is the repo for the Emacs website?
What do people think?
Previous discussions on the subject:
https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00356.html
RMS:
"
> We don't want to set Lisp up against other languages.
> We do want to get across what it offers that benefits
> an editor and environment such as Emacs.
Yes we do, to some extent. The Emacs web site should say this:
Lisp is the most powerful and elegant of programming languages. If
you want to see how powerful and elegant a programming language can
be, you need to learn Lisp. It will give you standard for measuring
other languages.
"
https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00335.html
RMS:
"
Calling Emacs Lisp "python-like" is derogatory to Emacs Lisp.
Python has some of the characteristics that make Lisp superior,
but not all of them.
Lisp is the most elegant and powerful programming language. That is
what we should say. In Lisp, programs are structured data and it is
easy to write other Lisp programs to operate on them.
Programmers that don't know Lisp do not realize what is missing in
other prograamming languages.
"
https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00200.html
Eli:
"
I believe the same could be true with other aspects. E.g., is it such
a preposterous assumption that someone might be interested in coding
in Lisp, instead of all the ad-hoc extension languages invented by
other editors?
"
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs website, Lisp, and other 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 0 siblings, 1 reply; 12+ messages in thread From: Emanuel Berg @ 2024-08-04 22:55 UTC (permalink / raw) To: emacs-devel Jeremy Bryant wrote: > Lisp is the most powerful and elegant of programming > languages. If you want to see how powerful and elegant > a programming language can be, you need to learn Lisp. > It will give you standard for measuring other languages. Ah, I don't know, that kind of boasting. Powerful and elegant are both immeasurable things, well, maybe in electrical engineering one can measure it. > Calling Emacs Lisp "python-like" is derogatory to Emacs > Lisp. Python has some of the characteristics that make Lisp > superior, but not all of them. Okay, then everyone should know this is a controversial thing to say. No one, or very few, would recommend Emacs Lisp as an alternative to Python 2024. It will sounds like we are a bunch of fanatics boasting from our own echo chamber were, inside it, we all are fantastic and high on Lisp. Lisp's superiority is a myth. To me it is more like a drug :) -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 12+ messages in thread
* Emacs website, Lisp, and other 2024-08-04 22:55 ` Emanuel Berg @ 2024-08-05 9:23 ` Christopher Dimech 2024-08-05 12:28 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Christopher Dimech @ 2024-08-05 9:23 UTC (permalink / raw) To: Emanuel Berg; +Cc: emacs-devel > Sent: Monday, August 05, 2024 at 10:55 AM > From: "Emanuel Berg" <incal@dataswamp.org> > To: emacs-devel@gnu.org > Subject: Re: Emacs website, Lisp, and other > > Jeremy Bryant wrote: > > > Lisp is the most powerful and elegant of programming > > languages. If you want to see how powerful and elegant > > a programming language can be, you need to learn Lisp. > > It will give you standard for measuring other languages. It all depends on the specific work one is doing. In some instances the indented style and excessive use of () makes working with lisp code harder than other languages. > Ah, I don't know, that kind of boasting. Powerful and elegant > are both immeasurable things, well, maybe in electrical > engineering one can measure it. > > > Calling Emacs Lisp "python-like" is derogatory to Emacs > > Lisp. Python has some of the characteristics that make Lisp > > superior, but not all of them. Many people are being forced to use Python especially in many university graduate schools. Lisp has always been a choice. I have no problem with Python. But many graduate schools whose main aim is getting as many graduates as they can and publishing as many papers as they can, have been using Python in ways intended to maximize task completion time, to the detriment of everything else. In other words, education for these graduants has educated them out of education. The best education one can get today is by self discovery. Schools are not the way. > Okay, then everyone should know this is a controversial thing > to say. No one, or very few, would recommend Emacs Lisp as an > alternative to Python 2024. There is nothing controversial, one simple has to see how things are in specific situations. > It will sounds like we are a bunch of fanatics boasting from > our own echo chamber were, inside it, we all are fantastic and > high on Lisp. > > Lisp's superiority is a myth. > > To me it is more like a drug :) The designers of Lisp had to deal with much more things. Hence its design has been very well thought out by extremely good designers. Today there are many programmers, but good system designers are rare despite the increase in systematic education strategies. > -- > underground experts united > https://dataswamp.org/~incal > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs website, Lisp, and other 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 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2024-08-05 12:28 UTC (permalink / raw) To: Christopher Dimech; +Cc: incal, emacs-devel > From: Christopher Dimech <dimech@gmx.com> > Cc: emacs-devel@gnu.org > Date: Mon, 5 Aug 2024 11:23:13 +0200 > > > > Calling Emacs Lisp "python-like" is derogatory to Emacs > > > Lisp. Python has some of the characteristics that make Lisp > > > superior, but not all of them. > > Many people are being forced to use Python especially in many university > graduate schools. Lisp has always been a choice. > > I have no problem with Python. But many graduate schools whose main aim is > getting as many graduates as they can and publishing as many papers as they > can, have been using Python in ways intended to maximize task completion time, > to the detriment of everything else. In other words, education for these > graduants has educated them out of education. The best education one can get > today is by self discovery. Schools are not the way. Please, everybody, take the Lisp vs Python argument off this list, it is off-topic here. If you must discuss this, please use the emacs-tangents@gnu.org mailing list instead. ^ permalink raw reply [flat|nested] 12+ messages in thread
* 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) 2024-08-05 12:28 ` Eli Zaretskii @ 2024-08-05 16:27 ` Emanuel Berg 2024-08-05 16:38 ` Eli Zaretskii ` (3 more replies) 0 siblings, 4 replies; 12+ messages in thread From: Emanuel Berg @ 2024-08-05 16:27 UTC (permalink / raw) To: emacs-devel Eli Zaretskii wrote: > Please, everybody, take the Lisp vs Python argument off this > list, it is off-topic here. If you must discuss this, please > use the emacs-tangents@gnu.org mailing list instead. Sure, but we are allowed to discuss how to make Elisp better? Since Python has had enormous success, and Lisp hasn't - or if it had, it lost it - it might be a good ide to analyze what they (Python) did good. You might think this is some bängalow discussion just because certain people are in it. But it doesn't have to be like that, it can be very hands-on. Ten things that are annoying with Emacs Lisp from the holster, and what to do about them: 10. Moving point around all the time. Whatever program, what you do is, it feels like, not solving your problem algorithmicly, you are just doing endless (goto (point-min)) (prong (end-of-paragraph) (current-column)) (pos-eol -1) (setq exists-after-point (unless (re-search-forward re nil t) (point))) Frustration: What has this to do with my problem and proposed solution? I understand Emacs grew around its function as a text editor, but "everything is in the buffer" and "the buffer is the data structure of Emacs", that has goon too far and we see a lot of code being virtually a very, very long traversal of buffers moving around point. So what ought to have been a tolerable exception, has become the norm and hailed model to the point, as I said earlier, interfaces toward programming are so weak it is considered normal that ispell can't even to (spell "word") without first outputting it somewhere and to the operation on that surface. Solution: MVC-ish separation of the interface, the computation, and the presentation of the result. To solve a problem, get the data into modern data structures with modern access methods, apply known algorithms by the book known specifically to help this problem rather than "Everything goes" Elisp hackin. (Yes you find that stuff in libraries, often. Apply on data in data structures, not on data as it appears in Emacs buffers.) But how ever well one does, it is gonna be _a lot_ of of moving point around in Emacs Lisp, so don't worry :) Example of problem from my favorite part of Emacs, ispell.el: (defun ispell-mime-multipartp (&optional limit) "Return multipart message start boundary or nil if none." ;; caller must ensure `case-fold-search' is set to t (and (re-search-forward "Content-Type: *multipart/\\([^ \t\n]*;[ \t]*[\n]?[ \t]*\\)+boundary=" limit t) (let (boundary) (if (looking-at "\"") (let (start) (forward-char) (setq start (point)) (while (not (looking-at "\"")) (forward-char 1)) (setq boundary (buffer-substring-no-properties start (point)))) (let ((start (point))) (while (looking-at "[-0-9a-zA-Z'()+_,./:=?]") (forward-char)) (setq boundary (buffer-substring-no-properties start (point))))) (if (< (length boundary) 1) (setq boundary nil) (concat "--" boundary))))) Moving point around, looking, searching, seeing or not seeing. This is boring and error prone to write, and error prone to take over from someone else, or return to after x years. You don't think in terms of the problem, or the solution for that matter, you are just somewhere in the buffer and according the the map you are completely lost! That is why I have, at place 10 annoying things about Elisp, excessive movement of point around the buffer, often involving manual retrieving and editing data from a buffer that, in execution, might not even look like what you thought it would, and that was 25 lines ago! Okay, I know - if only I could be passionate about it. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) 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 17:13 ` Yuri Khan ` (2 subsequent siblings) 3 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2024-08-05 16:38 UTC (permalink / raw) To: Emanuel Berg; +Cc: emacs-devel > From: Emanuel Berg <incal@dataswamp.org> > Date: Mon, 05 Aug 2024 18:27:35 +0200 > > Eli Zaretskii wrote: > > > Please, everybody, take the Lisp vs Python argument off this > > list, it is off-topic here. If you must discuss this, please > > use the emacs-tangents@gnu.org mailing list instead. > > Sure, but we are allowed to discuss how to make Elisp better? Yopu could try, although it is usually not a useful discussion. > Since Python has had enormous success, and Lisp hasn't - or if > it had, it lost it - it might be a good ide to analyze what > they (Python) did good. > > You might think this is some bängalow discussion just because > certain people are in it. But it doesn't have to be like > that, it can be very hands-on. > > Ten things that are annoying with Emacs Lisp from the holster, > and what to do about them: > > 10. Moving point around all the time. Whatever program, what > you do is, it feels like, not solving your problem > algorithmicly, you are just doing endless > > (goto (point-min)) > (prong (end-of-paragraph) (current-column)) > (pos-eol -1) > > (setq exists-after-point (unless (re-search-forward re nil t) (point))) > > Frustration: What has this to do with my problem and > proposed solution? I understand Emacs grew around its > function as a text editor, but "everything is in the > buffer" and "the buffer is the data structure of Emacs", > that has goon too far and we see a lot of code being > virtually a very, very long traversal of buffers moving > around point. So what ought to have been a tolerable > exception, has become the norm and hailed model to the > point, as I said earlier, interfaces toward programming > are so weak it is considered normal that ispell can't even > to (spell "word") without first outputting it somewhere > and to the operation on that surface. There's nothing more natural than an editor analyzing text in a buffer. Why it frustrates you is beyond me. Emacs Lisp is not a general-purpose programming language. It is a language for implementing Emacs and Emacs extensions. Thus, comparing it with Python is, in general, simply wrong. We can compare a few specific aspects, but not the languages as a whole, and definitely not their success rate: the scope of Emacs Lisp is limited to Emacs, which is orders of magnitude more narrow than the scope of Python (or any other general-purpose programming language). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) 2024-08-05 16:38 ` Eli Zaretskii @ 2024-08-05 17:03 ` Emanuel Berg 2024-08-05 18:58 ` Christopher Dimech 0 siblings, 1 reply; 12+ messages in thread From: Emanuel Berg @ 2024-08-05 17:03 UTC (permalink / raw) To: emacs-devel Eli Zaretskii wrote: > There's nothing more natural than an editor analyzing text > in a buffer. Why it frustrates you is beyond me. Sure, as is analyzing chemical substances in chemistry. And it is well known that instead of using machines and well-known methods from the outside to do the job, the chemists are swimming around in the substances mucking around with individual molecules giving explicit instructions what should happen for each case? Oh, no, all computing is the same, basically, we have of course specific problems and applications here, but instead of doing the old thing we should move up one level of abstraction and be there instead, and focus not on "getting the job done" but instead getting it done in a way that is much better than what we - to a large extent - have been doing so far. Everyone has a problem domain with specific characteristics that isn't the same as do stuff on the detail level, "everyone" doesn't do that if that is what you thought. > Emacs Lisp is not a general-purpose programming language. It doesn't matter what it is, it can be better, we should aim for that. > It is a language for implementing Emacs and Emacs > extensions. Thus, comparing it with Python is, in general, > simply wrong. Yes, Python is incomparable to Emacs Lisp and would probably win quite even against the collective Lisp world, I'm afraid. Lisp would probably loose to some other languages as well. > We can compare a few specific aspects, but not the languages > as a whole, and definitely not their success rate: the scope > of Emacs Lisp is limited to Emacs, which is orders of > magnitude more narrow than the scope of Python (or any other > general-purpose programming language). Emacs is the bastion of Lisp, if we care about Lisp we should do what we can to make Elisp more competitive altho we should focus on getting better, and not compare us to other languages as we are way too far behind in many areas, I'm afraid. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 12+ messages in thread
* 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) 2024-08-05 17:03 ` Emanuel Berg @ 2024-08-05 18:58 ` Christopher Dimech 0 siblings, 0 replies; 12+ messages in thread From: Christopher Dimech @ 2024-08-05 18:58 UTC (permalink / raw) To: Emanuel Berg; +Cc: emacs-devel > Sent: Tuesday, August 06, 2024 at 5:03 AM > 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) > > Eli Zaretskii wrote: > > > There's nothing more natural than an editor analyzing text > > in a buffer. Why it frustrates you is beyond me. > > Sure, as is analyzing chemical substances in chemistry. > > And it is well known that instead of using machines and > well-known methods from the outside to do the job, the > chemists are swimming around in the substances mucking around > with individual molecules giving explicit instructions what > should happen for each case? > > Oh, no, all computing is the same, basically, we have of > course specific problems and applications here, but instead of > doing the old thing we should move up one level of abstraction > and be there instead, and focus not on "getting the job done" > but instead getting it done in a way that is much better than > what we - to a large extent - have been doing so far. > > Everyone has a problem domain with specific characteristics > that isn't the same as do stuff on the detail level, > "everyone" doesn't do that if that is what you thought. > > > Emacs Lisp is not a general-purpose programming language. > > It doesn't matter what it is, it can be better, we should aim > for that. > > > It is a language for implementing Emacs and Emacs > > extensions. Thus, comparing it with Python is, in general, > > simply wrong. > > Yes, Python is incomparable to Emacs Lisp and would probably > win quite even against the collective Lisp world, I'm afraid. Python is not great. But people can believe what they want. Sometimes we discover unpleasant truths. Whenever we do so, we are in difficulties: suppressing them is scientifically dishonest, so we must tell them, but telling them, however, will fire back on us. If the truths are sufficiently impalatable, our audience is psychically incapable of accepting them and we will be written off as totally unrealistic, hopelessly idealistic, dangerously revolutionary, foolishly gullible or what have you. Most Computer Science Departments have opted for the easy way out, to pretend that problems do not exist. Programming is one of the most difficult branches of applied mathematics; most mathematicians should better remain pure mathematicians. It is practically impossible to teach good programming to students that have had a prior exposure to Python, as potential programmers they are mentally mutilated beyond hope of regeneration. In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to Python, so that they can share each other's programs, bugs included. > Lisp would probably loose to some other languages as well. > > > We can compare a few specific aspects, but not the languages > > as a whole, and definitely not their success rate: the scope > > of Emacs Lisp is limited to Emacs, which is orders of > > magnitude more narrow than the scope of Python (or any other > > general-purpose programming language). > > Emacs is the bastion of Lisp, if we care about Lisp we should > do what we can to make Elisp more competitive altho we should > focus on getting better, and not compare us to other languages > as we are way too far behind in many areas, I'm afraid. > > -- > underground experts united > https://dataswamp.org/~incal > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) 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:13 ` Yuri Khan 2024-08-06 6:39 ` Emanuel Berg 2024-08-06 11:16 ` Richard Stallman 3 siblings, 0 replies; 12+ messages in thread From: Yuri Khan @ 2024-08-05 17:13 UTC (permalink / raw) To: emacs-devel On Mon, 5 Aug 2024 at 23:31, Emanuel Berg <incal@dataswamp.org> wrote: > 10. Moving point around all the time.[…] > > Frustration: What has this to do with my problem and > proposed solution? I understand Emacs grew around its > function as a text editor, but "everything is in the > buffer" and "the buffer is the data structure of Emacs", > that has goon too far and we see a lot of code being > virtually a very, very long traversal of buffers moving > around point. In a differently designed API, you[^*] would have iterators into buffers. And you would want from an iterator everything that is available from the point, just that there could be many of them simultaneously and that they wouldn’t affect the real user’s point. And you would want iterators to be visible in the buffer text when debugging. In Elisp, you have save-excursion which protects the user’s point, and markers which provide multiplicity. [^*]: I. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) 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:13 ` Yuri Khan @ 2024-08-06 6:39 ` Emanuel Berg 2024-08-06 11:16 ` Richard Stallman 3 siblings, 0 replies; 12+ messages in thread From: Emanuel Berg @ 2024-08-06 6:39 UTC (permalink / raw) To: emacs-devel > 10. Moving point around all the time. Whatever program, what > you do is, it feels like, not solving your problem > algorithmicly, you are just doing endless > > (goto (point-min)) > (progn (end-of-paragraph) (current-column)) > (pos-eol -1) It isn't even "end-of-paragraph", is is `end-of-paragraph-text'. This brings up another interesting aspect, namely if moving point around in a future buffer - if that is our whole business model and everyone tries really hard to convince themself it is what everybody does - which is completely wrong by the way - then answer me, how is is that we have so poor tools to do it? Just look above. There isn't even a way to go to the beginning of the buffer without combining not "goto" (should be `goto-char' of course) with `point-min'. `pos-eol' is the only one to my liking of those I just mentioned as they came up, then. It does say `current-column' but it doesn't matter because (end-of-paragraph-text) doesn't return point. Such, and many, many other examples are why Elisp is filled with constructs such as ( save-mark-and-excursion ( progn ( move the point somewhere ) (point) ) If anyone really believed in that idea, all such cases would have been streamlined into single functions ages ago instead of having programmers put together those meaningless towers all the time just to retrieve information from what is supposed to be one of our native methods to do just that. I can complete the list (9 more) but I don't know, maybe leave the whole thing at that? I don't want to be too negative. But the endless moving around point in a future buffer one envision while typing code - yeah, it is a crazy idea -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) 2024-08-05 16:27 ` 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) Emanuel Berg ` (2 preceding siblings ...) 2024-08-06 6:39 ` Emanuel Berg @ 2024-08-06 11:16 ` Richard Stallman 2024-08-06 22:08 ` Emanuel Berg 3 siblings, 1 reply; 12+ messages in thread From: Richard Stallman @ 2024-08-06 11:16 UTC (permalink / raw) To: Emanuel Berg; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Solution: MVC-ish separation of the interface, the > computation, and the presentation of the result. To solve > a problem, get the data into modern data structures with > modern access methods, apply known algorithms by the book > known specifically to help this problem rather than That is very abstract and does not propose any change concretely enough that we could consider it. I am guessing that "MVC" refers to some Microsoft editor. Please don't expect us to have seen it. Emacs is older than Windows. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) 2024-08-06 11:16 ` Richard Stallman @ 2024-08-06 22:08 ` Emanuel Berg 0 siblings, 0 replies; 12+ messages in thread From: Emanuel Berg @ 2024-08-06 22:08 UTC (permalink / raw) To: emacs-devel Richard Stallman wrote: >> Solution: MVC-ish separation of the interface, the >> computation, and the presentation of the result. To solve >> a problem, get the data into modern data structures with >> modern access methods, apply known algorithms by the book >> known specifically to help this problem rather than > > That is very abstract and does not propose any change > concretely enough that we could consider it. MVC is a term from CS theory, it means "Model View Control" and you can summarize it just by saying that data, data processing, and the interface, those should be kept apart. We have an interesting situation where the processing of data with Elisp is often done directly in the buffer, i.e. _in_ that same data! This is why Elisp code often gets completely littered with commands that move point back and forth, that extracts data, modifies data, inserts it back again, and so on. What we should do - well, (1) one should be aware of it and that it is a problem. So for example, instead of sorting a region in the buffer, one should ask - what does that region represent? what outputted it? - and then modify that function, for example to make it accept an optional alternative sorter or whatever. And (2), since it is gonna be like this anyway to a huge extent, to not have Elisp code being completely overrun by such stuff, we can provide a much neater, more consistent such set of functions. So this is bad (save-mark-and-excursion (progn (forward-paragraph -2) (point))) This OTOH is much better (pos-bol &optional N) (pos-eol &optional N) So for every unit, we should have pos-unit, pos-unit-beg, pos-unit-end, and pos-unit-reg (pos-unit should probably be the same as pos-unit-beg rather than pos-unit-reg for practical reasons). -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2024-08-07 11:26 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [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 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
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).