Mattias Gaertner schrieb:
Only those should be created that were open when the IDE was closed.
Right.
When a window is later opened by the user it would be nice if the
docking manager would put it there where it was when it was last time
opened.
This would require that every window saves
Hi,
As a matter of interest. If I have specified custom compiler
optimization options in the custom editbox like SSE2, Pentium4 etc...
(Tools Configure Build Lazarus Advanced tab). Does those
optimizations filter down to the Packages compiled into the IDE as well?
--
Regards,
- Graeme -
Mattias Gaertner wrote:
At the moment the IDE calls 'make' to compile IDE, codetools, synedit,
Thanks Mattias...
Regards,
- Graeme -
___
fpGUI - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
--
Graeme Geldenhuys schrieb:
Graeme Geldenhuys wrote:
Wouldn't it be better if the Form Designer always used a consistent EOL
character - no matter what platform?
To back up my claim of altering the behaviour of the Form Designer...
Many applications and protocols on the internet also use a
Florian Klaempfl wrote:
This behaviour is imo correct? Being flexible when importing files and
when exporting save them in the native format?
So the repository doesn't truly reflect what you have locally. :-( I
guess another one of the hordes of SubVersion limitations.
Regards,
- Graeme
Florian Klaempfl wrote:
BTW: Some .lrs files in lazarus/ide miss this property. Furthermore,
some have text/plain as mime type, others text/pascal.
Thanks Florian. You just proved my point, that mistakes can and do
happen in a SubVersion repository.
As I mentioned in my previous reply to
By letting SubVersion silently modify files could corrupt sensitive text
data files as well. What if I have data files that must stay exactly as
is, no matter the platform.
In this case just don't set the mime type to text :)
--
___
Lazarus
Marc Weustink wrote:
They should. Especially if you have your sources shared with different
environments. Svn will change them to on consistent value.
To quote one of my other replies
Even the RFC4180 document dictates that CSV files *must* use CRLF as the
EOL character, no matter what
Florian Klaempfl wrote:
In this case just don't set the mime type to text :)
Funny that - a CSV file is a text file.
Regards,
- Graeme -
___
fpGUI - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
--
Graeme Geldenhuys schrieb:
Florian Klaempfl wrote:
In this case just don't set the mime type to text :)
Funny that - a CSV file is a text file.
You talked about data files in general. For a csv just set the mime type
to e.g. text/csv and svn:eolstyle to crlf and it works on all platforms
and
Marc Weustink wrote:
Since you are creating a problem which doesn't exist (for years) for the
laz developers I don't think that will happen.
Considering that many projects are flocking away from SubVersion to
something better like Git or Mercurial, it might become a problem in the
future. You
Mattias Gaertner wrote:
lfm files are human edited.
Probably by 0.1% of the general Lazarus users. In that case, the Lazarus
editor can simply detect that it's a .lfm and always use CRLF when
saving it. It already detects the .lfm because of syntax highlighting.
What .lfm patches are bigger
Graeme Geldenhuys schrieb:
Florian, you are not helping your case. ;-) Pointing out more and more
issues in SubVersion.
In which regard? cvs had a poor eol handling which caused a lot of
trouble. svn fixes this. However, when converting, the missing eol info
had been added by the conversion
Graeme Geldenhuys wrote:
Marc Weustink wrote:
They should. Especially if you have your sources shared with different
environments. Svn will change them to on consistent value.
To quote one of my other replies
Even the RFC4180 document dictates that CSV files *must* use CRLF as the
EOL
Florian Klaempfl wrote:
had been added by the conversion script but it was missed at certain
points and these omissions still pop up.
I hope the script I supplied helps a bit, or gets you on the right track.
If git is better you shouldn't have any trouble with line feeding.
Remember that my
Op donderdag 11-06-2009 om 12:39 uur [tijdzone +0200], schreef Graeme
Geldenhuys:
Marc Weustink wrote:
Since you are creating a problem which doesn't exist (for years) for the
laz developers I don't think that will happen.
Considering that many projects are flocking away from SubVersion
Graeme Geldenhuys schrieb:
Florian Klaempfl wrote:
had been added by the conversion script but it was missed at certain
points and these omissions still pop up.
I hope the script I supplied helps a bit, or gets you on the right track.
We used such a script but if you forget about certain
Op donderdag 11-06-2009 om 13:20 uur [tijdzone +0200], schreef Graeme
Geldenhuys:
Fixed. Git is more that just a source code repository (ala
SubVersion),
it is more like a file system with integrity checking all built in.
What
you put in, is exactly (guaranteed by SHA1 checks) what you
Joost van der Sluis wrote:
That's why _you_ have a problem now with line-endings, because your tool
doesn't handle this right.
I use the best tool for the job, otherwise we would all be developing
software using vi or notepad.
I am NOT suggesting you guys change you repository!!! We have
Mattias Gaertner wrote:
I just tested: They are not huge when using svn diff, nor when using
In the patches I submitted, every single line in the .lfm files have
changed, when in fact only a few values have changed. This makes in near
impossible for the person committing that patch to actually
Op donderdag 11-06-2009 om 14:17 uur [tijdzone +0200], schreef Graeme
Geldenhuys:
Joost van der Sluis wrote:
That's why _you_ have a problem now with line-endings, because your tool
doesn't handle this right.
I use the best tool for the job, otherwise we would all be developing
Florian Klaempfl wrote:
Tell this unix editor writers (and MS too).
If I create a document using OpenOffice under Linux, that document also
works fine under Windows and vice-versa. Most editors I know or use can
happily edit a text file and keep the EOL style as it was before. No
need for
Vincent Snijders schreef:
http://wiki.lazarus.freepascal.org/MorphOS
No Lazarus port yet, though.
Vincent
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Joost van der Sluis wrote:
Maybe in your -unix-centric- world. But not in the real
-windows-centric- world. And we are aiming to build some tools which are
really cross-platform. And not with all kind of tricks.
Oh like the tricks to tell SubVersion to convert line-endings and then
you
Vincent Snijders wrote:
http://wiki.lazarus.freepascal.org/MorphOS
Thanks Vincent. Amiga compatible. Amiga was before my time or just not
popular in South Africa. :-)
Regards,
- Graeme -
___
fpGUI - a cross-platform GUI toolkit using Free
25 matches
Mail list logo
