Re: thank you someone(s)

/ApplicationSupport/LyX-2.2 directory and copied it to a new LyX-2.3 folder.  And it converted the 2.2 file entirely correctly.  Some clever person(s) have done a beautiful job with this conversion.  So, THANK YOU!! This is supposed always to work: Even LyX 1.0 files should open in LyX 2.3. They may have

thank you someone(s)

/LyX-2.2 directory and copied it to a new LyX-2.3 folder.  And it converted the 2.2 file entirely correctly.  Some clever person(s) have done a beautiful job with this conversion.  So, THANK YOU!! --  Oliver Davis Johns, Ph.D

Re: \S

On 7/27/23 17:00, Enrico Forestieri wrote: On Thu, Jul 27, 2023 at 01:27:09AM -0400, Richard Kimberly Heck wrote: This is really a special case, so I'm inclined just to handle it as one via the attached hack-ish patch. But maybe someone else knows how to fix Encodings::fromLaTeXCommand? It

Re: \S

On Thu, Jul 27, 2023 at 01:27:09AM -0400, Richard Kimberly Heck wrote: This is really a special case, so I'm inclined just to handle it as one via the attached hack-ish patch. But maybe someone else knows how to fix Encodings::fromLaTeXCommand? It has been a long time and I don't remember

\S

I often use \S in citations, but it does not get displayed properly in the label. The reason is that unicodesymbols uses \textsection instead, and if I add an extra line: 0x00a7 "\\S" "" that doesn't work either, because Encodings::fromLaTeXCommand doesn't consider 'e

Re: Japanese Math manual on current master: ! Too many }'s.

Am Fri, 21 Aug 2020 15:35:05 +0200 schrieb Jürgen Spitzmüller : > Am Fr., 21. Aug. 2020 um 12:16 Uhr schrieb Kornel Benko : > > > export/doc/fr/Customization_(dvi3|pdf[45])_systemF > > > > This seems to work for me (if I select appropriate system fonts). What > error do you get? > LaTeX.cpp

Re: Japanese Math manual on current master: ! Too many }'s.

Am Fr., 21. Aug. 2020 um 12:16 Uhr schrieb Kornel Benko : > export/doc/fr/Customization_(dvi3|pdf[45])_systemF > This seems to work for me (if I select appropriate system fonts). What error do you get? > export/examples/ru/Graphics_and_Insets/XY-Figure_(dvi3|pdf[45])_systemF > I get errors

Re: Japanese Math manual on current master: ! Too many }'s.

Am Fri, 21 Aug 2020 11:07:44 +0200 schrieb Jürgen Spitzmüller : > Am Donnerstag, den 20.08.2020, 21:43 -0400 schrieb Scott Kostyshak: > > I get the following error when compiling the Japanese math manual > > with > > default format: > > > > ! Too many }'s.

Re: Japanese Math manual on current master: ! Too many }'s.

Am Donnerstag, den 20.08.2020, 21:43 -0400 schrieb Scott Kostyshak: > I get the following error when compiling the Japanese math manual > with > default format: > > ! Too many }'s. Fixed. A full test cycle will reveal whether this fix broke something elsewhere (I haven't fou

Japanese Math manual on current master: ! Too many }'s.

I get the following error when compiling the Japanese math manual with default format: ! Too many }'s. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel

daily binaries (was: [LyX/master] Reset layout when inserting an inset over full paragraph(s))

On Fri, Sep 13, 2019 at 09:25:21AM +0200, Jean-Marc Lasgouttes wrote: > Le 13/09/2019 ?? 00:55, Richard Kimberly Heck a écrit : >>> We are sorely lacking daily builds for stable releases. If we knew how >>> to automate these, that could be done by our CI tools. I have taken a >>> look at the

Re: [LyX/master] Reset layout when inserting an inset over full paragraph(s)

Le 13/09/2019 à 05:00, Pavel Sanda a écrit : On Thu, Sep 12, 2019 at 10:04:19AM +0200, Jean-Marc Lasgouttes wrote: But if there is a consensus about 2.3, I am OK with it. I was not actually suggesting to push it into official 2.3.x, just wanted to know whether putting into my private patchset

Re: [LyX/master] Reset layout when inserting an inset over full paragraph(s)

Le 13/09/2019 à 00:55, Richard Kimberly Heck a écrit : We are sorely lacking daily builds for stable releases. If we knew how to automate these, that could be done by our CI tools. I have taken a look at the Ubuntu side of things, and ran away screaming. I do not have the time to invest in even

Re: [LyX/master] Reset layout when inserting an inset over full paragraph(s)

On Thu, Sep 12, 2019 at 10:04:19AM +0200, Jean-Marc Lasgouttes wrote: > But if there is a consensus about 2.3, I am OK with it. I was not actually suggesting to push it into official 2.3.x, just wanted to know whether putting into my private patchset is likely to cause some harm... Pavel

Re: [LyX/master] Reset layout when inserting an inset over full paragraph(s)

On 9/12/19 3:43 PM, Jean-Marc Lasgouttes wrote: > Le 12/09/2019 à 20:54, Richard Kimberly Heck a écrit : >>> But if there is a consensus about 2.3, I am OK with it. >> >> The basic idea seems correct. I've played around with this before, too. >> I haven't tested, but one question that arose when I

Re: [LyX/master] Reset layout when inserting an inset over full paragraph(s)

Le 12/09/2019 à 20:54, Richard Kimberly Heck a écrit : But if there is a consensus about 2.3, I am OK with it. The basic idea seems correct. I've played around with this before, too. I haven't tested, but one question that arose when I was dealing with this was with lists and depth issues.

Re: [LyX/master] Reset layout when inserting an inset over full paragraph(s)

On 9/12/19 4:04 AM, Jean-Marc Lasgouttes wrote: > Le 12/09/2019 à 01:38, Pavel Sanda a écrit : >> I like this patch. Is it safe to put it into my personal 2.3 patchset >> (in the terms of the patch being congruent with old 2.3 codebase >> or way too many changes were done around in 2.4?) > > I

Re: [LyX/master] Reset layout when inserting an inset over full paragraph(s)

Le 12/09/2019 à 01:38, Pavel Sanda a écrit : I like this patch. Is it safe to put it into my personal 2.3 patchset (in the terms of the patch being congruent with old 2.3 codebase or way too many changes were done around in 2.4?) I like the patch too, and I checked that it applies almost

Re: [LyX/master] Reset layout when inserting an inset over full paragraph(s)

On Wed, Sep 11, 2019 at 10:26:44AM +0200, Jean-Marc Lasgouttes wrote: > commit e1be71da59e405a1c36769121b684c9d10333bff > Author: Jean-Marc Lasgouttes > Date: Wed Sep 4 16:13:22 2019 +0200 > > Reset layout when inserting an inset over full paragraph(s) > >

Re: Fwd: [Bug 1815278] [NEW] LyX restores the same cursor position wherever it was placed next time(s)

--- Message transféré > Sujet : [Bug 1815278] [NEW] LyX restores the same cursor position > wherever it was placed next time(s) > Date : Sat, 09 Feb 2019 10:48:49 - > De : Konstantin Boyandin <1815...@bugs.launchpad.net> > Répondre à : Bug 1815278 <1815...@bugs.launchpad.ne

Fwd: [Bug 1815278] [NEW] LyX restores the same cursor position wherever it was placed next time(s)

An interesting bug report from ubuntu bugs. I did not try confirm the bug. JMarc Message transféré Sujet : [Bug 1815278] [NEW] LyX restores the same cursor position wherever it was placed next time(s) Date : Sat, 09 Feb 2019 10:48:49 - De : Konstantin Boyandin <1

Re: Ctrl+s inserts an omega sign instead of saving the document, escape inserts a sun sign

833 apt update 834 apt install lyx Shortcuts work fine after this update! Have a nice day, Paul On Fri, Nov 16, 2018 at 5:21 PM Richard Kimberly Heck wrote: > On 11/16/18 9:24 AM, Paul Rougieux wrote: > > Dear Lyx Devel, > > I have found a fix by editing the key bindings as

Re: Ctrl+s inserts an omega sign instead of saving the document, escape inserts a sun sign

On 11/16/18 9:24 AM, Paul Rougieux wrote: > Dear Lyx Devel, >   > I have found a fix by editing the key bindings as follows: > \bind "C-s" "buffer-write" > \bind "Escape" "escape" What OS was this? Which LyX version? It'd be nice to try to

Re: Ctrl+s inserts an omega sign instead of saving the document, escape inserts a sun sign

Dear Lyx Devel, I have found a fix by editing the key bindings as follows: \bind "C-s" "buffer-write" \bind "Escape" "escape" Still it's strange that those crucial shortcuts got overwritten. Have a nice day, Paul On Fri, Nov 16, 2018 at 12:22 PM Paul Ro

Re: Ctrl+s inserts an omega sign instead of saving the document, escape inserts a sun sign

Am Freitag, 16. November 2018 12:22:05 CET schrieb Paul Rougieux : > Dear Developers, > Lyx Shortcuts have a strange and annoying bug: > where ctrl+s inserts an omega symbol instead of saving the document, escape > inserts a sun symbol instead of escaping from a menu or window.

Ctrl+s inserts an omega sign instead of saving the document, escape inserts a sun sign

Dear Developers, Lyx Shortcuts have a strange and annoying bug: where ctrl+s inserts an omega symbol instead of saving the document, escape inserts a sun symbol instead of escaping from a menu or window. Screen shot attached. I don't know if it's related. A couple of days ago, I edited the Lyx

Re: Question on osuosl.org hosting service(s)

Thanks, Pavel, to taking this responsiblity. On 09/06/2018 10:37 AM, Pavel Sanda wrote: > Hi OSU Open Source Lab, > > I'm one of developers of LyX, open source document processor (www.lyx.org). > Our services (web/bug tracker system/git server/wiki site) used to be kindly > hosted for the past

Re: Latex Error: There\'s no line here to end

First, Thanks for your interest. Then, i sloved the problem by replace: empty {} in local layout with: {vspace{-3pt}} Do you observe the same behavior on your platform? No, lyx 2.3 is working nice and perfect. Besr regards بتاريخ ١٧‏/٠٦‏/٢٠١٧ ٩:٥٣ م، كتب "mn" : > On 16.06.17

Re: Mark line(s) on Reverse search instead of close position

Andrew Parsloe wrote: > I often wonder how to reply: to list, to all? For example I received three > copies of your reply: one addressed to me, one to lyx-devel, and one to > gmane. It was to avoid this situation that I've made a point of replying > only to the developers' or users' lists. I

Re: Mark line(s) on Reverse search instead of close position

at the position chosen in the pdf document. It is a bit tricky for me to always find the former position in my document. Since it is anyway not the exact position maybe it is possible to select the whole line(s) rather than a close position? You can try it in master after 5fbbf0f2. Thanks

Re: Mark line(s) on Reverse search instead of close position

document. It is a bit tricky for me to always find the former position in my document. Since it is anyway not the exact position maybe it is possible to select the whole line(s) rather than a close position? You can try it in master after 5fbbf0f2. Thanks. For some reason I cannot get Reverse search

Re: Mark line(s) on Reverse search instead of close position

the former position in my document. Since it is anyway not the exact position maybe it is possible to select the whole line(s) rather than a close position? You can try it in master after 5fbbf0f2. Thanks. For some reason I cannot get Reverse search to work with Sumatra. Maybe I set something

Re: Mark line(s) on Reverse search instead of close position

it is anyway not the exact position maybe it is possible to select the whole line(s) rather than a close position? You can try it in master after 5fbbf0f2. Thanks. For some reason I cannot get Reverse search to work with Sumatra. Maybe I set something wrong in preferences that I overlook

Re: LyXRC - %%s/scripts

Le 24/10/2016 à 16:29, Tommaso Cucinotta a écrit : On 24/10/2016 15:31, Scott Kostyshak wrote: Do not hesitate to commit to master once you have tested it. This is our playground, after all. Only stable is subject to authorization from Richard. +1. If it worked for you and the change makes

Re: LyXRC - %%s/scripts

On 24/10/2016 15:31, Scott Kostyshak wrote: Do not hesitate to commit to master once you have tested it. This is our playground, after all. Only stable is subject to authorization from Richard. +1. If it worked for you and the change makes logical sense, I would say go ahead for master.

Re: LyXRC - %%s/scripts

On Mon, Oct 24, 2016 at 09:42:10AM +0200, Jean-Marc Lasgouttes wrote: > Le 24/10/2016 à 08:27, Tommaso Cucinotta a écrit : > > shall I commit to regular master, or would you like to give it a try first? > > Do not hesitate to commit to master once you have tested it. This is our > playground,

Re: LyXRC - %%s/scripts

Le 24/10/2016 à 08:27, Tommaso Cucinotta a écrit : On 24/10/2016 03:32, Scott Kostyshak wrote: On Sun, Oct 23, 2016 at 09:47:10PM +0200, Tommaso Cucinotta wrote: For me, this [1] fixes the issue: commit d5495caa in tommaso/master Thanks for coming up with a fix shall I commit to regular

Re: LyXRC - %%s/scripts

On 24/10/2016 03:32, Scott Kostyshak wrote: On Sun, Oct 23, 2016 at 09:47:10PM +0200, Tommaso Cucinotta wrote: For me, this [1] fixes the issue: commit d5495caa in tommaso/master Thanks for coming up with a fix shall I commit to regular master, or would you like to give it a try first?

Re: LyXRC - %%s/scripts

On Sun, Oct 23, 2016 at 09:47:10PM +0200, Tommaso Cucinotta wrote: > For me, this [1] fixes the issue: commit d5495caa in tommaso/master Thanks for coming up with a fix and sorry for the trouble my commit caused. > FYI, with this patch, I can finally have a proper patch for gnuplot scripts: >

Re: LyXRC - %%s/scripts

: a6053cf9 T. [1] tommaso@tommylap:~/lyx-trunk-ws/lyx$ git show d5495caa commit d5495caa Author: Tommaso Cucinotta <tomm...@lyx.org> Date: Sun Oct 23 21:35:56 2016 +0200 Fix bug in replacement of "$$s/" in converter commands, introduced in 8b66f9ce. diff --gi

Re: LyXRC - %%s/scripts

Am 19.10.2016 um 23:54 schrieb Tommaso Cucinotta <tomm...@lyx.org>: > > On 19/10/2016 23:10, Scott Kostyshak wrote: >> See 8b66f9ce. Perhaps the commit introduced a bug? > > might be. AFAICS, the attempt to replace $$s centrally in > filetools.cpp:commandPrep() fails

Re: LyXRC - %%s/scripts

On Wed, Oct 19, 2016 at 11:54:06PM +0200, Tommaso Cucinotta wrote: > Do you know when / under what condition, such a Python intermediate script is > created and how to prevent that? I have no idea. If you don't figure out the problem/fix, I can probably take a look at this next week. Scott

Re: LyXRC - %%s/scripts

On 19/10/2016 23:10, Scott Kostyshak wrote: See 8b66f9ce. Perhaps the commit introduced a bug? might be. AFAICS, the attempt to replace $$s centrally in filetools.cpp:commandPrep() fails because the string getting there, is NOT the converter command as from the \converter line, but rather

Re: LyXRC - %%s/scripts

On Wed, Oct 19, 2016 at 10:57:05PM +0200, Tommaso Cucinotta wrote: > Hi, > > LyXRC specifies "%%s/scripts/" as converter command, but how/where is the > %%s/ expanded/processed, when running those commands? See 8b66f9ce. Perhaps the commit introduced a bug?

LyXRC - %%s/scripts

Hi, LyXRC specifies "%%s/scripts/" as converter command, but how/where is the %%s/ expanded/processed, when running those commands? Trying to add this in ~/.lyx/lyxrc.defaults +\converter gnuplot pdf6 "$$s/scripts/gnuplot2pdf.sh $$i $$o" ""'''

Re: Mark line(s) on Reverse search instead of close position

it is possible to select the whole line(s) rather than a close position? You can try it in master after 5fbbf0f2.

Re: Mark line(s) on Reverse search instead of close position

rsor at a position only *close* to but > > > > not exactly at the position chosen in the pdf document. It is a bit > > > > tricky for me to always find the former position in my document. Since > > > > it is anyway not the exact position maybe it is possibl

Re: Mark line(s) on Reverse search instead of close position

the former position in my document. Since it is anyway not the exact position maybe it is possible to select the whole line(s) rather than a close position? This is quite easy to do. It would select text up to the next recorded entry, as is done during error reporting. Any objection? Not sure

Re: Mark line(s) on Reverse search instead of close position

it is anyway not the exact position maybe it is possible to select the whole line(s) rather than a close position? This is quite easy to do. It would select text up to the next recorded entry, as is done during error reporting. Any objection? Not sure you are asking me in particular or people

Re: Mark line(s) on Reverse search instead of close position

it is possible to select the whole line(s) rather than a close position? This is quite easy to do. It would select text up to the next recorded entry, as is done during error reporting. Any objection?

Re: [LyX/master] Reset anchor before selecting with S-button1

Le 29/08/2016 à 17:02, Richard Heck a écrit : You're right of course. Fixed at 68d825fed. Richard, this is candidate for branch, unless you are in a hurry prefer that I revert the faulty commit instead. Go ahead. Thanks, done. JMarc

Re: [LyX/master] Reset anchor before selecting with S-button1

On 08/29/2016 06:08 AM, Jean-Marc Lasgouttes wrote: > Le 29/08/2016 à 00:27, Guillaume Munch a écrit : >> This causes a regression in master and stable: when selecting with >> S-button1 a second time, the previous selection is unselected. This is >> inconsistent with ot

Mark line(s) on Reverse search instead of close position

On Reverse search LyX puts the cursor at a position only *close* to but not exactly at the position chosen in the pdf document. It is a bit tricky for me to always find the former position in my document. Since it is anyway not the exact position maybe it is possible to select the whole line(s

Re: [LyX/master] Reset anchor before selecting with S-button1

Le 29/08/2016 à 00:27, Guillaume Munch a écrit : This causes a regression in master and stable: when selecting with S-button1 a second time, the previous selection is unselected. This is inconsistent with other software and I am not sure that this was intended. You're right of course. Fixed

Re: [LyX/master] Reset anchor before selecting with S-button1

Le 23/08/2016 à 11:23, Jean-Marc Lasgouttes a écrit : commit b583fb26e89ccdc242e5c11d5e9d8b0606bee957 Author: Jean-Marc Lasgouttes <lasgout...@lyx.org> Date: Tue Aug 23 12:22:35 2016 +0200 Reset anchor before selecting with S-button1 --- src/Text3.cpp |1 + 1 files chan

Re: Beta hopefully soon, only waiting on Windows installer(s)

>>>Hopefully we will release beta1 very soon. As far as I'm concerned, the > >>>only thing we are waiting for is the Windows installer(s). > >> > >>Note also that we have a memory corruption in undo: > >>http://www.lyx.org/trac/ticket/9916 > >>

Re: Beta hopefully soon, only waiting on Windows installer(s)

Le 21/01/2016 11:37, Scott Kostyshak a écrit : On Wed, Jan 20, 2016 at 03:34:05PM +0100, Jean-Marc Lasgouttes wrote: Good. Hopefully we can get a final review and +1 for Guillaume's pending patches regarding #9794 and then I think we will be ready for beta. I would like to mention that

Re: Beta hopefully soon, only waiting on Windows installer(s)

On Thu, Jan 21, 2016 at 12:13:18AM +0100, Uwe Stöhr wrote: > Am 20.01.2016 um 03:40 schrieb Scott Kostyshak: > > >I see. It is nice of you but you really should not sacrifice your > >health. > > It is not what you think. Some hours less sleep in a week does not sacrifice > the health. For me it

Re: Beta hopefully soon, only waiting on Windows installer(s)

Am 20.01.2016 um 03:40 schrieb Scott Kostyshak: I see. It is nice of you but you really should not sacrifice your health. It is not what you think. Some hours less sleep in a week does not sacrifice the health. That is a good point. I often do not think often enough about marketing, even

Re: Beta hopefully soon, only waiting on Windows installer(s)

Le 17/01/2016 13:33, Jean-Marc Lasgouttes a écrit : Le 17/01/16 13:32, Jean-Marc Lasgouttes a écrit : Le 16/01/16 23:43, Scott Kostyshak a écrit : Dear all, Hopefully we will release beta1 very soon. As far as I'm concerned, the only thing we are waiting for is the Windows installer(s

Re: Beta hopefully soon, only waiting on Windows installer(s)

Am 19.01.2016 um 04:53 schrieb Scott Kostyshak: Please, do not sacrifice hours of sleep. I know but I had only this week and will soon have not much time for LyX. So the task was now or never. This was not my intention. I just meant that the Windows installer was the only thing left

Re: Beta hopefully soon, only waiting on Windows installer(s)

On Tue, Jan 19, 2016 at 09:59:07PM +0100, Uwe Stöhr wrote: > Am 19.01.2016 um 04:53 schrieb Scott Kostyshak: > > >Please, do not sacrifice hours of sleep. > > I know but I had only this week and will soon have not much time for LyX. So > the task was now or never. I see. It is nice of you but

Re: Beta hopefully soon, only waiting on Windows installer(s)

Am 18. Januar 2016 09:33:17 MEZ, schrieb "Uwe Stöhr" <uwesto...@web.de>: > > >  Original Message   >From: Peter Kümmel >Sent: Montag, 18. Januar 2016 03:49 >To: Uwe Stöhr; Scott Kostyshak; LyX Developers >Subject: Re: Beta hopefully soon, only waiting on Windo

Re: Beta hopefully soon, only waiting on Windows installer(s)

  Original Message   From: Peter Kümmel Sent: Montag, 18. Januar 2016 03:49 To: Uwe Stöhr; Scott Kostyshak; LyX Developers Subject: Re: Beta hopefully soon, only waiting on Windows installer(s) Am 18. Januar 2016 01:24:38 MEZ, schrieb "Uwe Stöhr" <uwesto...@web.de>: >Am

Re: Beta hopefully soon, only waiting on Windows installer(s)

To summarize: After a very tiring trip abroad I invested almost all spare time‎ and hours of sleep to get ready for beta1. Although I don't know much about CMake and compilers I was able to overcome all corner cases. I reported the CMake bugs I found. I am able to build LyX with Qt 5.5.1 and

Re: Beta hopefully soon, only waiting on Windows installer(s)

On Tue, Jan 19, 2016 at 01:10:22AM +0100, Uwe Stöhr wrote: > To summarize: > > After a very tiring trip abroad I invested almost all spare time‎ and hours > of sleep to get ready for beta1. Please, do not sacrifice hours of sleep. No one here wants you to do this. We want LyX development to be

Re: Beta hopefully soon, only waiting on Windows installer(s)

On Mon, Jan 18, 2016 at 01:17:09AM +0100, Uwe Stöhr wrote: > Am 16.01.2016 um 23:43 schrieb Scott Kostyshak: > > >Hopefully we will release beta1 very soon. As far as I'm concerned, the > >only thing we are waiting for is the Windows installer(s). > > Why? I reported t

Re: Beta hopefully soon, only waiting on Windows installer(s)

On Sun, Jan 17, 2016 at 07:12:22PM +0100, Peter Kümmel wrote: > Am 17.01.2016 um 08:06 schrieb Scott Kostyshak: > > > >>I would release the beta with the available Windows installer, but would > >>also mention, that because of men power this time on Windows there will be > >>nothing better that

Re: Beta hopefully soon, only waiting on Windows installer(s)

Am 17.01.2016 um 08:06 schrieb Scott Kostyshak: I would release the beta with the available Windows installer, but would also mention, that because of men power this time on Windows there will be nothing better that beta quality. In the announcement you could mention that we are busy

Re: Beta hopefully soon, only waiting on Windows installer(s)

Am 16.01.2016 um 23:43 schrieb Scott Kostyshak: Hopefully we will release beta1 very soon. As far as I'm concerned, the only thing we are waiting for is the Windows installer(s). Why? I reported that I am ready on Friday. regards Uwe

Re: Beta hopefully soon, only waiting on Windows installer(s)

Am 17.01.2016 um 03:22 schrieb Peter Kümmel: I would release the beta with the available Windows installer, but would also mention, that because of men power this time on Windows there will be nothing better that beta quality. In the announcement you could mention that we are busy improving

Re: Beta hopefully soon, only waiting on Windows installer(s)

Am 18. Januar 2016 01:24:38 MEZ, schrieb "Uwe Stöhr" : >Am 17.01.2016 um 03:22 schrieb Peter Kümmel: > >> I would release the beta with the available Windows installer, but >would also mention, that because of men power this time on Windows >there will be nothing better that beta

Re: Beta hopefully soon, only waiting on Windows installer(s)

>And to repeat myself, building the installer was never a problem, Great! And it looks like necessary stuff is committet by you to the repository. Ideally all files needed for the installer would be part of the repository, but this would mean to add multiple MB of Windows binaries which is not

Re: Beta hopefully soon, only waiting on Windows installer(s)

Le 16/01/16 23:43, Scott Kostyshak a écrit : Dear all, Hopefully we will release beta1 very soon. As far as I'm concerned, the only thing we are waiting for is the Windows installer(s). Note also that we have a memory corruption in undo: http://www.lyx.org/trac/ticket/9916 I'd appreciate

Re: Beta hopefully soon, only waiting on Windows installer(s)

Le 17/01/16 13:32, Jean-Marc Lasgouttes a écrit : Le 16/01/16 23:43, Scott Kostyshak a écrit : Dear all, Hopefully we will release beta1 very soon. As far as I'm concerned, the only thing we are waiting for is the Windows installer(s). Note also that we have a memory corruption in undo: http

Re: Beta hopefully soon, only waiting on Windows installer(s)

Am 16. Januar 2016 23:43:12 MEZ, schrieb Scott Kostyshak <skost...@lyx.org>: >Dear all, > >Hopefully we will release beta1 very soon. As far as I'm concerned, the >only thing we are waiting for is the Windows installer(s). The reason >why we are waiting for this an

Re: Beta hopefully soon, only waiting on Windows installer(s)

Le 16/01/2016 22:43, Scott Kostyshak a écrit : Dear all, Hopefully we will release beta1 very soon. As far as I'm concerned, the only thing we are waiting for is the Windows installer(s). The reason why we are waiting for this and not just proceeding with the other parts of the beta1 release

Beta hopefully soon, only waiting on Windows installer(s)

Dear all, Hopefully we will release beta1 very soon. As far as I'm concerned, the only thing we are waiting for is the Windows installer(s). The reason why we are waiting for this and not just proceeding with the other parts of the beta1 release is that there might be changes needed to the source

Re: Beta hopefully soon, only waiting on Windows installer(s)

On Sun, Jan 17, 2016 at 02:30:06AM +, Guillaume Munch wrote: > Le 16/01/2016 22:43, Scott Kostyshak a écrit : > >Dear all, > > > >Hopefully we will release beta1 very soon. As far as I'm concerned, the > >only thing we are waiting for is the Windows install

Re: Beta hopefully soon, only waiting on Windows installer(s)

On Sun, Jan 17, 2016 at 03:22:46AM +0100, Peter Kümmel wrote: > Am 16. Januar 2016 23:43:12 MEZ, schrieb Scott Kostyshak : > I would release the beta with the available Windows installer, but would also > mention, that because of men power this time on Windows there will be

Re: Can I take over C-S-PageUp binding for tab moving?

Am Mittwoch, 8. April 2015 um 01:29:11, schrieb Scott Kostyshak skost...@lyx.org On Sun, Apr 5, 2015 at 8:40 PM, Richard Heck rgh...@lyx.org wrote: On 04/05/2015 07:47 PM, Scott Kostyshak wrote: It is currently bound to buffer-begin-select. But this LFUN is also bound to C-S-Home. I

Re: Can I take over C-S-PageUp binding for tab moving?

to buffer-begin-select. But this LFUN is also bound to C-S-Home. I would like to implement buffer-move-next, which will move the tab up one spot (and similar for C-S-PageDown. This feature and keybinding would be consistent with tab behavior in Chromium, Firefox, and Nautilus. Seems

Re: Can I take over C-S-PageUp binding for tab moving?

/05/2015 07:47 PM, Scott Kostyshak wrote: It is currently bound to buffer-begin-select. But this LFUN is also bound to C-S-Home. I would like to implement buffer-move-next, which will move the tab up one spot (and similar for C-S-PageDown. This feature and keybinding would be consistent

Re: Can I take over C-S-PageUp binding for tab moving?

Mittwoch, 8. April 2015 um 01:29:11, schrieb Scott Kostyshak skost...@lyx.org On Sun, Apr 5, 2015 at 8:40 PM, Richard Heck rgh...@lyx.org wrote: On 04/05/2015 07:47 PM, Scott Kostyshak wrote: It is currently bound to buffer-begin-select. But this LFUN is also bound to C-S-Home. I would

Re: Can I take over C-S-PageUp binding for tab moving?

to buffer-begin-select. But this LFUN is also bound to C-S-Home. I would like to implement buffer-move-next, which will move the tab up one spot (and similar for C-S-PageDown. This feature and keybinding would be consistent with tab behavior in Chromium, Firefox, and Nautilus

Re: Can I take over C-S-PageUp binding for tab moving?

: On 04/05/2015 07:47 PM, Scott Kostyshak wrote: It is currently bound to buffer-begin-select. But this LFUN is also bound to C-S-Home. I would like to implement buffer-move-next, which will move the tab up one spot (and similar for C-S-PageDown. This feature and keybinding would

Re: Can I take over C-S-PageUp binding for tab moving?

On Sun, Apr 5, 2015 at 8:40 PM, Richard Heck rgh...@lyx.org wrote: On 04/05/2015 07:47 PM, Scott Kostyshak wrote: It is currently bound to buffer-begin-select. But this LFUN is also bound to C-S-Home. I would like to implement buffer-move-next, which will move the tab up one spot

Re: Can I take over C-S-PageUp binding for tab moving?

elect. But this LFUN is also > >> bound to C-S-Home. I would like to implement buffer-move-next, which > >> will move the tab up one spot (and similar for C-S-PageDown. This > >> feature and keybinding would be consistent with tab behavior in > >> Chromium, Firefox,

Re: Can I take over C-S-PageUp binding for tab moving?

5 07:47 PM, Scott Kostyshak wrote: > > >> > > >> It is currently bound to buffer-begin-select. But this LFUN is also > > >> bound to C-S-Home. I would like to implement buffer-move-next, which > > >> will move the tab up one spot (and similar for C-S-PageDown. This >

Re: Can I take over C-S-PageUp binding for tab moving?

:40 PM, Richard Heck <rgh...@lyx.org> wrote: >> > > On 04/05/2015 07:47 PM, Scott Kostyshak wrote: >> > >> >> > >> It is currently bound to buffer-begin-select. But this LFUN is also >> > >> bound to C-S-Home. I would like to im

Re: Can I take over C-S-PageUp binding for tab moving?

29:11, schrieb Scott Kostyshak >>> <skost...@lyx.org> >>> > On Sun, Apr 5, 2015 at 8:40 PM, Richard Heck <rgh...@lyx.org> wrote: >>> > > On 04/05/2015 07:47 PM, Scott Kostyshak wrote: >>> > >> >>> > >> It is currently bound to

Re: Can I take over C-S-PageUp binding for tab moving?

05/2015 07:47 PM, Scott Kostyshak wrote: >>>> > >> >>>> > >> It is currently bound to buffer-begin-select. But this LFUN is also >>>> > >> bound to C-S-Home. I would like to implement buffer-move-next, which >>>> > &

Re: Can I take over C-S-PageUp binding for tab moving?

> On Sun, Apr 5, 2015 at 8:40 PM, Richard Heck <rgh...@lyx.org> wrote: >>>>> > > On 04/05/2015 07:47 PM, Scott Kostyshak wrote: >>>>> > >> >>>>> > >> It is currently bound to buffer-begin-select. But this LFUN is also &

Re: Can I take over C-S-PageUp binding for tab moving?

ttwoch, 8. April 2015 um 01:29:11, schrieb Scott Kostyshak >>>>>> <skost...@lyx.org> >>>>>> > On Sun, Apr 5, 2015 at 8:40 PM, Richard Heck <rgh...@lyx.org> wrote: >>>>>> > > On 04/05/2015 07:47 PM, Scott Kostys

Re: Can I take over C-S-PageUp binding for tab moving?

On Sun, Apr 5, 2015 at 8:40 PM, Richard Heck rgh...@lyx.org wrote: On 04/05/2015 07:47 PM, Scott Kostyshak wrote: It is currently bound to buffer-begin-select. But this LFUN is also bound to C-S-Home. I would like to implement buffer-move-next, which will move the tab up one spot (and similar

Re: Can I take over C-S-PageUp binding for tab moving?

On Sun, Apr 5, 2015 at 8:40 PM, Richard Heck <rgh...@lyx.org> wrote: > On 04/05/2015 07:47 PM, Scott Kostyshak wrote: >> >> It is currently bound to buffer-begin-select. But this LFUN is also >> bound to C-S-Home. I would like to implement buffer-move-next, which >&

Re: Can I take over C-S-PageUp binding for tab moving?

On 04/05/2015 07:47 PM, Scott Kostyshak wrote: It is currently bound to buffer-begin-select. But this LFUN is also bound to C-S-Home. I would like to implement buffer-move-next, which will move the tab up one spot (and similar for C-S-PageDown. This feature and keybinding would be consistent

Can I take over C-S-PageUp binding for tab moving?

It is currently bound to buffer-begin-select. But this LFUN is also bound to C-S-Home. I would like to implement buffer-move-next, which will move the tab up one spot (and similar for C-S-PageDown. This feature and keybinding would be consistent with tab behavior in Chromium, Firefox, and Nautilus

Can I take over C-S-PageUp binding for tab moving?

It is currently bound to buffer-begin-select. But this LFUN is also bound to C-S-Home. I would like to implement buffer-move-next, which will move the tab up one spot (and similar for C-S-PageDown. This feature and keybinding would be consistent with tab behavior in Chromium, Firefox, and Nautilus

Re: Can I take over C-S-PageUp binding for tab moving?

On 04/05/2015 07:47 PM, Scott Kostyshak wrote: It is currently bound to buffer-begin-select. But this LFUN is also bound to C-S-Home. I would like to implement buffer-move-next, which will move the tab up one spot (and similar for C-S-PageDown. This feature and keybinding would be consistent

  1   2   3   4   5   6   7   8   >