nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] [RFC] Improve nano's completion feature to use external


From: Marco Diego Aurélio Mesquita
Subject: Re: [Nano-devel] [RFC] Improve nano's completion feature to use external sources of completion
Date: Sun, 20 May 2018 21:29:44 -0300

On Sun, May 20, 2018 at 8:37 PM, Brand Huntsman <address@hidden> wrote:
> On Sun, 20 May 2018 19:01:25 -0300
> Marco Diego Aurélio Mesquita <address@hidden> wrote:
>
>> Also, remeber that my tags are generated by:
>>
>>  ctags -x src/*.[ch]|awk '{print $4":"$3": "$1}'> tags
>
> Is there a reason you can't use the same ctags file format as every other 
> editor? I might want to add a ctags rule to my project's makefile. Your 
> approach forces me to add two rules: ctags and nano-ctags.
>

You can use the standard ctags file format. The reason I use this is
because the generated format (file:line: tag) is recognised by nano's
linter feature and I can easily use it for source code navigation (go
to declaration). But, of course, since the linter is an external
command, it is possible to write a tool to generate this output (in a
way that nano understands) from a standard tags file. So, my proposed
format for the tags file is not really needed.

>
>>  extendsyntax c completer grep $shard tags
>
> Does it look in pwd for the tags file? I'd have to start nano from the 
> directory containing the tags file. Put the tags file in nano/ and it fails 
> if I'm in nano/src/. Put it in nano/src/ and it fails if I'm in nano/ and 
> open src/nano.c. And what if the project has multiple source directories 
> inside src/?
>
> Scanning up the directory tree (from the file's directory) for a tags file 
> always works. And loading a tags file for a syntax using an absolute path 
> also always works. The one benefit of your approach is that the tags file can 
> be regenerated and nano would pick up the changes on the next completion. But 
> nano could either watch the tags files it has loaded for changes and reload 
> them, or stat the files every time completion is used.
>
>

The completer used (grep) is just an external command. Any behaviour
can be implemented by an external command to act just the way you
describe. We don't even need grep actually, we could use cscope or
ycmd or gnu global... we just need an output with a list of possible
completions! An interesting feature of the current approach is that we
don't need to load or parse a tags file, this keeps the code small,
simple and, since completion and code navigation are provided by
external tools, future proof.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]