bug#22646: help pages don't point to code

bug#22646: help pages don't point to code

[Samuel Wales]

when you do c-h f or c-h v, emacs provides a link to the source.  i have
always relied on this feature.

in my own code, i have always kept byte-compiled files in a separate
directory from the source.  this has never been a problem.

in a recent version of emacs, perhaps a recent emacs 24 minor version,
it seems that these source links no longer exist if you keep your
byte-compiled files in a separate directory from the source files.

i'd like them to exist again, without having to change the way i load my
byte-compiled files.

keeping byte-compiled files in a separate directory solves a bunch of
problems all at once that i'd rather not unsolve only to have to solve
again in different kludgey ways.

in other words, i want c-h f and c-h v to work again, the way they did
before the recent version of emacs.

i do not know why this occurs.  i just know that it stopped working.

thanks.


In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2015-03-07 on trouble, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11604000
System Description:	Debian GNU/Linux 8.3 (jessie)

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-z,relro'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: el

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  org-link-minor-mode: t
  delete-selection-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  ido-hacks-mode: t
  show-paren-mode: t
  type-break-query-mode: t
  type-break-mode: t
  display-time-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.

bug#22646: help pages don't point to code

[Drew Adams]

Why on Earth was this bug immediately relegated to the Wishlist?

Isn't it a regression (assuming it is reproducible)?

If so, is restoring lost correct behavior just a wish now?

bug#22646: help pages don't point to code

[Glenn Morris]

I didn't recall this ever working, but by experiment, seems it last
worked in 22.3.

Tested with foo.el in /tmp/source, foo.elc in /tmp/compile, PWD /tmp, and

(push (expand-file-name "source") load-path)
(push (expand-file-name "compile") load-path)
(load "foo")
C-h f foo-func

bug#22646: help pages don't point to code

[Glenn Morris]

Version: 25.1

I failed to notice that this is already fixed for the next release.