Corkboard code

Hi, I wanna have a look at the corkboard code, but haven't found a git branch anywhere, only Rob's bazaar repository with changes from February. Is there something more actual? Thanks, Peter

Re: Corkboard code

Op 17 okt. 2013 07:27 schreef Peter Kümmel syntheti...@gmx.net: Hi, I wanna have a look at the corkboard code, but haven't found a git branch anywhere, only Rob's bazaar repository with changes from February. Is there something more actual? The code thay Ashley produced lives somewhere on

Re: Corkboard code

On 17.10.2013 17:13, Vincent van Ravesteijn wrote: Op 17 okt. 2013 07:27 schreef Peter Kümmel syntheti...@gmx.net mailto:syntheti...@gmx.net: Hi, I wanna have a look at the corkboard code, but haven't found a git branch anywhere, only Rob's bazaar repository with changes from February. Is

Re: minor re-definition of the chunk inset

On Thu, Oct 17, 2013 at 5:01 AM, Scott Kostyshak skost...@lyx.org wrote: I had a quick chat with JMarc off-list, and it seems that the additional breaks could in some cases create a double \n and thus an unwanted paragraph break. Personally, I'm not sure how to reproduce such a case, but then

Moving forward with XHTML and EPUB export work

Hi all, I'm hoping to devote some time soon to working some more on XHTML and EPUB exporting, and here are a few questions I came up with while thinking about how to proceed: 1. Breaking an XHTML file into smaller files can lead to better performance in an EPUB document. I think I can modify the

Re: minor re-definition of the chunk inset

It is probably possible to commit Liviu's patch now and to improve on it later. Sorry I do not have time to look at it seriously now. JMarc Liviu Andronic landronim...@gmail.com a écrit : On Thu, Oct 17, 2013 at 5:01 AM, Scott Kostyshak skost...@lyx.org wrote: I had a quick chat with JMarc

Re: Moving forward with XHTML and EPUB export work

Josh Hieronymus wrote: 1. Breaking an XHTML file into smaller files can lead to better performance I think that for people who use XHTML as export format for different formats won't be happy about this. 3. There's certain metadata that is required for all EPUB documents in order to be valid

Clang's memory error detector.

Attached a patch to build with Clang and with its sanitize flags. It should help to detect wrong memory usage: http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation (Some sanitize flags are also available in GCC 4.7/4.8) Short build recipe for Linux: 1. Build Clang clone

[PATCH] Remove FreeBSD checks when defining USE_WCHAR_T.

The problems the comments in the build systems refer to seem to have been fixed for years. [1] says the checks in libstdc++ have been improved, and all supported FreeBSD versions enable wchar_t support unconditionally in libstdc++. Additionally, this needlessly impacts FreeBSD when libc++ is used

Re: minor re-definition of the chunk inset

On Wed, Oct 16, 2013 at 08:43:27PM +0200, Liviu Andronic wrote: On Wed, Oct 16, 2013 at 7:27 PM, Scott Kostyshak skost...@lyx.org wrote: With the attached patch applied, the above construct becomes: \centering{} = 2+2 #chunk @ and compilation proceeds without a hitch. What do

Re: minor re-definition of the chunk inset

Le 17/10/13 22:44, Enrico Forestieri a écrit : On Wed, Oct 16, 2013 at 08:43:27PM +0200, Liviu Andronic wrote: On Wed, Oct 16, 2013 at 7:27 PM, Scott Kostyshak skost...@lyx.org wrote: With the attached patch applied, the above construct becomes: \centering{} = 2+2 #chunk @ and compilation

Re: [PATCH] Remove FreeBSD checks when defining USE_WCHAR_T.

Le 17/10/13 22:39, Raphael Kubo da Costa a écrit : The problems the comments in the build systems refer to seem to have been fixed for years. [1] says the checks in libstdc++ have been improved, and all supported FreeBSD versions enable wchar_t support unconditionally in libstdc++. Additionally,

Re: Moving forward with XHTML and EPUB export work

On Thu, Oct 17, 2013 at 1:49 PM, Pavel Sanda sa...@lyx.org wrote: Josh Hieronymus wrote: 1. Breaking an XHTML file into smaller files can lead to better performance I think that for people who use XHTML as export format for different formats won't be happy about this. Indeed, I would be

Re: git help!

On Wed, Oct 16, 2013 at 5:23 PM, John Tapsell johnf...@gmail.com wrote: Like it says, that commit is a merge.. You can just checkout that commit: git checkout HEAD@{27} or reset to that commit: git reset HEAD@{27} Personally I advise against using git reset except when you *really* know

Re: git help!

Thanx both! At least I learnt that even when u feel like having lost all the work messing around with not so well-known options of git, actually there's some way to recover, if the work had been committed. T. On 17/10/13 23:17, Nico Williams wrote: On Wed, Oct 16, 2013 at 5:23 PM, John

Re: git help!

In general, if you stay away from destructive operations, git is quite safe. If you find yourself wanting to perform a destructive operation, make sure first that any extant changes in your workspace are committed so that you can always get them back from the reflog. Committing stuff you don't

Re: git help!

Nico Williams schreef op 18-10-2013 0:59: In general, if you stay away from destructive operations, git is quite safe. If you find yourself wanting to perform a destructive operation, make sure first that any extant changes in your workspace are committed so that you can always get them back

Re: git help!

I once made a mistake with git, too, that took a while to recover. IMHO git works well if (1) You are very careful and RTFM closely before using reset, rebase. (2) If any option has --hard, see above, and read up on the same topic on other sources, or ask someone, before proceeding. (3) Be

Re: Corkboard code

Peter Kümmel schreef op 17-10-2013 17:45: On 17.10.2013 17:13, Vincent van Ravesteijn wrote: Op 17 okt. 2013 07:27 schreef Peter Kümmel syntheti...@gmx.net mailto:syntheti...@gmx.net: Hi, I wanna have a look at the corkboard code, but haven't found a git branch anywhere, only Rob's bazaar

Re: Corkboard code

Hey all, I'm in the process of merging this code into the LyX codebase. I'll push what I have as soon as I have a chance. (Probably tomorrow or Saturday.) Rob

Re: [PATCH] Remove FreeBSD checks when defining USE_WCHAR_T.

Jean-Marc Lasgouttes schreef op 17-10-2013 23:03: Le 17/10/13 22:39, Raphael Kubo da Costa a écrit : The problems the comments in the build systems refer to seem to have been fixed for years. [1] says the checks in libstdc++ have been improved, and all supported FreeBSD versions enable

Re: #8703: 'new shortcut' box closes if no shortcut

Scott Kostyshak schreef op 15-10-2013 21:51: On Mon, Oct 7, 2013 at 6:43 PM, Scott Kostyshak skost...@lyx.org wrote: On Sun, Oct 6, 2013 at 7:12 AM, Martin Hoffmann hoffi...@gmail.com wrote: On 06.10.2013 10:25, Jürgen Spitzmüller wrote: Scott Kostyshak wrote: Welcome to the list! Yes,

Re: git help!

On Thu, Oct 17, 2013 at 8:11 PM, Cyrille Artho c.ar...@aist.go.jp wrote: I once made a mistake with git, too, that took a while to recover. IMHO git works well if (1) You are very careful and RTFM closely before using reset, rebase. Rebase is not destructive: your commits remain available

Re: git help!

On Thu, Oct 17, 2013 at 8:02 PM, Vincent van Ravesteijn v...@lyx.org wrote: Nico Williams schreef op 18-10-2013 0:59: The ironic thing using Git is that it is very safe if and only if you know your way around with Git. I remember that when I started using Git, I frequently lost stuff, and it

Corkboard code

Hi, I wanna have a look at the corkboard code, but haven't found a git branch anywhere, only Rob's bazaar repository with changes from February. Is there something more actual? Thanks, Peter

Re: Corkboard code

Op 17 okt. 2013 07:27 schreef "Peter Kümmel" : > > Hi, I wanna have a look at the corkboard code, but haven't > found a git branch anywhere, only Rob's bazaar repository with > changes from February. Is there something more actual? > The code thay Ashley produced lives

Re: Corkboard code

On 17.10.2013 17:13, Vincent van Ravesteijn wrote: Op 17 okt. 2013 07:27 schreef "Peter Kümmel" >: Hi, I wanna have a look at the corkboard code, but haven't found a git branch anywhere, only Rob's bazaar repository with changes from February.

Re: minor re-definition of the chunk inset

On Thu, Oct 17, 2013 at 5:01 AM, Scott Kostyshak wrote: >> I had a quick chat with JMarc off-list, and it seems that the >> additional breaks could in some cases create a double \n and thus an >> unwanted paragraph break. Personally, I'm not sure how to reproduce >> such a case,

Moving forward with XHTML and EPUB export work

Hi all, I'm hoping to devote some time soon to working some more on XHTML and EPUB exporting, and here are a few questions I came up with while thinking about how to proceed: 1. Breaking an XHTML file into smaller files can lead to better performance in an EPUB document. I think I can modify the

Re: minor re-definition of the chunk inset

It is probably possible to commit Liviu's patch now and to improve on it later. Sorry I do not have time to look at it seriously now. JMarc Liviu Andronic a écrit : >On Thu, Oct 17, 2013 at 5:01 AM, Scott Kostyshak >wrote: >>> I had a quick chat

Re: Moving forward with XHTML and EPUB export work

Josh Hieronymus wrote: > 1. Breaking an XHTML file into smaller files can lead to better performance I think that for people who use XHTML as export format for different formats won't be happy about this. > 3. There's certain metadata that is required for all EPUB documents in > order to be

Clang's memory error detector.

Attached a patch to build with Clang and with its "sanitize" flags. It should help to detect wrong memory usage: http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation (Some sanitize flags are also available in GCC 4.7/4.8) Short build recipe for Linux: 1. Build Clang

[PATCH] Remove FreeBSD checks when defining USE_WCHAR_T.

The problems the comments in the build systems refer to seem to have been fixed for years. [1] says the checks in libstdc++ have been improved, and all supported FreeBSD versions enable wchar_t support unconditionally in libstdc++. Additionally, this needlessly impacts FreeBSD when libc++ is used

Re: minor re-definition of the chunk inset

On Wed, Oct 16, 2013 at 08:43:27PM +0200, Liviu Andronic wrote: > On Wed, Oct 16, 2013 at 7:27 PM, Scott Kostyshak wrote: > >> With the attached patch applied, the above construct becomes: > >> \centering{} > >> <<>>= > >> 2+2 #chunk > >> @ > >> > >> and compilation proceeds

Re: minor re-definition of the chunk inset

Le 17/10/13 22:44, Enrico Forestieri a écrit : On Wed, Oct 16, 2013 at 08:43:27PM +0200, Liviu Andronic wrote: On Wed, Oct 16, 2013 at 7:27 PM, Scott Kostyshak wrote: With the attached patch applied, the above construct becomes: \centering{} <<>>= 2+2 #chunk @ and

Re: [PATCH] Remove FreeBSD checks when defining USE_WCHAR_T.

Le 17/10/13 22:39, Raphael Kubo da Costa a écrit : The problems the comments in the build systems refer to seem to have been fixed for years. [1] says the checks in libstdc++ have been improved, and all supported FreeBSD versions enable wchar_t support unconditionally in libstdc++. Additionally,

Re: Moving forward with XHTML and EPUB export work

On Thu, Oct 17, 2013 at 1:49 PM, Pavel Sanda wrote: > Josh Hieronymus wrote: >> 1. Breaking an XHTML file into smaller files can lead to better performance > > I think that for people who use XHTML as export format for different formats > won't be happy about this. Indeed, I would

Re: git help!

On Wed, Oct 16, 2013 at 5:23 PM, John Tapsell wrote: > Like it says, that commit is a merge.. > > You can just checkout that commit: git checkout HEAD@{27} > > or reset to that commit: git reset HEAD@{27} Personally I advise against using git reset except when you *really*

Re: git help!

Thanx both! At least I learnt that even when u feel like having lost all the work messing around with not so well-known options of git, actually there's some way to recover, if the work had been committed. T. On 17/10/13 23:17, Nico Williams wrote: > On Wed, Oct 16, 2013 at 5:23 PM, John

Re: git help!

In general, if you stay away from destructive operations, git is quite safe. If you find yourself wanting to perform a destructive operation, make sure first that any extant changes in your workspace are committed so that you can always get them back from the reflog. Committing stuff you don't

Re: git help!

Nico Williams schreef op 18-10-2013 0:59: In general, if you stay away from destructive operations, git is quite safe. If you find yourself wanting to perform a destructive operation, make sure first that any extant changes in your workspace are committed so that you can always get them back

Re: git help!

I once made a mistake with git, too, that took a while to recover. IMHO git works well if (1) You are very careful and RTFM closely before using "reset", "rebase". (2) If any option has "--hard", see above, and read up on the same topic on other sources, or ask someone, before proceeding.

Re: Corkboard code

Peter Kümmel schreef op 17-10-2013 17:45: On 17.10.2013 17:13, Vincent van Ravesteijn wrote: Op 17 okt. 2013 07:27 schreef "Peter Kümmel" >: Hi, I wanna have a look at the corkboard code, but haven't found a git branch anywhere, only Rob's

Re: Corkboard code

Hey all, I'm in the process of merging this code into the LyX codebase. I'll push what I have as soon as I have a chance. (Probably tomorrow or Saturday.) Rob

Re: [PATCH] Remove FreeBSD checks when defining USE_WCHAR_T.

Jean-Marc Lasgouttes schreef op 17-10-2013 23:03: Le 17/10/13 22:39, Raphael Kubo da Costa a écrit : The problems the comments in the build systems refer to seem to have been fixed for years. [1] says the checks in libstdc++ have been improved, and all supported FreeBSD versions enable

Re: #8703: 'new shortcut' box closes if no shortcut

Scott Kostyshak schreef op 15-10-2013 21:51: On Mon, Oct 7, 2013 at 6:43 PM, Scott Kostyshak wrote: On Sun, Oct 6, 2013 at 7:12 AM, Martin Hoffmann wrote: On 06.10.2013 10:25, Jürgen Spitzmüller wrote: Scott Kostyshak wrote: Welcome to the list! Yes,

Re: git help!

On Thu, Oct 17, 2013 at 8:11 PM, Cyrille Artho wrote: > I once made a mistake with git, too, that took a while to recover. > > IMHO git works well if > > (1) You are very careful and RTFM closely before using "reset", "rebase". Rebase is not destructive: your commits remain

Re: git help!

On Thu, Oct 17, 2013 at 8:02 PM, Vincent van Ravesteijn wrote: > Nico Williams schreef op 18-10-2013 0:59: > > The ironic thing using Git is that it is very safe if and only if you know > your way around with Git. I remember that when I started using Git, I > frequently lost stuff,