-
I tried it: works like a charm.
Thank you,
Danilo Turina.
2008-09-18 07:36:29 UTC in Uncrustify Code Beautifier
-
Sorry, don't know why but bug description was truncated.
I complete it here:
Imho, it should be possible to have an option that allows to decide whether to apply the default behavior to "
2008-09-16 05:56:11 UTC in Uncrustify Code Beautifier
-
Hi,
with the latest (0.49) version of Uncrustify I reformatted this piece of code (spaces replaced by underscores):
void f() {
____int a=
________1 + 2
________+3
________+4
____;
____bool b=
________1 == 2
________==3
________==4
____;
____int a=
________1
2008-09-16 05:54:26 UTC in Uncrustify Code Beautifier
-
Sorry, forgot to tell that I wrote the patch on the source code of SciTE 1.76.
2008-05-24 13:55:11 UTC in Scintilla
-
You can find a patch attached to this comment.
A few notes about the patch:
1) while there where multiple choices ([a] closing the current buffer and switching to the one that already have the chosen filename, [b] preventing the action at all, [c] alerting the user and letting him continue if he wants, etc.) with different flavors (with or without alert to the user, configurable or not...
2008-05-24 13:51:22 UTC in Scintilla
-
I understand the design choice of SciTE (and I agree too: the test case came from a real world situation in which I, by mistake, performed a "save as" on two different buffers to the same file).
Anyway, the problem that I had with this "bug" was not that I had two buffers for the same file and it wasn't handled correctly but, instead, that I, by mistake, had the same file opened in two...
2008-05-24 07:09:41 UTC in Scintilla
-
Scenario
--------
1) PC with Windows XP Professional.
2) SciTE with:
load.on.activate=1
in its config file.
Test
----
1) create two new buffers and write some text on each of them;
2) save the second buffer to a file;
3) save the first buffer to the same file of the first.
(save order is important to reproduce this problem)
Now you have two buffers open for the same...
2008-05-23 12:42:36 UTC in Scintilla
-
Forgot to mention that I discovered this problem because it occurs when using ClearCase (in particular when asking the comparison with the previous version in the Find Checkouts tool that is listing the files of a view to which no drive letter has been assigned)
2008-02-27 12:08:31 UTC in KDiff3
-
Context
-------
1) Client Windows machine (on which KDiff3 is installed)
2) Network share on remote machine accessible by the client machine ("\\remotemachine\share")
When the current directory is on the remote share (e.g. \\remotemachine\share or \\remotemachine\share\some\dir) an "absolute" path starting with the backslash ("\") is relative to the network share.
For example:
2008-02-27 12:07:16 UTC in KDiff3
-
Now I'm able to reproduce it:
1) open a text file in SciTE;
2) modify it externally (e.g. using another editor)
3) go back to SciTE that will ask you to reload the file, answer "Yes"
4) from now on (until you reload ("Revert") the file) you'll have the described behavior, i.e.:
a) delete some text from the file (a word for example);
b) move the cursor away from that...
2007-07-30 06:52:32 UTC in Scintilla
