<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 19 November 2013 06:48, Carlos Pita <span dir="ltr"><<a href="mailto:carlosjosepita@gmail.com" target="_blank">carlosjosepita@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I see that option reading and initializing was removed from<br>

tagmanager/ctags/options.c:<br>
<br>
#define readOptionConfiguration<br>
#define initOptions<br>
#define freeOptionResources<br>
<br>
I assume there are good reasons for this, but would it be too<br>
difficult to make the embedded ctags read ~/.ctags? Would it take a<br>
lot more effort than more or less copy&pasting some code from the<br>
official ctags?<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
I understand one can just write a C extension for ctags, even one only<br>
relying on regexs the same as would be done in ~/.ctags, which is not<br>
that hard, but it would be nice to avoid geany recompilation for<br>
simple tasks.<br>
<br></blockquote><div><br class="">Currently there is no way to define new parsers without re-compiling and no way of assigning them to filetypes without re-compiling.  So to allow configurable parsers you would need to add that capability first.</div>
<div><br></div><div>It would be less work to compile in your new filetype and add the capability to load the regexen to it.</div><div><br></div><div>Note that the current R parser has the (compile time) option to use the regex parser, but it defaults to a coded one.  Don't know why or whats the difference.  But even if it used the regex one it would not load options, you would have to add that.</div>
<div> </div><div>On using regex parsers, note that by default the parser runs every 250ms when you are making changes to a file, don't make your regexes too complex (or get a faster machine I guess).</div><div><br></div>
<div>Cheers</div><div>Lex</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Any advice will be very much appreciated.<br>
<div class=""><div class="h5"><br>
On Mon, Nov 18, 2013 at 11:25 AM, Carlos Pita <<a href="mailto:carlosjosepita@gmail.com">carlosjosepita@gmail.com</a>> wrote:<br>
>>> I don't think so, but I'm not 100% positive.  I'm sure Geany won't<br>
>>> recognize a new language added like this, but I'm not 100% sure you<br>
>><br>
>> Can anyone else confirm this? IMO this is an important point from the<br>
>> extensibility perspective. If a language is not supported out of the<br>
>> box you need to be able to configure both geany workhorses: scintilla<br>
>> and, in this case, ctags.<br>
><br>
> Or maybe ctags configuration could be done at the geany language level<br>
> (filetypes.*) instead of at the system user level (~/.ctags). That<br>
> seems the correct way to do it but also looks harder to implement. I<br>
> don't know how difficult it is to initialize the embedded ctags with<br>
> specific options or to instruct it to load some initialization file at<br>
> startup.<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.geany.org">Users@lists.geany.org</a><br>
<a href="https://lists.geany.org/cgi-bin/mailman/listinfo/users" target="_blank">https://lists.geany.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div></div>