From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: eww Date: Sat, 18 Jan 2014 21:12:22 -0500 Message-ID: References: <87zjn0gmas.fsf@bzg.ath.cx> <87fvorbjuh.fsf@bzg.ath.cx> <87r48aaog5.fsf@bzg.ath.cx> <878uui6cqr.fsf@yahoo.fr> <87k3e2ldpd.fsf@bzg.ath.cx> <52D56C90.7000902@yahoo.fr> <87y52ijufd.fsf@bzg.ath.cx> <877ga172zi.fsf@igel.home> <52D6B310.8080702@yahoo.fr> <87y52f4wn7.fsf@igel.home> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390097572 25280 80.91.229.3 (19 Jan 2014 02:12:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 02:12:52 +0000 (UTC) Cc: bzg@gnu.org, theonewiththeevillook@yahoo.fr, schwab@linux-m68k.org, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 19 03:12:55 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4hsW-0004kb-Kh for ged-emacs-devel@m.gmane.org; Sun, 19 Jan 2014 03:12:48 +0100 Original-Received: from localhost ([::1]:44852 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4hsV-0002Wn-VS for ged-emacs-devel@m.gmane.org; Sat, 18 Jan 2014 21:12:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4hsM-0002Wf-FM for emacs-devel@gnu.org; Sat, 18 Jan 2014 21:12:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4hsF-0003As-5f for emacs-devel@gnu.org; Sat, 18 Jan 2014 21:12:38 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:45536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4hs7-00037S-Dn; Sat, 18 Jan 2014 21:12:23 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCplR/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDiGGcGYFegxU X-IPAS-Result: Av4EABK/CFFMCplR/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="45287374" Original-Received: from 76-10-153-81.dsl.teksavvy.com (HELO pastel.home) ([76.10.153.81]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Jan 2014 21:12:22 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id A2B6C603B8; Sat, 18 Jan 2014 21:12:22 -0500 (EST) In-Reply-To: (Richard Stallman's message of "Sat, 18 Jan 2014 07:33:30 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168711 Archived-At: > Nothing at all. This problem with etags exists already with many other > macros and noone cares. > Are you sure no one cares? I guess that's a rhetorical question, since you seem to care, and obviously I can't be sure anyway. > When people look for a tag, and it isn't defined, they will hunt > around and find it somehow. As stated it's part of etags's problems, and it's true for uses of etags with any language that provides a macro facility, AFAIK. etags probably also suffers from similar problems (missed tags) in various other corner cases even for language without macros. People who care enough about these issues probably just use something else than etags. Otherwise we'd already have had plenty more bug reports along these lines. > These problems are sloppinesses, and we can avoid them by taking a little > care in defining the macros, or by making etags recognize them specially. I wouldn't call it "a little care defining the macro" but rather "disfiguring the macro". > It's bad in define-derived-mode, too. It's unfortunate > that there is no tag for `...-mode-map'. It's not just ..-mode-map, but also ..-abbrev-table, ..-syntax-table, and ..-mode-hook. > However, at least the presence of `mode' will suggest to people where > they should look. There is no comparable word in `web-alternatives' > to suggest where to look. My guess is that they'll do `C-h v web-alternatives' then click on the button to jump to the source code, and ... tadaa!! No problem with etags because they didn't need to use etags for that. > We could make find-tag know about these cases, so it will find > the tags anyway. `find-tag' works for dozens of different languages. Why should it suddenly be uglified with special hacks for one of those languages (and one where etags is particularly less important because this one language happens to be the one that's only edited from Emacs where things like `C-h v' and `C-h f' work even more reliably than etags and without having to build and update any TAGS table)? > That won't even make tag tables do it. If we want find-tag to do the right thing, the right way to do it is by teaching `etags' to recognizes macros like define-derived-mode and add corresponding entries in the TAGS file. Stefan