GNU bug report logs -
#3400
Let C-x = show info about visible and invisible text near point
Previous Next
Reported by: Werner LEMBERG <wl <at> gnu.org>
Date: Wed, 27 May 2009 09:00:04 UTC
Severity: wishlist
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3400 in the body.
You can then email your comments to 3400 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Wed, 27 May 2009 09:00:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Werner LEMBERG <wl <at> gnu.org>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Wed, 27 May 2009 09:00:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
[emacs CVS build 2009-05-13]
Steps to repeat the bug:
0. Start `emacs -Q'.
1. Load attached file `emacs-bug.txt' with `C-x C-f'.
2. Load attached file `emacs-bug.el' with `load-file'.
3. Say `M-x make-first-line-invisible'.
The first line properly disappears, however, the first character in
the now visible part of the buffer (the letter `a') makes problems: It
incorrectly refers to the character at buffer position 1 (the digit
`1'). In particular, `C-u C-x =' for letter `a' shows
---
character: 1 (49, #o61, #x31)
preferred charset: ascii (ASCII (ISO646 IRV))
code point: 0x31
syntax: w which means: word
category: .:Base, a:ASCII, l:Latin, r:Roman
buffer code: #x31
file code: #x31 (encoded by coding system undecided-unix)
display: by this font (glyph code)
xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-21-*-*-*-m-0-iso10646-1 (#x14)
Character code properties: customize what to show
name: DIGIT ONE
general-category: Nd (Number, Decimal Digit)
There are text properties here:
intangible t
invisible t
---
A side effect is that `C-a' no longer moves to the beginning of the
line.
Werner
[emacs-bug.txt (text/plain, inline)]
12345
abcde
[emacs-bug.el (text/plain, inline)]
(defun make-first-line-invisible ()
(interactive)
(goto-char (point-min))
(setq start (line-beginning-position))
(setq end (1+ (line-end-position))) ; handle \n
(add-text-properties start
end
'(invisible t
intangible t)))
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Thu, 28 May 2009 15:25:07 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
martin rudalics <rudalics <at> gmx.at>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 28 May 2009 15:25:07 GMT)
Full text and
rfc822 format available.
Message #10 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
> The first line properly disappears, however, the first character in
> the now visible part of the buffer (the letter `a') makes problems: It
> incorrectly refers to the character at buffer position 1 (the digit
> `1'). In particular, `C-u C-x =' for letter `a' shows
>
> ---
>
> character: 1 (49, #o61, #x31)
[...]
> There are text properties here:
> intangible t
> invisible t
`add-text-properties' describes the character after point and when you
call `describe-char' point is at the beginning of the buffer. So IMHO
this is not a bug in `add-text-properties'. It's arguable whether point
should be allowed to be there in your case, but then where to move point
when the entire buffer is invisible?
> A side effect is that `C-a' no longer moves to the beginning of the
> line.
A side effect of what?
martin
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Thu, 28 May 2009 16:35:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Werner LEMBERG <wl <at> gnu.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 28 May 2009 16:35:04 GMT)
Full text and
rfc822 format available.
Message #15 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
>> The first line properly disappears, however, the first character in
>> the now visible part of the buffer (the letter `a') makes problems:
>> It incorrectly refers to the character at buffer position 1 (the
>> digit `1'). In particular, `C-u C-x =' for letter `a' shows
>>
>> ---
>>
>> character: 1 (49, #o61, #x31)
> [...]
>> There are text properties here:
>> intangible t
>> invisible t
>
> `add-text-properties' describes the character after point and when
> you call `describe-char' point is at the beginning of the buffer.
Hmm. If I have
12345
ABCDE
and I make `12345' + the newline after the `5' invisible and
intangible, I see
ABCDE
in the buffer. If the blinking cursor stays on the `A', and you press
`C-x =', do you *really* expect to see the properties of character `1'
instead of `A'? This is completely counterintuitive IMHO.
> So IMHO this is not a bug in `add-text-properties'.
Maybe. I don't know the internal details of Emacs. However, calling
add-text-properties triggers the problem I experience.
> It's arguable whether point should be allowed to be there in your
> case,
In this particular case I don't care where `point' is. I want to get
the correct result of `C-x ='.
> but then where to move point when the entire buffer is invisible?
This might be handled as a special case.
>> A side effect is that `C-a' no longer moves to the beginning of the
>> line.
>
> A side effect of what?
Of calling add-text-properties as described in my report. I do expect
that C-a moves the blinking cursor to the beginning of the line and
not to the *second* character in the buffer, letter `B'.
Werner
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Thu, 28 May 2009 17:20:07 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
martin rudalics <rudalics <at> gmx.at>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 28 May 2009 17:20:07 GMT)
Full text and
rfc822 format available.
Message #20 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Hmm. If I have
>
> 12345
> ABCDE
>
> and I make `12345' + the newline after the `5' invisible and
> intangible, I see
>
> ABCDE
>
> in the buffer. If the blinking cursor stays on the `A', and you press
> `C-x =', do you *really* expect to see the properties of character `1'
> instead of `A'? This is completely counterintuitive IMHO.
Then the value of `point' at the time you invoke that command is
counterintuitive.
>> So IMHO this is not a bug in `add-text-properties'.
>
> Maybe. I don't know the internal details of Emacs. However, calling
> add-text-properties triggers the problem I experience.
>
>> It's arguable whether point should be allowed to be there in your
>> case,
>
> In this particular case I don't care where `point' is. I want to get
> the correct result of `C-x ='.
Don't blame `describe-char' here. It must be able to work on any buffer
position including those preceded and/or followed by invisible text.
>> but then where to move point when the entire buffer is invisible?
>
> This might be handled as a special case.
Maybe. But then you admit that the problem is with the position of
`point' ;-) Anyway, IIRC the idea was that you should be able put a
visible overlay before invisible text at the beginning of the buffer and
be able to move the cursor there. I have no idea whether that ever
worked, though.
>>> A side effect is that `C-a' no longer moves to the beginning of the
>>> line.
>> A side effect of what?
>
> Of calling add-text-properties as described in my report. I do expect
> that C-a moves the blinking cursor to the beginning of the line and
> not to the *second* character in the buffer, letter `B'.
This _is_ a bug and I doubt it's the only one with respect to moving
point over invisible text.
martin
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Thu, 28 May 2009 18:35:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> IRO.UMontreal.CA>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 28 May 2009 18:35:04 GMT)
Full text and
rfc822 format available.
Message #25 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Hmm. If I have
> 12345
> ABCDE
> and I make `12345' + the newline after the `5' invisible and
> intangible, I see
> ABCDE
> in the buffer. If the blinking cursor stays on the `A', and you press
> `C-x =', do you *really* expect to see the properties of character `1'
> instead of `A'? This is completely counterintuitive IMHO.
If you hit `b', the `b' will be inserted right before "12345", and it
will not be invisible. BTW, why are you using `intangible'?
Stefan
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Thu, 28 May 2009 21:55:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Werner LEMBERG <wl <at> gnu.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 28 May 2009 21:55:04 GMT)
Full text and
rfc822 format available.
Message #30 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
>> Hmm. If I have
>
>> 12345
>> ABCDE
>
>> and I make `12345' + the newline after the `5' invisible and
>> intangible, I see
>
>> ABCDE
>
>> in the buffer. If the blinking cursor stays on the `A', and you
>> press `C-x =', do you *really* expect to see the properties of
>> character `1' instead of `A'? This is completely counterintuitive
>> IMHO.
>
> If you hit `b', the `b' will be inserted right before "12345", and it
> will not be invisible.
So what? With `C-x =' I see `A' and get the data of `1', this is what
I consider a bug. Actually, there is no way to retrieve information
from `A' at all.
> BTW, why are you using `intangible'?
I've just copied some code -- I haven't checked whether I can omit it.
BTW, the problem is not restricted to the beginning of the buffer.
With this input
12345
ABCDE
abcde
and this lisp code
(defun make-second-line-invisible ()
(interactive)
(goto-line 2)
(setq start (line-beginning-position))
(setq end (1+ (line-end-position))) ; handle \n
(add-text-properties start
end
'(invisible t
intangible t)))
there is the same problem: After calling the function you get
12345
abcde
and `C-x =' (positioned on the `a') reports the info of the now
invisible character `A'. Similarly, C-a only moves to character `b'.
Werner
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Fri, 29 May 2009 02:15:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Fri, 29 May 2009 02:15:03 GMT)
Full text and
rfc822 format available.
Message #35 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
>> If you hit `b', the `b' will be inserted right before "12345", and it
>> will not be invisible.
> So what? With `C-x =' I see `A' and get the data of `1',
Point is at position 1 (i.e. just before the char "1" rather than
before the char "A"), so it makes sense for C-h = to return data about
that position rather than about some other position one line down.
Also it makes sense to draw the cursor over the "A" because there's
nowhere else to draw it. Basically, since the chars "12345\n" are
invisible and intangible, the display should pretend they don't exist,
but C-x = is designed to show you the actual underlying data.
> Actually, there is no way to retrieve information from `A' at all.
Your `intangible' span basically requests "12345\nA" to be treated as one
indivisible entity, so it's indeed difficult to get info about most of
those individual chars.
>> BTW, why are you using `intangible'?
> I've just copied some code -- I haven't checked whether I can omit it.
First things first: if you're not 200% sure you absolutely need
`intangible', then don't use it. It's a nasty beast.
Stefan
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Fri, 29 May 2009 12:20:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Werner LEMBERG <wl <at> gnu.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Fri, 29 May 2009 12:20:05 GMT)
Full text and
rfc822 format available.
Message #40 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Point is at position 1 (i.e. just before the char "1" rather than
> before the char "A"), so it makes sense for C-h = to return data
> about that position rather than about some other position one line
> down.
I disagree. Whereever point is, it should report the character after
point which is accessible (this is, visible). Perhaps it makes sense
to add a red warning message in the output of `C-x =' that point is
not located right before the displayed character.
If we had a small line instead of a blinking, block-like cursor (as it
is used with, say, OpenOffice), I could accept your argumentation.
But the visual effect is overwhelming, and it is extremely confusing
if the optical appearance differs so much from the `theoretical'
result.
>> Actually, there is no way to retrieve information from `A' at all.
>
> Your `intangible' span basically requests "12345\nA" to be treated
> as one indivisible entity, so it's indeed difficult to get info
> about most of those individual chars.
Hmm. IMHO, the same argumentation as above holds.
> if you're not 200% sure you absolutely need `intangible', then don't
> use it. It's a nasty beast.
Indeed. But for my particular needs -- filtering out some lines, then
searching and editing the visible ones only without accidentally
editing invisible stuff, it seems that `intangible' is still
necessary, and probably will stay so.
Werner
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Fri, 29 May 2009 13:30:06 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Lennart Borgman <lennart.borgman <at> gmail.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Fri, 29 May 2009 13:30:07 GMT)
Full text and
rfc822 format available.
Message #45 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
On Fri, May 29, 2009 at 9:00 AM, Werner LEMBERG <wl <at> gnu.org> wrote:
>
>> Point is at position 1 (i.e. just before the char "1" rather than
>> before the char "A"), so it makes sense for C-h = to return data
>> about that position rather than about some other position one line
>> down.
>
> I disagree. Whereever point is, it should report the character after
> point which is accessible (this is, visible). Perhaps it makes sense
> to add a red warning message in the output of `C-x =' that point is
> not located right before the displayed character.
I agree with you here, Werner. And I think the red warning is a good idea too.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Fri, 29 May 2009 14:55:08 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Fri, 29 May 2009 14:55:08 GMT)
Full text and
rfc822 format available.
Message #50 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
> >> Point is at position 1 (i.e. just before the char "1" rather than
> >> before the char "A"), so it makes sense for C-h = to return data
> >> about that position rather than about some other position one line
> >> down.
> >
> > I disagree. Whereever point is, it should report the
> > character after point which is accessible (this is, visible).
> > Perhaps it makes sense to add a red warning message in the
> > output of `C-x =' that point is
> > not located right before the displayed character.
>
> I agree with you here, Werner. And I think the red warning is
> a good idea too.
I haven't followed this thread, so apologies if I miss the point.
To me, we want C-x = to give as much info as possible, including info about
positions that we might not be able to see or even to reach/access by
positioning point.
Since there already is a way to get info about the positions that are accessible
and those that are visible, by moving the cursor a bit, there is no loss in also
providing info about positions that are inaccessible or invisible. So I think I
agree with Stefan here (if this is in fact what he says): C-x = should return
info about the closest position you can access.
That is, if C-x = can help by giving some info about invisible or intangible
chars, so much the better. Nothing prevents us from moving the cursor a bit and
getting the info about the accessible, visible, boundary positions.
If the info shown for such unusual positions is accurate, it will, itself,
indicate that the char is intangible or invisible or whatever. But I do agree
that perhaps some extra notification (red or, preferably just an additional
statement) of this might be helful. (But please don't call such a notification a
"warning".)
Again, ignore if not relevant.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Fri, 29 May 2009 15:10:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Fri, 29 May 2009 15:10:06 GMT)
Full text and
rfc822 format available.
Message #55 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
> I disagree. Whereever point is, it should report the character after
> point which is accessible (this is, visible). Perhaps it makes sense
> to add a red warning message in the output of `C-x =' that point is
> not located right before the displayed character.
I think what would make most sense if for C-x = to notice such invisible
text and either give info about the whole invisible area, or prompt
which position within that area is actually desired. In your case, you
want info about the visible char, but I most often use C-x =
specifically to get info about the part I can't see.
> If we had a small line instead of a blinking, block-like cursor (as it
> is used with, say, OpenOffice), I could accept your argumentation.
That can be configured via `cursor-type'.
>> if you're not 200% sure you absolutely need `intangible', then don't
>> use it. It's a nasty beast.
> Indeed. But for my particular needs -- filtering out some lines, then
> searching and editing the visible ones only without accidentally
> editing invisible stuff, it seems that `intangible' is still
> necessary, and probably will stay so.
Your call, but you've been warned. I'd still recommend you first try it
without `intangible'.
Stefan
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Fri, 29 May 2009 15:25:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Werner LEMBERG <wl <at> gnu.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Fri, 29 May 2009 15:25:05 GMT)
Full text and
rfc822 format available.
Message #60 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
> I think what would make most sense if for C-x = to notice such
> invisible text and either give info about the whole invisible area,
> or prompt which position within that area is actually desired.
Yes, this sounds like a good idea.
What do you think about the C-a issue, BTW?
> In your case, you want info about the visible char, but I most often
> use C-x = specifically to get info about the part I can't see.
Honestly, up to now I had never the idea of using C-x = like that. I
wasn't even aware that I can use it for that purpose.
>> If we had a small line instead of a blinking, block-like cursor (as
>> it is used with, say, OpenOffice), I could accept your
>> argumentation.
>
> That can be configured via `cursor-type'.
I know, but the default is a block cursor...
Werner
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Fri, 29 May 2009 16:15:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> IRO.UMontreal.CA>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Fri, 29 May 2009 16:15:03 GMT)
Full text and
rfc822 format available.
Message #65 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
>> I think what would make most sense if for C-x = to notice such
>> invisible text and either give info about the whole invisible area,
>> or prompt which position within that area is actually desired.
> Yes, this sounds like a good idea.
Patches welcome ;-)
> What do you think about the C-a issue, BTW?
That would be a bug in C-a, but I can't reproduce it: if I go to "c" and
hit C-a, my cursor correctly moves to the beginning of line (just
before "A", displayed as being just before "a").
Stefan
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Fri, 29 May 2009 16:55:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
martin rudalics <rudalics <at> gmx.at>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Fri, 29 May 2009 16:55:05 GMT)
Full text and
rfc822 format available.
Message #70 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
>> What do you think about the C-a issue, BTW?
>
> That would be a bug in C-a, but I can't reproduce it: if I go to "c" and
> hit C-a, my cursor correctly moves to the beginning of line (just
> before "A", displayed as being just before "a").
It's a Heisenbug.
martin
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Sat, 30 May 2009 06:00:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Werner LEMBERG <wl <at> gnu.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sat, 30 May 2009 06:00:04 GMT)
Full text and
rfc822 format available.
Message #75 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
>>> What do you think about the C-a issue, BTW?
>> That would be a bug in C-a, but I can't reproduce it: if I go to "c"
>> and
>> hit C-a, my cursor correctly moves to the beginning of line (just
>> before "A", displayed as being just before "a").
>
> It's a Heisenbug.
Hmm. It seems to be a problem with the `intangible' property. If I
remove it, C-a works correctly. I'll try a newer Emacs version; maybe
this problem has vanished meanwhile.
Werner
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Sat, 30 May 2009 07:05:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Werner LEMBERG <wl <at> gnu.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sat, 30 May 2009 07:05:04 GMT)
Full text and
rfc822 format available.
Message #80 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
>> What do you think about the C-a issue, BTW?
>
> That would be a bug in C-a, but I can't reproduce it: if I go to "c"
> and hit C-a, my cursor correctly moves to the beginning of line
> (just before "A", displayed as being just before "a").
I've just recompiled current CVS, and I get still the erroneous
behaviour, using the files I've sent in my bug report.
Anyone else who sees this?
Werner
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Sat, 30 May 2009 10:10:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stephen Berman <stephen.berman <at> gmx.net>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sat, 30 May 2009 10:10:04 GMT)
Full text and
rfc822 format available.
Message #85 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
On Sat, 30 May 2009 09:01:34 +0200 (CEST) Werner LEMBERG <wl <at> gnu.org> wrote:
>>> What do you think about the C-a issue, BTW?
>>
>> That would be a bug in C-a, but I can't reproduce it: if I go to "c"
>> and hit C-a, my cursor correctly moves to the beginning of line
>> (just before "A", displayed as being just before "a").
>
> I've just recompiled current CVS, and I get still the erroneous
> behaviour, using the files I've sent in my bug report.
>
> Anyone else who sees this?
>
>
> Werner
I also see the buggy C-a behavior with GNU Emacs 23.0.94.1
(i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2009-05-28 on escher
Steve Berman
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#3400
; Package
emacs
.
(Sat, 30 May 2009 10:20:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
martin rudalics <rudalics <at> gmx.at>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sat, 30 May 2009 10:20:03 GMT)
Full text and
rfc822 format available.
Message #90 received at 3400 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Hmm. It seems to be a problem with the `intangible' property. If I
> remove it, C-a works correctly. I'll try a newer Emacs version; maybe
> this problem has vanished meanwhile.
It's not necessarily related to the intangible property. Have a
look at the thread starting with
http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00601.html
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#3400
; Package
emacs
.
(Wed, 27 Jul 2016 22:08:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 3400 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> I also see the buggy C-a behavior with GNU Emacs 23.0.94.1
> (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2009-05-28 on escher
I can't reproduce the C-a behavior issue on Emacs built today, commit
c54238d.
The issue with C-u C-x = is still there though.
Cheers,
Nico
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#3400
; Package
emacs
.
(Fri, 29 Jul 2016 02:27:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 3400 <at> debbugs.gnu.org (full text, mbox):
retitle 3400 Let C-x = show info about visible and invisible text near point
severity 3400 wishlist
quit
Nicolas Petton <nicolas <at> petton.fr> writes:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> I also see the buggy C-a behavior with GNU Emacs 23.0.94.1
>> (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2009-05-28 on escher
>
> I can't reproduce the C-a behavior issue on Emacs built today, commit
> c54238d.
Same here (25.1-rc1).
>
> The issue with C-u C-x = is still there though.
So I'm setting this to wishlist.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3400#55 is the clearest
statement of what's wished for.
Changed bug title to 'Let C-x = show info about visible and invisible text near point' from 'bug in add-text-properties'
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Fri, 29 Jul 2016 02:27:02 GMT)
Full text and
rfc822 format available.
Severity set to 'wishlist' from 'normal'
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Fri, 29 Jul 2016 02:27:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#3400
; Package
emacs
.
(Fri, 22 Apr 2022 13:00:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 3400 <at> debbugs.gnu.org (full text, mbox):
npostavs <at> users.sourceforge.net writes:
> retitle 3400 Let C-x = show info about visible and invisible text near point
I've now made the command say something more about invisibility/point
confusion in Emacs 29.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
3400 <at> debbugs.gnu.org and Werner LEMBERG <wl <at> gnu.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 22 Apr 2022 13:00:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 21 May 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 313 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.