Sometimes I like to edit single scripts or test files in my home
folder. And creating a project in there will cause rope/emacs to
freeze when I open it. The files in my home folder aren't really
related, so I'm wondering if it's possible to use rope in a "single-
script" mode that doesn't try to use a project. I'd just like rope for
completing the stdlib and things in the same file stuff.
magcius <jstpie...@mecheye.net> wrote:
> Sometimes I like to edit single scripts or test files in my home
> folder. And creating a project in there will cause rope/emacs to
> freeze when I open it. The files in my home folder aren't really
> related, so I'm wondering if it's possible to use rope in a "single-
> script" mode that doesn't try to use a project. I'd just like rope for
> completing the stdlib and things in the same file stuff.
You can call rope-open-project on an empty temporary folder. After
that, rope commands should not show the open project prompt again.
I'm not sure if that can be called non-interactively; does putting
(rope-open-project "/tmp/") inside .emacs work?
Anyway, AFAIR refactorings won't work for out-of-project modules.
I rarely use refactorings. Anyway, I use rope-guess-project, so if I have
/tmp/ opened and I open
/home/myproject/package/two/three.py, will it be smart enough to look to see
that
/home/myproject/.ropeproject/ exists and open that?
On Mon, Apr 26, 2010 at 7:13 AM, Ali Gholami Rudi <aligr...@gmail.com>wrote:
> magcius <jstpie...@mecheye.net> wrote:
> > Sometimes I like to edit single scripts or test files in my home
> > folder. And creating a project in there will cause rope/emacs to
> > freeze when I open it. The files in my home folder aren't really
> > related, so I'm wondering if it's possible to use rope in a "single-
> > script" mode that doesn't try to use a project. I'd just like rope for
> > completing the stdlib and things in the same file stuff.
> You can call rope-open-project on an empty temporary folder. After
> that, rope commands should not show the open project prompt again.
> I'm not sure if that can be called non-interactively; does putting
> (rope-open-project "/tmp/") inside .emacs work?
> Anyway, AFAIR refactorings won't work for out-of-project modules.
"Jasper St. Pierre" <jstpie...@mecheye.net> wrote:
> I rarely use refactorings. Anyway, I use rope-guess-project, so if I have
> /tmp/ opened and I open
> /home/myproject/package/two/three.py, will it be smart enough to look to see that
> /home/myproject/.ropeproject/ exists and open that?
No, you have to close the project first (or open the second one
which closes the first automatically). That's not always bad;
sometimes you just want to have a look at a module outside current
project, maybe via goto definition, and go back.
But if you really want that behavior, that doesn't seem hard.
See _check_project() in ropemode/interface.py. Maybe this works:
"Jasper St. Pierre" <jstpie...@mecheye.net> wrote:
> Oh, that reminds me of another bug/feature. If I open a file with
> goto-definition, the buffer is readonly. Even if the
> file is already open in a buffer, and I goto-definition, it turns the buffer
> readonly I don't like that.
See _goto_location() in ropemode/interface.py; it opens the
file in readonly mode when the file is outside current project;
resource.project is an instance of NoProject for files outside
current project. This fixes the bug, but out-of-project files
are no longer opened readonly, is this behavior change OK?
Otherwise one can change the find_file() in ropemacs not to
toggle a file readonly if it is already open.
"Jasper St. Pierre" <jstpie...@mecheye.net> wrote:
> > See _goto_location() in ropemode/interface.py; it opens the
> > file in readonly mode when the file is outside current project;
> > resource.project is an instance of NoProject for files outside
> > current project. This fixes the bug, but out-of-project files
> > are no longer opened readonly, is this behavior change OK?
> > Otherwise one can change the find_file() in ropemacs not to
> > toggle a file readonly if it is already open.
> I don't understand this readonly stuff. I don't think it's ever useful.
> "Jasper St. Pierre" <jstpie...@mecheye.net> wrote:
>> > See _goto_location() in ropemode/interface.py; it opens the
>> > file in readonly mode when the file is outside current project;
>> > resource.project is an instance of NoProject for files outside
>> > current project. This fixes the bug, but out-of-project files
>> > are no longer opened readonly, is this behavior change OK?
>> > Otherwise one can change the find_file() in ropemacs not to
>> > toggle a file readonly if it is already open.
>> I don't understand this readonly stuff. I don't think it's ever useful.
> angri, what do you think?
> Thanks,
> Ali
I don't see a big problem with the fact that after "go to definition"
you get to read-only buffer. I usually do ":set modifieable" if i need
to modify it and thats all.
Maybe the more useable feature would be to open definition found in
new buffer. But, again, I don't see a problem here.
general <gene...@angri.ru> wrote:
> I don't see a big problem with the fact that after "go to definition"
> you get to read-only buffer. I usually do ":set modifieable" if i need
> to modify it and thats all.
> Maybe the more useable feature would be to open definition found in
> new buffer. But, again, I don't see a problem here.
Then what about this patch? (I'm not sure if ropevim_goto_def_newwin
is the best possible name for it though; rename it if you can think of
a better one :-) ).
> general <gene...@angri.ru> wrote:
> > I don't see a big problem with the fact that after "go to definition"
> > you get to read-only buffer. I usually do ":set modifieable" if i need
> > to modify it and thats all.
> > Maybe the more useable feature would be to open definition found in
> > new buffer. But, again, I don't see a problem here.
> Then what about this patch? (I'm not sure if ropevim_goto_def_newwin
> is the best possible name for it though; rename it if you can think of
> a better one :-) ).
On Tue, Apr 27, 2010 at 12:03 PM, Ali Gholami Rudi <aligr...@gmail.com> wrote:
> Hi,
> "Jasper St. Pierre" <jstpie...@mecheye.net> wrote:
>> Well, angri, it's not that useful for us using emacs because
>> there's no way to make it modifyable again except open it.
> C-c C-q should work, AFAIR.
you mean C-x C-q?
I found this bothers me a lot when the file opend does not
belong to the current project.I think it would be better to first
check the file whether it is opened or not, if it is already open,
then just switch to that buffer without change the modifyable
status, if it is not opened yet then open it readonly.
> On Tue, Apr 27, 2010 at 12:03 PM, Ali Gholami Rudi <aligr...@gmail.com> wrote:
>> Hi,
>> "Jasper St. Pierre" <jstpie...@mecheye.net> wrote:
>>> Well, angri, it's not that useful for us using emacs because
>>> there's no way to make it modifyable again except open it.
>> C-c C-q should work, AFAIR.
> you mean C-x C-q?
> I found this bothers me a lot when the file opend does not
> belong to the current project.I think it would be better to first
> check the file whether it is opened or not, if it is already open,
> then just switch to that buffer without change the modifyable
> status, if it is not opened yet then open it readonly.
general <gene...@angri.ru> wrote:
> > I found this bothers me a lot when the file opend does not
> > belong to the current project.I think it would be better to first
> > check the file whether it is opened or not, if it is already open,
> > then just switch to that buffer without change the modifyable
> > status, if it is not opened yet then open it readonly.
> I'm agree, that would be great.
The patch in my last mail should do it; it doesn't open files
in readonly mode anymore and based on goto_def_newwin config
(ropevim_goto_def_newwin in ropevim and ropemacs-goto-def-newwin
in ropemacs) opens the definition in a new window. But I haven't
tested it. If you don't see any problems with it, would you take
it?
> general <gene...@angri.ru> wrote:
>> > I found this bothers me a lot when the file opend does not
>> > belong to the current project.I think it would be better to first
>> > check the file whether it is opened or not, if it is already open,
>> > then just switch to that buffer without change the modifyable
>> > status, if it is not opened yet then open it readonly.
>> I'm agree, that would be great.
> The patch in my last mail should do it; it doesn't open files
> in readonly mode anymore and based on goto_def_newwin config
> (ropevim_goto_def_newwin in ropevim and ropemacs-goto-def-newwin
> in ropemacs) opens the definition in a new window. But I haven't
> tested it. If you don't see any problems with it, would you take
> it?
> Thanks,
> Ali
I've tested the patch and it works like a charm! :)
I've commited it as two distinct changes: first for opening file in
new buffer and second for disabling nomodifieable buffers. And I've
commited a notice in ropevim/README.txt about new ropevim_envvar.
On Tuesday, 27 April 2010 19:32:44 UTC+5:30, aligrudi wrote:
> Hi,
> general <gen...@angri.ru <javascript:>> wrote: > > > I found this bothers me a lot when the file opend does not > > > belong to the current project.I think it would be better to first > > > check the file whether it is opened or not, if it is already open, > > > then just switch to that buffer without change the modifyable > > > status, if it is not opened yet then open it readonly.
> > I'm agree, that would be great.
> The patch in my last mail should do it; it doesn't open files > in readonly mode anymore and based on goto_def_newwin config > (ropevim_goto_def_newwin in ropevim and ropemacs-goto-def-newwin > in ropemacs) opens the definition in a new window. But I haven't > tested it. If you don't see any problems with it, would you take > it?
> On Tuesday, 27 April 2010 19:32:44 UTC+5:30, aligrudi wrote:
>> Hi,
>> general <gen...@angri.ru> wrote: >> > > I found this bothers me a lot when the file opend does not >> > > belong to the current project.I think it would be better to first >> > > check the file whether it is opened or not, if it is already open, >> > > then just switch to that buffer without change the modifyable >> > > status, if it is not opened yet then open it readonly.
>> > I'm agree, that would be great.
>> The patch in my last mail should do it; it doesn't open files >> in readonly mode anymore and based on goto_def_newwin config >> (ropevim_goto_def_newwin in ropevim and ropemacs-goto-def-newwin >> in ropemacs) opens the definition in a new window. But I haven't >> tested it. If you don't see any problems with it, would you take >> it?
