On Apr 21, 7:32 pm, "Kayvan A. Sylvan" <[EMAIL PROTECTED]> wrote:
> Great! Maybe this will be my first Leo plugin. I am still very much
> loving using Leo as my programming platform.
The following is just "thinking out loud". Anyone (including Kayvan)
should feel free to ignore it :-) Somehow this project has got my
attention. I like puzzles, and besides, why should Kayvan have all
the fun :-)
In the absence of meaningful docs, we are left with the sources.
Sometimes it's useful to guess what the sources do before looking at
them. This will guide the search, and it will highlight where the
initial guesses need to be revised. So here goes.
I. My initial guesses
Let us suppose brm provides n refactorings. n is 5 or 6, I am
guessing. For each refactoring, we expect to see the following:
1. Code to create a corresponding menu item. Important: a brm plugin
should not create brm menu items: the user can create such items using
@menu entries in Leo's settings files. I expect such menu items to
become a standard part of Leo eventually. For example, Leo could
distribute a copy of brm in the leo/extensions folder to be used if
brm is not otherwise installed.
2. Code that calls the brm "engine" with requests for refactoring.
These calls my pass files, or parts of files, to brm. Important:
Python has good support for file-like objects. I expect that brm
calls could pass such objects to brm. If, otoh, brm really wants file-
system files, Leo's brm plugin might eventually "patch" brm at startup
time to accept file-like objects.
I expect this to be useful because the brm plugin may well want to do
refactorings one (Leo) node at a time. Indeed, doing a pseudo-write
of, say, an @thin tree to a file-like object will cause problems
because after brm does the refactoring the brm plugin would somehow
have to update the outline based on the brm results. Do you see the
problem? So it seems, at first glance, to be much easier to do the
refactorings node by node. We shall see.
II. Looking at the code
With these guesses as a starting point, I turned my attention to
BicycleRepairMan_Idle.py. Normally I would import this file into Leo,
but I was in a hurry. The first thing to notice is that this is a
small file. Not much is happening.
At the start of the file is data used to create menu items:
menudefs = [
('bicycleRepairMan', [
('----- Queries -----',''),
('_Find References','<<brm-find-references>>'),
('_Find Definition','<<brm-find-definition>>'),
None,
('--- Refactoring ---',''),
('_Rename', '<<brm-rename>>'),
('_Extract Method', '<<brm-extract-method>>'),
None,
('_Undo', '<<brm-undo>>'),
])
]
So it looks like there are two queries, two refactorings and a brm
undo operation. That is, n == 2.
After a bit of looking around, I found that brmctx is the brm
controller. You can find all calls to brm just by searching for
brmctx. Doing so yields the following calls:
brmctx = bike.init()
if self.TRACE == 1:
brmctx.setProgressLogger(self.progressLogger)
for ref in
brmctx.findReferencesByCoordinates(filename,int(line),int(column)):
print >>matchwin, "File \""+ref.filename+"\", line
"+str(ref.lineno)+", "+str(ref.confidence)+"% confidence"
defns = brmctx.findDefinitionByCoordinates(
filename,int(line),int(column))
brmctx.extractMethod(
filename, int(beginline), int(begincolumn),
int(endline), int(endcolumn), newname)
savedfiles = brmctx.save()
brmctx.undo()
brmctx.setRenameMethodPromptCallback(self.renameMethodPromptCallback)
brmctx.renameByCoordinates(filename, int(line), int(column), newname)
That's it. Obviously, we must understand in detail how to use these
methods, but clearly the problem is limited in scope.
At the end of the file is some window-related code. My guess is that
none of this code is needed for the initial prototype of a Leo brm
plugin. Eventually, the Leonine way to prompt for arguments would be
in the minibuffer. This isn't really difficult code to write, but it
takes getting used to. See the search classes in leoEditCommands.py
for many examples of such state-based code.
III. Revising the guesses
We see the dreaded 'filename' argument to several brm functions.
Maybe these functions can also accept an open file. We can certainly
use a single temp file for prototyping, but it's likely to be pretty
slow to create a temp file for every node in a large Leo outline. So
if brm functions presently do not support an open-file object we shall
want to 'help' brm a bit by allowing brm to accept file-like objects.
In conclusion, brm offers exactly two refactorings, which is
underwhelming. And I kinda suspect that Leo's own undo can take the
place of the brm undo. On the plus side, it might be possible to
create a prototype for Leo + brm in an hour or two with @button nodes.
Edward
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---
