It seems that code-browser is not aware of external changes to the files it is editting. A bug, IMO.
I opened a file, edit, save, close it (Esc key). Then edit it with another editor and reopen the file in code-browser, the latest changes are not there.
Looks like code-browser didn't close the file at all, it just hides it. Also, there is no File->Close command.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a bug and I know that Marc is aware of it.
The behaviour with closed files are by design, however. If you open the File->Files... dialog, you will see the files that are in memory.
As Marc pointed out to me, it is not trivial to implement a "reload" functionality as the file might have changed in a way that doesn't work with the current view (the folder structure might be different). My suggestion is implement it by reloading and then doing the equivalent to chosing "Go To Line" in the edit menu.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is the problem with closing a file completely (deleting the file and associated viewer/editer objects) and re-opening it ? You loose your current view on the file, but at least it is safe. That is what editors like vim and emacs do when a file changes outside of their control.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Code Browser has a system of links between text files, it differs from traditional text editors where files are just isolated objects. it can display several files a single window and a single file can be displayed in several windows. There is also hidden references to files because of web style navigation (the back stacks).
Unloading a file should be done automatically when there is no more window having a reference on it. So I won't implement a "Close File" command.
The reload functionality is not easy to implement without having windows that disapear. But I agree that this feature is necessary to avoid restarting the application when external changes occur (source control, other editor, ...).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think at the very least, code-browser should detect external changes and then ask the user if they want to continue. Otherwise external changes would be discard without the user's knowledge.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But it is a bit funky, code-browser doesn't always detect the external changes and it seems to detect external changes only once, subsequent changes are not detected at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you give me more information (platform/window manager). it might be a bug.
External changes are detected when the editor window is re-activated or after running a tool. If changes are done remotely or by a background process, they won't be detected.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am running Code-Browser on Linux (Debian unstable, kernel 2.4.29, XFree86 4.3.0.1, Ion3 ds20041005 for wm).
What I did was: start up code-browser with a file then repeatedly do some edits and saves with vim on the same file.
Sometimes it works perfectly, Code-browser detects all the changes, but sometimes it detects at the most one single external change, or it doesn't detect any changes at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's interesting for me to know that someone else uses Code Browser with Ion, because I've experimented non-floating dialog boxes (text area is temporarily resized and dialogs are displayed below it), this should be useful with this WM. So I may add an option in preferences.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems that code-browser is not aware of external changes to the files it is editting. A bug, IMO.
I opened a file, edit, save, close it (Esc key). Then edit it with another editor and reopen the file in code-browser, the latest changes are not there.
Looks like code-browser didn't close the file at all, it just hides it. Also, there is no File->Close command.
This is a bug and I know that Marc is aware of it.
The behaviour with closed files are by design, however. If you open the File->Files... dialog, you will see the files that are in memory.
As Marc pointed out to me, it is not trivial to implement a "reload" functionality as the file might have changed in a way that doesn't work with the current view (the folder structure might be different). My suggestion is implement it by reloading and then doing the equivalent to chosing "Go To Line" in the edit menu.
What is the problem with closing a file completely (deleting the file and associated viewer/editer objects) and re-opening it ? You loose your current view on the file, but at least it is safe. That is what editors like vim and emacs do when a file changes outside of their control.
Code Browser has a system of links between text files, it differs from traditional text editors where files are just isolated objects. it can display several files a single window and a single file can be displayed in several windows. There is also hidden references to files because of web style navigation (the back stacks).
Unloading a file should be done automatically when there is no more window having a reference on it. So I won't implement a "Close File" command.
The reload functionality is not easy to implement without having windows that disapear. But I agree that this feature is necessary to avoid restarting the application when external changes occur (source control, other editor, ...).
I think at the very least, code-browser should detect external changes and then ask the user if they want to continue. Otherwise external changes would be discard without the user's knowledge.
Cool ! This had been implemented in 1.3. :)
But it is a bit funky, code-browser doesn't always detect the external changes and it seems to detect external changes only once, subsequent changes are not detected at all.
Hi Mark,
Can you give me more information (platform/window manager). it might be a bug.
External changes are detected when the editor window is re-activated or after running a tool. If changes are done remotely or by a background process, they won't be detected.
I am running Code-Browser on Linux (Debian unstable, kernel 2.4.29, XFree86 4.3.0.1, Ion3 ds20041005 for wm).
What I did was: start up code-browser with a file then repeatedly do some edits and saves with vim on the same file.
Sometimes it works perfectly, Code-browser detects all the changes, but sometimes it detects at the most one single external change, or it doesn't detect any changes at all.
Also, once CB failed to detect an external change in a file, it won't detect any other external changes after that.
I cannot reproduce the bug, but I have an idea. It could happen if the file is temporarily unavailable.
Can you help me: in the file lib/zlib/file/private/io.c, line 39, replace the "return 0xFFFFFFFF;" by "return 0;" and redo a make + make install.
Let me know if it works better, I'll do a better fix for the next release.
The problems seems to be with the interaction between CB and the WM (Ion3 ds20041005), check file updates is not always called.
Also, I didn't need the s/0xFFFFFFFF/0/ fix. It works fine with other wm's or ion's floatWS. :)
Ok, I use Ion1 and I didn't have any problems.
As a work around, you can create a dummy tool like this:
def refresh
caption = Check file updates
command = echo
arguments = ...
save.all = false
end
and run it to force checking file updates.
It's interesting for me to know that someone else uses Code Browser with Ion, because I've experimented non-floating dialog boxes (text area is temporarily resized and dialogs are displayed below it), this should be useful with this WM. So I may add an option in preferences.
The problem remains with the latest version of ion3 - ds-20050115; thanks for the force check update trick.
Can we move the update check up the event chain closer to the mainloop ? Or that would affect performance too much ?
Non-floating dialog boxes would certain be useful to me too. :)