From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: pinmacs Newsgroups: gmane.emacs.devel Subject: Re: yank-media: allow users to limit image types that can be inserted Date: Thu, 31 Oct 2024 11:47:42 +0100 Message-ID: <358410b5-29c3-4c75-a63c-68edd123fad8@cas.cat> References: <79fc91f3-c2c3-44db-9817-595808917f26@cas.cat> <86ed5ahb08.fsf@gnu.org> <87zfnywki8.fsf@gmail.com> <86setqfnmq.fsf@gnu.org> <87frpqflv4.fsf@gmail.com> <86ikumfjri.fsf@gnu.org> <877cb2fj0c.fsf@gmail.com> <86cykufhw7.fsf@gnu.org> <3a015d0f-549a-401f-be1c-651c9dbd5d9a@cas.cat> <8634lqfcaf.fsf@gnu.org> <87ikulwsd6.fsf@gmail.com> <86o74ddzxp.fsf@gnu.org> <87msiqvkph.fsf@localhost> <86ed42bs03.fsf@gnu.org> <874j4yot7x.fsf@localhost> <861q01c3h9.fsf@gnu.org> <87wmht3n17.fsf@gmail.com> <86v7xdamck.fsf@gnu.org> <87sesh37ya.fsf@gmail.com> <86iktd8o9h.fsf@gnu.org> <87iktb171d.fsf@gmail.com> <830de500-7c21-4dad-8290-9ab0f210af97@cas.cat> <86y1243cbx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37090"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 31 11:48:38 2024 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 1t6SjF-0009Td-Ms for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Oct 2024 11:48:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t6SiU-0007JL-TO; Thu, 31 Oct 2024 06:47:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t6SiS-0007J8-TB for emacs-devel@gnu.org; Thu, 31 Oct 2024 06:47:48 -0400 Original-Received: from cas.cat ([45.150.187.15]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t6SiQ-0000Jr-Qv for emacs-devel@gnu.org; Thu, 31 Oct 2024 06:47:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cas.cat; s=2023; t=1730371662; bh=sqcH7uQXWbB/Z5/LGUY9T5nOjPKbGwXHdNeLwKnbS8E=; h=Date:To:References:From:Subject:In-Reply-To:From; b=rtysi3Rec3x7i0Fy/jwn8DAEu3dLOxxRH9Px7howbSEJBGjXB4yC903cqeEqVf1mZ U+f1YM9xqPX/RYoUwzl2NVGIHP1+MjLDgLD+xG6Jg74hL8jbFlfU8iLM0mZ1Sy+Lki OIYqAgBDkI3e+45Koa4uLN2r64nVgdK2M5eX1XL+tpsYWobNp4NFtLxgx3YLmDc3uh FE2xLCJ138GGd1+5dYg8B47ep0sjq48+I43+1OLZsJzqrGuCm4SqmVxNZZoQcYG0SO DDR3tSRNhstDW5ZUKyKDCdT1e6yn1tTEXZoLuZOpyvz+aw1FL2DfiKSMff/Az/PFOr M5EWS0yafKjig== Content-Language: en-US In-Reply-To: <86y1243cbx.fsf@gnu.org> Received-SPF: pass client-ip=45.150.187.15; envelope-from=pinmacs@cas.cat; helo=cas.cat 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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324963 Archived-At: With the Visuwesh patch everything is fine. A good default is not provided, but I see that as a "second part" for the discussion, even a second commit, so we get some progress done. I was just saying that as a user I prefer to define on my own my custom commands for flexibility, but that is a user preference, not something to upstream to emacs core in terms of yank-media commands. I just tell that, to justify, why the flexible design of having that variable, that as Visuwesh, allows me to do that. Maybe I am missing too but when you choose a format, you choose how you store and retain that information. Depending on what you are going to do with that images, you might be interested in different formats. That's why different users might want different media types. On 2024-10-31 09:29, Eli Zaretskii wrote: >> Date: Thu, 31 Oct 2024 00:22:57 +0100 >> From: Pedro >> >> The approach of this patch permits to have different yank commands with >> different keybindings and context to respond to different needs (For the >> things I care, I end up having two commands, one that is simple and fast >> with the most preferred thing; and the other that gives all flexibility >> and possibilities). So, happy to see flexibility here too. > Flexibility doesn't come for free, though: are you arguing for having > N yank-media commands, each with its own preference of media formats? > Which means the user will have to remember the preferences for each > command and allocate a separate key binding to each? How is that a > good thing? > >> It might be useful to know why this is better: it is less error prone to >> what I have now. Let me explain this: the other day, by mistake (being >> in a hurry) I did several screen captures and I thought I was using .png >> (I usually pick png on the first time, and then, by frequency, it >> appears in the first position because of the completion tool >> (vertico/orderless ?)). But I was wrong, I took .pbm, for that case, >> that was fine, it was notes for me, but it could be the case of having >> screen captures with the wrong format and having difficulty to generate >> them again. This patch and approach helps the user to avoid that risk. > I don't understand that: how is the image format of the screen capture > relevant to yanking images into an Emacs buffer? What am I missing? >