On 2022-Oct-12, Tatsuo Ishii wrote:
> I tried to apply the v2 patch approach to make_etags but noticed that
> make_ctags and make_etags have quite a few duplicate codes, that would
> bring maintenance headache. I think we could merge make_etags into
> make_ctags, then add "-e" option (or whatever) to make_ctags so that
> it generates tags files for emacs if the option is specified.
If we're going to do this, then I suggest that make_etags should become
a symlink to make_ctags, and behave as if -e is given when called under
that name.
> +tags_file=tags
> +rm -f ./$tags_file
I think $tags_file should include the leading ./ bit, to reduce
confusion.
However ... hmm ...
> find . \( -name 'CVS' -prune \) -o \( -name .git -prune \) -o -type d -print |
> while read DIR
> -do [ "$DIR" != "." ] && ln -f -s `echo "$DIR" | sed 's;/[^/]*;/..;g'`/tags "$DIR"/tags
> +do [ "$DIR" != "." ] && ln -f -s `echo "$DIR" | sed 's;/[^/]*;/..;g'`/$tags_file "$DIR"/$tags_file
> done
... does this create a tags symlink on each directory? This seems
strange to me, but I admit the hack I keep in my .vim/vimrc looks even
more strange:
: let $CSCOPE_DB=substitute(getcwd(), "^\\(.*/pgsql/source/ [^/]*\\)/.*", "\\1", "")
: let &tags=substitute(getcwd(), "^\\(.*/pgsql/source/[^/]*\\)/.*", "\\1", "") . "/tags"
Not sure which is worse. Having dozens of identically named symlinks
doesn't strike me as a great arrangement though. I would definitely not
use make_ctags if this is unavoidable. I see both scripts do likewise
currently.
(I keep all my build trees under /pgsql/build [a symlink to
~/Code/pgsql/source], and all source trees under /pgsql/source, so this
is an easy conversion to make most of the time.)
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"World domination is proceeding according to plan" (Andrew Morton)
