emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: invisible text and point


From: Stefan Monnier
Subject: Re: invisible text and point
Date: Mon, 26 May 2003 13:21:43 -0400

> There has been a relatively recent change in the treatment of point
> near invisible text.  That change can be very confusing to the user
> and apparently also to the Emacs code.  I noticed several bugs which
> seem to be related to the change in question.  I have the impression
> that they all could be undone by reverting the change.

I removed all the invisible-adjustment in adjust_point_for_property and
could still get the same infinite looping, so the bug is elsewhere.

> Reverting the change would automatically get rid of these bugs.

Clearly not.

> could find tons of similar bugs.  For instance, with point in
> invisible text, one could easily get extremely strange defaults for
> C-h f, C-h v, M-x man and so on...

The change you refer to tries to move point out of invisible areas,
so if anything it should help.

> Move that window upward with mouse-1.  No problem until we hit that
> same spot with the invisible text.  There Emacs goes in an infinite
> loop, apparently in the C code.  C-g is no help.

Indeed, and it seems that the loop is in redisplay:

(gdb) bt
#0  0x080a653a in compute_line_metrics (it=0xbfffd6c0) at xdisp.c:13948
#1  0x080a8117 in display_line (it=0xbfffd6c0) at xdisp.c:14613
#2  0x0809ee9b in try_window (window=1216242496, pos=
      {charpos = 12347417, bytepos = 12347417}) at xdisp.c:12023
#3  0x0809affb in try_scrolling (window=1216242496, just_this_one_p=0, 
    scroll_conservatively=1000, scroll_step=0, temp_scroll_step=0, 
    last_line_misfit=1) at xdisp.c:10926
#4  0x0809d4f4 in redisplay_window (window=1216242496, just_this_one_p=0)
    at xdisp.c:11732
#5  0x08098c0d in redisplay_window_0 (window=1216242496) at xdisp.c:10444
#6  0x0821cbf3 in internal_condition_case_1 (
    bfun=0x8098bdc <redisplay_window_0>, arg=1216242496, handlers=1482251844, 
    hfun=0x8098bb4 <redisplay_window_error>) at eval.c:1385
#7  0x08098b9d in redisplay_windows (window=1216242496) at xdisp.c:10423
#8  0x08098aec in redisplay_windows (window=1218249664) at xdisp.c:10417
#9  0x08096e96 in redisplay_internal (preserve_echo_area=0) at xdisp.c:10012
#10 0x08094d6d in redisplay () at xdisp.c:9439
#11 0x08173eb5 in read_char (commandflag=0, nmaps=0, maps=0x0, 
    prev_event=408301780, used_mouse_menu=0x0) at keyboard.c:2501
#12 0x0824754a in read_filtered_event (no_switch_frame=0, ascii_required=0, 
    error_nonascii=0, input_method=0) at lread.c:465
#13 0x082477b8 in Fread_event (prompt=408301732, 
    inherit_input_method=408301732) at lread.c:563
#14 0x08221423 in Ffuncall (nargs=1, args=0xbfffe860) at eval.c:2763
#15 0x0826e7ef in Fbyte_code (bytestr=943814520, vector=1212250440, maxdepth=4)
    at bytecode.c:712
#16 0x0821f0ac in Feval (form=1480685416) at eval.c:2114
#17 0x0821a37b in Fprogn (args=1480685408) at eval.c:410
#18 0x08177794 in Ftrack_mouse (args=1480685408) at keyboard.c:3434
#19 0x0821ea0d in Feval (form=1480685400) at eval.c:2055
#20 0x0821a37b in Fprogn (args=1480685392) at eval.c:410
#21 0x08222121 in funcall_lambda (fun=1480685376, nargs=0, 
    arg_vector=0xbfffec94) at eval.c:2940
#22 0x08221988 in Ffuncall (nargs=1, args=0xbfffec90) at eval.c:2817
#23 0x0826e7ef in Fbyte_code (bytestr=943814092, vector=1212249784, maxdepth=5)
    at bytecode.c:712
#24 0x0822223b in funcall_lambda (fun=1212249504, nargs=2, 
    arg_vector=0xbfffee74) at eval.c:2947
#25 0x082218d3 in Ffuncall (nargs=3, args=0xbfffee70) at eval.c:2808
#26 0x0826e7ef in Fbyte_code (bytestr=943815292, vector=1212250792, maxdepth=3)
    at bytecode.c:712
#27 0x0822223b in funcall_lambda (fun=1212250708, nargs=1, 
    arg_vector=0xbffff074) at eval.c:2947
#28 0x082218d3 in Ffuncall (nargs=2, args=0xbffff070) at eval.c:2808
#29 0x08219712 in Fcall_interactively (function=410154500, 
    record_flag=408301732, keys=1213667744) at callint.c:848
#30 0x0818ab15 in Fcommand_execute (cmd=410154500, record_flag=408301732, 
    keys=408301732, special=408301732) at keyboard.c:9644
#31 0x08171c97 in command_loop_1 () at keyboard.c:1761
#32 0x0821cab1 in internal_condition_case (bfun=0x816ef9c <command_loop_1>, 
    handlers=408397268, hfun=0x816e974 <cmd_error>) at eval.c:1344
#33 0x0816ee28 in command_loop_2 () at keyboard.c:1298
#34 0x0821c407 in internal_catch (tag=408394572, 
    func=0x816ee04 <command_loop_2>, arg=408301732) at eval.c:1104
#35 0x0816eda5 in command_loop () at keyboard.c:1277
#36 0x0816e2eb in recursive_edit_1 () at keyboard.c:993
#37 0x0816e6f3 in Frecursive_edit () at keyboard.c:1049
#38 0x0816c57b in main (argc=3, argv=0xbffff934) at emacs.c:1666
#39 0x402d44ed in __libc_start_main () from /lib/libc.so.6
(gdb) xbacktrace
"read-event"
"byte-code"
"track-mouse"
0x58417740 Lisp type 5
"mouse-drag-mode-line-1"
"mouse-drag-mode-line"
"call-interactively"
(gdb) 

> I realize that putting point inside that invisible text has some
> advantages in terms of stickiness.

Point is not put inside the invisible text.  It's put at one of the
two ends.  In this case it happens to be "just before" rather than
"just after" because the stickiness is the default one so that inserting
a char at the end would lead to a hidden char whereas inserting a char
at the beginning would lead to a visible char: the choice is to prefer
putting point at a position such that inserted text is visible.

I believe that the `intangible' change mentioned underneath in the NEWS
file did the same for intangible&invisible text.

>  However, in user produced buffers,
> a user sophisticated enough to be playing around with invisibility
> properties is probably sophisticated enough to handle stickiness in
> the way that is best for him/her.  The Emacs produced buffers we are
> talking about are all read-only to begin with, but to avoid confusing
> users who, for some reason make them writable, we could give
> text-property-default-nonsticky a buffer-local value and make the
> invisibility property non-sticky in those particular buffers.

Or rather make it "front-sticky" rather than "rear-sticky", such
that when the user sees point in front of letter "a", `char-after'
will indeed show letter ?a.  Right now, it's the opposite: if point
is right after letter "a" `char-before' will indeed return ?a.


        Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]