Re: Extending layouts
On 02/07/2018 12:01 PM, racoon wrote: > On 24.01.2018 21:22, Richard Heck wrote: >> On 01/23/2018 03:49 AM, Jean-Marc Lasgouttes wrote: >>> >>> Now that I think about it, the advantage of using a special syntax is >>> that there is not need to specify the file name, which makes the code >>> safer. >>> >>> Idead of syntax: >>> Input >>> Input * >>> InputParent >> >> I had a similar thought: something like class inheritance. The last of >> these looks best to me. > > And seems to get the job done I need at the moment. So, I'd be happy > is something like this existed. Can you file an enhancement request for this, milestone 2.4.0? Riki
Re: Extending layouts
On 24.01.2018 21:22, Richard Heck wrote: On 01/23/2018 03:49 AM, Jean-Marc Lasgouttes wrote: Now that I think about it, the advantage of using a special syntax is that there is not need to specify the file name, which makes the code safer. Idead of syntax: Input Input * InputParent I had a similar thought: something like class inheritance. The last of these looks best to me. And seems to get the job done I need at the moment. So, I'd be happy is something like this existed. Daniel
Re: Extending layouts
On 01/23/2018 03:49 AM, Jean-Marc Lasgouttes wrote: > > Now that I think about it, the advantage of using a special syntax is > that there is not need to specify the file name, which makes the code > safer. > > Idead of syntax: > Input > Input * > InputParent I had a similar thought: something like class inheritance. The last of these looks best to me. Richard
Re: Extending layouts
On 23.01.2018 11:50, Jean-Marc Lasgouttes wrote: When is it useful to extend an extension in the same user directory? I do not see the point... For example, you might have a module locally installed in the user dir which you want to extend. This is not strictly speaking an extension of an extension but maybe a good enough use case to consider it seriously? Daniel
Re: Extending layouts
Le 23/01/2018 à 10:02, racoon a écrit : On 23.01.2018 10:41, Jean-Marc Lasgouttes wrote: Le 23/01/2018 à 09:35, racoon a écrit : Yes, that would work for my case. However, it will fail if I want to extend an extension since it will not search my user directory. Let's say in the user directory there is 1. user_dir/foo.layout.ext which extends an extension Actually, what I proposed would be an alternative to the .ext proposal. It is not meant to be used at the same time. I see. Would your suggestion be able to allow the extension of extensions? If I see it correctly, my example could be changes as follows to extend your suggestion: 1. user_dir/foo.layout 2. user_dir/foo.ext 3. sys_dir/foo.layout When is it useful to extend an extension in the same user directory? I do not see the point... JMarc
Re: Extending layouts
On 23.01.2018 11:02, racoon wrote: On 23.01.2018 10:41, Jean-Marc Lasgouttes wrote: Le 23/01/2018 à 09:35, racoon a écrit : Yes, that would work for my case. However, it will fail if I want to extend an extension since it will not search my user directory. Let's say in the user directory there is 1. user_dir/foo.layout.ext which extends an extension Actually, what I proposed would be an alternative to the .ext proposal. It is not meant to be used at the same time. I see. Would your suggestion be able to allow the extension of extensions? If I see it correctly, my example could be changes as follows to extend your suggestion: 1. user_dir/foo.layout 2. user_dir/foo.ext 3. sys_dir/foo.layout 1 has a line line "Input bar.ext" and 2 has a line "Input foo.layout". The last line should of course be 1 has a line line "Input *foo*.ext" and 2 has a line "Input foo.layout". If "Input filename" not only searches in the higher order directory as I suggested before, this might work. (Notice that the 2's extension ".ext" is non-essential to the example.) Daniel
Re: Extending layouts
On 23.01.2018 10:41, Jean-Marc Lasgouttes wrote: Le 23/01/2018 à 09:35, racoon a écrit : Yes, that would work for my case. However, it will fail if I want to extend an extension since it will not search my user directory. Let's say in the user directory there is 1. user_dir/foo.layout.ext which extends an extension Actually, what I proposed would be an alternative to the .ext proposal. It is not meant to be used at the same time. I see. Would your suggestion be able to allow the extension of extensions? If I see it correctly, my example could be changes as follows to extend your suggestion: 1. user_dir/foo.layout 2. user_dir/foo.ext 3. sys_dir/foo.layout 1 has a line line "Input bar.ext" and 2 has a line "Input foo.layout". If "Input filename" not only searches in the higher order directory as I suggested before, this might work. (Notice that the 2's extension ".ext" is non-essential to the example.) Daniel
Re: Extending layouts
Le 23/01/2018 à 06:11, Richard Heck a écrit : My sense, from our previous discussion, is that this would work in the cases racoon had in mind. But I'm not sure why this wouldn't scale. We could of course look also for *.ext.ext. OK, imagine that we have support for a site directory (and I think that we should). The administrator of the machine has installed for some reason an extension site_dir/stdlayouts.inc.ext How do you use your own extension without hiding the site-level one? An added bonus of using Input is that some stuff can be redefined either before or after loading the base file. A simpler way to see it would be to add a InputParent tag. However in the cases were it is usefule (AFAICS), Input is not usable, since it would lead to recursive input. This is why I got the idea of repurposing it. Now that I think about it, the advantage of using a special syntax is that there is not need to specify the file name, which makes the code safer. Idead of syntax: Input Input * InputParent These ideas could also probably be combined. I fear this would become too complicated. And I am not sure yet that there are use cases that work with .ext and not with repurposed recursive Input. JMarc
Re: Extending layouts
Le 23/01/2018 à 09:35, racoon a écrit : Yes, that would work for my case. However, it will fail if I want to extend an extension since it will not search my user directory. Let's say in the user directory there is 1. user_dir/foo.layout.ext which extends an extension Actually, what I proposed would be an alternative to the .ext proposal. It is not meant to be used at the same time. JMarc
Re: Extending layouts
On 23.01.2018 07:11, Richard Heck wrote: On 01/22/2018 04:23 AM, Jean-Marc Lasgouttes wrote: Le 22/01/2018 à 10:10, racoon a écrit : So LyX should load the library's stdinset.inc first and then load the code that extends it next. Richard, who ran into similar problems as I did, suggested that LyX could be enhanced by automatically looking for and loading an .ext file, e.g. stdinset.inc.ext. I think that is a good idea and this concept could be used for other sorts of layout files, like .modules. One idea that I do not like about the .ext file idea is that it does not scale when you want to extend a file that has already been extended, which might happen if we had a site directory as proposed in http://www.lyx.org/trac/ticket/10326. One idea I had about that is to change the behavior of Input (which searches for files in user dir, then build dir, and finally system dir) so that it skips to the next level when doing recursive input. Example: * In user_dir/foo.layout, if I do "Input foo.layout", it will search in build dir, and then system dir * in build_dir/foo.layout, it will try only sys_dir/foo.layout The same will work if we add a site directory. Would that fix your issue, or are there cases where it would not do what you expect? My sense, from our previous discussion, is that this would work in the cases racoon had in mind. But I'm not sure why this wouldn't scale. We could of course look also for *.ext.ext. These ideas could also probably be combined. I guess a benefit of Jean-Marc's suggestion is that it provides the user with more freedom to choose filenames (if his suggestion is extended in some way like I proposed in reply to him). Daniel
Re: Extending layouts
On 22.01.2018 11:23, Jean-Marc Lasgouttes wrote: Le 22/01/2018 à 10:10, racoon a écrit : So LyX should load the library's stdinset.inc first and then load the code that extends it next. Richard, who ran into similar problems as I did, suggested that LyX could be enhanced by automatically looking for and loading an .ext file, e.g. stdinset.inc.ext. I think that is a good idea and this concept could be used for other sorts of layout files, like .modules. One idea that I do not like about the .ext file idea is that it does not scale when you want to extend a file that has already been extended, which might happen if we had a site directory as proposed in http://www.lyx.org/trac/ticket/10326. One idea I had about that is to change the behavior of Input (which searches for files in user dir, then build dir, and finally system dir) so that it skips to the next level when doing recursive input. Example: * In user_dir/foo.layout, if I do "Input foo.layout", it will search in build dir, and then system dir * in build_dir/foo.layout, it will try only sys_dir/foo.layout The same will work if we add a site directory. Would that fix your issue, or are there cases where it would not do what you expect? Yes, that would work for my case. However, it will fail if I want to extend an extension since it will not search my user directory. Let's say in the user directory there is 1. user_dir/foo.layout.ext which extends an extension 2. user_dir/foo.layout of 3. sys_dir/foo.layout Since Input foo.layout will search only in the higher order directories, sys_dir and build_dir, there is no way to reach 2 from 1. A way around would be to start search the user directory (but, obviously, only if the filename differs from itself) and then upwards. Daniel
Re: Extending layouts
Le 22/01/2018 à 10:10, racoon a écrit : So LyX should load the library's stdinset.inc first and then load the code that extends it next. Richard, who ran into similar problems as I did, suggested that LyX could be enhanced by automatically looking for and loading an .ext file, e.g. stdinset.inc.ext. I think that is a good idea and this concept could be used for other sorts of layout files, like .modules. One idea that I do not like about the .ext file idea is that it does not scale when you want to extend a file that has already been extended, which might happen if we had a site directory as proposed in http://www.lyx.org/trac/ticket/10326. One idea I had about that is to change the behavior of Input (which searches for files in user dir, then build dir, and finally system dir) so that it skips to the next level when doing recursive input. Example: * In user_dir/foo.layout, if I do "Input foo.layout", it will search in build dir, and then system dir * in build_dir/foo.layout, it will try only sys_dir/foo.layout The same will work if we add a site directory. Would that fix your issue, or are there cases where it would not do what you expect? JMarc
Extending layouts
I am bringing over a topic from the general list for dev discussion: By default LyX loads standard layouts and insets. Is there a way to extend them without overwriting the default .inc file and without using a module? Let's say I want to extend the standard Note style. I don't want to use a module since I want to make a non-optional change to the Note inset. For example, I want to use another font size for all LyX notes. If I understood correctly, I can just put a copy of the stdinset.inc file from the library to the user directory. But this will have the unwelcome effect to overwrite whatever is in the stdinset.inc in the library directory. So, to avoid unwanted consequences, I will have to update my user stdinset.inc every time the library stdinset.inc changes, for example, in a new version of LyX. So I would rather like to *extend* the current library file by just the font-size changes by InsetLayout Note:Note CopyStyle Note Font Size Small EndFont End So LyX should load the library's stdinset.inc first and then load the code that extends it next. Richard, who ran into similar problems as I did, suggested that LyX could be enhanced by automatically looking for and loading an .ext file, e.g. stdinset.inc.ext. I think that is a good idea and this concept could be used for other sorts of layout files, like .modules. Daniel
