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.

  • 1
    Solved by applying field property to intangible area. – Shmozart Jan 17 '18 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 Jan 17 '18 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 Jan 18 '18 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 Jan 18 '18 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 Jan 18 '18 at 14:17
3

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.

  • 1
    Please provide a more complete answer so that other users who find this post later will understand what you did. – Dan Jan 18 '18 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 Jan 18 '18 at 14:22
  • @Dan Does the flagging system automatically reverse the downvote if all close-votes have been retracted? – Tobias Jan 18 '18 at 20:25
  • @Tobias : I’m sorry, I don’t know. – Dan Jan 18 '18 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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