From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: change-log-goto-source: recognising . within tag names Date: Sun, 22 Mar 2009 10:10:11 +0100 Message-ID: <49C60073.7090808@gmx.at> References: <20806.1237544562@maps> <49C3F31F.6090902@gmx.at> <18885.42821.907043.840826@rgr.rgrjr.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1237713075 19189 80.91.229.12 (22 Mar 2009 09:11:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Mar 2009 09:11:15 +0000 (UTC) Cc: Stephen Eglen , emacs-devel@gnu.org To: Bob Rogers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 22 10:12:32 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LlJjL-00081d-63 for ged-emacs-devel@m.gmane.org; Sun, 22 Mar 2009 10:12:31 +0100 Original-Received: from localhost ([127.0.0.1]:33260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LlJhx-00055U-V5 for ged-emacs-devel@m.gmane.org; Sun, 22 Mar 2009 05:11:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LlJhq-00055P-N7 for emacs-devel@gnu.org; Sun, 22 Mar 2009 05:10:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LlJhl-00053t-Fc for emacs-devel@gnu.org; Sun, 22 Mar 2009 05:10:57 -0400 Original-Received: from [199.232.76.173] (port=47506 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LlJhl-00053o-9f for emacs-devel@gnu.org; Sun, 22 Mar 2009 05:10:53 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:53096) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1LlJhk-00028X-PY for emacs-devel@gnu.org; Sun, 22 Mar 2009 05:10:53 -0400 Original-Received: (qmail invoked by alias); 22 Mar 2009 09:10:41 -0000 Original-Received: from 62-47-63-132.adsl.highway.telekom.at (EHLO [62.47.63.132]) [62.47.63.132] by mail.gmx.net (mp036) with SMTP; 22 Mar 2009 10:10:41 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX186rwBqZAo6/6B1Dfa7bBUc1ugvniMi9AVfhQoh8r zjrCFnhM4hZ2yM User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: <18885.42821.907043.840826@rgr.rgrjr.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:109774 Archived-At: > A simple fix would be to find the file name first, read it into a buffer > (since we'll need it anyway), and then use its syntax table to parse the > tag name. The code below is a start at this; it seems to work. But it > would have to be integrated with the change-log-goto-source logic that > finds both the file at point and the file near the tag and then picks > the best one. The logic seems rather obscure; I suspect I would break > it if I tried to change it. ;-} Because I look for the nearest tag first and "the file matching the tag" afterwards. The idea behind that logic was to do something reasonable regardless of the current position of `point' within a ChangeLog entry. As mentioned earlier that's far too clever. Users _should_ care a bit about from where they want to invoke that function. I think it would be better to make `change-log-list' entries mousable and and provide the goto-source facility iff `point' is on such an entry. In that case your "use the syntax-table of the source file approach" would fit perfectly. > For Lisp in particular, the problem is actually fairly broad, as > people often use "+", "*", "$", "%", etc., to distinguish certain > definition names. A better solution might be to ask the language mode > itself to do the name parsing, in order to handle such things as name > quoting conventions. But, of course, that's a much bigger job. It's less the question of a "bigger job" but that of providing some standard interface for language modes. That is, I pass you a string (or a narrowed buffer region) and you tell me all identifier names you can find in it. martin