GNU bug report logs - #8667
24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8667 in the body.
You can then email your comments to 8667 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Thu, 12 May 2011 17:46:33 -0700

emacs -Q
 
Put point at position 3061 in file thingatpt.el (i.e., just before the
`a' of `condition-case').
 
M-: (bounds-of-thing-at-point 'comment)
returns (3061 . 3061), which represents an empty thing, "".
 
This happens at most positions, probably all positions outside a comment.
 
The code should handle this kind of case correctly (in other respects it
seems to work OK for comments).
 
The problem is that there is no `beginning-op' or `end-op' and all of
the calls to `forward-thing' (with 1 and -1) do not move point at all,
and return nil.  So the code falls through to the end:
 
(let ((end (point))
      (real-beg
       (progn
        (funcall
         (or (get thing 'beginning-op)
             (lambda () (forward-thing thing -1))))
        (point))))
  ;; real-beg = end = (point).  Result is (cons 3061 . 3061).
  (if (and real-beg end (<= real-beg orig) (<= orig end))
      (cons real-beg end)))

`bounds-of-thing-at-point' should foresee such a case (that `forward-THING' does
nothing).  IOW, it should of course be fixed for this problem.

But it sounds like `forward-comment' should also be fixed so that it acts like
other `forward-THING' functions, and not just be a no-op when outside a comment.
 
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-05-10 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'
 

Message #8 received at 8667 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <8667 <at> debbugs.gnu.org>
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Thu, 12 May 2011 20:00:50 -0700

> The problem is that there is no `beginning-op' or `end-op' and all of
> the calls to `forward-thing' (with 1 and -1) do not move point at all,
> and return nil.  So the code falls through to the end:
>  
> (let ((end (point))
>       (real-beg
>        (progn
>         (funcall
>          (or (get thing 'beginning-op)
>              (lambda () (forward-thing thing -1))))
>         (point))))
>   ;; real-beg = end = (point).  Result is (cons 3061 . 3061).
>   (if (and real-beg end (<= real-beg orig) (<= orig end))
>       (cons real-beg end)))
> 
> `bounds-of-thing-at-point' should foresee such a case (that 
> `forward-THING' does nothing).  IOW, it should of course be
>  fixed for this problem.

This should be all that's needed, if it wasn't obvious:

- (if (and beg real-end (<= beg orig) (<= orig real-end))
-     (cons beg real-end))

+ (and beg real-end (<= beg orig) (<= orig real-end)
+      (/= beg read-end)
+      (cons beg real-end))

and

- (if (and real-beg end (<= real-beg orig) (<= orig end))
-     (cons real-beg end)))

+ (and real-beg end (<= real-beg orig) (<= orig end)
+      (/= real-beg end)
+      (cons real-beg end))

(Dunno why some people insist on using `(if (and...) singleton)'.  It gets in
the way of readability and just represents extra noise.  Binary `if' is
generally an impediment to readability and communicating intention.)

> But it sounds like `forward-comment' should also be fixed so 
> that it acts like other `forward-THING' functions, and not
> just be a no-op when outside a comment.

And it seems that `forward-comment' is otherwise buggy, in that it moves only
over whitespace when point is within a comment.

E.g.:
;; Some comment with some     whitespace somewhere.

Put point before any of the whitespace and (forward-comment 1) moves to the end
of the whitespace.  Put point after any of the whitespace and (forward-comment
-1) moves to the beginning of that whitespace.  And in these cases swapping 1
and -1 produces a no-op.

The only time `forward-comment' actually moves over a whole (Lisp) comment is
when point is before `;'.  And even then, if point is between the two `;' above,
then (forward-comment -1) is a no-op.

`forward-comment' should behave the way other `forward-THING' functions behave.
It should do what we expect of a `forward-*' function.

Yes, I have read the `forward-comment' doc string.  If it really needs to behave
this way then it should have a different name.  That is, after fixing the bugged
behavior, if we still need a function that does what `forward-comment' does now,
then it needs a different name.

No, it's not too late to change, even if renaming would be bothersome.  The way
it is now breaks `thing-at-point' functions, and they should work regardless of
the `forward-*' functions.  Thing-at-point depends on this naming convention.

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N)
	for `comment'
Date: Thu, 12 May 2011 23:56:09 -0600

On 5/12/11 9:00 PM, Drew Adams wrote:

> - (if (and beg real-end (<= beg orig) (<= orig real-end))
> -     (cons beg real-end))
>
> + (and beg real-end (<= beg orig) (<= orig real-end)
> +      (/= beg read-end)
> +      (cons beg real-end))
>
> and
>
> - (if (and real-beg end (<= real-beg orig) (<= orig end))
> -     (cons real-beg end)))
>
> + (and real-beg end (<= real-beg orig) (<= orig end)
> +      (/= real-beg end)
> +      (cons real-beg end))
>
> (Dunno why some people insist on using `(if (and...) singleton)'.  It gets in
> the way of readability and just represents extra noise.  Binary `if' is
> generally an impediment to readability and communicating intention.)

Readability is in the eye of the beholder, intention is in the mind of the
author.

Personally, I think (if (and...) result) communicates the intent more clearly
than (and ... result)

-- 
Kevin Rodgers
Denver, Colorado, USA

Message #14 received at 8667 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 8667 <at> debbugs.gnu.org
Subject: Re: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Fri, 13 May 2011 11:11:07 -0300

> (Dunno why some people insist on using `(if (and...) singleton)'.

Probably because those people find it better communicates the intent.

> And it seems that `forward-comment' is otherwise buggy, in that it moves only
> over whitespace when point is within a comment.

Not only over whitespace: also over a nested comment.
What would you want it to do instead?  Jump to the end of the comment?
Kind of like an `up-comment'?

The forward-<thingy> functions all share the following property AFAIK:
when called with a positive argument with point *before* some
<thingies>, they will skip over that many <thingies> and when called
with a negative argument with point *after* some <thingies> they will
skip over that many <thingies>.

E.g. just like forward-comment, forward-sexp from within a sexp will not
skip to the end of that sexp.  And just like forward-sexp,
forward-comment called in front of a nested comment will jump over that
nested comment.

All calls with point elsewhere than before/after a <thingy> behave in
somewhat arbitrary ways which mostly depend on how the function is
implemented and what kind of structure <thingies> have (e.g. can they
nest?  Can we easily tell when we're in the middle of a <thingy>?).


        Stefan

Message #17 received at 8667 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 8667 <at> debbugs.gnu.org
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Fri, 13 May 2011 08:49:27 -0700

> > And it seems that `forward-comment' is otherwise buggy, in 
> > that it moves only over whitespace when point is within a comment.
> 
> Not only over whitespace: also over a nested comment.
> What would you want it to do instead?  Jump to the end of the comment?
> Kind of like an `up-comment'?
> 
> The forward-<thingy> functions all share the following property AFAIK:
> when called with a positive argument with point *before* some
> <thingies>, they will skip over that many <thingies> and when called
> with a negative argument with point *after* some <thingies> they will
> skip over that many <thingies>.
> 
> E.g. just like forward-comment, forward-sexp from within a 
> sexp will not skip to the end of that sexp.  And just like forward-sexp,
> forward-comment called in front of a nested comment will jump 
> over that nested comment.
> 
> All calls with point elsewhere than before/after a <thingy> behave in
> somewhat arbitrary ways which mostly depend on how the function is
> implemented and what kind of structure <thingies> have (e.g. can they
> nest?  Can we easily tell when we're in the middle of a <thingy>?).

You're right, and I was aware of that.  While dealing with the
`bounds-of-thing-at-point' bug I mistakenly got the impression that
`forward-char' was also misbehaving.

Let's please fix `bounds-of-thing-at-point', though.  The fix is trivial.  It's
OK for `b-o-t-a-p' to return a purely whitespace thing (`whitespace' is even a
proper thing), but it's not OK for it to return an empty thing (""), IMO.

--

BTW (do I need to create a separate bug report for this?), I think
`forward-whitespace' is incorrect: \n should be \n+, like this:

(defun forward-whitespace (arg)
  (interactive "p")
  (if (natnump arg)
      (re-search-forward "[ \t]+\\|\n+" nil 'move arg)
    (while (< arg 0)
      (if (re-search-backward "[ \t]+\\|\n+" nil 'move)
	  (or (eq (char-after (match-beginning 0)) 10)
	      (skip-chars-backward " \t")))
      (setq arg (1+ arg)))))

Try `(bounds-of-thing-at-point 'whitespace)' at various places, in particular at
the end of a line followed by an empty line.  The current definition does not
consider contiguous whitespace from newlines to be part of the same whitespace
thing - it treats \n as separating whitespace things.

Dunno whether that was the intention (why?).  Without any indication of the
reason/intention (no doc string), I'd say that any sequence of contiguous
whitespace, including newlines, should form a single whitespace thing.

Can we also please add doc strings to functions such as `forward-whitespace'?
They are missing, generally, in thingatpt.el.

Message #20 received at 8667 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 8667 <at> debbugs.gnu.org
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Fri, 13 May 2011 09:11:07 -0700

> I think `forward-whitespace' is incorrect: \n should be \n+, like this:
> 
> (defun forward-whitespace (arg)
>   (interactive "p")
>   (if (natnump arg)
>       (re-search-forward "[ \t]+\\|\n+" nil 'move arg)
>     (while (< arg 0)
>       (if (re-search-backward "[ \t]+\\|\n+" nil 'move)
> 	  (or (eq (char-after (match-beginning 0)) 10)
> 	      (skip-chars-backward " \t")))
>       (setq arg (1+ arg)))))

Note too that `forward-whitespace' is not currently used anywhere in the Emacs
source files.  Can we please make this change, so that it always moves over all
contiguous whitespace and so takes point up to a non-whitespace char (or eob)?

Message #27 received at 8667-close <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 8667-close <at> debbugs.gnu.org
Subject: Re: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Fri, 13 May 2011 14:05:06 -0300

Installed a patch along the lines of what you suggested.

>> I think `forward-whitespace' is incorrect: \n should be \n+, like this:
>> 
>> (defun forward-whitespace (arg)
>> (interactive "p")
>> (if (natnump arg)
>> (re-search-forward "[ \t]+\\|\n+" nil 'move arg)
>> (while (< arg 0)
>> (if (re-search-backward "[ \t]+\\|\n+" nil 'move)
>> (or (eq (char-after (match-beginning 0)) 10)
>> (skip-chars-backward " \t")))
>> (setq arg (1+ arg)))))

The current behavior is clearly intentional (the (skip-chars-backward "
\t") shows that the function wants to treat newlines as
not-just-whitespace).  So I'd rather not change it.


        Stefan

Message #33 received at 8667-close <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 8667-close <at> debbugs.gnu.org
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Fri, 13 May 2011 10:18:47 -0700

> >> I think `forward-whitespace' is incorrect
> 
> The current behavior is clearly intentional (the 
> (skip-chars-backward " \t") shows that the function wants
> to treat newlines as not-just-whitespace).
> So I'd rather not change it.

OK, but the name is not suggestive of what it does, and there is no doc to tell
users what it does.

Also, who really cares what the original intention was in this case (what "the
funciton wants" to do), since it is not even used (in the Emacs sources)?

There has been plenty of incomplete, incorrect, and bad-intentioned or badly
designed code in thingatpt.el, since the beginning.  I don't see this particular
original intention as holy.  But I'm OK with leaving it as is, as long as the
behavior is documented.

You're right that to correct it to skip over all contiguous whitespace, we would
need to include \n in the skip-chars-backward part.  I think that is what should
be done, but so be it.  It's easy enough to define a
`forward-whitespace-&-newlines' that DTRT.

Message #34 received at 8667-close <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 8667-close <at> debbugs.gnu.org
Subject: Re: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Fri, 13 May 2011 15:22:55 -0300

> Also, who really cares what the original intention was in this case
> (what "the funciton wants" to do), since it is not even used (in the
> Emacs sources)?

Agreed.  To my eyes, the best fix is to throw it away.


        Stefan

Message #35 received at 8667-close <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 8667-close <at> debbugs.gnu.org
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Fri, 13 May 2011 11:28:25 -0700

> > Also, who really cares what the original intention was in this case
> > (what "the funciton wants" to do), since it is not even used (in the
> > Emacs sources)?
> 
> Agreed.  To my eyes, the best fix is to throw it away.

I disagree, but don't really care (someone can always add it to external code).
For thing-at-point (bounds-of*, in particular) it can be useful.

Message #42 received at 8667-close <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 8667-close <at> debbugs.gnu.org
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Thu, 19 May 2011 10:12:22 -0700

> Installed a patch along the lines of what you suggested.

No, I don't think you did.  I just downloaded the latest thingatpt.el.  There is
no fix AFAICT.

There are still the two problems reported for `bounds-of-thing-at-point' in this
bug report: (1) it can return a cons with equal car and cdr (representing an
empty thing), (2) it can return a cons representing only whitespace, instead of
returning nil when there is no comment at point.


1. You did not filter out the case where (= beg real-end) or
(= real-beg end), so `bounds-of-thing-at-point' can still return a cons with
equal car and cdr.

You need to add these conditions to the tests:

(and beg real-end (<= beg orig) (<= orig real-end)
                  (/= beg real-end) ; <===== NEEDED
                  (cons beg real-end))
...

(and real-beg end (<= real-beg orig) (<= orig end)
                  (/= real-beg end) ; <===== NEEDED
                  (cons real-beg end))


2. It is still the case that (bounds-of-thing-at-point 'comment) can return a
cons representing only whitespace, when called outside a comment.  Put point
here, for instance:

(defun bounds-of-thing-at-point...
       ^

It should always return nil, never return a cons, when there is no comment at
point.  This is a `b-o-t-a-p' bug (not a `forward-comment' bug).  In turn, this
bug causes (thing-at-point 'comment) to return " " at such a location.

Message #52 received at 8667 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 8667 <at> debbugs.gnu.org
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Thu, 19 May 2011 11:24:46 -0700

> All calls with point elsewhere than before/after a <thingy> behave in
> somewhat arbitrary ways which mostly depend on how the function is
> implemented and what kind of structure <thingies> have (e.g. can they
> nest?  Can we easily tell when we're in the middle of a <thingy>?).

That's clearly no good for thing-at-point, in general.  `thing-at-point' uses
`bounds-of-thing-at-point', and that uses `forward-THING' in both directions (1,
-1).

`forward-comment' moves point even when there is no comment at point (before or
after).  And that causes (thing-at-point 'comment) to return a non-comment
string of text (e.g. only whitespace), instead of nil, when point is not on a
comment.

`thing-at-point' should always return nil or a comment, when THING is `comment'.

It is up to the `forward-THING' functions to each DTRT, or else they break
`thing-at-point'.  The alternative is to prevent `b-o-t-a-p' from relying on
`forward-comment'.

IOW, either (a) we need to fix `forward-comment' to DTRT in this case, (b) we
need to add a function `bounds-of-comment-at-point' and then (put 'comment
'bounds-of-thing-at-point 'bounds-of-comment-at-point), or (c) we need to define
adequate `beginning-op' and `end-op' functions for type `comment'.

(b) and (c) are the only ways that `bounds-of-thing-at-point' will avoid
(mis)using a `forward-THING' that does not DTRT for thing-at-point.

Message #57 received at 8667-close <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 8667-close <at> debbugs.gnu.org
Subject: Re: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Thu, 19 May 2011 23:12:40 -0300

> No, I don't think you did.  I just downloaded the latest thingatpt.el.
> There is no fix AFAICT.

From which branch?

> You need to add these conditions to the tests:

> (and beg real-end (<= beg orig) (<= orig real-end)
>                   (/= beg real-end) ; <===== NEEDED
>                   (cons beg real-end))
> ...

> (and real-beg end (<= real-beg orig) (<= orig end)
>                   (/= real-beg end) ; <===== NEEDED
>                   (cons real-beg end))

The code you show here is not on the trunk any more (e.g. I removed the
non-null test of real-beg and end because they were redundant).


        Stefan

Message #65 received at 8667 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 8667 <at> debbugs.gnu.org
Subject: Re: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Thu, 19 May 2011 23:18:11 -0300

> That's clearly no good for thing-at-point, in general.

Guess where I think the problem lies?


        Stefan

Message #70 received at 8667 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 8667 <at> debbugs.gnu.org
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Sat, 21 May 2011 07:51:26 -0700

> > That's clearly no good for thing-at-point, in general.
> 
> Guess where I think the problem lies?

Good, so you recognize there is a problem.  The bug is that `thing-at-point' and
`bounds-of-thing-at-point' can return non-nil for type `comment' when there is
no comment at point.  The former returns a purely whitespace string; the latter
returns its bounds as a cons.

You seem to suggest that the problem, and the proper fix, involves thingatpt.el,
not `forward-comment'.  That sounds fine to me.

One way or the other, however, this needs to be fixed.

Message #75 received at 8667-close <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 8667-close <at> debbugs.gnu.org
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Sat, 21 May 2011 07:52:58 -0700

> > No, I don't think you did.  I just downloaded the latest 
> > thingatpt.el.  There is no fix AFAICT.
> 
> From which branch?

From here:
http://repo.or.cz/w/emacs.git/tree/HEAD:/lisp

In the past that has always given the trunk AFAIK.  And in the past it has been
the _only_ HTTP access that has been reliable (works).  But apparently it is no
longer kept up-to-date.

I just now tried
http://bazaar.launchpad.net/~vcs-imports/emacs/trunk/files/head%3A/lisp/
and got this, which is typically the case:

 Please try again
 Sorry, there was a problem connecting to the Launchpad server. 

 Try reloading this page in a minute or two. If the problem persists,
 let us know in the #launchpad IRC channel on Freenode. 

 Thanks for your patience.

It used to be easy to access Emacs source code via HTTP (back when you used CVS,
IIRC).  Now it is difficult, even if occasionally still possible.  After
repeatedly trying that second URL, I was finally able to get your fixed file.

The first part of this bug report does seem to be fixed: no empty thing
returned.

The second part is not fixed.  `bounds-of-thing-at-point' can still return a
cons when it should return nil.  It can easily return a cons that represents a
purely whitespace, non-comment for thing-type `comment'.  This in turn means
that `thing-at-point' returns a whitespace, non-comment for thing-type
`comment'.

This is a bug in `thingatpt.el'.  It is either a bug in
`bounds-of-thing-at-point', if we expect that general function to DTRT in this
case, or it is a bug in that there is a missing function
`bounds-of-comment-at-point' and consequent (put 'comment
'bounds-of-thing-at-point 'bounds-of-comment-at-point).  Or some such fix.

I already gave the recipe to reproduce the bug.  I can repeat it if necessary.

`b-o-t-a-p' depends for its generic effect on functions such as `forward-THING'.
Sometimes that is enough to make `b-o-t-a-p' DTRT; sometimes it is not enough.
When it is not, as in this case, other measures need to be taken, such as
defining a THING-specific `bounds-of-THING-at-point' function and putting that
on the THING symbol as property `bounds-of-thing-at-point'.

One way or the other, and there are several alternatives, this needs to be
fixed.  It is a bug for `b-o-t-a-p' to return non-nil when there is no comment
at point, and thus for `thing-at-point' to return a non-nil, non-comment value.

Message #83 received at 8667 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8667 <at> debbugs.gnu.org
Subject: Re: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Sat, 21 May 2011 18:06:05 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Sat, 21 May 2011 07:52:58 -0700
> Cc: 8667-close <at> debbugs.gnu.org
> 
> > From which branch?
> 
> >From here:
> http://repo.or.cz/w/emacs.git/tree/HEAD:/lisp
> 
> In the past that has always given the trunk AFAIK.  And in the past it has been
> the _only_ HTTP access that has been reliable (works).  But apparently it is no
> longer kept up-to-date.
> 
> I just now tried
> http://bazaar.launchpad.net/~vcs-imports/emacs/trunk/files/head%3A/lisp/
> and got this, which is typically the case:
> 
>  Please try again
>  Sorry, there was a problem connecting to the Launchpad server. 

That URL is obsolete.  This one is correct and working:

   http://bzr.savannah.gnu.org/lh/emacs/trunk/files

I'm quite sure I posted a message about that to emacs-devel... let me
see... yep, on Apr 10, Re: Development sources can be viewed in bzr
with a Web browser.

Message #86 received at 8667 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 8667 <at> debbugs.gnu.org
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Sat, 21 May 2011 08:15:06 -0700

> That URL is obsolete.  This one is correct and working:
>    http://bzr.savannah.gnu.org/lh/emacs/trunk/files
> I'm quite sure I posted a message about that to emacs-devel... let me
> see... yep, on Apr 10, Re: Development sources can be viewed in bzr
> with a Web browser.

OK, thanks; must have missed that mail.  FYI, the "obsolete" one still works,
apparently (when it works ;-)).

BTW - Why not have a more or less permanent URL that you guys can redirect to
wherever, as needed?  Why so many changes to the user-end URL?  No need to
answer - just food for thought.  Ideally, users should not need to juggle
bookmarks to keep up with dev changes.

Message #89 received at 8667 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8667 <at> debbugs.gnu.org
Subject: Re: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Sat, 21 May 2011 18:52:33 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <8667 <at> debbugs.gnu.org>
> Date: Sat, 21 May 2011 08:15:06 -0700
> 
> BTW - Why not have a more or less permanent URL that you guys can redirect to
> wherever, as needed?  Why so many changes to the user-end URL?

I have no idea why it changed, but the one I mentioned should stay
put.

Message #92 received at 8667 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 8667 <at> debbugs.gnu.org
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Sat, 21 May 2011 11:18:29 -0700

> > BTW - Why not have a more or less permanent URL that you 
> > guys can redirect to wherever, as needed?  Why so many
> > changes to the user-end URL?
> 
> I have no idea why it changed, but the one I mentioned
> should stay put.

Good to hear.  Thanks again.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.