I had never heard of ctags, and it looks interesting, although the lack of Objective-C support is concerning... http://ctags.sourceforge.net/languages.html I agree that most SVN users are probably dealing with source code. If the feature is sufficiently low-hanging fruit and wouldn't bloat the code, I wouldn't mind having it, but certainly not at the expense of some core features.
Glad I didn't put anyone off. At least, not anyone who has replied... :-) - Quinn On Feb 9, 2011, at 4:18 PM, dave wrote: > thanks for the input. ctags and etags look straightforward to > implement for this functionality. see sourceforge: > http://ctags.sourceforge.net/ctags.html > > i agree, merging would take priority. but i do guess that a large > majority of svn users are coding, at least primarily. i also use svn > for text files, but 'text file name' auto-complete would be useful > too. incidentally, thanks for telling me about code symbols; i don't > do much oop--mainly scientific programming in matlab--so this was > useful! > > also, re your (Quinn) disclaimer, i say pith is kind not curt. i > prefer it; thanks! > > > On Feb 9, 9:49 am, Lorin Rivers <lriv...@mosasaur.com> wrote: >> I wonder if adding support for ctags would be achievable? >> >> Also, you didn't seem off-putting to me. >> >> On Feb 9, 2011, at 11:17 AM, Quinn Taylor wrote: >> >>> Disclaimer: Sometimes my tone seems confrontational, but I'm really being >>> nice. I just tend to looks at things objectively and pragmatically. Please >>> don't let me scare you off. :-) >> >>> I meant "code symbols" to encapsulate function names; for example, it could >>> also include methods, classes, variables, etc. >> >>> File names would be easy to support, but remember that a Subversion >>> repository doesn't necessarily just store source code. Even assuming code, >>> there is a wide variety of programming languages that would have to be >>> supported for such a feature to be considered useful. On top of that, >>> there's an implicit assumption that most people even *put* >>> script/function/class names in their log messages. >> >>> I just a Versions user too, but I'm also a software engineer myself, and my >>> gut reaction is that this feature — while admittedly cool and potentially >>> useful — is one that I would expect to require a lot more time and money >>> than could be justified, especially when compared to other core Subversion >>> features like merging. >> >>> Personally, when I *do* put code symbols (like class and method names) in a >>> log message, I either type them out by hand or copy/paste from the source >>> or a diff. I tend to triple-check changes before committing, so the latter >>> is usually the easiest. >> >>> As far as spelling mistakes, that's because Versions uses the built-in >>> spelling functionality and dictionary, which doesn't (and shouldn't) >>> contain script/function names. I'd bet that most users are more likely to >>> misspell common words than code symbols anyhow. I've caught a lot of minor >>> typos this way. >> >>> If I've missed something, please let me know. Thanks! >> >>> - Quinn >> >> -- >> Lorin Rivers >> Mosasaur: Killer Technical Marketing <http://www.mosasaur.com> >> <mailto:lriv...@mosasaur.com> >> 512/203.3198 (m) >> >> smime.p7s >> 6KViewDownload > > -- > You received this message because you are subscribed to the Google Groups > "Versions" group. > To post to this group, send email to versions@googlegroups.com. > To unsubscribe from this group, send email to > versions+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/versions?hl=en. >
smime.p7s
Description: S/MIME cryptographic signature
