From: Alexandre Garreau <galex-713@galex-713.eu>
To: emacs-devel@gnu.org
Cc: tomas@tuxteam.de, Arthur Miller <arthur.miller@live.com>
Subject: Re: GUI and redisplay work
Date: Fri, 29 Oct 2021 21:29:43 +0200 [thread overview]
Message-ID: <14226483.5uGeTH8QoZ@galex-713.eu> (raw)
In-Reply-To: <AM9PR09MB4977C6613CA0558B6438010696879@AM9PR09MB4977.eurprd09.prod.outlook.com>
Le vendredi 29 octobre 2021, 19:34:14 CEST Arthur Miller a écrit :
> Alexandre Garreau <galex-713@galex-713.eu> writes:
> > Le mercredi 27 octobre 2021, 19:12:36 CEST tomas@tuxteam.de a écrit :
> >> On Wed, Oct 27, 2021 at 06:07:53PM +0200, Alexandre Garreau wrote:
> >>
> >> [...]
> >>
> >> > All current Web engines derive from KHTML and Gecko, which are very
> >> > old… wouldn’t the web engines in 2050 still derive from them, given
> >> > their age?
> >> >
> >> > On the other hand, TeX has now’ve been around for half a century,
> >> > as
> >> > long as emacs, and longer than the gnu (and nowadays main or even
> >> > only seriously used) implementation of emacs [...]
> >>
> >> Before you start re-inventing the world, if I were you, I'd have a
> >> look at what is "out there" already. Perhaps to contribute to it,
> >> perhaps to copy it, but just perhaps to learn from it on how to
> >>
> >> do (or not to do) things:
> >> https://en.wikipedia.org/wiki/GNU_TeXmacs
> >> http://texmacs.org/tmweb/home/welcome.en.html
> >>
> >> I think Joris and the other (many!) contributors could share quite
> >> a few stories...
> >
> > I know TeXmacs and since it initially enthusiastmed me a lot (iirc I
> > even talked a bit with its author during a GHM a decade ago), I
> > several times tried to use it but unfortunately my computer is too
> > slow to run it fluently, so I gave up trying.
> >
> > Moreover while WYSIWYM looked like a good idea orally, using TeXmacs
> > was at the same time more confusing than standard markup, and WYSIWYG
> > (although I typically use WYSIWYG only in a very very limited way),
> > so maybe the idea is just too innovative to be easy to grasp from a
> > single software that’s rarely used (I rarely typeset documents
> > actually, especially to print anything, and I prefer to take notes in
> > text editors because I don’t get margins nor slowness, I just compile
> > them once when I export my exams to pdf).
> >
> > Also looks like it’s only a text processor with it own format, and not
> > a general purpose editor, that could edit, say, HTML or TeX, or, most
> > importantly, its own config files, so it’s nor really like emacs, nor
> > TeX :/
> >
> > And although it looks as good as TeX typographically, it’s younger and
> > could be less stable, but I’m sure there could be good ideas and
> > experiment here… I just already don’t have the time and attention
> > capability to work on emacs as much as I’d like (so I still haven’t
> > contributed anything), and TeXmacs would be lower priority for me.
> >
> > Also I’d like first and foremost to read and understand all TeX’s and
> > Metafont’s source (especially as it’s heavily documented in its own
> > favored way and made to be read that way), and understand how does GTK
> > works, before to try to understand some software that uses the later
> > to
> > incompatibly mimmick the first. I still haven’t done that. And I
> > should reread the TeXbook, but doing the exercises and reading the
> > source at same time.
>
> Have you checked out Nyxt browser?
>
> https://nyxt.atlas.engineer/
>
> CL + another widget derived from khtml ...
>
> I am quite sure someone could develop a text editor based on "web
> technologies" or just in pure CL that works in Nyxt.
That’s very very interesting, and it pretty much looks like what I always
imagined when I imagined a web engine inside emacs… at least the minimal
part of it. In the bigger pictures, it *oughts* to integrate with
javascript, give access to its DOM API to lisp, allow finegrained control
of scripts (like NoScript but more developed, like including information
about network/inter-site communication, which APIs are enabled, allowing
to let APIs to *lie* to the remote program, and, most importantly,
reacting to licenses and source informations, just as LibreJS, but more
developed (for instance involving the ability to detect obfuscation, to
archive executed programs, share them (if the program *really* is free
that’s anyway legal however you do it), rate them (the most readable
(hence the most likely free (because how are you gonna know an unreadable
software is purposedly so or the dev’s just terrible?))/trustable, the
least malware, the best)), support WebExtensions, including ones involving
other languages (not only lisp, but also scheme, for instance (such as
what would have been possible with guile)), or even native/compiled ones.
Talking about CL, that makes me also think that there’s maybe a great deal
of loss by letting the web engine being written in C, while cl could
nowadays, with proper typing, be just as fast, yet with the ability to be
compiled at will. Along with partial evaluation, that allows a great deal
of optimization and performance gain with web, as long as you visit again
a non-totally-changing page, and don’t execute a different script at each
run (which, btw, completely *disable* any benefit of free software). Maybe
even up to the point where a web app could be just as fast as a native
toolkit (modulo any non-clearly-forseen shortcoming of lisp).
Another issue with CL (and scheme too, and that’s a common obstacle found
in TeXmacs as well), and combined with the fact it’s apparently still not
packaged into debian, discourages me to try (to seriously switch to it) is
that to customize and extend it, I would have to learn a whole new system
than emacs’ one, which already has a great deal of complexity (I could say
richness, because that complexity looks useful and justified to me), and
even is improvable (as no more than recently here have been discussed the
ability to add more metadata to packages, and in not-so-far past the one
to natively compile elisp). Again, guile would have been made for that,
if only it successfully merged with emacs.
The final problem
next prev parent reply other threads:[~2021-10-29 19:29 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-20 2:00 SVG widget in GNU Emacs Anand Tamariya
2021-10-20 3:15 ` Po Lu
2021-10-20 12:09 ` Eli Zaretskii
2021-10-20 12:48 ` Po Lu
2021-10-20 13:08 ` Eli Zaretskii
2021-10-20 13:17 ` Po Lu
2021-10-20 14:13 ` Eli Zaretskii
2021-10-26 6:32 ` Akira Kyle
2021-10-26 12:32 ` GUI and redisplay work (was: SVG widget in GNU Emacs) Stefan Monnier
2021-10-26 12:51 ` Stefan Kangas
2021-10-26 13:23 ` Eli Zaretskii
2021-10-26 13:19 ` Eli Zaretskii
2021-10-27 16:07 ` Alexandre Garreau
2021-10-27 17:12 ` tomas
2021-10-27 19:00 ` Alexandre Garreau
2021-10-29 17:34 ` GUI and redisplay work Arthur Miller
2021-10-29 19:29 ` Alexandre Garreau [this message]
2021-10-29 20:05 ` Alexandre Garreau
2021-10-27 9:47 ` SVG widget in GNU Emacs Po Lu
2021-10-27 12:10 ` Eli Zaretskii
2021-10-27 12:25 ` Po Lu
2021-10-27 20:01 ` Akira Kyle
2021-10-28 1:21 ` Po Lu
2021-10-28 13:50 ` Fix flickering on X11 xwidgets (was: Re: SVG widget in GNU Emacs) Po Lu
2021-10-27 19:49 ` SVG widget in GNU Emacs Akira Kyle
2021-10-28 1:15 ` Po Lu
2021-10-28 6:15 ` Eli Zaretskii
2021-10-28 9:39 ` Po Lu
2021-10-20 22:35 ` Richard Stallman
2021-10-20 23:37 ` dalanicolai
2021-10-21 0:31 ` dalanicolai
2021-10-21 0:07 ` Po Lu
2021-10-20 8:15 ` Lars Ingebrigtsen
2021-10-20 9:13 ` Anand Tamariya
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14226483.5uGeTH8QoZ@galex-713.eu \
--to=galex-713@galex-713.eu \
--cc=arthur.miller@live.com \
--cc=emacs-devel@gnu.org \
--cc=tomas@tuxteam.de \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.