all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [Riku Saikkonen] Bug#205035: gnus: Cannot find definition of `gnus-article-treat-dumbquotes' in library `gnus-art'
@ 2003-10-01 23:43 Dan Jacobson
  0 siblings, 0 replies; only message in thread
From: Dan Jacobson @ 2003-10-01 23:43 UTC (permalink / raw)
  Cc: bugs

[-- Attachment #1: Type: text/plain, Size: 65 bytes --]

He says this http://bugs.debian.org/205035 is a emacs bug, etc.


[-- Attachment #2: Type: message/rfc822, Size: 2790 bytes --]

From: rjs@cs.hut.fi (Riku Saikkonen)
To: 205035@bugs.debian.org
Cc: 205035-submitter@bugs.debian.org
Subject: Bug#205035: gnus: Cannot find definition of `gnus-article-treat-dumbquotes' in library `gnus-art'

(I'm trying to help out in a bug tagged "help".)

Thd problem appears to be due to a missing feature in (GNU) Emacs:
gnus-article-treat-dumbquotes is defined in gnus-art.el using defalias
inside a loop, and Emacs cannot find this definition from the file,
since it's not written out anywhere.

Note that C-h f article-treat-dumbquotes works (though this function
isn't meant to be used directly). I think that the only problem caused
by this bug is the inability to jump to source code directly.

The purpose of the defalias in gnus-art.el seems to be to add a fixed
wrapper around a lot of functions that start with gnus-article-treat-.
Quite useful from a programmer's point of view, but it makes it very
difficult to automatically find the source for a given piece of code.

The only general (but partial) solution I can think of is that Emacs's
C-h f could show that the function was defined using defalias - but
it's difficult to do anything else than warn that the link probably
does not work.

In theory, it would be possible to link to that defalias instead of
trying to find the function definition, but I don't think this is easy
to implement - I think the source code links saved by Emacs's Lisp
interpreter (and byte compiler) currently contain just the file name.

So, I think this bug should be reassigned to Emacs (and probably sent
to the upstream authors). Here are two possible ways to fix it:

 - simple: change the error produced by the link in C-h f when it
   can't find the function to a warning, and jump to the start of the
   source file in question

 - complex: include a file position (e.g. line number) in all
   functions saved by the Lisp interpreter, and save the location of
   the definition that creates the function (more precisely, the
   location of the special form currently being executed when the
   function gets defined) - then C-h f can jump there directly instead
   of searching for the correct position (currently symbol-file
   returns the file name, and find-function-search-for-symbol is
   called to search through the file for the definition)

(My investigations were done with GNU Emacs 21.2.1 and Gnus v5.10.2,
but I don't think this situation has changed for a long time. I
haven't looked at the CVS version of Emacs, though.)

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2003-10-01 23:43 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-10-01 23:43 [Riku Saikkonen] Bug#205035: gnus: Cannot find definition of `gnus-article-treat-dumbquotes' in library `gnus-art' Dan Jacobson

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.