Enrico Forestieri wrote:
On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
Please, find attached the corresponding patches.
- overwrite-1.diff implements behavior 1
- overwrite-2.diff implements behavior 2
The patch obtaining more votes
On Sat, Jul 17, 2010 at 01:49:38PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
Please, find attached the corresponding patches.
- overwrite-1.diff implements behavior 1
-
Enrico Forestieri wrote:
The patch obtaining more votes will be applied.
from what i have counted you won.
I would like to have a higher turnout of voters. I also think that
this poll should not be limited to developers.
whosoever wanted to add his comment did it, so
Enrico Forestieri wrote:
> On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote:
> > Enrico Forestieri wrote:
> > > Please, find attached the corresponding patches.
> > >
> > > - overwrite-1.diff implements behavior 1
> > > - overwrite-2.diff implements behavior 2
> > >
> > > The patch
On Sat, Jul 17, 2010 at 01:49:38PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote:
> > > Enrico Forestieri wrote:
> > > > Please, find attached the corresponding patches.
> > > >
> > > > - overwrite-1.diff implements behavior
Enrico Forestieri wrote:
> > > > > The patch obtaining more votes will be applied.
> > > >
> > > > from what i have counted you won.
> > >
> > > I would like to have a higher turnout of voters. I also think that
> > > this poll should not be limited to developers.
> >
> > whosoever wanted to
Enrico Forestieri wrote:
Please, find attached the corresponding patches.
- overwrite-1.diff implements behavior 1
- overwrite-2.diff implements behavior 2
The patch obtaining more votes will be applied.
from what i have counted you won.
pavel
On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
Please, find attached the corresponding patches.
- overwrite-1.diff implements behavior 1
- overwrite-2.diff implements behavior 2
The patch obtaining more votes will be applied.
from what i
Enrico Forestieri wrote:
> Please, find attached the corresponding patches.
>
> - overwrite-1.diff implements behavior 1
> - overwrite-2.diff implements behavior 2
>
> The patch obtaining more votes will be applied.
from what i have counted you won.
pavel
On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > Please, find attached the corresponding patches.
> >
> > - overwrite-1.diff implements behavior 1
> > - overwrite-2.diff implements behavior 2
> >
> > The patch obtaining more votes will be applied.
>
>
On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote:
you really mean lyx -e lyx foo.lyx seriously? :) its just pretty normal that
if you ask on command line to write output over the input file it gets
overwritten
like the infamous 'cat file1 file2 file1' mistake. don't see the
Am 14.07.2010 um 10:15 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote:
you really mean lyx -e lyx foo.lyx seriously? :) its just pretty normal
that
if you ask on command line to write output over the input file it gets
overwritten
like the
Enrico Forestieri wrote:
commands can be changed if they are wrong, but the exotic case invented
just for
this debate like lyx -e lyx foo.lyx is hardly enough reason.
it looks as fixing acrobatic usecases never reported by anybody for
the price of introducing new problems. typical
Stephan Witt wrote:
One remark here (nitpick):
In the first example cat is not the program which overwrites the original.
It is the shell - and to avoid that stupid mistake they introduced the
variable noclobber.
When it is set and if your scripts assume overwrite of already existent files
Am 14.07.2010 um 11:57 schrieb Pavel Sanda:
Stephan Witt wrote:
One remark here (nitpick):
In the first example cat is not the program which overwrites the original.
It is the shell - and to avoid that stupid mistake they introduced the
variable noclobber.
When it is set and if your
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
i still maintain that the backward compatibility will cause less user's
frustration for this particular switch (ie default RC setting would need to
be set on main file overwrite) than new gun-discharged-course but i let
the responsibility on
On Wed, Jul 14, 2010 at 11:45:54AM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
So, let's have a poll:
1) Leave things as they are (need -f to overwrite)
2) The main file should always be overwritten
3) If no -f switch is given, use preferences settings for overwriting
as i
Pavel Sanda wrote:
I don't stop 1.6.7 because of this.
which means that you dont want to postpone it for other discussions or that
Enricos's patch is no-go for 1.6.7?
the former. On the patch itself, I do not have a strong opinion.
Jürgen
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
I don't stop 1.6.7 because of this.
which means that you dont want to postpone it for other discussions or that
Enricos's patch is no-go for 1.6.7?
the former. On the patch itself, I do not have a strong opinion.
ok unless Enrico is not
Pavel Sanda wrote:
ok unless Enrico is not against i would be thaknful if we could put
his patch into branch now...
As said, I do not want to unfreeze 1.6.7svn again.
Jürgen
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
ok unless Enrico is not against i would be thaknful if we could put
his patch into branch now...
As said, I do not want to unfreeze 1.6.7svn again.
aha i misunderstood.
pavel
Enrico Forestieri wrote:
as i said i accept both 2 or 3 but will strongly opose to 1 since it not
only
changes the behaviour but also make impossible for anybody to reuse old
scripts
without revisiting each of them.
since its pretty clear that you are strongly against 2 and me
On Wed, Jul 14, 2010 at 02:04:16PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
as i said i accept both 2 or 3 but will strongly opose to 1 since it not
only
changes the behaviour but also make impossible for anybody to reuse old
scripts
without revisiting each of them.
Am 14.07.2010 um 14:25 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 02:04:16PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
as i said i accept both 2 or 3 but will strongly opose to 1 since it not
only
changes the behaviour but also make impossible for anybody to reuse old
Enrico Forestieri wrote:
what would be the implicit value? if 'none', its kind of equivalent with
the rc patch.
if 'main' then i like it more, of course ;)
Yes, of course none would be the default if anything other than all or
main is specified. See the attached patch. I like this
On 14/07/2010 4:15 AM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote:
you really mean lyx -e lyx foo.lyx seriously? :) its just pretty normal that
if you ask on command line to write output over the input file it gets
overwritten
like the infamous 'cat
On 07/14/2010 08:25 AM, Enrico Forestieri wrote:
LYX_FORCE_OVERWRITE=main lyx -e dvi foo.lyx
does what you want.
and, of course, you can
export LYX_FORCE_OVERWRITE=main
from .bash_profile if you want.
rh
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
It is hard to believe that you would /inadvertently/ use the command
line. If you do, then it was your mistake. But wary users could have
a shortcut: alias lyx='lyx -f=none'
I think you're missing the point, too. On July 14 you
On 14/07/2010 11:52 AM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
It is hard to believe that you would /inadvertently/ use the command
line. If you do, then it was your mistake. But wary users could have
a shortcut: alias lyx='lyx -f=none'
I think
Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
It is hard to believe that you would /inadvertently/ use the command
line. If you do, then it was your mistake. But wary users could have
a shortcut: alias lyx='lyx -f=none'
I think you're missing the
Pavel Sanda wrote:
Juergen, status file for 1.6.7 does not clearly warns about the issue,
you maybe want at least put some note about commandline incompatibility
into web annoucement.
I think this can go into the wiki version of the RELEASE_NOTES.
Jürgen
On Wed, Jul 14, 2010 at 12:38:41PM -0400, Julien Rioux wrote:
Note that cp also has a -n (don't overwrite) flag. This seems pretty
pointless for a cp command, no? Imagine if this was the default
behavior. cp /path/file.tex . does nothing... sounds strange, no?
$ lyx -e latex foo.lyx
On Wed, Jul 14, 2010 at 06:41:13PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
It is hard to believe that you would /inadvertently/ use the command
line. If you do, then it was your mistake. But wary users could have
On 14/07/2010 1:10 PM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 12:38:41PM -0400, Julien Rioux wrote:
Note that cp also has a -n (don't overwrite) flag. This seems pretty
pointless for a cp command, no? Imagine if this was the default
behavior. cp /path/file.tex . does nothing...
On Wed, Jul 14, 2010 at 07:47:56PM +0200, Enrico Forestieri wrote:
I did not imagine I could have caused such a reaction for a safety measure
that I thought could have been quite easily overcomed. I am going to do
nothing until a *clear* consensus emerges about what should be the default
On 07/14/2010 02:47 PM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 07:47:56PM +0200, Enrico Forestieri wrote:
I did not imagine I could have caused such a reaction for a safety measure
that I thought could have been quite easily overcomed. I am going to do
nothing until a *clear*
On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote:
>
> you really mean "lyx -e lyx foo.lyx" seriously? :) its just pretty normal that
> if you ask on command line to write output over the input file it gets
> overwritten
> like the infamous 'cat file1 file2 > file1' mistake. don't see
Am 14.07.2010 um 10:15 schrieb Enrico Forestieri:
> On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote:
>>
>> you really mean "lyx -e lyx foo.lyx" seriously? :) its just pretty normal
>> that
>> if you ask on command line to write output over the input file it gets
>> overwritten
>>
Enrico Forestieri wrote:
> > commands can be changed if they are wrong, but the exotic case invented
> > just for
> > this debate like "lyx -e lyx foo.lyx" is hardly enough reason.
> > it looks as fixing acrobatic usecases never reported by anybody for
> > the price of introducing new problems.
Stephan Witt wrote:
> One remark here (nitpick):
> In the first example "cat" is not the program which overwrites the original.
> It is the shell - and to avoid that stupid mistake they introduced the
> variable noclobber.
> When it is set and if your scripts assume overwrite of already existent
Am 14.07.2010 um 11:57 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> One remark here (nitpick):
>> In the first example "cat" is not the program which overwrites the original.
>> It is the shell - and to avoid that stupid mistake they introduced the
>> variable noclobber.
>> When it is set and
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > i still maintain that the backward compatibility will cause less user's
> > frustration for this particular switch (ie default RC setting would need to
> > be set on main file overwrite) than new gun-discharged-course but i let
> > the
On Wed, Jul 14, 2010 at 11:45:54AM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > So, let's have a poll:
> >
> > 1) Leave things as they are (need -f to overwrite)
> > 2) The main file should always be overwritten
> > 3) If no -f switch is given, use preferences settings for overwriting
Pavel Sanda wrote:
> > I don't stop 1.6.7 because of this.
>
> which means that you dont want to postpone it for other discussions or that
> Enricos's patch is no-go for 1.6.7?
the former. On the patch itself, I do not have a strong opinion.
Jürgen
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > > I don't stop 1.6.7 because of this.
> >
> > which means that you dont want to postpone it for other discussions or that
> > Enricos's patch is no-go for 1.6.7?
>
> the former. On the patch itself, I do not have a strong opinion.
ok unless
Pavel Sanda wrote:
> ok unless Enrico is not against i would be thaknful if we could put
> his patch into branch now...
As said, I do not want to unfreeze 1.6.7svn again.
Jürgen
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > ok unless Enrico is not against i would be thaknful if we could put
> > his patch into branch now...
>
> As said, I do not want to unfreeze 1.6.7svn again.
aha i misunderstood.
pavel
Enrico Forestieri wrote:
> > as i said i accept both 2 or 3 but will strongly opose to 1 since it not
> > only
> > changes the behaviour but also make impossible for anybody to reuse old
> > scripts
> > without revisiting each of them.
> >
> > since its pretty clear that you are strongly
On Wed, Jul 14, 2010 at 02:04:16PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > > as i said i accept both 2 or 3 but will strongly opose to 1 since it not
> > > only
> > > changes the behaviour but also make impossible for anybody to reuse old
> > > scripts
> > > without revisiting
Am 14.07.2010 um 14:25 schrieb Enrico Forestieri:
> On Wed, Jul 14, 2010 at 02:04:16PM +0200, Pavel Sanda wrote:
>> Enrico Forestieri wrote:
as i said i accept both 2 or 3 but will strongly opose to 1 since it not
only
changes the behaviour but also make impossible for anybody to
Enrico Forestieri wrote:
> > what would be the implicit value? if 'none', its kind of equivalent with
> > the rc patch.
> > if 'main' then i like it more, of course ;)
>
> Yes, of course none would be the default if anything other than "all" or
> "main" is specified. See the attached patch. I
On 14/07/2010 4:15 AM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote:
you really mean "lyx -e lyx foo.lyx" seriously? :) its just pretty normal that
if you ask on command line to write output over the input file it gets
overwritten
like the infamous 'cat
On 07/14/2010 08:25 AM, Enrico Forestieri wrote:
LYX_FORCE_OVERWRITE=main lyx -e dvi foo.lyx
does what you want.
and, of course, you can
export LYX_FORCE_OVERWRITE=main
from .bash_profile if you want.
rh
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
> It is hard to believe that you would /inadvertently/ use the command
> line. If you do, then it was your mistake. But wary users could have
> a shortcut: alias lyx='lyx -f=none'
I think you're missing the point, too. On July 14 you
On 14/07/2010 11:52 AM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
It is hard to believe that you would /inadvertently/ use the command
line. If you do, then it was your mistake. But wary users could have
a shortcut: alias lyx='lyx -f=none'
I think
Enrico Forestieri wrote:
> On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
> > It is hard to believe that you would /inadvertently/ use the command
> > line. If you do, then it was your mistake. But wary users could have
> > a shortcut: alias lyx='lyx -f=none'
>
> I think you're
Pavel Sanda wrote:
> Juergen, status file for 1.6.7 does not clearly warns about the issue,
> you maybe want at least put some note about commandline incompatibility
> into web annoucement.
I think this can go into the wiki version of the RELEASE_NOTES.
Jürgen
On Wed, Jul 14, 2010 at 12:38:41PM -0400, Julien Rioux wrote:
>
> Note that cp also has a -n (don't overwrite) flag. This seems pretty
> pointless for a cp command, no? Imagine if this was the default
> behavior. "cp /path/file.tex ." does nothing... sounds strange, no?
$ lyx -e latex foo.lyx
On Wed, Jul 14, 2010 at 06:41:13PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote:
> > > It is hard to believe that you would /inadvertently/ use the command
> > > line. If you do, then it was your mistake. But wary users could
On 14/07/2010 1:10 PM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 12:38:41PM -0400, Julien Rioux wrote:
Note that cp also has a -n (don't overwrite) flag. This seems pretty
pointless for a cp command, no? Imagine if this was the default
behavior. "cp /path/file.tex ." does nothing...
On Wed, Jul 14, 2010 at 07:47:56PM +0200, Enrico Forestieri wrote:
>
> I did not imagine I could have caused such a reaction for a safety measure
> that I thought could have been quite easily overcomed. I am going to do
> nothing until a *clear* consensus emerges about what should be the default
On 07/14/2010 02:47 PM, Enrico Forestieri wrote:
On Wed, Jul 14, 2010 at 07:47:56PM +0200, Enrico Forestieri wrote:
I did not imagine I could have caused such a reaction for a safety measure
that I thought could have been quite easily overcomed. I am going to do
nothing until a *clear*
Pavel Sanda wrote:
hi,
some of my script do not work anymore due to the fact that lyx silently fails
to overwrite exported files.
i vaguely remember introducing -f switch to enforce overwriting, which must
be related.
in particular commands like:
lyx file.lyx -e dvi
won't rewrite main
On Tue, Jul 13, 2010 at 07:39:16PM +0200, Pavel Sanda wrote:
Pavel Sanda wrote:
hi,
some of my script do not work anymore due to the fact that lyx silently
fails to overwrite exported files.
i vaguely remember introducing -f switch to enforce overwriting, which must
be related.
Enrico Forestieri wrote:
this is a showstoppper for anybody using lyx in scripts.
Come on, simply add -f if you don't care overwriting existing files.
The way it worked before r34533 was fundamentally wrong.
well, changing the semantics of commandline switches is a nightmare.
just imagine
On Tue, Jul 13, 2010 at 10:54:07PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
this is a showstoppper for anybody using lyx in scripts.
Come on, simply add -f if you don't care overwriting existing files.
The way it worked before r34533 was fundamentally wrong.
well, changing
On Tue, Jul 13, 2010 at 07:01:04PM +0200, Pavel Sanda wrote:
hi,
some of my script do not work anymore due to the fact that lyx
silently fails to overwrite exported files.
This is rather a trunk regression, as in branch you get notified
when the file is not overwritten.
--
Enrico
Enrico Forestieri wrote:
Funny that you mention that:
host1 tail --version
tail (GNU coreutils) 5.97
...
host1 tail +20 foo
[commands succeeds, showing last lines of foo starting from line 20]
host2 tail --version
tail (GNU coreutils) 8.5
...
host2 tail +20 foo
tail: cannot open
Enrico Forestieri wrote:
some of my script do not work anymore due to the fact that lyx
silently fails to overwrite exported files.
This is rather a trunk regression, as in branch you get notified
when the file is not overwritten.
which is not of much help in batch mode
pavel
On Wed, Jul 14, 2010 at 01:10:18AM +0200, Pavel Sanda wrote:
core of my complaint was that changing semantics of traditional
switch is pita and will be hardly changed by disputing nitpicks
of selected examples inside coreutils.
Core of my answer was that switches of commands can be changed
On Wed, Jul 14, 2010 at 01:15:52AM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
some of my script do not work anymore due to the fact that lyx
silently fails to overwrite exported files.
This is rather a trunk regression, as in branch you get notified
when the file is not
Enrico Forestieri wrote:
could you elaborate why strong disagreement? another utils i'm currently
using
around lyx work also like that - pdflatex rewrites ouput, dvips too. you are
strongly disagree with their doing also?
its really no fun to scan all the scripts in various projects
Pavel Sanda wrote:
i still maintain that the backward compatibility will cause less user's
frustration for this particular switch (ie default RC setting would need to
be set on main file overwrite) than new gun-discharged-course but i let
the responsibility on Juergen or anybody else who want
Pavel Sanda wrote:
> hi,
>
> some of my script do not work anymore due to the fact that lyx silently fails
> to overwrite exported files.
> i vaguely remember introducing -f switch to enforce overwriting, which must
> be related.
> in particular commands like:
> lyx file.lyx -e dvi
> won't
On Tue, Jul 13, 2010 at 07:39:16PM +0200, Pavel Sanda wrote:
> Pavel Sanda wrote:
> > hi,
> >
> > some of my script do not work anymore due to the fact that lyx silently
> > fails to overwrite exported files.
> > i vaguely remember introducing -f switch to enforce overwriting, which must
> > be
Enrico Forestieri wrote:
> > this is a showstoppper for anybody using lyx in scripts.
>
> Come on, simply add -f if you don't care overwriting existing files.
> The way it worked before r34533 was fundamentally wrong.
well, changing the semantics of commandline switches is a nightmare.
just
On Tue, Jul 13, 2010 at 10:54:07PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > > this is a showstoppper for anybody using lyx in scripts.
> >
> > Come on, simply add -f if you don't care overwriting existing files.
> > The way it worked before r34533 was fundamentally wrong.
>
>
On Tue, Jul 13, 2010 at 07:01:04PM +0200, Pavel Sanda wrote:
> hi,
>
> some of my script do not work anymore due to the fact that lyx
> silently fails to overwrite exported files.
This is rather a trunk regression, as in branch you get notified
when the file is not overwritten.
--
Enrico
Enrico Forestieri wrote:
> Funny that you mention that:
>
> host1> tail --version
> tail (GNU coreutils) 5.97
> ...
> host1> tail +20 foo
> [commands succeeds, showing last lines of foo starting from line 20]
>
> host2> tail --version
> tail (GNU coreutils) 8.5
> ...
> host2> tail +20 foo
>
Enrico Forestieri wrote:
> > some of my script do not work anymore due to the fact that lyx
> > silently fails to overwrite exported files.
>
> This is rather a trunk regression, as in branch you get notified
> when the file is not overwritten.
which is not of much help in batch mode
pavel
On Wed, Jul 14, 2010 at 01:10:18AM +0200, Pavel Sanda wrote:
>
> core of my complaint was that changing semantics of traditional
> switch is pita and will be hardly changed by disputing nitpicks
> of selected examples inside coreutils.
Core of my answer was that switches of commands can be
On Wed, Jul 14, 2010 at 01:15:52AM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > > some of my script do not work anymore due to the fact that lyx
> > > silently fails to overwrite exported files.
> >
> > This is rather a trunk regression, as in branch you get notified
> > when the file
Enrico Forestieri wrote:
> > could you elaborate why strong disagreement? another utils i'm currently
> > using
> > around lyx work also like that - pdflatex rewrites ouput, dvips too. you are
> > strongly disagree with their doing also?
> > its really no fun to scan all the scripts in various
Pavel Sanda wrote:
> i still maintain that the backward compatibility will cause less user's
> frustration for this particular switch (ie default RC setting would need to
> be set on main file overwrite) than new gun-discharged-course but i let
> the responsibility on Juergen or anybody else who
Uwe Stöhr wrote:
I fixed this now in trunk and branch (I hope this was OK Jürgen.). I
simply forgot to handle OVER and also ATOP in the draw routine.
It's OK.
Jürgen
Uwe Stöhr wrote:
> I fixed this now in trunk and branch (I hope this was OK Jürgen.). I
> simply forgot to handle OVER and also ATOP in the draw routine.
It's OK.
Jürgen
On Mon, May 25, 2009 at 10:30:10PM +0200, Pavel Sanda wrote:
1. new file
2. ctrl+m
3. type \over and spacebar
4. cursor moves out of window, typed characters are not visible
The regression was introduced here:
http://www.lyx.org/trac/changeset/29263
--
Enrico
On Mon, May 25, 2009 at 11:38:24PM +0200, Enrico Forestieri wrote:
On Mon, May 25, 2009 at 10:30:10PM +0200, Pavel Sanda wrote:
1. new file
2. ctrl+m
3. type \over and spacebar
4. cursor moves out of window, typed characters are not visible
The regression was introduced here:
1. new file
2. ctrl+m
3. type \over and spacebar
4. cursor moves out of window, typed characters are not visible
The regression was introduced here:
http://www.lyx.org/trac/changeset/29263
I fixed this now in trunk and branch (I hope this was OK Jürgen.). I simply forgot to handle OVER
On Mon, May 25, 2009 at 10:30:10PM +0200, Pavel Sanda wrote:
> 1. new file
> 2. ctrl+m
> 3. type "\over" and spacebar
> 4. cursor moves out of window, typed characters are not visible
The regression was introduced here:
http://www.lyx.org/trac/changeset/29263
--
Enrico
On Mon, May 25, 2009 at 11:38:24PM +0200, Enrico Forestieri wrote:
> On Mon, May 25, 2009 at 10:30:10PM +0200, Pavel Sanda wrote:
>
> > 1. new file
> > 2. ctrl+m
> > 3. type "\over" and spacebar
> > 4. cursor moves out of window, typed characters are not visible
>
> The regression was
>> 1. new file
>> 2. ctrl+m
>> 3. type "\over" and spacebar
>> 4. cursor moves out of window, typed characters are not visible
>
> The regression was introduced here:
> http://www.lyx.org/trac/changeset/29263
I fixed this now in trunk and branch (I hope this was OK Jürgen.). I simply forgot to
92 matches
Mail list logo
