Re: Missing features in Flex insets and style definition question

Le 19/07/2011 03:21, Uwe Stöhr a écrit : This doesn't help, because in some cases you need the feature that LyX does not add nothing, no par break and also no newline but to continue with the code right after the command. Looks like a very badly coded macro, then. It might be easier to fix the

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 10:15, schrieb Jean-Marc Lasgouttes: This doesn't help, because in some cases you need the feature that LyX does not add nothing, no par break and also no newline but to continue with the code right after the command. Looks like a very badly coded macro, then. No, these cases

Re: Missing features in Flex insets and style definition question

Le 19/07/2011 13:47, Uwe Stöhr a écrit : No, these cases occur often. They are also not badly coded but standard and valid LaTeX that commands affect the paragraph they are in. What typical examples do you have in mind? JMarc

Re: Missing features in Flex insets and style definition question

Le 19/07/2011 13:47, Uwe Stöhr a écrit : Yes, it should be done eventually, and it is not very difficult. However, I think it would be better to factor in the two cases, rather then duplicating code (with subtly different bugs :) Will you do this or is this something for Richard? Should I open

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 14:23, schrieb Jean-Marc Lasgouttes: Le 19/07/2011 13:47, Uwe Stöhr a écrit : No, these cases occur often. They are also not badly coded but standard and valid LaTeX that commands affect the paragraph they are in. What typical examples do you have in mind? Pictures in

Re: Missing features in Flex insets and style definition question

Le 19/07/2011 14:28, Uwe Stöhr a écrit : Pictures in paragraphs (e.g. via picins, picinpar), wrapped floats, initials, email commands, address formatting commands, various scientific paper titling commands, ... Most of these are indeed part of a paragraph an thus should be handled by custom

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 14:38, schrieb Jean-Marc Lasgouttes: Most of these are indeed part of a paragraph an thus should be handled by custom insets. There is no point to change normal layouts for them. Yes, we already agree here. The only pint is that InsetLayout (a.k.a. flex inset) does not yet

Re: Missing features in Flex insets and style definition question

On 07/19/2011 08:25 AM, Jean-Marc Lasgouttes wrote: Le 19/07/2011 13:47, Uwe Stöhr a écrit : Yes, it should be done eventually, and it is not very difficult. However, I think it would be better to factor in the two cases, rather then duplicating code (with subtly different bugs :) Will you

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 15:08, schrieb Richard Heck: I'm still hoping to do some major reworking of how arguments are handled, i.e., get rid of that inset. What do you have in mind instead? I have now a lot of experience with it and find the current implementation acceptable, except of these 2 things:

Re: Missing features in Flex insets and style definition question

On 07/19/2011 09:58 AM, Uwe Stöhr wrote: Am 19.07.2011 15:08, schrieb Richard Heck: I'm still hoping to do some major reworking of how arguments are handled, i.e., get rid of that inset. What do you have in mind instead? I have now a lot of experience with it and find the current

Re: Missing features in Flex insets and style definition question

Richard Heck wrote: - the menu entry must read optional Argument, not short title (this is misleading and this appears often at the users list that people are confused, a short title is only ONE occurrence of optional arguments It's much less clear how you can label different insets

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 16:38, schrieb Richard Heck: - the menu entry must read optional Argument, not short title (this is misleading and this appears often at the users list that people are confused, a short title is only ONE occurrence of optional arguments It's much less clear how you can label

Re: Missing features in Flex insets and style definition question

On 07/19/2011 12:54 PM, Uwe Stöhr wrote: Am 19.07.2011 16:38, schrieb Richard Heck: - the menu entry must read optional Argument, not short title (this is misleading and this appears often at the users list that people are confused, a short title is only ONE occurrence of optional arguments

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 19:33, schrieb Richard Heck: I understand the idea, but it would make the Bibitem mess look neat. What do you mean? - the optional argument can sty as it is, only its menu entry in the Insert menu must be changed. There can be more than one optional argument. Think about

Re: Missing features in Flex insets and style definition question

On 07/19/2011 01:49 PM, Uwe Stöhr wrote: Am 19.07.2011 19:33, schrieb Richard Heck: I understand the idea, but it would make the Bibitem mess look neat. What do you mean? The InsetBibitem code is a complete disaster. There are all kinds of bugs associated with it, because we are trying to

Re: Missing features in Flex insets and style definition question

Le 19/07/2011 03:21, Uwe Stöhr a écrit : This doesn't help, because in some cases you need the feature that LyX does not add nothing, no par break and also no newline but to continue with the code right after the command. Looks like a very badly coded macro, then. It might be easier to fix the

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 10:15, schrieb Jean-Marc Lasgouttes: This doesn't help, because in some cases you need the feature that LyX does not add nothing, no par break and also no newline but to continue with the code right after the command. Looks like a very badly coded macro, then. No, these cases

Re: Missing features in Flex insets and style definition question

Le 19/07/2011 13:47, Uwe Stöhr a écrit : No, these cases occur often. They are also not "badly coded" but standard and valid LaTeX that commands affect the paragraph they are in. What typical examples do you have in mind? JMarc

Re: Missing features in Flex insets and style definition question

Le 19/07/2011 13:47, Uwe Stöhr a écrit : Yes, it should be done eventually, and it is not very difficult. However, I think it would be better to factor in the two cases, rather then duplicating code (with subtly different bugs :) Will you do this or is this something for Richard? Should I open

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 14:23, schrieb Jean-Marc Lasgouttes: Le 19/07/2011 13:47, Uwe Stöhr a écrit : No, these cases occur often. They are also not "badly coded" but standard and valid LaTeX that commands affect the paragraph they are in. What typical examples do you have in mind? Pictures in

Re: Missing features in Flex insets and style definition question

Le 19/07/2011 14:28, Uwe Stöhr a écrit : Pictures in paragraphs (e.g. via picins, picinpar), wrapped floats, initials, email commands, address formatting commands, various scientific paper titling commands, ... Most of these are indeed part of a paragraph an thus should be handled by custom

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 14:38, schrieb Jean-Marc Lasgouttes: Most of these are indeed part of a paragraph an thus should be handled by custom insets. There is no point to change normal layouts for them. Yes, we already agree here. The only pint is that InsetLayout (a.k.a. flex inset) does not yet

Re: Missing features in Flex insets and style definition question

On 07/19/2011 08:25 AM, Jean-Marc Lasgouttes wrote: > Le 19/07/2011 13:47, Uwe Stöhr a écrit : >>> Yes, it should be done eventually, and it is not very difficult. >>> However, I think it would be better >>> to factor in the two cases, rather then duplicating code (with subtly >>> different bugs

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 15:08, schrieb Richard Heck: I'm still hoping to do some major reworking of how arguments are handled, i.e., get rid of that inset. What do you have in mind instead? I have now a lot of experience with it and find the current implementation acceptable, except of these 2 things:

Re: Missing features in Flex insets and style definition question

On 07/19/2011 09:58 AM, Uwe Stöhr wrote: > Am 19.07.2011 15:08, schrieb Richard Heck: > >> I'm still hoping to do some major reworking of how arguments are >> handled, i.e., get rid of that inset. > > What do you have in mind instead? I have now a lot of experience with > it and find the current

Re: Missing features in Flex insets and style definition question

Richard Heck wrote: > > - the menu entry must read "optional Argument, not "short title" (this > > is misleading and this appears often at the users list that people are > > confused, a short title is only ONE occurrence of optional arguments > > It's much less clear how you can label different

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 16:38, schrieb Richard Heck: - the menu entry must read "optional Argument, not "short title" (this is misleading and this appears often at the users list that people are confused, a short title is only ONE occurrence of optional arguments It's much less clear how you can label

Re: Missing features in Flex insets and style definition question

On 07/19/2011 12:54 PM, Uwe Stöhr wrote: > Am 19.07.2011 16:38, schrieb Richard Heck: > >>> - the menu entry must read "optional Argument, not "short title" (this >>> is misleading and this appears often at the users list that people are >>> confused, a short title is only ONE occurrence of

Re: Missing features in Flex insets and style definition question

Am 19.07.2011 19:33, schrieb Richard Heck: I understand the idea, but it would make the Bibitem mess look neat. What do you mean? - the optional argument can sty as it is, only its menu entry in the Insert menu must be changed. There can be more than one optional argument. Think about

Re: Missing features in Flex insets and style definition question

On 07/19/2011 01:49 PM, Uwe Stöhr wrote: > Am 19.07.2011 19:33, schrieb Richard Heck: > >> I understand the idea, but it would make the Bibitem mess look neat. > > What do you mean? > The InsetBibitem code is a complete disaster. There are all kinds of bugs associated with it, because we are

Re: Missing features in Flex insets and style definition question

On 07/18/2011 01:46 PM, Uwe Stöhr wrote: I often have the case that I need to define an inset that is internally a LaTeX command. I use for this the Flex inset. But why does it not support optional and required arguments. I mean it represents a LaTeX command, the same way as a normal Style

Re: Missing features in Flex insets and style definition question

Le 18/07/11 22:26, Richard Heck a écrit : Styles in this sense are paragraph-level entities, so I don't think you can do this. Flex insets are what you would want in this case. It would be possible using parbreakisnewline if this was made to work generally. JMarc

Re: Missing features in Flex insets and style definition question

On Mon, Jul 18, 2011 at 7:46 PM, Uwe Stöhr uwesto...@web.de wrote: I often have the case that I need to define an inset that is internally a LaTeX command. I use for this the Flex inset. But why does it not support optional and required arguments. I mean it represents a LaTeX command, the same

Re: Missing features in Flex insets and style definition question

Am 18.07.2011 22:30, schrieb Jean-Marc Lasgouttes: Le 18/07/11 22:26, Richard Heck a écrit : Styles in this sense are paragraph-level entities, so I don't think you can do this. Flex insets are what you would want in this case. It would be possible using parbreakisnewline if this was made to

Re: Missing features in Flex insets and style definition question

On 07/18/2011 01:46 PM, Uwe Stöhr wrote: > I often have the case that I need to define an inset that is > internally a LaTeX command. I use for this the Flex inset. But why > does it not support optional and required arguments. I mean it > represents a LaTeX command, the same way as a normal Style

Re: Missing features in Flex insets and style definition question

Le 18/07/11 22:26, Richard Heck a écrit : Styles in this sense are paragraph-level entities, so I don't think you can do this. Flex insets are what you would want in this case. It would be possible using parbreakisnewline if this was made to work generally. JMarc

Re: Missing features in Flex insets and style definition question

On Mon, Jul 18, 2011 at 7:46 PM, Uwe Stöhr wrote: > I often have the case that I need to define an inset that is internally a > LaTeX command. I use for this the Flex inset. But why does it not support > optional and required arguments. I mean it represents a LaTeX command, the

Re: Missing features in Flex insets and style definition question

Am 18.07.2011 22:30, schrieb Jean-Marc Lasgouttes: Le 18/07/11 22:26, Richard Heck a écrit : Styles in this sense are paragraph-level entities, so I don't think you can do this. Flex insets are what you would want in this case. It would be possible using parbreakisnewline if this was made to