From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.help Subject: Re: make a drawing with Emacs Date: Thu, 03 Sep 2020 17:21:20 +0200 Message-ID: <874koehonj.fsf@logand.com> References: <20200901145854.GF15433@tuxteam.de> <87sgbzsx4q.fsf@logand.com> <87ft7zs48u.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24876"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 03 17:21:54 2020 Return-path: Envelope-to: geh-help-gnu-emacs@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 1kDr3h-0006K8-HJ for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 03 Sep 2020 17:21:53 +0200 Original-Received: from localhost ([::1]:36984 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kDr3g-0007jS-Je for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 03 Sep 2020 11:21:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48748) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kDr3H-0007jE-JW for help-gnu-emacs@gnu.org; Thu, 03 Sep 2020 11:21:27 -0400 Original-Received: from logand.com ([37.48.87.44]:57850) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kDr3F-0007qT-JE for help-gnu-emacs@gnu.org; Thu, 03 Sep 2020 11:21:27 -0400 Original-Received: by logand.com (Postfix, from userid 1001) id C6F811A4B11; Thu, 3 Sep 2020 17:21:22 +0200 (CEST) X-Mailer: emacs 26.3 (via feedmail 11-beta-1 I) In-Reply-To: Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/03 11:21:23 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:123928 Archived-At: On Thu 03 Sep 2020 at 09:38, Stefan Monnier wrote: >> 1) It is not clear upfront, when it does not work, as demonstrated with >> svg-image vs svg-print. >> This is general problem with foreign dependencies. > > I believe svg-image is the only exception and it's an intuitive one at > that Sorry it wasn't intuitive to me as I don't know emacs internals (yet?). > since it is used to create an internal Emacs image object whose only > use is to display the image inside an Emacs buffer. There seem to be other uses as well, e.g. to save the image (image-save function). Maybe other uses like create a screenshot? image.el also has some questionable constraints. For example: - Can an image have pages? - What about tiff images? - Why is pdf not an image? - Can I implement new or redefine old image format in pure Elisp? How? Many modes depend on image.el which is hard to plug into when the foreign libraries are not there. That is why I have to reimplement more than I like in emacs-framebuffer.el. And probably the reason why there are more than one pdf viewers. >> 2) Elisp does not have keyword arguments. However, svg.el works around >> that with rest arg plist. This brings the worst of both worlds: >> complexity and useless tools. >> >> For example, I use eldoc. Eldoc hint for svg-circle is useless: >> >> svg-circle: (SVG X Y RADIUS &rest ARGS) >> >> I have to dig into the source code to find out what ARGS is. Every >> time I use svg-circle. >> >> Writing own alternative to svg.el offers a chance to fix those problems. > > Or maybe you can improve the package instead of writing a new one. > Code is sometimes called "software" because presumably it's more > malleable than "hardware". Maybe. svg.el seems to be 4 years old and likely has many users already. The fake keyword args as rest args plist was a bad choice 4 years ago which will be hard to fix. What would be the right way to do this if not writing svg2.el? Perhaps to implement proper keyword support in Elisp?