My problem was not with remote files, but with local files.
I use one emacs to load a file which is then parsed by semantic. Also
idle timer kicks in once in a while where it iterates over all
buffers and it seemed to attempt to update the tags.
I use another machine and remove the file in question, so that although
the file is no longer on disk, my emacs still has a buffer with the old
content of now removed file.
Under this condition, when the idle timer code kicks in it did not check
whether the file still existed or not. Intead it just went ahead and
tried to update the semantic tags for the buffer. This is when emacs
threw some general idle timer error message.
So recently Alex added a check in semantic-idle-scheduler-enabled-p (bzr
rev 8113 on trunk) to make sure that a remote file is still accessible
before continuing on with idle processing. He also added a
file-exists-p check for local files. I believe he did this latter part
at my request.
Now Alex seemed to have taken the code that was added initially in
semantic-idle-scheduler-enabled-p, package it into a separate function,
then seems to be replacing many occurrences of file-exists-p with the
new function. This changes seems reasonable to me, but I do not use
remote files myself and semantic together.
If it would help still, I could try to capture the stack trace of the
idle timer code, but then I would have to revert rev 8113 to be able to
obtain the stack trace.
In general I think idle timer must be very conservative in that it
should do no harm. One of the reasons why it took me so long to get
back to using semantic (my laziness being the foremost reason) is that
each time I tried it over the years, my emacs somehow got hosed and it
was difficult for me to figure out what was going on. Even now I turn
off semantic sometimes, because my emacs just becomes so sluggish and
quite often it does not respond to repeated control-g. I've been trying
to obtain stack trace of such problems, but emacs is so hosed that I
just kill it altogether. I will continue to try to help diagnose idle
timer problems in the future. Tips on how to do that would be helpful,
because I only know very old methods such as debug-on-error
and debug-on-quit which do not seem to be very helpful.
Lastly I should add that my impatience compounds the problem.
I think my repeated control-g to wake up emacs while it id doing
idle timer processing seems to make matters worse by making emacs
even more sluggish.
On Thu, Dec 22 2011, Alex Ott wrote:
I don't have exact stacktrace, only screenshot of it
Emacs became crazy and doesn't responded :-(
As I remember, other users also had similar problems, but I don't know
- does they use Semantic's features for remote files or not?
On Thu, Dec 22, 2011 at 8:12 AM, David Engster <deng@...> wrote:
> Alex Ott writes:
>> Hello all
>> I made changes to semantic so instead of file-exists-p the new
>> function semantic-safe-file-exist-p will be used, could core
>> developers look onto patch? (it attached) If everything ok, then I can
>> commit it...
>> The main reason for this change - if remote server goes down, and I
>> want to exit Emacs, then it fails because it wants to store tags for
>> files, that aren't exist anymore... This change is generalization of
>> my previous changes to semantic-idle-scheduler-enabled-p...
> I'm having trouble understanding the exact problem; Semantic should try
> to save the db files locally, and it already has parsed the remote files
> when you've opened them. So say you're editing a remote C file like
> /ssh:myserver:test.c. The connection to 'myserver' goes down and
> sometime later you do C-x C-c, and `semanticdb-save-all-db' throws an
> error? Could you maybe post a backtrace of that error?
> I just want to see if there isn't an easier way to fix this. Frankly,
> I'm not thrilled by the idea of replacing all the file-exists-p
> calls. Is it even possible to get CEDET reliably working with Tramp? If
> not, we should simply disable Semantic for remote files.
With best wishes, Alex Ott
Tiwtter: alexott_en (English), alexott (Russian)
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
Cedet-devel mailing list