3

I want to make the beginning of a line uneditable, which I can achieve by applying the read-only and cursor-intangible properties. But I have the problem, that line-beginning-position moves point not to the first reachable position of the current line, as I expect, but to the end of the previous line. This may be a bug in Emacs. Is there some workaround for this issue?

Example: Let's say buffer contains "blablabla\nINTANGIBLEfooooo" INTANGIBLE has properties cursor-intangible t rear-nonsticky t front-sticky t. Then it is not possible to put point before any symbol of "INTANGIBLE", that is exactly wanted behavior, however if point is somewhere in fooooo, move-beginning-of-line puts point to the end of blablabla, which is strange.

Reconstruction:

  • Copy and paste the following form into the *scratch* buffer. There the black rectangle ▮ indicates the point position. (You should not copy that character.)
(insert "\nblablabla\n"
        (propertize "INTANGIBLE" 'cursor-intangible t 'rear-nonsticky t 'front-sticky t)
        "fooooo")▮
  • Eval the form with C-x C-e. You get
(insert "\nblablabla\n"
        (propertize "INTANGIBLE" 'cursor-intangible t 'rear-nonsticky t 'front-sticky t)
        "fooooo")
blablabla
INTANGIBLEfooooo▮
  • Hit the home key. You end up with:
(insert "\nblablabla\n" (propertize "INTANGIBLE" 'cursor-intangible t 'rear-nonsticky t 'front-sticky t) "fooooo")
blablabla▮
INTANGIBLEfooooo

It becomes really interesting if one tries to get this behavior completely with the evaluation of a lisp expression:

(progn
  (insert "\nblablabla\n"
          (propertize "INTANGIBLE" 'cursor-intangible t 'rear-nonsticky t 'front-sticky t)
          "fooooo")
  (call-interactively #'move-beginning-of-line))▮

After evaluation with C-x C-e one gets: lisp form evaluation

I.e., point is between the last intangentiable character and the f of foooooo.

5
  • 1
    Solved by applying field property to intangible area.
    – Shmozart
    Commented Jan 17, 2018 at 13:43
  • 3
    Please post your comment as an answer (which you can accept). Try to make clear what the problem was and show how the solution solves it.
    – Drew
    Commented Jan 17, 2018 at 14:19
  • 1
    I cannot reproduce this behaviour. With point at BOL, (progn (add-text-properties (point) (1+ (point)) '(read-only t cursor-intangible t)) (cursor-intangible-mode) (end-of-line) (beginning-of-line)) takes me back to where I started. Note that the function line-beginning-position which you mention does not move point.
    – Basil
    Commented Jan 18, 2018 at 13:10
  • You get the effect of the OP if you use a wrong beginning: (progn (add-text-properties (1- (point)) (1+ (point)) '(read-only t cursor-intangible t)) (cursor-intangible-mode) (end-of-line) (beginning-of-line)). Maybe something like that was the cause.
    – Tobias
    Commented Jan 18, 2018 at 13:53
  • @Tobias Yes, and this is expected behaviour for cursor-intangible-mode. Drew is right in that OP should provide more information about what they are trying to do and how.
    – Basil
    Commented Jan 18, 2018 at 14:17

1 Answer 1

4

Applying field property to intangible area solves the problem.

Adding of field t to the properties of INTANGIBLE makes move-beginning-of-line putting point between INTANGIBLE and fooooo, like expected.

Reconstruction:

  • Copy-paste following lisp code into the *scratch* buffer. There the black rectangle ▮ indicates the point position. (You should not copy that character.)
(insert "\nblablabla\n"
        (propertize "INTANGIBLE"
                    'cursor-intangible t
                    'rear-nonsticky t
                    'front-sticky t
                    'field t)
        "fooooo")▮
  • Evaluate it with C-x C-e.
  • Press the home key. You get:

final state of *scratch* with field-propertized string

I.e., point is between the last intangentiable character and the f of foooooo.

4
  • 1
    Please provide a more complete answer so that other users who find this post later will understand what you did.
    – Dan
    Commented Jan 18, 2018 at 14:21
  • Sorry about that downvote -- the flagging system did it automatically. If you can expand your answer to be more explanatory, I will upvote to compensate.
    – Dan
    Commented Jan 18, 2018 at 14:22
  • @Dan Does the flagging system automatically reverse the downvote if all close-votes have been retracted?
    – Tobias
    Commented Jan 18, 2018 at 20:25
  • @Tobias : I’m sorry, I don’t know.
    – Dan
    Commented Jan 18, 2018 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.