From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets) Date: Fri, 27 Nov 2020 22:01:03 +0200 Message-ID: <83h7pao9hc.fsf@gnu.org> References: <864kmzupp0.fsf@akirakyle.com> <86pn46awrr.fsf@akirakyle.com> <87y2ise7j5.fsf@gnus.org> <87lferb7co.fsf@gnus.org> <20201126082711.GA12134@tuxteam.de> <87im9s3pdh.fsf@logand.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37935"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, tom@logand.com, emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 27 21:02:38 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 1kijwy-0009l7-Mu for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 21:02:36 +0100 Original-Received: from localhost ([::1]:57392 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kijwx-0000mp-N0 for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 15:02:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58640) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kijvt-0008Q1-Gn for emacs-devel@gnu.org; Fri, 27 Nov 2020 15:01:30 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58212) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kijvs-0004cP-14; Fri, 27 Nov 2020 15:01:28 -0500 Original-Received: from [176.228.60.248] (port=2119 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kijvk-0000Ce-4h; Fri, 27 Nov 2020 15:01:20 -0500 In-Reply-To: (message from Arthur Miller on Fri, 27 Nov 2020 20:22:42 +0100) 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:259919 Archived-At: > From: Arthur Miller > Date: Fri, 27 Nov 2020 20:22:42 +0100 > Cc: tom@logand.com, emacs-devel@gnu.org > > To my knowledge, mpv is probably the neetiest one to bring in media > playing capabilities; it has lots of codecs, is written to be embedded, > is free and would make Emacs be able to play music and video files > without external players. Adding multimedia capabilities opens up for > lots of flexibility and creativity; people can maybe do interesting > stuff with it. I would certainly like Emacs to become a multimedia > player, I play my music with Emacs already :-). > > If other people think it is too expensive in terms of implementation > cost and what it offers, and if multimedia is not desirable in Emacs, I > can have understanding with that. I might not agree, but my opinion is > just one persons opinion, and I am not even an Emacs developer, so of > course, you who make Emacs work probably know better and have precedence > in what Emacs should do/have or not. It would be wrong to claim anything > else :). Expensive or not, talking about mpv as providing video playing facilities for Emacs is makes little sense as long as the issue of embedding video in a window that shows an Emacs buffer is not resolved. As the xwidgets experiment suggests, the problem to solve here is not a trivial one. Until someone comes up with some clever idea for how to do that, let alone submits patches for that, the issue of which library to use is not really relevant to Emacs development. If someone wants a flexible way of playing video under Emacs control, I think a more practically useful way at this time is to provide a feature that runs VLC or a similar player program as an Emacs subprocess, and controls that player via Emacs commands. That could need extending the players themselves, if their command-line arguments aren't flexible enough and there's no other API that Emacs could use.