Author Topic: B4: SE confused, won't allow edits on certain files, brings up .command buffer  (Read 3529 times)

DanEngholm

  • Community Member
  • Posts: 8
  • Hero Points: 0
Since I wasn't expecting this to happen, I didn't take notes of the exact sequence that led to this problem but I have at least two files that are now uneditable in my project.  They were both named something different but I have renamed them.  I did this by closing the buffers on them, renaming them outside of SE, then going into the project properties, removing them from the files list then adding the files under their new names.  Now, I can open them but if I try to do some things on them (go to references, scroll a ways down), the buffer is replaced by one from a different open file.  If no other files are open, the buffer is for .command.

I haven't tried anything to make the problem go away, such as removing them from the project and re-adding them or recreating the project, although I have restarted SE a few times since it started.  It does seem to be persistent.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6826
  • Hero Points: 526
I have no idea what's going on. You can try rebuilding the workspace tag file (Project>Retag Workspace...). I'm just guessing what could still be storing the old filenames but I don't understand why it would matter.

You should also try a default configuration (vs -sc tempdir).
« Last Edit: May 29, 2013, 02:02:34 AM by Clark »

DanEngholm

  • Community Member
  • Posts: 8
  • Hero Points: 0
I tried retagging the workspace and it didn't make any difference.  I then removed the files from the project and closed the project properties dialog.  When I opened the file from the open tool window, it did not suffer the problem.  Then, I added the files back to the project and they still have trouble.

One thing I discovered is that it makes a difference how I open the file.  My home directory is /localhome/dengholm but /localhome is a symlink to /usr/localhome.  The way I created the project, the bulk of the files are listed with the full path name starting with /usr/localhome but the two newly renamed files only have the relative path from the project directory, which is in /localhome.  If I open through /localhome, the problem occurs.  Opening through /usr/localhome is fine.

bengle

  • Senior Community Member
  • Posts: 168
  • Hero Points: 4
This sounds like the same thing that I have started seeing in Beta 5.  There is a separate thread going on about that.  I never did see it in Beta 4, however.

bengle

  • Senior Community Member
  • Posts: 168
  • Hero Points: 4
BTW... This sounds like the same thing to me because the problem only occurs when you are opening the file via an alias path name.  In my case it was alias drive letters created via the "subst" command or mapped network drive letters.  In your case, the alias name is a symbolic link, but the idea is the same.

Also, like you, for me it either turns the window into a .command log or else a buffer for some completely different file.  I'll bet this is a variation of the Beta 5 problem.     

DanEngholm

  • Community Member
  • Posts: 8
  • Hero Points: 0
I have verified that this is no longer a problem with Beta 6.