Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Feature Requests
 Context specific macros/autotext

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
drzoom Posted - Jan 09 2007 : 11:37:54 AM

Preface: "Things look different from another point of view." (myself, now)

Topic: VAX knows the context of the cursor. Auto text entries should have some kind of flags to enable/disable entries depending on the current context.

Also on different context, there are more macros which are available. E.g. inside an class construction, there should be a $CLASS$ macro. Inside a member function there should also be a $FUNCTION$ macro.

This simple (!) extension makes it possible write macros to create a copy constructor or an assignment operator. It also makes possible to extend a method quickly.

Your objections: No one I can imagine.

Bonus Features: Why not integrate Python or C# into VAX macros. So everyone can extend the macros with simple logic.


7   L A T E S T    R E P L I E S    (Newest First)
support Posted - Jan 27 2009 : 10:06:05 PM
case=2050 is implemented in build 1715
New tokens are $NamespaceName$, $BaseClassName$, $ClassName$, $MethodName$, and $MethodArgs$.
These should not be used in refactoring snippets.
feline Posted - Jan 10 2007 : 10:01:17 AM
This is why I am wondering what drzoom is after. Making the existing refactoring tokens available is already in the list, this is actually what case=3204 asks for. So it does the current function, and a bit more

Note that drzoom is asking about using Python or C#, which suggests he is after something quite different.

In between these two points, which seem quite far apart, people express interest in some form of "automation" of VA and refactoring.

The refactoring operations are designed to be chained together, to allow each person to achieve the thing they themselves want. It did not take long for someone to ask for some way of automating this. So I am open to the concept of something a bit like macro's, but I also suspect it would really have to be a whole new product / addin, unless we can come up with some particularly brilliant solution
sl@sh Posted - Jan 10 2007 : 09:44:26 AM
Using macro commands like the basic ones you listed would just be the workaround to what was originally requested: access to a couple of context-dependent symbols within Autotext.

For a start it would help to be able to use those symbols already available for the Refactor autotext entries. $namespace$ (if it's not already in there, I'm not sure) might also be nice to have, but to be honest I'm not sure many people will really need that.

The real work behind the implementation shouldn't be that big an issue: just finding the header of the method and then invoking the same functions that are already being used for Refactor should do the trick. Or at least that's what I assume, maybe I'm missing something big and ugly
feline Posted - Jan 10 2007 : 07:33:04 AM
logging is a good answer, and one I fully support. I was just wondering if there was some other plan here for $FUNCTION$ that I was not thinking of.

case=3204

depending on your IDE you may be able to use __FUNCTION__, which works like __FILE__ and __LINE__, but from memory this is not available in VC6, and is not as powerful as you may want.


turning to the broader question of macro's and autotext, I have spent years in VIM, and used to use both macro's and functions extensively to extend the editor. so for me turning to the IDE macro's is a fairly obvious step, and every time I have considered this I have just given up. There is no obvious good starting point, the keyboard macro's are a joke to someone who is used to VIM, and the IDE's macro explorer (VS2003) tends to depress me *rolls eyes*

so you do have a receptive audience in me

the flip side is the amount of work required, and how much return we will see for this work. there are quite a lot of outstanding bug reports at the moment, just for a change

what sort of things are you thinking of doing with autotext macro's? I am trying to get some feel for the scope of the request here.

In VIM most macro's that I used were based around and built out of the following operations:

movement - find the next occurrence of the letter 'x' on the current line
movement - find the last occurrence of the letter 'x' on the current line
movement - forwards one "word"
movement - backwards one "word"
movement - end of line
movement - start of line
select - start selection and then move
edit - delete current selection
edit - copy current selection
edit - cut current selection
edit - insert a given block of text

with care you can achieve a LOT with this "basic" set of operations. however the IDE does not have the first two movement commands, which immediately breaks most of my macro's.

looking at this list you can probably agree that we are not really talking autotext any more, instead we are really talking about some whole new VA macro language.

or are you thinking of something much smaller than this?
drzoom Posted - Jan 10 2007 : 03:53:01 AM
quote:
Originally posted by feline
I don't see how you are going to use the function name though. I know people sometimes want to use this in logging statements, but off hand I cannot think of any code uses for the current function name inside the function. Recursion would use this, but that is hardly something you are going to want to trigger via autotext, is it?



Think of:


class UnstableClass
{
void unstableFunction()
{
  debug() << "UnstableClass::unstableFunction: start" << std::endl;
  // dirty spaghetti code 
  debug() << "UnstableClass::unstableFunction: end" << std::endl;
}
}


With a macro:


debug() << "$CLASSNAME$::$FUNCTIONNAME$: $end$" << std::endl;


It's easy to add debug statements.


/**
 * copy ctor
 */
const $CLASSNAME$& $CLASSNAME$( const $CLASSNAME$& copy );


Write copy constructor.

quote:

What is the advantage of adding a programming language tool to autotext? I see a lot of potential overhead here, and immediately people wanting 3,500 additional functions added, mainly to do with accessing the current context, the editor window, the code, surrounding files...
Isn't this what the IDE's macro language is for?



That's right. If MS VS would be a good IDE, I could use the built-in macro language to write my own extensions. But the MS VS without VAX is somewhat minimalistic, that I need extreme deep knowledge about the IDE internas to write a macro which act's like an autotext from VAX.

Why invent the same thing twice? I would love it to have VAX with the autotext feature as trigger of my scripts. Or please make me a simple example, how I can reach this goal with a few lines of C# or VB code.

quote:

...and immediately people wanting 3,500 additional functions added, mainly to do with accessing the current context...



What's bad with that? People wanting a lot of features from VAX. They post it to this forum, and you pick the best suggestions out. Nobody has requested that you implement all the 3,500 requested functions.

The problem why people don't write own macros for VS is that the code model from MS is somewhat cryptic that it's no fun to use it.


sl@sh Posted - Jan 10 2007 : 03:29:25 AM
quote:
Originally posted by feline
I don't see how you are going to use the function name though. I know people sometimes want to use this in logging statements, but off hand I cannot think of any code uses for the current function name inside the function.

Considering the level of abstraction class heirarchies in languages like C++ sometimes arrive at I for one would be quite happy for a little context information that I could use for logging!

We discussed this in another thread and the final solution you came up with as a workaround is to add specific lines of logging code to the Refactor Document Method autotext and use this method, followed by moving the code lines to the appropriate place.

While this method does work for me, some people might be using logging mechanisms in a more evolved way and would benefit greatly from such a feature. Also, redefining the refactoring autotext isn't a good solution, really, since likely you wouldn't want to log *all* functions and thus would cause the added work of deleting the code lines from all the functions that don't need them. (which is why, ultimately, I stopped using your suggested solution)

Providing alternate autotext for various refactor methods would be a solution, but that would add another step in using the refactor features, to the detriment of a lot of other users. Thus, I consider Tobias' suggestion a very good one: it wouldn't complicate any existing features and users get to decide whether and how to use it.

Please consider how much of an effort this would be to implement, and whether it's worth it. Not all users might want to make use of it, but since logging is part of the software development process for many people I think there's still a lot of people out there who would be glad to have it.
feline Posted - Jan 09 2007 : 3:04:03 PM
I am good at imagining objections What is the current context for the red mark?

class CFoo
{

int main()
{
    |
}


currently VA not knowing the context is not much of a problem, but this starts to matter more with this extension to autotext. Having said that adding the class name has already come up, and the solution is to have it insert nothing if there is no current class name.

case=2050

I don't see how you are going to use the function name though. I know people sometimes want to use this in logging statements, but off hand I cannot think of any code uses for the current function name inside the function. Recursion would use this, but that is hardly something you are going to want to trigger via autotext, is it?

What is the advantage of adding a programming language tool to autotext? I see a lot of potential overhead here, and immediately people wanting 3,500 additional functions added, mainly to do with accessing the current context, the editor window, the code, surrounding files...

Isn't this what the IDE's macro language is for?

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000