* bug#71909: 30.0.60; [not found] <865xtnhyn6.fsf@foxmail.com> @ 2024-10-05 12:28 ` Cecilio Pardo 2024-10-05 12:33 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Cecilio Pardo @ 2024-10-05 12:28 UTC (permalink / raw) To: 71909 I'll be working on this, if no one else is. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-05 12:28 ` bug#71909: 30.0.60; Cecilio Pardo @ 2024-10-05 12:33 ` Eli Zaretskii 2024-10-05 12:42 ` Eli Zaretskii 2024-10-10 10:04 ` Cecilio Pardo 0 siblings, 2 replies; 26+ messages in thread From: Eli Zaretskii @ 2024-10-05 12:33 UTC (permalink / raw) To: Cecilio Pardo; +Cc: 71909 > Date: Sat, 5 Oct 2024 14:28:35 +0200 > From: Cecilio Pardo <cpardo@imayhem.com> > > > I'll be working on this, if no one else is. Thanks in advance. Btw, if you are looking for significant enhancements to Emacs on Windows, then support for color fonts (which needs to use Direct2D, AFAIU) will be greatly appreciated. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-05 12:33 ` Eli Zaretskii @ 2024-10-05 12:42 ` Eli Zaretskii 2024-10-05 17:14 ` Cecilio Pardo 2024-10-10 10:04 ` Cecilio Pardo 1 sibling, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2024-10-05 12:42 UTC (permalink / raw) To: cpardo; +Cc: 71909 > Cc: 71909@debbugs.gnu.org > Date: Sat, 05 Oct 2024 15:33:39 +0300 > From: Eli Zaretskii <eliz@gnu.org> > > > Date: Sat, 5 Oct 2024 14:28:35 +0200 > > From: Cecilio Pardo <cpardo@imayhem.com> > > > > > > I'll be working on this, if no one else is. > > Thanks in advance. Btw, perhaps we should discuss the implementation ideas you have first. I'm guessing you are going to somehow map the clipboard formats defined by Windows to MIME types, then I wonder what should we do with the virtually open-ended set of Windows clipboard formats. Or maybe you have other ideas? ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-05 12:42 ` Eli Zaretskii @ 2024-10-05 17:14 ` Cecilio Pardo 2024-10-05 19:31 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Cecilio Pardo @ 2024-10-05 17:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71909 On 05/10/2024 14:42, Eli Zaretskii wrote: > Btw, perhaps we should discuss the implementation ideas you have > first. I'm guessing you are going to somehow map the clipboard > formats defined by Windows to MIME types, then I wonder what should we > do with the virtually open-ended set of Windows clipboard formats. > > Or maybe you have other ideas? Yes, I was thinking about mapping some of the formats, and ignoring the rest. Looking at the lisp files inside emacs, only these formats seem to be in use: image/* text/html (which is treated as text in sgml-mode) x/special-\\(?:gnome\\|KDE\\|mate\\)-files So CF_BITMAP and CF_HDROP, and maybe CF_HTML would cover all. Metafiles could be converted to bitmaps. As for other formats, other than offer them as application/octet-stream, I don't know. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-05 17:14 ` Cecilio Pardo @ 2024-10-05 19:31 ` Eli Zaretskii 2024-10-05 21:24 ` Cecilio Pardo 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2024-10-05 19:31 UTC (permalink / raw) To: Cecilio Pardo; +Cc: 71909 > Date: Sat, 5 Oct 2024 19:14:20 +0200 > Cc: 71909@debbugs.gnu.org > From: Cecilio Pardo <cpardo@imayhem.com> > > On 05/10/2024 14:42, Eli Zaretskii wrote: > > > Btw, perhaps we should discuss the implementation ideas you have > > first. I'm guessing you are going to somehow map the clipboard > > formats defined by Windows to MIME types, then I wonder what should we > > do with the virtually open-ended set of Windows clipboard formats. > > > > Or maybe you have other ideas? > > Yes, I was thinking about mapping some of the formats, and ignoring the > rest. Looking at the lisp files inside emacs, only these formats seem to > be in use: > > image/* > text/html (which is treated as text in sgml-mode) > x/special-\\(?:gnome\\|KDE\\|mate\\)-files > > So CF_BITMAP and CF_HDROP, and maybe CF_HTML would cover all. Metafiles > could be converted to bitmaps. > > As for other formats, other than offer them as application/octet-stream, > I don't know. If you invoke "M-: (gui-get-selection 'CLIPBOARD 'TARGETS) RET" after copying something to the clipboard, you will see some very weird format names there. For the standard formats, we convert them to something similar to what X Window system produces (see w32-selection-targets), but the rest are returned as-is. For example, after copying an image from Firefox, I get this as the return value of the above evaluation: [DataObject text/html HTML\ Format text/_moz_htmlinfo text/_moz_htmlcontext application/x-moz-file-promise-url application/x-moz-file-promise-dest-filename FILE_NAMES Preferred\ DropEffect application/x-moz-nativeimage DIB Ole\ Private\ Data BITMAP nil] There's no image/* here, only DIB and BITMAP (which correspond to CF_DIB and CF_BITMAP clipboard formats). There are also a lot of text/* formats, but they are all non-standard, except, perhaps, text/html. Do you have ideas how to select the proper format and how to yank the data? What do the x/special-* formats correspond to on Windows? ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-05 19:31 ` Eli Zaretskii @ 2024-10-05 21:24 ` Cecilio Pardo 2024-10-06 5:59 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Cecilio Pardo @ 2024-10-05 21:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71909 On 05/10/2024 21:31, Eli Zaretskii wrote: > If you invoke "M-: (gui-get-selection 'CLIPBOARD 'TARGETS) RET" after > copying something to the clipboard, you will see some very weird > format names there. For the standard formats, we convert them to > something similar to what X Window system produces (see > w32-selection-targets), but the rest are returned as-is. For example, > after copying an image from Firefox, I get this as the return value of > the above evaluation: > > [DataObject text/html HTML\ Format text/_moz_htmlinfo text/_moz_htmlcontext application/x-moz-file-promise-url application/x-moz-file-promise-dest-filename FILE_NAMES Preferred\ DropEffect application/x-moz-nativeimage DIB Ole\ Private\ Data BITMAP nil] > > There's no image/* here, only DIB and BITMAP (which correspond to > CF_DIB and CF_BITMAP clipboard formats). There are also a lot of > text/* formats, but they are all non-standard, except, perhaps, > text/html. Do you have ideas how to select the proper format and how > to yank the data? > What do the x/special-* formats correspond to on Windows? We would convert the BITMAP format to image/png, and FILE_NAMES to x-special/gnome-copied-files, to be compatible with what org-mode does now. The offer to yank-media would then be text/html, image/png, and x-special/gnome-copied-files, ignoring the rest of formats. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-05 21:24 ` Cecilio Pardo @ 2024-10-06 5:59 ` Eli Zaretskii [not found] ` <87ldz1h5s4.fsf@gmail.com> 2024-10-07 10:24 ` Cecilio Pardo 0 siblings, 2 replies; 26+ messages in thread From: Eli Zaretskii @ 2024-10-06 5:59 UTC (permalink / raw) To: Cecilio Pardo; +Cc: 71909 > Date: Sat, 5 Oct 2024 23:24:09 +0200 > From: Cecilio Pardo <cpardo@imayhem.com> > Cc: 71909@debbugs.gnu.org > > On 05/10/2024 21:31, Eli Zaretskii wrote: > > > If you invoke "M-: (gui-get-selection 'CLIPBOARD 'TARGETS) RET" after > > copying something to the clipboard, you will see some very weird > > format names there. For the standard formats, we convert them to > > something similar to what X Window system produces (see > > w32-selection-targets), but the rest are returned as-is. For example, > > after copying an image from Firefox, I get this as the return value of > > the above evaluation: > > > > [DataObject text/html HTML\ Format text/_moz_htmlinfo text/_moz_htmlcontext application/x-moz-file-promise-url application/x-moz-file-promise-dest-filename FILE_NAMES Preferred\ DropEffect application/x-moz-nativeimage DIB Ole\ Private\ Data BITMAP nil] > > > > There's no image/* here, only DIB and BITMAP (which correspond to > > CF_DIB and CF_BITMAP clipboard formats). There are also a lot of > > text/* formats, but they are all non-standard, except, perhaps, > > text/html. Do you have ideas how to select the proper format and how > > to yank the data? > > > What do the x/special-* formats correspond to on Windows? > > We would convert the BITMAP format to image/png But BITMAP is not PNG, AFAIU. Moreover, with some images, when I copy them in a Web browser, I see "PNG" in the targets vector reported by gui-get-selection. So I think we need to understand what exactly we get with each format before we decide on the mapping. As another data point. text/html seems to be Firefox-specific thing; the standard Windows name for this is "HTML Format" (with the embedded space). > and FILE_NAMES to > x-special/gnome-copied-files, to be compatible with what org-mode does > now. The offer to yank-media would then be text/html, image/png, and > x-special/gnome-copied-files, ignoring the rest of formats. I don't like the Gnome-specific name x-special/gnome-copied-files. I'd rather we produced a more generic name, and then ask the Org developers to add support for it. What about other kinds of media, like audio and video data? Is that supported, and if so, can we include that in some way? ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <87ldz1h5s4.fsf@gmail.com>]
* bug#71909: 30.0.60; [not found] ` <87ldz1h5s4.fsf@gmail.com> @ 2024-10-06 11:50 ` Eli Zaretskii 2024-10-06 12:15 ` Visuwesh 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2024-10-06 11:50 UTC (permalink / raw) To: Visuwesh; +Cc: cpardo, 71909 > From: Visuwesh <visuweshm@gmail.com> > Cc: Cecilio Pardo <cpardo@imayhem.com>, 71909@debbugs.gnu.org > Date: Sun, 06 Oct 2024 16:12:03 +0530 > > What happens when you copy text from, say, MS Office with formatting > applied to it (bold, italic, whatever)? The same with MS Office Excel. > I was thinking of eventually™ writing handlers for LibreOffice when > copying over table cells for org-mode. That requires Emacs to know about Rich Text, and to be able to convert that to Emacs faces. > When copying rich text from LibreOffice's MS Word equivalent, > yank-media-types reports: > > Possible completions are: > primary:text/html > clipboard:application/x-openoffice-link;windows_formatname="Link" > clipboard:application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" > clipboard:TIMESTAMP > primary:STRING > primary:TEXT > primary:TIMESTAMP > primary:UTF8_STRING > primary:application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" > primary:application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="8BC6B165-B1B2-4EDD-aa47-dae2ee689dd6";typename="LibreOffice 24.2 Text Document";displayname="file:///home/viz/tmp/User_Manual.docx";viewaspect="1";width="17000";height="3000";posx="0";posy="0" > primary:text/plain > primary:text/plain;charset=utf-16 > primary:text/plain;charset=utf-8 > primary:text/richtext > primary:text/rtf It is similar with Word on Windows, but the names of the formats are different. Also, if "primary:" means this is available in the PRIMARY selection, then we are only talking about CLIPBOARD. Try M-: (gui-get-selection 'CLIPBOARD 'TARGETS) RET instead. > where text/html is the most useful. no, the most useful is Rich Text, but Emacs cannot yet yank that. > When I copy a few table cells from LibreOffice's MS Excel equivalent, it > reports: > > Possible completions are: > clipboard:application/x-openoffice-link;windows_formatname="Link" > clipboard:application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" > clipboard:STRING > clipboard:TEXT > clipboard:TIMESTAMP > clipboard:UTF8_STRING > clipboard:application/x-libreoffice-tsvc > clipboard:application/x-openoffice-bitmap;windows_formatname="Bitmap" > clipboard:application/x-openoffice-dif;windows_formatname="DIF" > clipboard:application/x-openoffice-emf;windows_formatname="Image EMF" > clipboard:application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile" > clipboard:application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="47BBB4CB-CE4C-4E80-a591-42d9ae74950f";typename="LibreOffice 24.2 Spreadsheet";displayname="file:///home/viz/doc/uni/pincer/convergence_for_Mn-1.ods";viewaspect="1";width="15846";height="4065";posx="0";posy="0" > clipboard:application/x-openoffice-sylk;windows_formatname="Sylk" > clipboard:application/x-openoffice-wmf;windows_formatname="Image WMF" > clipboard:image/bmp > clipboard:image/png > clipboard:text/html > clipboard:text/plain > clipboard:text/plain;charset=utf-16 > clipboard:text/plain;charset=utf-8 > clipboard:text/richtext > clipboard:text/rtf > primary:CLASS > primary:COMPOUND_TEXT > primary:HOST_NAME > primary:LENGTH > primary:NAME > primary:OWNER_OS > primary:STRING > primary:TEXT > primary:TIMESTAMP > primary:USER > primary:UTF8_STRING > primary:text/plain > primary:text/plain;charset=utf-8 > > image/png is, well, an image of the copied cells, and text/html has a > (an?) HTML table. On Windows, I see CSV, which I think is more useful (maybe tsvc above is something similar). You definitely do NOT want an image in this case. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-06 11:50 ` Eli Zaretskii @ 2024-10-06 12:15 ` Visuwesh 2024-10-20 13:09 ` Ihor Radchenko 0 siblings, 1 reply; 26+ messages in thread From: Visuwesh @ 2024-10-06 12:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cpardo, 71909 [ஞாயிறு அக்டோபர் 06, 2024] Eli Zaretskii wrote: >> From: Visuwesh <visuweshm@gmail.com> >> Cc: Cecilio Pardo <cpardo@imayhem.com>, 71909@debbugs.gnu.org >> Date: Sun, 06 Oct 2024 16:12:03 +0530 >> >> What happens when you copy text from, say, MS Office with formatting >> applied to it (bold, italic, whatever)? The same with MS Office Excel. >> I was thinking of eventually™ writing handlers for LibreOffice when >> copying over table cells for org-mode. > > That requires Emacs to know about Rich Text, and to be able to convert > that to Emacs faces. Which I hope someone will eventually do something about. When yank-media was first mentioned among org-mode users, one of the first question was "Can it paste text copied from the browser in org-mode format?" (i.e., convert bold text to *bold text*) >> When copying rich text from LibreOffice's MS Word equivalent, >> yank-media-types reports: >> >> Possible completions are: >> primary:text/html >> clipboard:application/x-openoffice-link;windows_formatname="Link" >> clipboard:application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" >> clipboard:TIMESTAMP >>[...] > It is similar with Word on Windows, but the names of the formats are > different. > > Also, if "primary:" means this is available in the PRIMARY selection, > then we are only talking about CLIPBOARD. Yes, it means the PRIMARY selection. For some reason, yank-media also seems to consider the PRIMARY selection? When I did M-x yank-media RET in a html-mode buffer, it pasted the above text/html data. > Try > > M-: (gui-get-selection 'CLIPBOARD 'TARGETS) RET > > instead. > >> where text/html is the most useful. > > no, the most useful is Rich Text, but Emacs cannot yet yank that. Possibly. But we could at least "hijack" shr to convert text/html to string with text properties on it, or make it insert markup elements. I've done the later as a personal hack and it works fairly well. >> When I copy a few table cells from LibreOffice's MS Excel equivalent, it >> reports: >> >> Possible completions are: >> [...] >> image/png is, well, an image of the copied cells, and text/html has a >> (an?) HTML table. > > On Windows, I see CSV, which I think is more useful (maybe tsvc above > is something similar). You are right. It pasted a TSV formatted text. I missed it in the long list of items. > You definitely do NOT want an image in this case. Definitely not. I simply found it amusing that LibreOffice offered it as a potential candidate. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-06 12:15 ` Visuwesh @ 2024-10-20 13:09 ` Ihor Radchenko 2024-10-20 13:51 ` Eli Zaretskii 2024-10-20 17:16 ` Cecilio Pardo 0 siblings, 2 replies; 26+ messages in thread From: Ihor Radchenko @ 2024-10-20 13:09 UTC (permalink / raw) To: Visuwesh; +Cc: Eli Zaretskii, 71909, cpardo Visuwesh <visuweshm@gmail.com> writes: >>> where text/html is the most useful. >> >> no, the most useful is Rich Text, but Emacs cannot yet yank that. > > Possibly. But we could at least "hijack" shr to convert text/html to > string with text properties on it, or make it insert markup elements. > I've done the later as a personal hack and it works fairly well. May we utilize tree-sitter? Having an AST, it should not be too hard to convert it into something Emacs can understand. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92> ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-20 13:09 ` Ihor Radchenko @ 2024-10-20 13:51 ` Eli Zaretskii 2024-10-20 13:59 ` Ihor Radchenko 2024-10-20 17:16 ` Cecilio Pardo 1 sibling, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2024-10-20 13:51 UTC (permalink / raw) To: Ihor Radchenko; +Cc: cpardo, 71909, visuweshm > From: Ihor Radchenko <yantar92@posteo.net> > Cc: Eli Zaretskii <eliz@gnu.org>, cpardo@imayhem.com, 71909@debbugs.gnu.org > Date: Sun, 20 Oct 2024 13:09:01 +0000 > > Visuwesh <visuweshm@gmail.com> writes: > > >>> where text/html is the most useful. > >> > >> no, the most useful is Rich Text, but Emacs cannot yet yank that. > > > > Possibly. But we could at least "hijack" shr to convert text/html to > > string with text properties on it, or make it insert markup elements. > > I've done the later as a personal hack and it works fairly well. > > May we utilize tree-sitter? > Having an AST, it should not be too hard to convert it into something > Emacs can understand. You mean, someone has written a tree-sitter grammar for Rich Text? If not, what do you mean by "utilize tree-sitter" in this context? ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-20 13:51 ` Eli Zaretskii @ 2024-10-20 13:59 ` Ihor Radchenko 2024-10-20 14:22 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Ihor Radchenko @ 2024-10-20 13:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cpardo, 71909, visuweshm Eli Zaretskii <eliz@gnu.org> writes: >> May we utilize tree-sitter? >> Having an AST, it should not be too hard to convert it into something >> Emacs can understand. > > You mean, someone has written a tree-sitter grammar for Rich Text? Yes. I did not check in details, but I did quick search before writing my email and arrived at https://github.com/GoodNotes/tree-sitter-rtf -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92> ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-20 13:59 ` Ihor Radchenko @ 2024-10-20 14:22 ` Eli Zaretskii 2024-10-20 15:02 ` Ihor Radchenko 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2024-10-20 14:22 UTC (permalink / raw) To: Ihor Radchenko; +Cc: cpardo, 71909, visuweshm > From: Ihor Radchenko <yantar92@posteo.net> > Cc: visuweshm@gmail.com, cpardo@imayhem.com, 71909@debbugs.gnu.org > Date: Sun, 20 Oct 2024 13:59:47 +0000 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> May we utilize tree-sitter? > >> Having an AST, it should not be too hard to convert it into something > >> Emacs can understand. > > > > You mean, someone has written a tree-sitter grammar for Rich Text? > > Yes. I did not check in details, but I did quick search before writing > my email and arrived at https://github.com/GoodNotes/tree-sitter-rtf Someone will need to generate the parser from that, before people can compile and use the grammar library. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-20 14:22 ` Eli Zaretskii @ 2024-10-20 15:02 ` Ihor Radchenko 2024-10-20 15:34 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Ihor Radchenko @ 2024-10-20 15:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cpardo, 71909, visuweshm Eli Zaretskii <eliz@gnu.org> writes: >> > You mean, someone has written a tree-sitter grammar for Rich Text? >> >> Yes. I did not check in details, but I did quick search before writing >> my email and arrived at https://github.com/GoodNotes/tree-sitter-rtf > > Someone will need to generate the parser from that, before people can > compile and use the grammar library. What is the problem generating parser library from source code? The source code is there. Generating is simply yarn generate. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92> ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-20 15:02 ` Ihor Radchenko @ 2024-10-20 15:34 ` Eli Zaretskii 2024-10-20 15:57 ` Ihor Radchenko 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2024-10-20 15:34 UTC (permalink / raw) To: Ihor Radchenko; +Cc: cpardo, 71909, visuweshm > From: Ihor Radchenko <yantar92@posteo.net> > Cc: visuweshm@gmail.com, cpardo@imayhem.com, 71909@debbugs.gnu.org > Date: Sun, 20 Oct 2024 15:02:18 +0000 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> > You mean, someone has written a tree-sitter grammar for Rich Text? > >> > >> Yes. I did not check in details, but I did quick search before writing > >> my email and arrived at https://github.com/GoodNotes/tree-sitter-rtf > > > > Someone will need to generate the parser from that, before people can > > compile and use the grammar library. > > What is the problem generating parser library from source code? > The source code is there. Generating is simply yarn generate. We want to assume that everyone has yarn (and Node.js)? treesit-install-language-grammar assumes the library's Git repository includes code in C or C++. All the other grammar libraries include the parser (and scanner, where needed) in the Git repository, so I wonder why this one doesn't. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-20 15:34 ` Eli Zaretskii @ 2024-10-20 15:57 ` Ihor Radchenko 2024-10-20 17:50 ` Visuwesh 0 siblings, 1 reply; 26+ messages in thread From: Ihor Radchenko @ 2024-10-20 15:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cpardo, 71909, visuweshm Eli Zaretskii <eliz@gnu.org> writes: >> What is the problem generating parser library from source code? >> The source code is there. Generating is simply yarn generate. > > We want to assume that everyone has yarn (and Node.js)? > treesit-install-language-grammar assumes the library's Git repository > includes code in C or C++. > All the other grammar libraries include the parser (and scanner, where > needed) in the Git repository, so I wonder why this one doesn't. I see. It looks like a small problem. But one can set a CI pipeline to compile the grammar automatically in a separate repository. AFAIU, there are no license obstacles for doing this. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92> ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-20 15:57 ` Ihor Radchenko @ 2024-10-20 17:50 ` Visuwesh 2024-10-20 17:59 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Visuwesh @ 2024-10-20 17:50 UTC (permalink / raw) To: Ihor Radchenko; +Cc: Eli Zaretskii, 71909, cpardo [ஞாயிறு அக்டோபர் 20, 2024] Ihor Radchenko wrote: > Eli Zaretskii <eliz@gnu.org> writes: > >>> What is the problem generating parser library from source code? >>> The source code is there. Generating is simply yarn generate. >> >> We want to assume that everyone has yarn (and Node.js)? >> treesit-install-language-grammar assumes the library's Git repository >> includes code in C or C++. > >> All the other grammar libraries include the parser (and scanner, where >> needed) in the Git repository, so I wonder why this one doesn't. > > I see. It looks like a small problem. But one can set a CI pipeline to > compile the grammar automatically in a separate repository. > > AFAIU, there are no license obstacles for doing this. Can we not ask the author of the library to provide the C/C++ files in the repo? ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-20 17:50 ` Visuwesh @ 2024-10-20 17:59 ` Eli Zaretskii 0 siblings, 0 replies; 26+ messages in thread From: Eli Zaretskii @ 2024-10-20 17:59 UTC (permalink / raw) To: Visuwesh; +Cc: yantar92, 71909, cpardo > From: Visuwesh <visuweshm@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, cpardo@imayhem.com, 71909@debbugs.gnu.org > Date: Sun, 20 Oct 2024 23:20:50 +0530 > > [ஞாயிறு அக்டோபர் 20, 2024] Ihor Radchenko wrote: > > > Eli Zaretskii <eliz@gnu.org> writes: > > > >>> What is the problem generating parser library from source code? > >>> The source code is there. Generating is simply yarn generate. > >> > >> We want to assume that everyone has yarn (and Node.js)? > >> treesit-install-language-grammar assumes the library's Git repository > >> includes code in C or C++. > > > >> All the other grammar libraries include the parser (and scanner, where > >> needed) in the Git repository, so I wonder why this one doesn't. > > > > I see. It looks like a small problem. But one can set a CI pipeline to > > compile the grammar automatically in a separate repository. > > > > AFAIU, there are no license obstacles for doing this. > > Can we not ask the author of the library to provide the C/C++ files in > the repo? It cannot hurt. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-20 13:09 ` Ihor Radchenko 2024-10-20 13:51 ` Eli Zaretskii @ 2024-10-20 17:16 ` Cecilio Pardo 2024-10-20 17:58 ` Eli Zaretskii 1 sibling, 1 reply; 26+ messages in thread From: Cecilio Pardo @ 2024-10-20 17:16 UTC (permalink / raw) To: Ihor Radchenko, Visuwesh; +Cc: Eli Zaretskii, 71909 On 20/10/2024 15:09, Ihor Radchenko wrote: > Visuwesh <visuweshm@gmail.com> writes: > >>>> where text/html is the most useful. >>> >>> no, the most useful is Rich Text, but Emacs cannot yet yank that. >> >> Possibly. But we could at least "hijack" shr to convert text/html to >> string with text properties on it, or make it insert markup elements. >> I've done the later as a personal hack and it works fairly well. > > May we utilize tree-sitter? > Having an AST, it should not be too hard to convert it into something > Emacs can understand. I had planned to try to use UnRTF for this. https://www.gnu.org/software/unrtf/ It's a GNU package, and despite being old and (I think) unmaintained, it is used by many wrappers for different languages, so it probably works well, though I haven't tested it myself yet. Has it been already tried for emacs? If not, which approach (tree-sitter, unrtf) would be more promising? ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-20 17:16 ` Cecilio Pardo @ 2024-10-20 17:58 ` Eli Zaretskii 0 siblings, 0 replies; 26+ messages in thread From: Eli Zaretskii @ 2024-10-20 17:58 UTC (permalink / raw) To: Cecilio Pardo; +Cc: yantar92, 71909, visuweshm > Date: Sun, 20 Oct 2024 19:16:03 +0200 > Cc: Eli Zaretskii <eliz@gnu.org>, 71909@debbugs.gnu.org > From: Cecilio Pardo <cpardo@imayhem.com> > > I had planned to try to use UnRTF for this. > > https://www.gnu.org/software/unrtf/ > > It's a GNU package, and despite being old and (I think) unmaintained, it > is used by many wrappers for different languages, so it probably works > well, though I haven't tested it myself yet. > > Has it been already tried for emacs? I don't think so. > If not, which approach (tree-sitter, unrtf) would be more promising? It depends on which one covers the RTF spec better, I think. All the rest being equal, I think tree-sitter is more promising, because it will definitely be faster. OTOH, an Emacs-specific downside of using tree-sitter is that we don't have any experience using TS structure-related information (sectioning, tables, numbered lists, etc.) in Emacs, we only use TS for faces and indentation. UnRTF converts to HTML, and we already know how to use this stuff when expressed in HTML. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-06 5:59 ` Eli Zaretskii [not found] ` <87ldz1h5s4.fsf@gmail.com> @ 2024-10-07 10:24 ` Cecilio Pardo 2024-10-07 11:58 ` Eli Zaretskii 1 sibling, 1 reply; 26+ messages in thread From: Cecilio Pardo @ 2024-10-07 10:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71909 On 06/10/2024 7:59, Eli Zaretskii wrote: > But BITMAP is not PNG, AFAIU. Moreover, with some images, when I copy > them in a Web browser, I see "PNG" in the targets vector reported by > gui-get-selection. So I think we need to understand what exactly we > get with each format before we decide on the mapping. The standard bitmap formats for the clipboard (CF_BITMAP, CF_DIB, CF_DIBV5) are image data specific to windows, not an image format for saving to file. We need to convert it to an image format, with a mime/type. PNG or any other, even multiple ones. GIMP on ubuntu for example does this when you copy a section of image: [TIMESTAMP TARGETS MULTIPLE SAVE_TARGETS image/png image/bmp image/x-bmp image/x-MS-bmp image/x-icon image/x-ico image/x-win-bitmap image/vnd.microsoft.icon ...] On windows it does this: [PNG DIB BITMAP DIBV5] And the Paint program that comes with Windows 11: [DataObject Embed\ Source Native OwnerLink Object\ Descriptor METAFILE DIB PNG image/png Ole\ Private\ Data ENHMETAFILE BITMAP ...] I didn't expect the PNG, image/png formats. I suppose they are the same image as the DIB/BITMAP. It seems programs are already doing the conversion. I don't know the details yet, I'm on it. So at least for images it seems most times we will have a well-known format. If not (BITMAP,DIV), then we can do the PNG conversion. > As another data point. text/html seems to be Firefox-specific thing; > the standard Windows name for this is "HTML Format" (with the embedded > space). It may be interesting to handle some of this specific formats, from Firefox, or OpenOffice as discussed on another thread. We will have to detect them somehow and decide what to do for each case. > I don't like the Gnome-specific name x-special/gnome-copied-files. > I'd rather we produced a more generic name, and then ask the Org > developers to add support for it. Of course. > What about other kinds of media, like audio and video data? Is that > supported, and if so, can we include that in some way? In standard formats there is CF_RIFF and CF_WAVE. Also programas may insert a file format (as they do with PNGS), but I haven't found any example yet. In any case, we can do the same as with images. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-07 10:24 ` Cecilio Pardo @ 2024-10-07 11:58 ` Eli Zaretskii 2024-10-09 12:52 ` Cecilio Pardo 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2024-10-07 11:58 UTC (permalink / raw) To: Cecilio Pardo; +Cc: 71909 > Date: Mon, 7 Oct 2024 12:24:01 +0200 > Cc: 71909@debbugs.gnu.org > From: Cecilio Pardo <cpardo@imayhem.com> > > On 06/10/2024 7:59, Eli Zaretskii wrote: > > > But BITMAP is not PNG, AFAIU. Moreover, with some images, when I copy > > them in a Web browser, I see "PNG" in the targets vector reported by > > gui-get-selection. So I think we need to understand what exactly we > > get with each format before we decide on the mapping. > > The standard bitmap formats for the clipboard (CF_BITMAP, CF_DIB, > CF_DIBV5) are image data specific to windows, not an image format for > saving to file. We need to convert it to an image format, with a > mime/type. PNG or any other, even multiple ones. Isn't CF_BITMAP format indicate the data to which we convert images on Windows in the w32-specific portions of image.c? Or maybe it's a BMP data (which we can already display, see w32image.c)? If so, then yanking images into an Emacs buffer could simply use the data instead of converting to PNG, then back to bitmap. > GIMP on ubuntu for example does this when you copy a section of image: > > [TIMESTAMP TARGETS MULTIPLE SAVE_TARGETS image/png image/bmp image/x-bmp > image/x-MS-bmp image/x-icon image/x-ico image/x-win-bitmap > image/vnd.microsoft.icon ...] > > On windows it does this: > > [PNG DIB BITMAP DIBV5] > > And the Paint program that comes with Windows 11: > > [DataObject Embed\ Source Native OwnerLink Object\ Descriptor METAFILE > DIB PNG image/png Ole\ Private\ Data ENHMETAFILE BITMAP ...] > > I didn't expect the PNG, image/png formats. I suppose they are the same > image as the DIB/BITMAP. I'd rather expect them to be in PNG format. > > What about other kinds of media, like audio and video data? Is that > > supported, and if so, can we include that in some way? > > In standard formats there is CF_RIFF and CF_WAVE. Also programas may > insert a file format (as they do with PNGS), but I haven't found any > example yet. In any case, we can do the same as with images. If CF_WAVE are the same data as in *.wav files, then we should be able to invoke play-sound in some way. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-07 11:58 ` Eli Zaretskii @ 2024-10-09 12:52 ` Cecilio Pardo 2024-10-09 13:40 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Cecilio Pardo @ 2024-10-09 12:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71909 On 07/10/2024 13:58, Eli Zaretskii wrote: > Isn't CF_BITMAP format indicate the data to which we convert images on > Windows in the w32-specific portions of image.c? Or maybe it's a BMP > data (which we can already display, see w32image.c)? If so, then > yanking images into an Emacs buffer could simply use the data instead > of converting to PNG, then back to bitmap. But how would lisp programs register for receiving that? yank-media-handler asks for mime types. >> I didn't expect the PNG, image/png formats. I suppose they are the same >> image as the DIB/BITMAP. > > I'd rather expect them to be in PNG format. Yes, the same pixels, but in PNG format. >>> What about other kinds of media, like audio and video data? Is that >>> supported, and if so, can we include that in some way? >> >> In standard formats there is CF_RIFF and CF_WAVE. Also programas may >> insert a file format (as they do with PNGS), but I haven't found any >> example yet. In any case, we can do the same as with images. > > If CF_WAVE are the same data as in *.wav files, then we should be able > to invoke play-sound in some way. But again, lisp programas need to register for a mime type, and then act on the data as they require. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-09 12:52 ` Cecilio Pardo @ 2024-10-09 13:40 ` Eli Zaretskii 0 siblings, 0 replies; 26+ messages in thread From: Eli Zaretskii @ 2024-10-09 13:40 UTC (permalink / raw) To: Cecilio Pardo; +Cc: 71909 > Date: Wed, 9 Oct 2024 14:52:57 +0200 > Cc: 71909@debbugs.gnu.org > From: Cecilio Pardo <cpardo@imayhem.com> > > On 07/10/2024 13:58, Eli Zaretskii wrote: > > > Isn't CF_BITMAP format indicate the data to which we convert images on > > Windows in the w32-specific portions of image.c? Or maybe it's a BMP > > data (which we can already display, see w32image.c)? If so, then > > yanking images into an Emacs buffer could simply use the data instead > > of converting to PNG, then back to bitmap. > > But how would lisp programs register for receiving that? > yank-media-handler asks for mime types. I believe the MIME type is image/bmp. > > If CF_WAVE are the same data as in *.wav files, then we should be able > > to invoke play-sound in some way. > > But again, lisp programas need to register for a mime type, and then act > on the data as they require. That's audio/wav, I believe. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-05 12:33 ` Eli Zaretskii 2024-10-05 12:42 ` Eli Zaretskii @ 2024-10-10 10:04 ` Cecilio Pardo 2024-10-10 10:49 ` Eli Zaretskii 1 sibling, 1 reply; 26+ messages in thread From: Cecilio Pardo @ 2024-10-10 10:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71909 On 05/10/2024 14:33, Eli Zaretskii wrote: >> Date: Sat, 5 Oct 2024 14:28:35 +0200 >> From: Cecilio Pardo <cpardo@imayhem.com> >> >> >> I'll be working on this, if no one else is. > > Thanks in advance. > > Btw, if you are looking for significant enhancements to Emacs on > Windows, then support for color fonts (which needs to use Direct2D, > AFAIU) will be greatly appreciated. Is there an open bug about this, or should I open a new one? ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#71909: 30.0.60; 2024-10-10 10:04 ` Cecilio Pardo @ 2024-10-10 10:49 ` Eli Zaretskii 0 siblings, 0 replies; 26+ messages in thread From: Eli Zaretskii @ 2024-10-10 10:49 UTC (permalink / raw) To: Cecilio Pardo; +Cc: 71909 > Date: Thu, 10 Oct 2024 12:04:31 +0200 > Cc: 71909@debbugs.gnu.org > From: Cecilio Pardo <cpardo@imayhem.com> > > On 05/10/2024 14:33, Eli Zaretskii wrote: > >> Date: Sat, 5 Oct 2024 14:28:35 +0200 > >> From: Cecilio Pardo <cpardo@imayhem.com> > >> > > Btw, if you are looking for significant enhancements to Emacs on > > Windows, then support for color fonts (which needs to use Direct2D, > > AFAIU) will be greatly appreciated. > > Is there an open bug about this, or should I open a new one? I don't think we have a bug open for this. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2024-10-20 17:59 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <865xtnhyn6.fsf@foxmail.com> 2024-10-05 12:28 ` bug#71909: 30.0.60; Cecilio Pardo 2024-10-05 12:33 ` Eli Zaretskii 2024-10-05 12:42 ` Eli Zaretskii 2024-10-05 17:14 ` Cecilio Pardo 2024-10-05 19:31 ` Eli Zaretskii 2024-10-05 21:24 ` Cecilio Pardo 2024-10-06 5:59 ` Eli Zaretskii [not found] ` <87ldz1h5s4.fsf@gmail.com> 2024-10-06 11:50 ` Eli Zaretskii 2024-10-06 12:15 ` Visuwesh 2024-10-20 13:09 ` Ihor Radchenko 2024-10-20 13:51 ` Eli Zaretskii 2024-10-20 13:59 ` Ihor Radchenko 2024-10-20 14:22 ` Eli Zaretskii 2024-10-20 15:02 ` Ihor Radchenko 2024-10-20 15:34 ` Eli Zaretskii 2024-10-20 15:57 ` Ihor Radchenko 2024-10-20 17:50 ` Visuwesh 2024-10-20 17:59 ` Eli Zaretskii 2024-10-20 17:16 ` Cecilio Pardo 2024-10-20 17:58 ` Eli Zaretskii 2024-10-07 10:24 ` Cecilio Pardo 2024-10-07 11:58 ` Eli Zaretskii 2024-10-09 12:52 ` Cecilio Pardo 2024-10-09 13:40 ` Eli Zaretskii 2024-10-10 10:04 ` Cecilio Pardo 2024-10-10 10:49 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).