Vincent van Ravesteijn wrote:
>> please make sure that doxygen comments are still valid for the lfuns you
>> changed
>> pavel
>>
> I'll take care of it.. (when things are not changing anymore).
thanks
pavel
Pavel Sanda schreef:
v...@lyx.org wrote:
Author: vfr
Date: Fri Apr 10 02:20:12 2009
New Revision: 29176
URL: http://www.lyx.org/trac/changeset/29176
Log:
Make the insets accept LFUN_INSET_SETTINGS. These insets did not yet respond to
LFUN_INSET_SETTINGS. One had to use LFUN_INSET_TOGGLE to
v...@lyx.org wrote:
> Author: vfr
> Date: Fri Apr 10 02:20:12 2009
> New Revision: 29176
> URL: http://www.lyx.org/trac/changeset/29176
>
> Log:
> Make the insets accept LFUN_INSET_SETTINGS. These insets did not yet respond
> to LFUN_INSET_SETTINGS. One had to use LFUN_INSET_TOGGLE to show the se
Jean-Marc Lasgouttes wrote:
1. If an LFUN_INSET_TOGGLE is send to an InsetCommand, the settings
dialog is shown. Wouldn't it make more sense to dispatch an
LFUN_INSET_SETTINGS instead ?
Actually, I would remove this possibility for inset-toggle to open a
dialog, and find a convenient shortcut
Pavel Sanda wrote:
> > I am not sure this idea is better than just parsing "svn status -v"...
>
> > Further ideas? Opinions?
another idea - svn is gpl-ed right? then what about to steal few lines of
code parsing .svn directory from svn status -v / svnversion?
pavel
Abdelrazak Younes wrote:
> 1) When a document "doc.lyx" is under version control, we can check its svn
> properties:
>
> svn propget svn:keywords dot.lyx
hopefully we can avoid this by checking (under_svn_control &&
revision_insetinfo_used)
> 2) For each of those keywords, we add the following
Jean-Marc Lasgouttes schreef:
1. If an LFUN_INSET_TOGGLE is send to an InsetCommand, the settings
dialog is shown. Wouldn't it make more sense to dispatch an
LFUN_INSET_SETTINGS instead ?
Actually, I would remove this possibility for inset-toggle to open a
dialog, and find a convenient shortc
1. If an LFUN_INSET_TOGGLE is send to an InsetCommand, the settings
dialog is shown. Wouldn't it make more sense to dispatch an
LFUN_INSET_SETTINGS instead ?
Actually, I would remove this possibility for inset-toggle to open a
dialog, and find a convenient shortcut for inset-setting instead
Vincent van Ravesteijn - TNW wrote:
Put a label in a note, then dissolve the note. LyX will
rename the label. I assume this must be because the renaming
business is done before the contents of the note itself are
deleted.
So, we don't cut and paste, but paste and cut.
Turns out it's a
On 09/04/2009 19:44, Vincent van Ravesteijn wrote:
Hi all,
I have some questions on de handling of LFUN_INSET_TOGGLE / SETTINGS.
1. If an LFUN_INSET_TOGGLE is send to an InsetCommand, the settings
dialog is shown. Wouldn't it make more sense to dispatch an
LFUN_INSET_SETTINGS instead ?
yes.
Hi all,
I have some questions on de handling of LFUN_INSET_TOGGLE / SETTINGS.
1. If an LFUN_INSET_TOGGLE is send to an InsetCommand, the settings
dialog is shown. Wouldn't it make more sense to dispatch an
LFUN_INSET_SETTINGS instead ?
2. the status of LFUN_INSET_SETTINGS is handled by
Buff
Today a user asked for an interesting feature:
When installing LyX, the LaTeX hyphenation patters are not installed for the
menu language of LyX.
(http://article.gmane.org/gmane.editors.lyx.general/55728)
To solve this problem, I can implement a solution only for the LyX installer, where I modif
Jürgen Spitzmüller writes:
> Jean-Marc Lasgouttes wrote:
>
>>> btw do you plan to backport the new monolithic switch in the branch?
>>
>> Sure (unless Juergen objects, that is). But I am a bit busy right now.
>
> No, no objections from me.
I did that now. The old switches still work (by autocon
Abdelrazak Younes wrote:
Pavel Sanda wrote:
Pavel Sanda wrote:
Hum, another solution would be to use propset:
svn propset svn:keywords "Rev"
see
http://dev.juokaz.com/php/automatic-svn-revision-number-in-source-code
interesting idea, however i don't get how you would like to use it
>Put a label in a note, then dissolve the note. LyX will
>rename the label. I assume this must be because the renaming
>business is done before the contents of the note itself are
>deleted.
So, we don't cut and paste, but paste and cut.
>rh
Vincent
Put a label in a note, then dissolve the note. LyX will rename the
label. I assume this must be because the renaming business is done
before the contents of the note itself are deleted.
rh
Pavel Sanda wrote:
Pavel Sanda wrote:
Hum, another solution would be to use propset:
svn propset svn:keywords "Rev"
see http://dev.juokaz.com/php/automatic-svn-revision-number-in-source-code
interesting idea, however i don't get how you would like to use it locally
(in the local cop
Pavel Sanda wrote:
Pavel Sanda wrote:
Hum, another solution would be to use propset:
svn propset svn:keywords "Rev"
see http://dev.juokaz.com/php/automatic-svn-revision-number-in-source-code
interesting idea, however i don't get how you would like to use it locally
(in the local cop
Pavel Sanda wrote:
> > Hum, another solution would be to use propset:
> >
> > svn propset svn:keywords "Rev"
> >
> > see http://dev.juokaz.com/php/automatic-svn-revision-number-in-source-code
>
> interesting idea, however i don't get how you would like to use it locally
> (in the local copy you wi
Kornel Benko wrote:
Am 2009-04-09 schrieb Abdelrazak Younes:
Kornel Benko wrote:
Am 2009-04-09 schrieb Pavel Sanda:
Pavel Sanda wrote:
Kornel Benko wrote:
try svnversion:
#cd .../branch1.6
#svnversion
29157M
b
The attached patch backports r27635, r28193, r28194, r28220, r29094, and
r29095. The point of these, taken together, is to improve the display of
information in InsetCitation and GuiCitation, by gathering missing data
from the crossref, if one is defined, basically as BibTeX does.
OK?
rh
I
Abdelrazak Younes wrote:
> Pavel Sanda wrote:
>> Pavel Sanda wrote:
>> > Kornel Benko wrote:
>> >> try svnversion:
>> >>
>> >> #cd .../branch1.6 #svnversion 29157M
>> > beware of the output, i just get 29123:29124M here...
>>
>> even worse, it doesn't produce version of the given file, which is
Am 2009-04-09 schrieb Kornel Benko:
> > 'svn status -v' is quite easy to parse too. And you get the current
> > global revision as a bonus as well as the last committer.
> >
> > >
> > > Why do you need it? Every new commit produces an new revision, which is
> > > then valid for _all_ files.
> >
Kornel Benko wrote:
Am 2009-04-09 schrieb Abdelrazak Younes:
Kornel Benko wrote:
Am 2009-04-09 schrieb Pavel Sanda:
Pavel Sanda wrote:
Kornel Benko wrote:
try svnversion:
#cd .../branch1.6
#svnversion
29157M
b
Am 2009-04-09 schrieb Abdelrazak Younes:
> Kornel Benko wrote:
> > Am 2009-04-09 schrieb Pavel Sanda:
> >
> >> Pavel Sanda wrote:
> >>
> >>> Kornel Benko wrote:
> >>>
> try svnversion:
>
> #cd .../branch1.6
> #svnversion
> 29157M
>
> >>> bewar
Pavel Sanda wrote:
Pavel Sanda wrote:
> Kornel Benko wrote:
>> try svnversion:
>>
>> #cd .../branch1.6 #svnversion 29157M
> beware of the output, i just get 29123:29124M here...
even worse, it doesn't produce version of the given file, which is a
must since different files can have different
rgheck wrote:
Pavel Sanda wrote:
Richard Heck wrote:
There must be a way to do it at build time. That said, the TREE
doesn't have a version in svn, so it's not immediately clear what to
check.
we dont want to check tree version but file version, ie to have
revision-controled
lyx fil
Pavel Sanda wrote:
Richard Heck wrote:
There must be a way to do it at build time. That said, the TREE doesn't
have a version in svn, so it's not immediately clear what to check.
we dont want to check tree version but file version, ie to have
revision-controled
lyx file with automatic
Kornel Benko wrote:
Am 2009-04-09 schrieb Pavel Sanda:
Pavel Sanda wrote:
Kornel Benko wrote:
try svnversion:
#cd .../branch1.6
#svnversion
29157M
beware of the output, i just get 29123:29124M here...
even worse, it doesn't produce version of the give
Am 2009-04-09 schrieb Pavel Sanda:
> Pavel Sanda wrote:
> > Kornel Benko wrote:
> > > try svnversion:
> > >
> > > #cd .../branch1.6
> > > #svnversion
> > > 29157M
> >
> > beware of the output, i just get 29123:29124M here...
>
> even worse, it doesn't produce version of the given file,
> whic
Am 2009-04-09 schrieb Pavel Sanda:
> Kornel Benko wrote:
> > try svnversion:
> >
> > #cd .../branch1.6
> > #svnversion
> > 29157M
>
> beware of the output, i just get 29123:29124M here...
> pavel
>
But that is ok. Try 'svnversion --help' to see, what it means.
...
4123:4168 mix
Pavel Sanda wrote:
> Kornel Benko wrote:
> > try svnversion:
> >
> > #cd .../branch1.6
> > #svnversion
> > 29157M
>
> beware of the output, i just get 29123:29124M here...
even worse, it doesn't produce version of the given file,
which is a must since different files can have different
revi
Kornel Benko wrote:
> try svnversion:
>
> #cd .../branch1.6
> #svnversion
> 29157M
beware of the output, i just get 29123:29124M here...
pavel
Richard Heck wrote:
> There must be a way to do it at build time. That said, the TREE doesn't
> have a version in svn, so it's not immediately clear what to check.
we dont want to check tree version but file version, ie to have
revision-controled
lyx file with automatical revision numbering when
Am 2009-04-09 schrieb Abdelrazak Younes:
> Kornel Benko wrote:
> > Am 2009-04-09 schrieb Abdelrazak Younes:
> >
> >> I guess this is a question for Pavel...
> >>
> >> Would it be easy to add svn revision number (or git hash) in InsetInfo?
> >> Well, once we have the number, this is easy to exten
Pavel Sanda wrote:
Abdelrazak Younes wrote:
I guess this is a question for Pavel...
Would it be easy to add svn revision number (or git hash) in InsetInfo?
Well, once we have the number, this is easy to extend InsetInfo for that
but how to get the number?
actually - i was already try
Kornel Benko wrote:
Am 2009-04-06 schrieb Kornel Benko:
Hi,
the problem is immediate crash when clicking on the outline-icon.
I wanted to trace it down, but the recompiled version with "-O0 -g3 -D_NDEBUG"
did not crash anymore.
Doublechecking I recompiled again, this time with "-O3 -DNDEBUG"
Pavel Sanda wrote:
Abdelrazak Younes wrote:
I guess this is a question for Pavel...
Would it be easy to add svn revision number (or git hash) in InsetInfo?
Well, once we have the number, this is easy to extend InsetInfo for that
but how to get the number?
actually - i was already try
Kornel Benko wrote:
Am 2009-04-09 schrieb Abdelrazak Younes:
I guess this is a question for Pavel...
Would it be easy to add svn revision number (or git hash) in InsetInfo?
Well, once we have the number, this is easy to extend InsetInfo for that
but how to get the number?
svn 'status -v' g
Abdelrazak Younes wrote:
> I guess this is a question for Pavel...
>
> Would it be easy to add svn revision number (or git hash) in InsetInfo?
> Well, once we have the number, this is easy to extend InsetInfo for that
> but how to get the number?
actually - i was already trying to do this, but pa
Am 2009-04-09 schrieb Abdelrazak Younes:
> I guess this is a question for Pavel...
>
> Would it be easy to add svn revision number (or git hash) in InsetInfo?
> Well, once we have the number, this is easy to extend InsetInfo for that
> but how to get the number?
> svn 'status -v' gives too much i
I guess this is a question for Pavel...
Would it be easy to add svn revision number (or git hash) in InsetInfo?
Well, once we have the number, this is easy to extend InsetInfo for that
but how to get the number?
svn 'status -v' gives too much information...
Ideas?
Abdel.
Am 2009-04-06 schrieb Kornel Benko:
> Hi,
> the problem is immediate crash when clicking on the outline-icon.
> I wanted to trace it down, but the recompiled version with "-O0 -g3
> -D_NDEBUG" did not crash anymore.
> Doublechecking I recompiled again, this time with "-O3 -DNDEBUG", and now the
>
43 matches
Mail list logo
