Am 28.01.2013 07:54, schrieb Jürgen Spitzmüller:
The linebreak is necessary to get the city in its own line.
This is a requirement for some job applications. At least that was once
reported to me.
Look, the problem is that some modernCV themes (casual, which has the address
information in the
Uwe Stöhr wrote:
> This cannot be fixed, because in trunk the new default theme is used. in
> branch I cannot use this because the document will then become
> uncompilable.
No it won't. Attached is a branch version that compiles with the casual theme.
All I did here is changing the theme and re
Uwe Stöhr wrote:
> I don't know why but this does not occur with the new layout in trunk.
Of course it does. See attached document. Or show me how to insert a linebreak
in the address layout with the casual theme in the new layout that does _not_
trigger a error.
Jürgen
modernCV-trunk.lyx
Des
Am 28.01.2013 03:07, schrieb Uwe Stöhr:
OK. I will fix this then.
This cannot be fixed, because in trunk the new default theme is used. in branch I cannot use this
because the document will then become uncompilable. The linebreak is necessary to get the city in
its own line. This is a requir
Am 26.01.2013 18:23, schrieb Jürgen Spitzmüller:
I cannot reproduce the failure you get when removing the linebreak. I can
reproduce the failure with a different theme. But I cannot see how the layout
update fixes this. Instead, the error goes away if the address declaration in
the preamble is t
Uwe Stöhr wrote:
> As soon as you e.g. change something in the example file it
> becomes uncompilable. Use for example another theme or remove the linebreak
> in the address.
I cannot reproduce the feilure you get when removing the linebreak. I can
reproduce the failure with a different theme. B
Am 26.01.2013 05:05, schrieb Uwe Stöhr:
Damn, you are right.
Damn me, of course you were not right. As soon as you e.g. change something in the example file it
becomes uncompilable. Use for example another theme or remove the linebreak in the address.
I now nevertheless reverted everything
Am 22.01.2013 15:45, schrieb Jürgen Spitzmüller:
I now also reverted your changes locally, and it turns out that the (old)
moderncv example file still works without any single problem with the old
layout. This is with most recent TL (2012/12/04 v1.2.1 of moderncv.cls).
Damn, you are right. I d
Am 22.01.2013 15:19, schrieb Jürgen Spitzmüller:
You added 14 styles of "InPreamble" type (CVStyle, CVColor, FirstName,
FamilyName, Title, Address, Mobile, Phone, Fax, Email, Homepage, ExtraInfo,
Photo and Quote).
None of these are needed to keep the layout working with recent releases of
moder
Am 21.01.2013 22:15, schrieb Georg Baum:
That is what I always stated, non of my changes (except of that nasty
modernCV beast) break the backward-compatibility in the strict sense but
they introduce new commands and that is what this thread is about.
Yes. In the beginning, I thought that these
Jürgen Spitzmüller wrote:
> In sum: As much as these changes enhance the support for moderncv, none of
> them is really needed to keep moderncv working.
I now also reverted your changes locally, and it turns out that the (old)
moderncv example file still works without any single problem with the
Uwe Stöhr wrote:
> > The same holds for moderncv. The author does support backward
> > compatibility so I would be interested to see what actually does not work
> > anymore.
>
> I had a look today and I cannot fiddle it out. The underlying table
> structure until modernCV 1.0 makes it complicated
Am 21.01.2013 09:34, schrieb Jean-Marc Lasgouttes:
But only sometimes. That is no accuse for not providing everything that
might be demanded by a journal.
Sure, but it has to be done case-by-case. My point is that the argument should not
be "all layouts
should be updated to match the latest v
Richard Heck wrote:
> It's currently possible to edit such a file without data loss, if I'm
> not mistaken. The unrecognized layouts are treated as "Standard", but
> they retain their labels. It is even possible to insert new such layouts
> (or insets) and save the file. So the "edit only" mode is
Uwe Stöhr wrote:
> Am 15.01.2013 22:24, schrieb Georg Baum:
>
>> IMHO, IEEEtran.cls does not support Uwe's reasoning at all, but rather
>> the oppsosite. And I'd really like to see _one_ example of an updated
>> journal/conference .cls file that broke an officially supported LyX
>> .layout file (
Le 21/01/13 00:55, Uwe Stöhr a écrit :
Am 16.01.2013 10:19, schrieb Jean-Marc Lasgouttes:
We also have the right to consider the new commands and the necessity
to support them right _now_.
It may be that they are really required, but I bet that in many cases
they will only correspond to
corner
Le 21/01/13 00:51, Uwe Stöhr a écrit :
Am 15.01.2013 22:36, schrieb Jean-Marc Lasgouttes:
The same holds for moderncv. The author does support backward
compatibility so I would be interested
to see what actually does not work anymore.
I had a look today and I cannot fiddle it out. The underly
Am 16.01.2013 10:19, schrieb Jean-Marc Lasgouttes:
We also have the right to consider the new commands and the necessity to
support them right _now_.
It may be that they are really required, but I bet that in many cases they will
only correspond to
corner cases.
But only sometimes. That is n
Am 15.01.2013 22:36, schrieb Jean-Marc Lasgouttes:
The same holds for moderncv. The author does support backward compatibility so
I would be interested
to see what actually does not work anymore.
I had a look today and I cannot fiddle it out. The underlying table structure until modernCV 1.0
Am 15.01.2013 22:24, schrieb Georg Baum:
IMHO, IEEEtran.cls does not support Uwe's reasoning at all, but rather the
oppsosite. And I'd really like to see _one_ example of an updated
journal/conference .cls file that broke an officially supported LyX .layout
file (and no, unless somebody presents
Am 14.01.2013 11:28, schrieb Enrico Forestieri:
Nothing. If you do nothing, you break nothing.
http://www.lyx.org/trac/ticket/8503#comment:1
Thanks for having a look. There might be a bug in MiKTeX's packaging. But that is not the main
problem. The problem is once again that there are new st
On 01/17/2013 01:53 PM, Enrico Forestieri wrote:
On Wed, Jan 16, 2013 at 04:13:31PM -0500, Richard Heck wrote:
On 01/16/2013 03:39 PM, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Le 16/01/2013 08:53, Liviu Andronic a écrit :
Consider that the updated layout (in 2.0.5) contains _new_ comman
On Wed, Jan 16, 2013 at 04:13:31PM -0500, Richard Heck wrote:
> On 01/16/2013 03:39 PM, Georg Baum wrote:
> >Jean-Marc Lasgouttes wrote:
> >
> >>Le 16/01/2013 08:53, Liviu Andronic a écrit :
> >>>Consider that the updated layout (in 2.0.5) contains _new_ commands
> >>>and that the user creates a do
On 01/16/2013 03:39 PM, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Le 16/01/2013 08:53, Liviu Andronic a écrit :
Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if
Jean-Marc Lasgouttes wrote:
> Le 16/01/2013 08:53, Liviu Andronic a écrit :
>> Consider that the updated layout (in 2.0.5) contains _new_ commands
>> and that the user creates a document using those new commands that the
>> 2.0.5 layout supports. What happens if a collaborator opens this
>> docume
On 01/16/2013 02:53 AM, Liviu Andronic wrote:
On Tue, Jan 15, 2013 at 10:24 PM, Georg Baum
wrote:
versions are backward incompatible: I only saw new commands, not changed or
deleted old ones).
Therefore, the best option is IMNSHO to use one of the several suggestions
of versioned layouts, _if_
On Wed, Jan 16, 2013 at 4:19 AM, Jean-Marc Lasgouttes
wrote:
> Le 16/01/2013 08:53, Liviu Andronic a écrit :
>
>> Consider that the updated layout (in 2.0.5) contains _new_ commands
>> and that the user creates a document using those new commands that the
>> 2.0.5 layout supports. What happens if
Le 16/01/2013 08:53, Liviu Andronic a écrit :
Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if a collaborator opens this
document in 2.0.3? Will it work, or will openin
On Tue, Jan 15, 2013 at 10:24 PM, Georg Baum
wrote:
> versions are backward incompatible: I only saw new commands, not changed or
> deleted old ones).
> Therefore, the best option is IMNSHO to use one of the several suggestions
> of versioned layouts, _if_ new layouts in the stable branch are nec
Le 15/01/2013 22:24, Georg Baum a écrit :
IMHO, IEEEtran.cls does not support Uwe's reasoning at all, but rather the
oppsosite. And I'd really like to see _one_ example of an updated
journal/conference .cls file that broke an officially supported LyX .layout
file (and no, unless somebody presents
Guenter Milde wrote:
> On 2013-01-14, Enrico Forestieri wrote:
>> On Mon, Jan 14, 2013 at 02:33:36AM +0100, Uwe Stöhr wrote:
>
>>> But to come to an end, decide once again but please act then
>>> consistently. I will have to update IEEEtran and I want to know from
>>> you what I should do now.
>
On 2013-01-14, Enrico Forestieri wrote:
> On Mon, Jan 14, 2013 at 02:33:36AM +0100, Uwe Stöhr wrote:
>> But to come to an end, decide once again but please act then
>> consistently. I will have to update IEEEtran and I want to know from
>> you what I should do now.
> Nothing. If you do nothing, y
Hello Uwe
On Mon, Jan 14, 2013 at 2:33 AM, Uwe Stöhr wrote:
>> The Windows installer is your business.
>
> That is not fair. We can assume that at least 50% of our users use LyX on
> Windows.
>
This is harsh reasoning. In many cases open-source projects only take
responsibility for providing sou
On 2013-01-14, Uwe Stöhr wrote:
> Am 02.01.2013 15:42, schrieb Richard Heck:
> I want:
> - for paper submission classes we can change the layout for every LyX
> release (this might break backward compatibility but for these
> classes you are not allowed to use older class versions)
> - for no
On Mon, Jan 14, 2013 at 02:33:36AM +0100, Uwe Stöhr wrote:
> But to come to an end, decide once again but please act then
> consistently. I will have to update IEEEtran and I want to know from
> you what I should do now.
Nothing. If you do nothing, you break nothing.
http://www.lyx.org/trac/tick
Am 02.01.2013 15:42, schrieb Richard Heck:
I'm sorry, Uwe, but you simply are not listening to what anyone else is saying.
No one is saying we
should not provide updated layout files, force people to enter TeX code, or
whatever. The ONLY issue
is what the names of these new layouts will be. I'
On 01/01/2013 10:34 PM, Uwe Stöhr wrote:
Am 16.12.2012 19:33, schrieb Richard Heck:
1. backward compatibility
Perhaps I am reading too much into this, but if your main concern is
the example or template file,
then there is no issue here. I have already said that I have no
objection to makin
Can we please revert the moderncv and achemso changes in branch unless we have
come to a final conclusion?
Jürgen
Am 17.12.2012 17:19, schrieb Jean-Marc Lasgouttes:
While looking into moderncv.cls, I saw an interesting line:
\RequirePackageWithOptions{moderncvcompatibility}
Looking inside this file is indeed interesting:
% compatibility with version 0.1
\newcommand*{\cvresume}[2]{\cvlistdoubleitem
Am 16.12.2012 19:33, schrieb Richard Heck:
1. backward compatibility
Perhaps I am reading too much into this, but if your main concern is the
example or template file,
then there is no issue here. I have already said that I have no objection to
making the example and
template files be up to
Uwe Stöhr wrote:
> But it also fails if you are using a KOMA version in your LaTeX distribution
> that does not know about a style that was added to a later version of
> KOMA. And that was what I was referring to. If you send someone your file
> created with e.g. KOMA version 2 but he has only KOM
Am 14.12.2012 08:29, schrieb Jürgen Spitzmüller:
KOMA Script is an excellent example: It has an option
version= exactly to fit the criterium we put forward:
backwards compatibility. In contrast to the moderncv author
(apparently), Markus Kohm has a very good understanding of how
important it is
Le 17/12/2012 16:32, Richard Heck a écrit :
How does LaTeX figure out the version, if we include that in
\usepackage? Or is that the worry, that not all classes do it the same way?
I was kind of thinking that we'd actually make this check in
chkconfig.ltx. Perhaps using something like:
\use
On 12/17/2012 04:57 AM, Jean-Marc Lasgouttes wrote:
Le 16/12/2012 19:33, Richard Heck a écrit :
Let me address the last point first. I do not see why you think
versioning makes more work. Why would you have to write three different
layouts? To support every single version of moderncv? We don't d
Le 16/12/2012 19:33, Richard Heck a écrit :
Let me address the last point first. I do not see why you think
versioning makes more work. Why would you have to write three different
layouts? To support every single version of moderncv? We don't do that
now, as you said. Why would we have to do it t
On 12/13/2012 05:45 PM, Uwe Stöhr wrote:
Dear colleagues,
sorry for the delay, but my spare time is currently very limited.
Before I will comment on the different posts in the old thread I want
to summarize what we are discussing about because the old thread is a
mixture of different topics an
2012/12/13 Uwe Stöhr :
> Another example is KOMA-script.
KOMA Script is an excellent example: It has an option
version= exactly to fit the criterium we put forward:
backwards compatibility. In contrast to the moderncv author
(apparently), Markus Kohm has a very good understanding of how
important
Am 10.12.2012 10:16, schrieb Jean-Marc Lasgouttes:
To try to discuss concrete example, could you give me a quick description of
typical changes that
have occurred between these moderncv releases? I would like to see how bad it
is.
Compared to modernCV < 1.0 the commands for the language and
Dear colleagues,
sorry for the delay, but my spare time is currently very limited.
Before I will comment on the different posts in the old thread I want to summarize what we are
discussing about because the old thread is a mixture of different topics and misunderstandings.
The different points
On 12/10/2012 12:15 PM, José Matos wrote:
On 12/10/2012 04:59 PM, Richard Heck wrote:
- From my point as the author of a layout I cannot know what a
version of the document class a user might have installed. So what
should I do, if the layout works only with modernCV 1.0, but fails
with 0.9 and
On 12/10/2012 04:59 PM, Richard Heck wrote:
>> - From my point as the author of a layout I cannot know what a
>> version of the document class a user might have installed. So what
>> should I do, if the layout works only with modernCV 1.0, but fails
>> with 0.9 and the recent version 1.2? - I have
On 12/09/2012 08:09 PM, Uwe Stöhr wrote:
Am 07.12.2012 10:09, schrieb Jean-Marc Lasgouttes:
OK. Let's face it: everything does not work like you are used to. It
is not good or bad, it is a
fact. And you cannot force everybody to do what you think is good.
I don't want to force anybody to do
Jürgen Spitzmüller wrote:
> Uwe Stöhr wrote:
> > What is if we add a layout that did not exist before? Of course this breaks
> > the backward compatibility.
>
> Yes, that's tolerated. Although it is an edge case (there are some good
> arguments to limit the inclusion of new layouts to major rele
Le 10/12/2012 02:09, Uwe Stöhr a écrit :
- What do you expect as LyX developer, that people are not bothering you
with complaints about things you already fixed years ago investing your
spare time. So please be that fair and allow also the modernCV developer
to act like you. Of course he has the
Uwe Stöhr wrote:
> Am 07.12.2012 10:52, schrieb Jürgen Spitzmüller:
> >> But as I just explained, backward compatibility is not
> >> necessary.
> >
> > You didn't convince me. As JMarc pointed out, people work on different
> > machines (I work on three, as well). And you are not allowed to always
Am 07.12.2012 10:09, schrieb Jean-Marc Lasgouttes:
OK. Let's face it: everything does not work like you are used to. It is not
good or bad, it is a
fact. And you cannot force everybody to do what you think is good.
I don't want to force anybody to do something. All I want to have is a working
Am 07.12.2012 08:07, schrieb Liviu Andronic:
But this version is 2.5 years old.
This is what Linux users usually have to put up with.
And what do you propose?
- Assume you are the developer of ModernCV, would you like to get bug reports for things that you
fixed years ago. What would you t
Am 07.12.2012 10:52, schrieb Jürgen Spitzmüller:
But as I just explained, backward compatibility is not
necessary.
You didn't convince me. As JMarc pointed out, people work on different
machines (I work on three, as well). And you are not allowed to always use the
most up-to-date version on ea
Uwe Stöhr wrote:
> Am 06.12.2012 21:21, schrieb Georg Baum:
>
>> Definitely. One big advantage of LyX is that you do not need to think if
>> you switch between minor point releases.
>
> But who does this?
> Have you have downgraded your LyX from e.g. 1.6.8 back to 1.6.3? That
> doesn't make sens
On 12/07/2012 04:03 AM, Jean-Marc Lasgouttes wrote:
Le 07/12/2012 00:13, Uwe Stöhr a écrit :
Am 06.12.2012 21:21, schrieb Georg Baum:
Definitely. One big advantage of LyX is that you do not need to think
if you switch between minor point releases.
But who does this?
Have you have downgraded
Uwe Stöhr wrote:
> > My idea would be to provide a new layout with a new name
> > (journalx-new.layout), then lyx2lyx could change this to
> > journalx.layout in the new major release (and also the old
> > journalx.layout) and revert accordingly.
>
> That is very confusing. What happens if we have
Le 06/12/2012 23:56, Uwe Stöhr a écrit :
LyX cannot take care of what OSes do/provide. For example on Windows you
get package updates regularly every week or at least every time you
upgrade LyX to a new version.
So should we discontinue LyX for unix and Mac OS and tell user to switch
to window
Le 07/12/2012 00:04, Uwe Stöhr a écrit :
Am 06.12.2012 09:12, schrieb Jean-Marc Lasgouttes:
For modernCV, I am not so sure it was a good idea. In texlive2012, I
have version 0.12.
But this version is 2.5 years old. I would have bet that the example
file that comes with LyX 2.0.5 fails with th
Le 07/12/2012 00:13, Uwe Stöhr a écrit :
Am 06.12.2012 21:21, schrieb Georg Baum:
Definitely. One big advantage of LyX is that you do not need to think
if you
switch between minor point releases.
But who does this?
Have you have downgraded your LyX from e.g. 1.6.8 back to 1.6.3? That
doesn't
On Fri, Dec 7, 2012 at 12:04 AM, Uwe Stöhr wrote:
> Am 06.12.2012 09:12, schrieb Jean-Marc Lasgouttes:
>> For modernCV, I am not so sure it was a good idea. In texlive2012, I have
>> version 0.12.
>
> But this version is 2.5 years old.
>
This is what Linux users usually have to put up with.
Liviu
Uwe Stöhr wrote:
>> Not everybody run miktex.
>
> But TeXLive also has an update button. At least here on Windows it works.
Yes, what you write works on Windows. As others already wrote this is not option
on many other platforms (although TeXLive is present, "live update" is not
used.)
Pavel
Uwe Stöhr wrote:
> Am 06.12.2012 21:21, schrieb Georg Baum:
>
>> Definitely. One big advantage of LyX is that you do not need to think if
>> you switch between minor point releases.
>
> But who does this?
At this moment for example me or more precisely several people working
under SVN on a single
Am 06.12.2012 21:21, schrieb Georg Baum:
Definitely. One big advantage of LyX is that you do not need to think if you
switch between minor point releases.
But who does this?
Have you have downgraded your LyX from e.g. 1.6.8 back to 1.6.3? That doesn't
make sense to me.
We already discussed
Am 06.12.2012 14:56, schrieb Jürgen Spitzmüller:
My idea would be to provide a new layout with a new name
(journalx-new.layout), then lyx2lyx could change this to
journalx.layout in the new major release (and also the old
journalx.layout) and revert accordingly.
That is very confusing. What ha
Am 06.12.2012 09:12, schrieb Jean-Marc Lasgouttes:
For modernCV, I am not so sure it was a good idea. In texlive2012, I have
version 0.12.
But this version is 2.5 years old. I would have bet that the example file that comes with LyX 2.0.5
fails with this version.
Not everybody run miktex.
Am 06.12.2012 09:14, schrieb Liviu Andronic:
Personally I'm rather uneasy about LyX shipping a layout file that
works only with the latest version of the modernCV class. The trouble
is that Linux distros usually lag for ages before shipping updated
versions to their users (and on Linux by defaul
Am 06.12.2012 08:58, schrieb Jürgen Spitzmüller:
I'm not sure about that. Adding one or two new layouts is OK, but a
major change is not, IMHO, unless you provide the old file for
compatibility.
All old files will still be compilable. But to fulfill the current guidelines, you have to use some
Uwe Stöhr wrote:
> Am 05.12.2012 08:21, schrieb Jürgen Spitzmüller:
>
>> Do you introduce new layouts? This would be a file format change in
>> the strict sense (since LyX 2.0.4 would not be able to handle these
>> new layouts).
Definitely. One big advantage of LyX is that you do not need to thi
On 12/06/2012 08:56 AM, Jürgen Spitzmüller wrote:
2012/12/6 Jean-Marc Lasgouttes:
For conferences/journals we probably do not have a choice (unless some
people rely on old layouts).
My idea would be to provide a new layout with a new name
(journalx-new.layout), then lyx2lyx could change this to
2012/12/6 Jean-Marc Lasgouttes :
> For conferences/journals we probably do not have a choice (unless some
> people rely on old layouts).
My idea would be to provide a new layout with a new name
(journalx-new.layout), then lyx2lyx could change this to
journalx.layout in the new major release (and a
On Thu, Dec 6, 2012 at 9:12 AM, Jean-Marc Lasgouttes wrote:
> For conferences/journals we probably do not have a choice (unless some
> people rely on old layouts).
>
Maybe it's time we introduced a 'Deprecated' Document class category.
There we could throw in all layout files that have been obsole
On Thu, Dec 6, 2012 at 8:58 AM, Jürgen Spitzmüller wrote:
>> for e.g. IJMP and ACM submissions. I'm sure that users will accept that and
>> it would be strange if they insist using a older LyX version if a newer one
>> is out fixing several bugs.
>
> I'm not sure about that. Adding one or two new
Le 06/12/12 08:58, Jürgen Spitzmüller a écrit :
2012/12/5 Uwe Stöhr :
My changes are necessary to keep documents compilable and/or to keep them
acceptable following the submission guidelines.
However, older LyX files are still compilable using LyX 2.0.6 (except of
modernCV as I wrote). I think i
2012/12/5 Uwe Stöhr :
> My changes are necessary to keep documents compilable and/or to keep them
> acceptable following the submission guidelines.
> However, older LyX files are still compilable using LyX 2.0.6 (except of
> modernCV as I wrote). I think it is enough to add the info in the release
Am 05.12.2012 08:21, schrieb Jürgen Spitzmüller:
Do you introduce new layouts? This would be a file format change in
the strict sense (since LyX 2.0.4 would not be able to handle these
new layouts).
We already discussed this topic several times. It is impossible to provide backward compatibili
2012/12/4 Uwe Stöhr :
> The updated layouts don't break any compilation and the changes are
> independent of the InsetArgument work I committed to trunk.
> OK to go in?
Do you introduce new layouts? This would be a file format change in
the strict sense (since LyX 2.0.4 would not be able to handle
Hello Richard,
I finished my layout revisions and their adaption to the new InsetArgument
feature.
This also lead to completely revised layouts for europeCV, ACM SIGplan and SIGgraph for LyX 2.0.6.
Attached is the patch.
The updated layouts don't break any compilation and the changes are inde
82 matches
Mail list logo
