Re: [RFC] Simple Search to Bottom Dock
Am Samstag, dem 13.02.2021 um 20:35 +0100 schrieb Pavel Sanda: > I do replace once a month while find 5xtimes a day, so the extra > click for replace does not really hurt. ... does not really hurt _you_. Anyway I am working on something. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am Samstag, dem 13.02.2021 um 16:48 -0500 schrieb Scott Kostyshak: > What if we get rid of the non-advanced replace? That is, if users > want so use replace, they need to go to Edit > Find & Replace > (Advanced). I am completely opposed to this. I use Advanced F only when I have to and use simple replace a lot. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX and markdown / pandoc
On Sat, Feb 13, 2021 at 11:08:57PM +0100, Thibaut Cuvelier wrote: > On Sat, 13 Feb 2021 at 22:42, Scott Kostyshak wrote: > > > On Sat, Feb 13, 2021 at 08:58:40PM +0100, Thibaut Cuvelier wrote: > > > Hi Julien, > > > > > > This would be awesome! It would still be quite a lot of work, though (I > > > have been through a similar pain when rewriting the DocBook export). > > > > > > As far as I can see, the Pandoc format is really poor (after all, it's > > very > > > similar to Markdown) compared to LyX: conversion to that format will > > lose a > > > lot of information from LyX. The HTML and DocBook exporters try to keep > > as > > > much information from LyX as possible, on the contrary, because these > > > formats are really flexible (even though the semantic information remains > > > at a presentational level for HTML). I'm afraid this could be a > > > road-blocker for using LyX as a Markdown editor for some users: you could > > > do so much more in LyX than in Markdown, without knowing in advance what > > > will be exportable in Markdown. > > > > > > Therefore, I don't think it's adviseable to use the Pandoc road for as > > many > > > formats as possible, but rather as a safety net. (It would be much better > > > if LyX could generate many formats without using external dependencies, > > > like DocBook and HTML — but unlike the new ePub support, for instance.) > > > > > > Due to the volatility of the LyX file format (and the lack of precise > > > definition, as far as I know), I would advise against your solution 2: > > LyX > > > can change its format between any two versions (except patch releases, > > if I > > > got it correctly), so that Pandoc would have to follow LyX for every > > change > > > in file format (LyX can convert between any two versions, but new > > features > > > may be lost when going backwards — and thus some content). Solution 1 > > > (implementing everything in LyX) would protect against any format > > changes, > > > as it would be implemented at the level of the LyX data structures > > instead > > > of the file format. Pandoc could then learn how to call LyX to perform > > the > > > conversion into their JSON schema, and you would use Pandoc to convert > > LyX > > > files directly. > > > > > > Projects like > > > https://github.com/nicowilliams/lyx2rfc/blob/master/src/lyx2xml.py are, > > in > > > my opinion, doomed to fail in the long run. It is really easier to write > > > code to work with LyX documents that directly within LyX, but the second > > > option gives more confidence in having the conversion work reliably in > > the > > > long term. > > > > > > Regarding the XML conversion of the LyX file format, you can also see > > > places where it's planned for 3.0, but it's not really alive right now > > (at > > > least, not that I know). > > > > > > These are just my thoughts on your proposal. I have not been a LyX > > > developer for a long time, so take everything with a pinch of salt or > > two. > > > However, I can guide you if you are willing to implement something in > > LyX. > > > > > > On Sat, 13 Feb 2021 at 17:42, Julien Dutant > > wrote: > > > > > > > Hi Lyx devs, > > > > > > > > tl;dr: interfacing LyX with pandoc's native or markdown formats would > > > > greatly expand its reach by adding many formats to the outputs it can > > > > generate and by making it by far the best visual editor for markdown > > > > available. What's the best way to go about it? > > > > > > > > I love LyX and have been using it for many years, I'm very grateful for > > > > your work. Like many people in academia and developers I'm also using > > > > markdown more and more, including for generating LaTeX. Pandoc (the > > > > "universal document converter", https://pandoc.org/) has a rich > > flavour > > > > of markdown that can cover most of academic needs and can be extended > > > > through 'filters. As I explain in this post: > > > > https://github.com/jgm/pandoc/issues/ on Pandoc's repo, there is a > > > > need for markdown visual editors and the few ones that exist are > > nowhere > > > > near as feature-rich and fast as an editor like LyX. > > > > But it would only take for LyX to read/write pandoc's markdown or > > native > > > > formats, or for Pandoc to read Lyx's format, to instantly turn LyX > > into a > > > > visual markdown editor. The layout system could be use to have a > > "markdown" > > > > class, and the extension system could even be used in combination with > > > > Pandoc's filters to extend markdown. > > > > > > > > In addition, doing this would allow LyX to generate all the outputs > > > > formats that Pandoc can generate: ebook, JATS XML, RST, various > > flavours of > > > > markdown, 6 slides formats, etc., etc., without going through LaTeX. I > > > > think this would significantly increase LyX's audience, esp. among > > > > documentation writers. > > > > > > > > Pandoc works by converting all documents to its Abstract Syntax Tree, > > > > which is simple and
Re: LyX and markdown / pandoc
On Sat, 13 Feb 2021 at 22:42, Scott Kostyshak wrote: > On Sat, Feb 13, 2021 at 08:58:40PM +0100, Thibaut Cuvelier wrote: > > Hi Julien, > > > > This would be awesome! It would still be quite a lot of work, though (I > > have been through a similar pain when rewriting the DocBook export). > > > > As far as I can see, the Pandoc format is really poor (after all, it's > very > > similar to Markdown) compared to LyX: conversion to that format will > lose a > > lot of information from LyX. The HTML and DocBook exporters try to keep > as > > much information from LyX as possible, on the contrary, because these > > formats are really flexible (even though the semantic information remains > > at a presentational level for HTML). I'm afraid this could be a > > road-blocker for using LyX as a Markdown editor for some users: you could > > do so much more in LyX than in Markdown, without knowing in advance what > > will be exportable in Markdown. > > > > Therefore, I don't think it's adviseable to use the Pandoc road for as > many > > formats as possible, but rather as a safety net. (It would be much better > > if LyX could generate many formats without using external dependencies, > > like DocBook and HTML — but unlike the new ePub support, for instance.) > > > > Due to the volatility of the LyX file format (and the lack of precise > > definition, as far as I know), I would advise against your solution 2: > LyX > > can change its format between any two versions (except patch releases, > if I > > got it correctly), so that Pandoc would have to follow LyX for every > change > > in file format (LyX can convert between any two versions, but new > features > > may be lost when going backwards — and thus some content). Solution 1 > > (implementing everything in LyX) would protect against any format > changes, > > as it would be implemented at the level of the LyX data structures > instead > > of the file format. Pandoc could then learn how to call LyX to perform > the > > conversion into their JSON schema, and you would use Pandoc to convert > LyX > > files directly. > > > > Projects like > > https://github.com/nicowilliams/lyx2rfc/blob/master/src/lyx2xml.py are, > in > > my opinion, doomed to fail in the long run. It is really easier to write > > code to work with LyX documents that directly within LyX, but the second > > option gives more confidence in having the conversion work reliably in > the > > long term. > > > > Regarding the XML conversion of the LyX file format, you can also see > > places where it's planned for 3.0, but it's not really alive right now > (at > > least, not that I know). > > > > These are just my thoughts on your proposal. I have not been a LyX > > developer for a long time, so take everything with a pinch of salt or > two. > > However, I can guide you if you are willing to implement something in > LyX. > > > > On Sat, 13 Feb 2021 at 17:42, Julien Dutant > wrote: > > > > > Hi Lyx devs, > > > > > > tl;dr: interfacing LyX with pandoc's native or markdown formats would > > > greatly expand its reach by adding many formats to the outputs it can > > > generate and by making it by far the best visual editor for markdown > > > available. What's the best way to go about it? > > > > > > I love LyX and have been using it for many years, I'm very grateful for > > > your work. Like many people in academia and developers I'm also using > > > markdown more and more, including for generating LaTeX. Pandoc (the > > > "universal document converter", https://pandoc.org/) has a rich > flavour > > > of markdown that can cover most of academic needs and can be extended > > > through 'filters. As I explain in this post: > > > https://github.com/jgm/pandoc/issues/ on Pandoc's repo, there is a > > > need for markdown visual editors and the few ones that exist are > nowhere > > > near as feature-rich and fast as an editor like LyX. > > > But it would only take for LyX to read/write pandoc's markdown or > native > > > formats, or for Pandoc to read Lyx's format, to instantly turn LyX > into a > > > visual markdown editor. The layout system could be use to have a > "markdown" > > > class, and the extension system could even be used in combination with > > > Pandoc's filters to extend markdown. > > > > > > In addition, doing this would allow LyX to generate all the outputs > > > formats that Pandoc can generate: ebook, JATS XML, RST, various > flavours of > > > markdown, 6 slides formats, etc., etc., without going through LaTeX. I > > > think this would significantly increase LyX's audience, esp. among > > > documentation writers. > > > > > > Pandoc works by converting all documents to its Abstract Syntax Tree, > > > which is simple and systematically specified ( > > > > https://hackage.haskell.org/package/pandoc-types-1.22/docs/Text-Pandoc-Definition.html > > > ). Pandoc can read it from a JSON file; alternatively, Pandoc's > markdown > > > can match it pretty closely. So all it would take would be either: > > > >
Re: [RFC] Simple Search to Bottom Dock
On Sat, Feb 13, 2021 at 08:35:27PM +0100, Pavel Sanda wrote: > On Sat, Feb 13, 2021 at 05:33:10PM +0100, Jürgen Spitzmüller wrote: > > Am Samstag, dem 13.02.2021 um 17:19 +0100 schrieb Pavel Sanda: > > > The hope of the switching to bar was to minimize space in a way like > > > firefox does, i.e. basically one-liner. > > > > Firefox only has find, not replace. > > > > > So any switch which would collapse this dialog > > > into way smaller beast would be appreciated... > > > > Yes. The price would be an extra click for replace, though (and option > > setting). > > I do replace once a month while find 5xtimes a day, so the extra click > for replace does not really hurt. What if we get rid of the non-advanced replace? That is, if users want so use replace, they need to go to Edit > Find & Replace (Advanced). Having a simple find bar with no replace functionality and then a separate dialog if the user wants to do replace seems consistent with Libre Office. I don't use LO much though so perhaps I missed something when checking. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX and markdown / pandoc
On Sat, Feb 13, 2021 at 08:58:40PM +0100, Thibaut Cuvelier wrote: > Hi Julien, > > This would be awesome! It would still be quite a lot of work, though (I > have been through a similar pain when rewriting the DocBook export). > > As far as I can see, the Pandoc format is really poor (after all, it's very > similar to Markdown) compared to LyX: conversion to that format will lose a > lot of information from LyX. The HTML and DocBook exporters try to keep as > much information from LyX as possible, on the contrary, because these > formats are really flexible (even though the semantic information remains > at a presentational level for HTML). I'm afraid this could be a > road-blocker for using LyX as a Markdown editor for some users: you could > do so much more in LyX than in Markdown, without knowing in advance what > will be exportable in Markdown. > > Therefore, I don't think it's adviseable to use the Pandoc road for as many > formats as possible, but rather as a safety net. (It would be much better > if LyX could generate many formats without using external dependencies, > like DocBook and HTML — but unlike the new ePub support, for instance.) > > Due to the volatility of the LyX file format (and the lack of precise > definition, as far as I know), I would advise against your solution 2: LyX > can change its format between any two versions (except patch releases, if I > got it correctly), so that Pandoc would have to follow LyX for every change > in file format (LyX can convert between any two versions, but new features > may be lost when going backwards — and thus some content). Solution 1 > (implementing everything in LyX) would protect against any format changes, > as it would be implemented at the level of the LyX data structures instead > of the file format. Pandoc could then learn how to call LyX to perform the > conversion into their JSON schema, and you would use Pandoc to convert LyX > files directly. > > Projects like > https://github.com/nicowilliams/lyx2rfc/blob/master/src/lyx2xml.py are, in > my opinion, doomed to fail in the long run. It is really easier to write > code to work with LyX documents that directly within LyX, but the second > option gives more confidence in having the conversion work reliably in the > long term. > > Regarding the XML conversion of the LyX file format, you can also see > places where it's planned for 3.0, but it's not really alive right now (at > least, not that I know). > > These are just my thoughts on your proposal. I have not been a LyX > developer for a long time, so take everything with a pinch of salt or two. > However, I can guide you if you are willing to implement something in LyX. > > On Sat, 13 Feb 2021 at 17:42, Julien Dutant wrote: > > > Hi Lyx devs, > > > > tl;dr: interfacing LyX with pandoc's native or markdown formats would > > greatly expand its reach by adding many formats to the outputs it can > > generate and by making it by far the best visual editor for markdown > > available. What's the best way to go about it? > > > > I love LyX and have been using it for many years, I'm very grateful for > > your work. Like many people in academia and developers I'm also using > > markdown more and more, including for generating LaTeX. Pandoc (the > > "universal document converter", https://pandoc.org/) has a rich flavour > > of markdown that can cover most of academic needs and can be extended > > through 'filters. As I explain in this post: > > https://github.com/jgm/pandoc/issues/ on Pandoc's repo, there is a > > need for markdown visual editors and the few ones that exist are nowhere > > near as feature-rich and fast as an editor like LyX. > > But it would only take for LyX to read/write pandoc's markdown or native > > formats, or for Pandoc to read Lyx's format, to instantly turn LyX into a > > visual markdown editor. The layout system could be use to have a "markdown" > > class, and the extension system could even be used in combination with > > Pandoc's filters to extend markdown. > > > > In addition, doing this would allow LyX to generate all the outputs > > formats that Pandoc can generate: ebook, JATS XML, RST, various flavours of > > markdown, 6 slides formats, etc., etc., without going through LaTeX. I > > think this would significantly increase LyX's audience, esp. among > > documentation writers. > > > > Pandoc works by converting all documents to its Abstract Syntax Tree, > > which is simple and systematically specified ( > > https://hackage.haskell.org/package/pandoc-types-1.22/docs/Text-Pandoc-Definition.html > > ). Pandoc can read it from a JSON file; alternatively, Pandoc's markdown > > can match it pretty closely. So all it would take would be either: > > > > 1) that Lyx reads and writes Pandoc's markdown or JSON > > 2) that Pandoc reads and writes Lyx's format .lyx . > > > > The first would be developping something like the DocBook or LyXHTML > > extension in Lyx. The second would be developing a reader and writer for
Re: LyX and markdown / pandoc
Hi Julien, This would be awesome! It would still be quite a lot of work, though (I have been through a similar pain when rewriting the DocBook export). As far as I can see, the Pandoc format is really poor (after all, it's very similar to Markdown) compared to LyX: conversion to that format will lose a lot of information from LyX. The HTML and DocBook exporters try to keep as much information from LyX as possible, on the contrary, because these formats are really flexible (even though the semantic information remains at a presentational level for HTML). I'm afraid this could be a road-blocker for using LyX as a Markdown editor for some users: you could do so much more in LyX than in Markdown, without knowing in advance what will be exportable in Markdown. Therefore, I don't think it's adviseable to use the Pandoc road for as many formats as possible, but rather as a safety net. (It would be much better if LyX could generate many formats without using external dependencies, like DocBook and HTML — but unlike the new ePub support, for instance.) Due to the volatility of the LyX file format (and the lack of precise definition, as far as I know), I would advise against your solution 2: LyX can change its format between any two versions (except patch releases, if I got it correctly), so that Pandoc would have to follow LyX for every change in file format (LyX can convert between any two versions, but new features may be lost when going backwards — and thus some content). Solution 1 (implementing everything in LyX) would protect against any format changes, as it would be implemented at the level of the LyX data structures instead of the file format. Pandoc could then learn how to call LyX to perform the conversion into their JSON schema, and you would use Pandoc to convert LyX files directly. Projects like https://github.com/nicowilliams/lyx2rfc/blob/master/src/lyx2xml.py are, in my opinion, doomed to fail in the long run. It is really easier to write code to work with LyX documents that directly within LyX, but the second option gives more confidence in having the conversion work reliably in the long term. Regarding the XML conversion of the LyX file format, you can also see places where it's planned for 3.0, but it's not really alive right now (at least, not that I know). These are just my thoughts on your proposal. I have not been a LyX developer for a long time, so take everything with a pinch of salt or two. However, I can guide you if you are willing to implement something in LyX. On Sat, 13 Feb 2021 at 17:42, Julien Dutant wrote: > Hi Lyx devs, > > tl;dr: interfacing LyX with pandoc's native or markdown formats would > greatly expand its reach by adding many formats to the outputs it can > generate and by making it by far the best visual editor for markdown > available. What's the best way to go about it? > > I love LyX and have been using it for many years, I'm very grateful for > your work. Like many people in academia and developers I'm also using > markdown more and more, including for generating LaTeX. Pandoc (the > "universal document converter", https://pandoc.org/) has a rich flavour > of markdown that can cover most of academic needs and can be extended > through 'filters. As I explain in this post: > https://github.com/jgm/pandoc/issues/ on Pandoc's repo, there is a > need for markdown visual editors and the few ones that exist are nowhere > near as feature-rich and fast as an editor like LyX. > But it would only take for LyX to read/write pandoc's markdown or native > formats, or for Pandoc to read Lyx's format, to instantly turn LyX into a > visual markdown editor. The layout system could be use to have a "markdown" > class, and the extension system could even be used in combination with > Pandoc's filters to extend markdown. > > In addition, doing this would allow LyX to generate all the outputs > formats that Pandoc can generate: ebook, JATS XML, RST, various flavours of > markdown, 6 slides formats, etc., etc., without going through LaTeX. I > think this would significantly increase LyX's audience, esp. among > documentation writers. > > Pandoc works by converting all documents to its Abstract Syntax Tree, > which is simple and systematically specified ( > https://hackage.haskell.org/package/pandoc-types-1.22/docs/Text-Pandoc-Definition.html > ). Pandoc can read it from a JSON file; alternatively, Pandoc's markdown > can match it pretty closely. So all it would take would be either: > > 1) that Lyx reads and writes Pandoc's markdown or JSON > 2) that Pandoc reads and writes Lyx's format .lyx . > > The first would be developping something like the DocBook or LyXHTML > extension in Lyx. The second would be developing a reader and writer for > Pandoc (in Haskell). > > It seems to me that the second line is easier (because there's already all > the library to build pandoc AST objects in Haskell). > > There are people in the pandoc community that might get involved. Or > someone
Re: [RFC] Simple Search to Bottom Dock
On Sat, Feb 13, 2021 at 05:33:10PM +0100, Jürgen Spitzmüller wrote: > Am Samstag, dem 13.02.2021 um 17:19 +0100 schrieb Pavel Sanda: > > The hope of the switching to bar was to minimize space in a way like > > firefox does, i.e. basically one-liner. > > Firefox only has find, not replace. > > > So any switch which would collapse this dialog > > into way smaller beast would be appreciated... > > Yes. The price would be an extra click for replace, though (and option > setting). I do replace once a month while find 5xtimes a day, so the extra click for replace does not really hurt. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] ePub: detect and use xsltproc.
On Sat, 13 Feb 2021 at 00:05, Pavel Sanda wrote: > On Fri, Feb 12, 2021 at 11:18:38PM +0100, Thibaut Cuvelier wrote: > > Are your two files correctly uploaded? 7Zip tells me that the CRC check > > failed for the xsltproc file (and indeed there is at least one missing > > character in its index.xhtml). Here are the SHA-256 of the two ePub > files, > > computed by 7Zip (I downloaded them multiple times to be sure the error > > should not come from my side): > > Saxon: 3BD5DC8B92F263ED0E8397C95BD39BEA3388E6BFDC3307F7ABA634B81DCD94D5 > > xsltproc: > 58B94B38558DF9CA724F894AD5E479D1D9C314D5E9A857C5B7C828A69FA74EB6 > > Hm, no this is not what it should have been: > $ sha256sum *epub > 99bbc4701306261ef426fc76379dff360087d6830fd8a8213b816dc79c68bac7 > Intro.saxon.epub > 6e5152a77c3d1b0ec16fdf5829f7c8c7380b98781b2f0ff4a9b8543d7dd31fa2 > Intro.xsltproc.epub > > In case mailman is playing dirty tricks with us, could you try: > https://filebin.net/lvw2i6t8jona3u12 > The files on filebin are indeed much better! No content seems to be missing. I checked thoroughly the two ePub files. The only differences I could see were in the IDs that were used for sections and other elements. Each XSLT processor is still consistent with itself, so there is no real difference between the two files. However, that means that automatically checking if both have the same output will be harder than expected… -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4 alpha2 failing on windows 10
On Sat, 13 Feb 2021 at 05:40, Enrico Forestieri wrote: > On Fri, Feb 12, 2021 at 07:31:46PM +, José Abílio Matos wrote: > > On Friday, February 12, 2021 3:01:19 PM WET Thibaut Cuvelier wrote: > > > Actually, it looks like \e is a GCC-only extension that is not > > > well-understood by MSVC. The attached patch solves the problem for me > by > > > replacing \e by another nonprintable character. > > > > @Enrico what do you think about this change. I think that it should be > > safe to apply. > > Yes, any nonprintable character will do. > I've pushed this commit. I think LyX deserves a new alpha release with this fix, as the issue is really bad on Windows. -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
LyX and markdown / pandoc
Hi Lyx devs, tl;dr: interfacing LyX with pandoc's native or markdown formats would greatly expand its reach by adding many formats to the outputs it can generate and by making it by far the best visual editor for markdown available. What's the best way to go about it? I love LyX and have been using it for many years, I'm very grateful for your work. Like many people in academia and developers I'm also using markdown more and more, including for generating LaTeX. Pandoc (the "universal document converter", https://pandoc.org/) has a rich flavour of markdown that can cover most of academic needs and can be extended through 'filters. As I explain in this post: https://github.com/jgm/pandoc/issues/ on Pandoc's repo, there is a need for markdown visual editors and the few ones that exist are nowhere near as feature-rich and fast as an editor like LyX. But it would only take for LyX to read/write pandoc's markdown or native formats, or for Pandoc to read Lyx's format, to instantly turn LyX into a visual markdown editor. The layout system could be use to have a "markdown" class, and the extension system could even be used in combination with Pandoc's filters to extend markdown. In addition, doing this would allow LyX to generate all the outputs formats that Pandoc can generate: ebook, JATS XML, RST, various flavours of markdown, 6 slides formats, etc., etc., without going through LaTeX. I think this would significantly increase LyX's audience, esp. among documentation writers. Pandoc works by converting all documents to its Abstract Syntax Tree, which is simple and systematically specified ( https://hackage.haskell.org/package/pandoc-types-1.22/docs/Text-Pandoc-Definition.html ). Pandoc can read it from a JSON file; alternatively, Pandoc's markdown can match it pretty closely. So all it would take would be either: 1) that Lyx reads and writes Pandoc's markdown or JSON 2) that Pandoc reads and writes Lyx's format .lyx . The first would be developping something like the DocBook or LyXHTML extension in Lyx. The second would be developing a reader and writer for Pandoc (in Haskell). It seems to me that the second line is easier (because there's already all the library to build pandoc AST objects in Haskell). There are people in the pandoc community that might get involved. Or someone could develop something on the LyX side (happy to get involved but in the longer term). The main obstacle, however, is that there doesn't seem to be a specification of LyX format, and (if I understand well) we can't rely on it being stable between releases (though we could rely on LyX's own conversion between versions of the LyX format). Around version 2.1 there was a "road to XML" but that has been abandoned, right? I'd be curious to have your thoughts on the project and what you think would be the best way to go about it and the main hurdles. All best, Julien -- julien dutant Department of Philosophy, King's College London julien.dut...@kcl.ac.uk http://julien.dutant.free.fr/ Strand London WC2R 2LS United Kingdom -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am Samstag, dem 13.02.2021 um 17:19 +0100 schrieb Pavel Sanda: > The hope of the switching to bar was to minimize space in a way like > firefox does, i.e. basically one-liner. Firefox only has find, not replace. > So any switch which would collapse this dialog > into way smaller beast would be appreciated... Yes. The price would be an extra click for replace, though (and option setting). Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Bookmark Shortcuts
Jürgen has done some work to make the search shortcuts work better, and it's led to the question how to bind word-find-backwards. The usual shortcut for that (on non-Mac machines) is S-F3 (with F3 being word-find). On LyX, that is taken by bookmark-save 3; similarly S-Fn (n a number) always sets a bookmark. I propose to change bookmark-save n to M-n; this goes better with C-n, which is what is bound to bookmark-goto n. That would free up S-F3 for find-next-backwards, and also free up the other S-Fn. I also thought about using "C-S-1", e.g., but that doesn't work, because S-1 types "!" here, so it actually has to be: \bind "S-C-exclam" "bookmark-save 1" \bind "S-C-at" "bookmark-save 2" \bind "C-S-numbersign" "bookmark-save 3" \bind "C-S-dollar" "bookmark-save 4" \bind "C-S-percent" "bookmark-save 5" \bind "C-S-asciicircum" "bookmark-save 6" \bind "C-S-ampersand" "bookmark-save 7" \bind "C-S-asterisk" "bookmark-save 8" \bind "C-S-parenleft" "bookmark-save 9" to work with my keyboard. I assume that would lead to chaos with non-English keyboards. Riki >From 7c30ab72debad77fe879867b1ef7f2564d72e6d7 Mon Sep 17 00:00:00 2001 From: Richard Kimberly Heck Date: Sat, 13 Feb 2021 11:23:38 -0500 Subject: [PATCH] Change bookmark shortcuts, freeing up S-F3 for word-find-backwards. --- lib/bind/cua.bind | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/lib/bind/cua.bind b/lib/bind/cua.bind index fc776c2dac..2b5630f1b4 100644 --- a/lib/bind/cua.bind +++ b/lib/bind/cua.bind @@ -107,7 +107,7 @@ Format 5 #bind "C-F1" "help-context" # Not yet implemented! \bind "F2" "buffer-write force" \bind "F3" "word-find" -\bind "C-F3" "word-find-backward" +\bind "S-F3" "word-find-backward" \bind "C-F4" "buffer-close" \bind "M-F4" "lyx-quit" \bind "F5" "screen-recenter" @@ -199,24 +199,24 @@ Format 5 # bookmarks # -\bind "C-~S-1" "bookmark-goto 1" -\bind "C-~S-2" "bookmark-goto 2" -\bind "C-~S-3" "bookmark-goto 3" -\bind "C-~S-4" "bookmark-goto 4" -\bind "C-~S-5" "bookmark-goto 5" -\bind "C-~S-6" "bookmark-goto 6" -\bind "C-~S-7" "bookmark-goto 7" -\bind "C-~S-8" "bookmark-goto 8" -\bind "C-~S-9" "bookmark-goto 9" -\bind "S-F1" "bookmark-save 1" -\bind "S-F2" "bookmark-save 2" -\bind "S-F3" "bookmark-save 3" -\bind "S-F4" "bookmark-save 4" -\bind "S-F5" "bookmark-save 5" -\bind "S-F6" "bookmark-save 6" -\bind "S-F7" "bookmark-save 7" -\bind "S-F8" "bookmark-save 8" -\bind "S-F9" "bookmark-save 9" +\bind "C-1" "bookmark-goto 1" +\bind "C-2" "bookmark-goto 2" +\bind "C-3" "bookmark-goto 3" +\bind "C-4" "bookmark-goto 4" +\bind "C-5" "bookmark-goto 5" +\bind "C-6" "bookmark-goto 6" +\bind "C-7" "bookmark-goto 7" +\bind "C-8" "bookmark-goto 8" +\bind "C-9" "bookmark-goto 9" +\bind "S-C-exclam" "bookmark-save 1" +\bind "S-C-at" "bookmark-save 2" +\bind "C-S-numbersign" "bookmark-save 3" +\bind "C-S-dollar" "bookmark-save 4" +\bind "C-S-percent" "bookmark-save 5" +\bind "C-S-asciicircum" "bookmark-save 6" +\bind "C-S-ampersand" "bookmark-save 7" +\bind "C-S-asterisk" "bookmark-save 8" +\bind "C-S-parenleft" "bookmark-save 9" # -- 2.29.2 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
On Sat, Feb 13, 2021 at 02:31:43PM +0100, Jürgen Spitzmüller wrote: > This solves some long standing UI issues: > > * https://www.lyx.org/trac/ticket/2625 > * https://www.lyx.org/trac/ticket/8054 > > Most importantly, search is more convenient when using the keyboard > (Ctrl-F toggles the search pane on and off, F3/Ctrl-F3 or Cmd-G/Shift- > Cmd-G, Return/Shift-Return and the respective accelerators search > backwards and forward, backwards search/replace does not need a > checkbox to be enabled), and there is no dialog getting in the way of > search results. > > To me, the UX seems significantly improved. > > The space taken is absolutely acceptable (note that the screenshot > shows a minimized main window), but if wanted, I can also add a button > that hides the replace and options widgets. The hope of the switching to bar was to minimize space in a way like firefox does, i.e. basically one-liner. So any switch which would collapse this dialog into way smaller beast would be appreciated... Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
On 2/13/21 8:49 AM, Kornel Benko wrote: > Am Sat, 13 Feb 2021 14:31:43 +0100 > schrieb Jürgen Spitzmüller : > >> Dear all >> >> I have a patch ready that moves the simple search dialog to the bottom >> dock widget (see attached screenshot). >> >> This solves some long standing UI issues: >> >> * https://www.lyx.org/trac/ticket/2625 >> * https://www.lyx.org/trac/ticket/8054 >> >> Most importantly, search is more convenient when using the keyboard >> (Ctrl-F toggles the search pane on and off, F3/Ctrl-F3 or Cmd-G/Shift- >> Cmd-G, Return/Shift-Return and the respective accelerators search >> backwards and forward, backwards search/replace does not need a >> checkbox to be enabled), and there is no dialog getting in the way of >> search results. >> >> To me, the UX seems significantly improved. >> >> The space taken is absolutely acceptable (note that the screenshot >> shows a minimized main window), but if wanted, I can also add a button >> that hides the replace and options widgets. >> >> Is this something we want in LyX 2.4? >> >> Jürgen > I like it. +1 for 2.4 And of course users who want to undock it can do so. So +1 here too. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am Sat, 13 Feb 2021 14:31:43 +0100 schrieb Jürgen Spitzmüller : > Dear all > > I have a patch ready that moves the simple search dialog to the bottom > dock widget (see attached screenshot). > > This solves some long standing UI issues: > > * https://www.lyx.org/trac/ticket/2625 > * https://www.lyx.org/trac/ticket/8054 > > Most importantly, search is more convenient when using the keyboard > (Ctrl-F toggles the search pane on and off, F3/Ctrl-F3 or Cmd-G/Shift- > Cmd-G, Return/Shift-Return and the respective accelerators search > backwards and forward, backwards search/replace does not need a > checkbox to be enabled), and there is no dialog getting in the way of > search results. > > To me, the UX seems significantly improved. > > The space taken is absolutely acceptable (note that the screenshot > shows a minimized main window), but if wanted, I can also add a button > that hides the replace and options widgets. > > Is this something we want in LyX 2.4? > > Jürgen I like it. +1 for 2.4 Kornel pgp5xECh7JWlv.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Windows installer: add version in all shortcuts
Am Do., 11. Feb. 2021 um 23:01 Uhr schrieb Thibaut Cuvelier < dourou...@gmail.com>: > Hi Eugene, > > I proposed in another discussion to add the version in all shortcuts > created by the installer, for specifically the case where the user has > several versions of LyX (or just updated, in which case there will be a > delay before the new shortcut gets into the search cache of the Start menu). > > Here is the patch I propose. I am by no means a NSIS expert, I don't know > if this will work, but I think there is a probability that it does. > > What do you think of this? > That won't work, because of overinstall, ppl install e.g. 2.3.5 into a folder "LyX 2.3" and then overinstall 2.3.6 into the same folder. after that there would be 2 shortcuts (LyX 2.3.5 and LyX 2.3.6) on the desktop pointing to the same (newer) LyX. Ofc it would be possible to delete the old shortcut, but it would be tricky and just a potential of more bugs imho. I am strictly against what you propose, because probably most Windows users have only 1 LyX installed (that would probably be the newest stable version) and many also don't really understand many concepts of Windows (like shortcuts, registry and other stuff), so we should not make it harder for them. The ones, who install more than 1 version, are more into that and can easily create their own shortcuts as they like. But as written, most just install, use, overinstall and don't wanna be bothered with multiple LyX versions and shortcuts. That's my opinion anyway. -- Eugene -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
