From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?U8O4cmVuIFBpbGfDpXJk?= Newsgroups: gmane.emacs.devel Subject: Re: Musings on creating an HTML-based WYSIWYG mode Date: Tue, 1 May 2018 21:00:09 +0200 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000058266b056b299438" X-Trace: blaine.gmane.org 1525201144 28584 195.159.176.226 (1 May 2018 18:59:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 May 2018 18:59:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 01 20:59:00 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fDaUO-0007I8-5o for ged-emacs-devel@m.gmane.org; Tue, 01 May 2018 20:59:00 +0200 Original-Received: from localhost ([::1]:45708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDaWT-0006Fz-HN for ged-emacs-devel@m.gmane.org; Tue, 01 May 2018 15:01:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDaVd-0006FR-Ha for emacs-devel@gnu.org; Tue, 01 May 2018 15:00:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fDaVY-0002yz-9h for emacs-devel@gnu.org; Tue, 01 May 2018 15:00:17 -0400 Original-Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:36528) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fDaVX-0002y1-Vs for emacs-devel@gnu.org; Tue, 01 May 2018 15:00:12 -0400 Original-Received: by mail-wm0-x22d.google.com with SMTP id n10so20345169wmc.1 for ; Tue, 01 May 2018 12:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gbWq0arEoMvmct7ALl/+QvxzyGqid3p5iqugR9SlTww=; b=nvZu/bUxh2KtVENjTSAklizcU7eGVGOXL8Xo1hXjFVbLoKnPW80g2R6KW4ZL1LpMKh qh2nmQ5TmZKmMT7rt07R/Pi2apPW88hQELcTduxJuB6ibXK1WLCDpgTG30Y1x/n6Vq9z CJfGcSjWwSUk4+vRDI8BnfptFFaMVmemdpRuzlj6tesWAQGUf8NJ3X0asqsSOCuwDkFD lYaj5uj9GBV9iawtnN2ShbZebk8yGU0HJIvoVdCXPIQGuaGokLaE8UUGUwlzXWWBJQ+f rlQ8jFoWPl7An34xy+wEE6R3PmaalfRV+X/7eCtLqUfvoVIacXgiRNVGc199HUP+M5Dn EoVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gbWq0arEoMvmct7ALl/+QvxzyGqid3p5iqugR9SlTww=; b=T4vtG37epBezA+TVYKyurjdSkGHX99bts/gksFdzJRT4wa+iudC1skc4y618TIqjHI gXcREBL8BjRxVUVEfEcJM2ZYIV1fUj90nV0W+x//BK3AhL8pFzudb4G16W5cVwcc/lJq vjsYgwt0pvxYo2naTx9Zdll+N0Knd0xjG0dOaR6SJIBcrMshcffqOvBc5EnQkqhI93YY VIMdgDym+rMYZ8Q/X0VRktHoS8Z7QLo2X72A3l7FoJRHDumsBpDnFXp21xtofqO5ufei +kAbjW+PANXPq2/YTEVMCMvqVOBTIUVZm36Y8lV3HHJNzYn226LfqnAoZyHL2MSHMXYn fhHQ== X-Gm-Message-State: ALQs6tDzu78MRGAZYsDi+pPjZrvBcbojvyG1flRw6jc2rCZZ8wdpYidp oplcdISuOX1i4aIzeRbv3fMYF9mrtrwZkAGm2K8= X-Google-Smtp-Source: AB8JxZqsiH9rVwg4Hgex4H7yFSus21hIbRt+6S30+8DQlbU5ta7shdJzNqPfZr2xEnNIB+busTHBO8p+Acv/q8ZzVHo= X-Received: by 2002:a50:f559:: with SMTP id w25-v6mr22968278edm.230.1525201210187; Tue, 01 May 2018 12:00:10 -0700 (PDT) Original-Received: by 10.167.213.195 with HTTP; Tue, 1 May 2018 12:00:09 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:225015 Archived-At: --00000000000058266b056b299438 Content-Type: text/plain; charset="UTF-8" On Tue, May 1, 2018 at 4:54 PM, Lars Ingebrigtsen wrote: > I'm not going to implement this any time soon, but I wondering how much > work it would be to create a WYSIWYG mode for Emacs based on > round-tripping through shr. > > I think most people who have approached this subject before have said > "just use some text properties and store as enriched text and there you > go", but it's just not sufficient: If you're writing a
    list, then > you want this to be rendered as it should be, and it should be rendered > as the recipient is likely to read the text. Otherwise it's not very > WYSIWYG, is it? > > So: The serialisation format would be HTML. Whenever a user types > something, Emacs generates HTML, asks shr to render it, and then present > the user with the results. This would, of course, potentially be > horrifically slow, but we could envision strategies to only re-render > parts of the buffer/document. > > Let's say the user is typing away at something resembling this > paragraph, and then decides to make "typing" bold, so the user would go > back to that work, mark it and issue whatever command there is for "make > this bold". The mode would do the change to the HTML document, ask shr > to re-render it, and then display the results. > > This is, of course, not like what Emacs does normally when editing text, > and would break a lot of invariants that people are used to. We can > preserve basic things like point and mark easily enough (by inserting > special constructs into the HTML that allows us to find and restore them > after re-generating the buffer), but I'm sure there's oodles of stuff > that will stop working with such a radical approach. But perhaps that's > OK? > > Inserting images and the like into the buffer would be unproblematic -- > just add a few new dired commands like "copy image to WYSIWYG clipboard" > and then yank from that "clipboard" into the buffer. This presents > further interesting questions about the serialisation format... but we > could, for instance, use MIME for that: multipart/related with the > images stashed as cid: links. > > "External" images are simpler, of course. > > The WYSIWYG clipboard would also be necessary for when cutting and > yanking text: If you're killing text starting from the middle of a link > and ending up in the middle of an
      link, you have to ensure that you > end up with something similar when you yank this mess somewhere else. > And you have to ensure that everything remains valid around where you > killed the region, too. > > And then there's always the interesting subject of tables, or rather: > Side-by-side continuous regions. Making editing commands work in those > circumstances may be, er, interesting... > > So here's what I think: I think somebody (i.e., me) should try > implementing this. I think there are so many unknowns here that it's > difficult to say whether this is a workable way of doing WYSIWYG in > Emacs before you have something semi-working and get a grip on how this > would feel in practice. > > But like I said, I don't have time at the moment. :-) > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > > > > The question is if it is worth the effort? To me the greatest benefit of a WYSIWYG editor would be if I could edit in the "finished" website eg. sort of like editing the elements in the developer tools of chrome/firefox. That means CSS has to be supported, and potentially also javascript. If a website is only HTML it is easy enough for me to visualize how it is going to look. Besides HTML rarely stands alone now a day, it is most likely consumed by some tool and or combined with CSS (or something compiled to CSS) and javascript (or something compiled to javascript). And in a lot of cases i do not edit actual HTML but some templating system complicating the issue even further. I personally think something like skewer where a browser is updated to reflect the current state is a lot more useful, though I havent found a way to make it work fluidly when doing more complex backends. Building a WYSIWYG editor in Emacs sounds like a complicated affair and I am not sure it is really worth it as editing plain standalone HTML is becoming a niche thing. It could be useful for HTML emails though! --00000000000058266b056b299438 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


      On Tue, May 1, 2018 at 4:54 PM, Lars Ingebrigtsen <= ;larsi@gnus.org>= wrote:
      I'm not going to imple= ment this any time soon, but I wondering how much
      work it would be to create a WYSIWYG mode for Emacs based on
      round-tripping through shr.

      I think most people who have approached this subject before have said
      "just use some text properties and store as enriched text and there yo= u
      go", but it's just not sufficient: If you're writing a <ol&= gt; list, then
      you want this to be rendered as it should be, and it should be rendered
      as the recipient is likely to read the text.=C2=A0 Otherwise it's not v= ery
      WYSIWYG, is it?

      So: The serialisation format would be HTML.=C2=A0 Whenever a user types
      something, Emacs generates HTML, asks shr to render it, and then present the user with the results.=C2=A0 This would, of course, potentially be
      horrifically slow, but we could envision strategies to only re-render
      parts of the buffer/document.

      Let's say the user is typing away at something resembling this
      paragraph, and then decides to make "typing" bold, so the user wo= uld go
      back to that work, mark it and issue whatever command there is for "ma= ke
      this bold".=C2=A0 The mode would do the change to the HTML document, a= sk shr
      to re-render it, and then display the results.

      This is, of course, not like what Emacs does normally when editing text, and would break a lot of invariants that people are used to.=C2=A0 We can preserve basic things like point and mark easily enough (by inserting
      special constructs into the HTML that allows us to find and restore them after re-generating the buffer), but I'm sure there's oodles of stu= ff
      that will stop working with such a radical approach.=C2=A0 But perhaps that= 's
      OK?

      Inserting images and the like into the buffer would be unproblematic --
      just add a few new dired commands like "copy image to WYSIWYG clipboar= d"
      and then yank from that "clipboard" into the buffer.=C2=A0 This p= resents
      further interesting questions about the serialisation format...=C2=A0 but w= e
      could, for instance, use MIME for that: multipart/related with the
      images stashed as cid: links.

      "External" images are simpler, of course.

      The WYSIWYG clipboard would also be necessary for when cutting and
      yanking text: If you're killing text starting from the middle of a link=
      and ending up in the middle of an <ol> link, you have to ensure that = you
      end up with something similar when you yank this mess somewhere else.
      And you have to ensure that everything remains valid around where you
      killed the region, too.

      And then there's always the interesting subject of tables, or rather: Side-by-side continuous regions.=C2=A0 Making editing commands work in thos= e
      circumstances may be, er, interesting...

      So here's what I think: I think somebody (i.e., me) should try
      implementing this.=C2=A0 I think there are so many unknowns here that it= 9;s
      difficult to say whether this is a workable way of doing WYSIWYG in
      Emacs before you have something semi-working and get a grip on how this
      would feel in practice.=C2=A0

      But like I said, I don't have time at the moment.=C2=A0 :-)

      --
      (domestic pets only, the antidote for overdose, milk.)
      =C2=A0 =C2=A0bloggy blog: http://lars.ingebrigtsen.no




      The q= uestion is if it is worth the effort?
      To me= the greatest benefit of a WYSIWYG editor would be if I could edit in the &= quot;finished" website eg. sort of like editing the elements in the de= veloper tools of=C2=A0 chrome/firefox. That means CSS has to be supported, = and potentially also javascript. If a website is only HTML it is easy enoug= h for me to visualize how it is going to look. Besides HTML rarely stands a= lone now a day, it is most likely consumed by some tool and or combined wit= h CSS (or something compiled to CSS) and javascript (or something compiled = to javascript). And in a lot of cases i do not edit actual HTML but some te= mplating system complicating the issue even further.

      I personally think something= like skewer where a browser is updated to reflect the current state is a l= ot more useful, though I havent found a way to make it work fluidly when do= ing more complex backends.

      Building a WYSIWYG editor in Emacs sounds like a compl= icated affair and I am not sure it is really worth it as editing plain stan= dalone HTML is becoming a niche thing. It could be useful for HTML emails t= hough!
      --00000000000058266b056b299438--