From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aiko Kyle Newsgroups: gmane.emacs.devel Subject: Re: Rethinking the design of xwidgets Date: Tue, 13 Oct 2020 15:20:23 -0600 Message-ID: <86h7qxu8ko.fsf@gmail.com> References: <864kmzupp0.fsf@akirakyle.com> <835z7e2ouj.fsf@gnu.org> <86v9fet5sg.fsf@akirakyle.com> <87o8l6geh1.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28333"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.13; emacs 28.0.50 Cc: emacs-devel@gnu.org To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 13 23:33:43 2020 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 1kSRvS-0007Gh-Vt for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 23:33:42 +0200 Original-Received: from localhost ([::1]:47792 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSRvS-0003Rl-2t for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 17:33:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40546) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSRie-00078S-5a for emacs-devel@gnu.org; Tue, 13 Oct 2020 17:20:28 -0400 Original-Received: from mail-il1-x132.google.com ([2607:f8b0:4864:20::132]:38441) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kSRic-0006vA-F3 for emacs-devel@gnu.org; Tue, 13 Oct 2020 17:20:27 -0400 Original-Received: by mail-il1-x132.google.com with SMTP id p16so2403859ilq.5 for ; Tue, 13 Oct 2020 14:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=rdDsv/gIHavA8meCoFLuzwNRQmnzaTIOjooNlvqz2mo=; b=ZRVOJngyKEHTRriWSLCuL/vUe3twjD+ogiGOwpa3GyDhuCmKf6ewsf0AuGGn3mvpkd O28f7hWnRgU1qapGQJwN3HdFc5QZp/P4bwtbffU1rFJ7nt/oBfAFG1osLzZwatqpOvPf K2HAyF4U4O6JCJBP3xeUrBGGOhoXClL4eh3mT8Zq48MfVrrcq5Jg8/3aO2r+KYaEBs2O NyMIAd0ZttB8B01My/uSo9PEbrCAZTUQPhSzfaw/XKe7G1AtVVIU6GqHBeXXiefG9arI IVsywZYltPhX6dkzbP7+9KlxnEiMd24cUq3Uefw3nBMjg6UlVnI8dNOPQVDcq/Lqsnum iiIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=rdDsv/gIHavA8meCoFLuzwNRQmnzaTIOjooNlvqz2mo=; b=lYKcIJlx4E9pNHLQ94vLB1MdZ3JWW/wFb9zVvYLcc8ou4TnM01mBF0ABFXcby6qQv7 zVmKSlok8U2KAhmEhymwd3FYkOjqPbW7CCbMB2vidFcBTbnR+/zpCMC5d9i3Axatccza zjqCTbfcl4OO2Ihr72Cv4SdrIoQlVa7ufwAY/GPhkLPOZvjLYF97gxCe3tGmSBIKaqMB ULtN43HcCoj1VjPBpremY3ntzbXGClLLfiOadSA9k8Y9NzcqKqST6VxKGzIJ+5hSBLFK Owq5cMVOydDpFdoG12up3Dk9QFGP/tibEOO1fghYqt/4tclbUf9GrXO3AzpNqlLjfjL+ pzew== X-Gm-Message-State: AOAM5339PLo2hwRD1YlqgNzGjOXFd257OaFUNA8l2w+eNTIWXCnVSafC P/T7l8QvpbmFKv4RV8TtJXmaksgOOo0Bp4vs X-Google-Smtp-Source: ABdhPJxqy3x+dFgl1yr0u+yhV+F89cWBXzGTydHKRsOj64B8y4E6XbQ1JRWwGDJqLWp/1Dyxol08eg== X-Received: by 2002:a05:6e02:785:: with SMTP id q5mr1514587ils.43.1602624025121; Tue, 13 Oct 2020 14:20:25 -0700 (PDT) Original-Received: from lore ([2601:281:8080:45f0:31b3:d856:a75f:645]) by smtp.gmail.com with ESMTPSA id s23sm957074iol.23.2020.10.13.14.20.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Oct 2020 14:20:24 -0700 (PDT) In-reply-to: <87o8l6geh1.fsf@logand.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::132; envelope-from=aikokyle@gmail.com; helo=mail-il1-x132.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 13 Oct 2020 17:32:06 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:257594 Archived-At: On Tue, Oct 13, 2020 at 12:36 PM, Tomas Hlavaty wrote: > some kind of canvas was discussed in > id:87zh9hrxfj.fsf@logand.c > and > id:83img4aegz.fsf@gnu.org > > It was discussed in context of a WYSIWYG editor features, and > console > based pdf viewer emacs-frabuffer and pure elisp pdf generator > emacs-pdf. > > Eli suggested: > > > If you want to do layout for PDF, I think one way forward > > would be > > to implement a pdfterm.c "terminal" for Emacs, which > > produces PDF > > like the existing *term.c backends do for supported display > > types. > > that might be better than some kind of xwidget I don't immediately see the connection of this proposal to mine. It seems like pdfterm would be a display backend like xterm that renders to PDF, however this is already possible using the x-export-frames command which uses cairo to render the emacs frame to. It seems like the hard part of making Emacs a WYSIWG editor isn't the rendering of the display to pdf, but rather all the features of a WISYWIG editor such as placement of arbitrary text boxes on screen. > It is not clear to me, why a dynamic module would be better. > > For example, emacs-framebuffer can display svg images without > any > dynamic module by using external program, because emacs-nox does > not > have cairo or librsvg or NS toolkit. > > Ideally, there would be a canvas (e.g. pdfterm) providing > low-level > drawing primitives (something like html canvas API) and the rest > built > on top of that in elisp. I wasn't previously aware of emacs-framebuffer. It's an interesting idea but I don't think it's very relevant to my goal. It doesn't appear that Emacs is very "aware" of the image with emacs-framebuffer. In otherwords the image won't move inline with the rest of buffer contents will it? The line that the image is on won't have the height of the image?