Inhibiting read-only

Inhibiting read-only

[Lars Magne Ingebrigtsen]

I'd like to make the eww buffers read-only, but leave text input fields
editable.  (And then do processing of the alterations with
`insert-behind-hooks' or `after-change-functions'.)

That doesn't seem to be possible?  Would it be possible to add a
`inhibit-read-only' text property?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Inhibiting read-only

[Juanma Barranquero]

On Wed, Jun 19, 2013 at 5:49 PM, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> That doesn't seem to be possible?  Would it be possible to add a
> `inhibit-read-only' text property?

Wouldn't it be possible by doing clever tricks with `point-entered'
and `point-left' functions and the `inhibit-read-only' variable?

   J

Re: Inhibiting read-only

[Jambunathan K]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I'd like to make the eww buffers read-only, but leave text input fields
> editable.  (And then do processing of the alterations with
> `insert-behind-hooks' or `after-change-functions'.)
>
> That doesn't seem to be possible?  Would it be possible to add a
> `inhibit-read-only' text property?

inhibit-read-only can be a list.

Re: Inhibiting read-only

[Juanma Barranquero]

On Wed, Jun 19, 2013 at 6:07 PM, Jambunathan K <kjambunathan@gmail.com> wrote:

> inhibit-read-only can be a list.

Yes, but if I'm reading correctly the documentation

 -- Variable: inhibit-read-only
     If this variable is non-`nil', then read-only buffers and,
     depending on the actual value, some or all read-only characters
     may be modified.  Read-only characters in a buffer are those that
     have a non-`nil' `read-only' text property.  *Note Special
     Properties::, for more information about text properties.

setting it to a list (or any non-nil value) will also have the effect
of allowing writting in read-only-buffers.

   J

Re: Inhibiting read-only

[Jambunathan K]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Wed, Jun 19, 2013 at 6:07 PM, Jambunathan K <kjambunathan@gmail.com> wrote:
>
>> inhibit-read-only can be a list.
>
> Yes, but if I'm reading correctly the documentation
>
>  -- Variable: inhibit-read-only
>      If this variable is non-`nil', then read-only buffers and,
>      depending on the actual value, some or all read-only characters
>      may be modified.  Read-only characters in a buffer are those that
>      have a non-`nil' `read-only' text property.  *Note Special
>      Properties::, for more information about text properties.
>
> setting it to a list (or any non-nil value) will also have the effect
> of allowing writting in read-only-buffers.

Look at the last line of the docstring.

You selectively inhibit the some read only properties.  

inhibit-read-only:read-only::buffer-invisibility-spec:invisible.


,----[ C-h v inhibit-read-only RET ]
| inhibit-read-only is a variable defined in `C source code'.
| Its value is nil
| 
| Documentation:
| Non-nil means disregard read-only status of buffers or characters.
| If the value is t, disregard `buffer-read-only' and all `read-only'
| text properties.  If the value is a list, disregard `buffer-read-only'
| and disregard a `read-only' text property if the property value
| is a member of the list.
| 
| [back]
`----

Mark editable fields with  (... 'readonly 'editable).

Now to make those fields editable, you push 'editable to
inhibit-read-only.

By properly making the newly inserted characters having right stickiness
it should be possible to make forms selectively editable.

>    J

Re: Inhibiting read-only

[Lars Magne Ingebrigtsen]

Jambunathan K <kjambunathan@gmail.com> writes:

> Mark editable fields with  (... 'readonly 'editable).

So you're suggesting making the buffer read-onlu, but then putting
'read-only 'editable on the input fields?  And then setting
`inhibit-read-only' to `(editable)' in that buffer?  If that works,
that's pretty twisty.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Inhibiting read-only

[Jambunathan K]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> Mark editable fields with  (... 'readonly 'editable).
>
> So you're suggesting making the buffer read-onlu, but then putting
> 'read-only 'editable on the input fields?  And then setting
> `inhibit-read-only' to `(editable)' in that buffer?  If that works,
> that's pretty twisty.  :-)

How about something like this to make first line editable and second and
third lines not editable.

(with-current-buffer (generate-new-buffer  "read-only")
  (pop-to-buffer (current-buffer))
  (insert "first line\nsecond line\nthird line")

  (add-text-properties (point-min) (point-max) '(read-only read-only))

  (let ((inhibit-read-only '(read-only)))
    (goto-char (point-min))                   
    (add-text-properties (point-at-bol) (point-at-eol) '(read-only
							 editable)))
  (setq inhibit-read-only '(editable)))

Re: Inhibiting read-only

[Juanma Barranquero]

On Wed, Jun 19, 2013 at 6:24 PM, Jambunathan K <kjambunathan@gmail.com> wrote:

> Look at the last line of the docstring.
>
> You selectively inhibit the some read only properties.

It says "if the value is a list, disregard `buffer-read-only' [...]

It is true that it will disregard a *text property* only if it is in
the list. But, AFAICS, if you have the buffer set to read-only via
`buffer-read-only' (regardless of text properties you're using to set
segments of text as read-only), setting inhibit-read-only to a list
will ignore the read-onliness of the buffer.

IOW, that would work if you have a non-read-only buffer, and some
parts of the buffer are set to read-only via text properties, and you
want to selectively ignore some or all these text properties.

I understand Lars' question as having a read-only buffer (not a
read-only text property set from (point-min) to (point-max)) and
wanting to deactivate it for some segments of the text.

   J

Re: Inhibiting read-only

[Jambunathan K]

Juanma Barranquero <lekktu@gmail.com> writes:

> I understand Lars' question as having a read-only buffer (not a
> read-only text property set from (point-min) to (point-max)) and
> wanting to deactivate it for some segments of the text.

I meant this.  M-: the below form.  You will see that first line is
editable.  But the second and third lines cannot be edited.

(with-current-buffer (generate-new-buffer  "read-only")
  (pop-to-buffer (current-buffer))
  (insert "first line\nsecond line\nthird line")  
  (goto-char (point-min))                   
  (add-text-properties (point-at-bol) (point-at-eol) '(read-only
						       editable))
  (forward-line 1)
  (add-text-properties (point) (point-max) '(read-only t))
  (setq inhibit-read-only '(editable)))

Re: Inhibiting read-only

[Juanma Barranquero]

On Wed, Jun 19, 2013 at 6:48 PM, Jambunathan K <kjambunathan@gmail.com> wrote:

> I meant this.

I already understood what you mean. Did you read what I said?

   J

Re: Inhibiting read-only

[Lars Magne Ingebrigtsen]

Jambunathan K <kjambunathan@gmail.com> writes:

>   (add-text-properties (point) (point-max) '(read-only t))

I do not want to put the `read-only' text property on the rest of the
text, because that makes copying/yanking the text really annoying.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Inhibiting read-only

[Juanma Barranquero]

On Wed, Jun 19, 2013 at 7:11 PM, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> I do not want to put the `read-only' text property on the rest of the
> text

As expected.

Try exploring the point-entered / point-left route. It's a bit
convoluted, but it should work.

   J

Re: Inhibiting read-only

[Lars Magne Ingebrigtsen]

Juanma Barranquero <lekktu@gmail.com> writes:

> Try exploring the point-entered / point-left route. It's a bit
> convoluted, but it should work.

Yes, that seems like the most promising solution.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Inhibiting read-only

[Jambunathan K]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>>   (add-text-properties (point) (point-max) '(read-only t))
>
> I do not want to put the `read-only' text property on the rest of the
> text, because that makes copying/yanking the text really annoying.

So `read-only' is discarded while yanking. (See `yank-excluded-properties') .

But when you are yanking a (... 'read-only 'read-only) text in the
middle of an (... 'read-only 'editable) field, I see that the 'read-only
property is removed altogether on the newly yanked portion.  (I am
wondering) Shouldn't the yanked text should inherit the read-only
property of the surrounding text and thus get the ('read-only 'editable)
value.

Re: Inhibiting read-only

[James Cloos]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> I'd like to make the eww buffers read-only, but leave text input
LMI> fields editable.  (And then do processing of the alterations with
LMI> `insert-behind-hooks' or `after-change-functions'.)

That sounds like how the Customize buffers work, yes?

Perhaps a clue lies there.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Inhibiting read-only

[Lars Magne Ingebrigtsen]

James Cloos <cloos@jhcloos.com> writes:

> That sounds like how the Customize buffers work, yes?
>
> Perhaps a clue lies there.

Perhaps, but I was unable to determine exactly what it does.  :-)
Something to do with overlays or filters?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Inhibiting read-only

[James Cloos]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> Perhaps, but I was unable to determine exactly what it does.  :-)

Evidently is obfuscates? :^)

But I see that Stefan has decoded.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Inhibiting read-only

[Stefan Monnier]

LMI> I'd like to make the eww buffers read-only, but leave text input
LMI> fields editable.  (And then do processing of the alterations with
LMI> `insert-behind-hooks' or `after-change-functions'.)
> That sounds like how the Customize buffers work, yes?

Exactly, they set buffer-read-only to nil but then use
a before-change-function to signal an error when trying to modify
a non-text-widget area.


        Stefan

Re: Inhibiting read-only

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> LMI> I'd like to make the eww buffers read-only, but leave text input
> LMI> fields editable.  (And then do processing of the alterations with
> LMI> `insert-behind-hooks' or `after-change-functions'.)
>> That sounds like how the Customize buffers work, yes?
>
> Exactly, they set buffer-read-only to nil but then use
> a before-change-function to signal an error when trying to modify
> a non-text-widget area.

I like `read-only' buffers -- they have an obvious interface.  If the
user decides to switch read-only off (which I sometimes do in otherwise
non-editable buffers) to do some weird ad-hoc editing, there's a
standard, convenient key-stroke for that.

So if there were a `inhibit-read-only' text property, we could avoid
doing all these tricks with `before-change-function' and the like -- we
could just make the buffer read-only, put the text property on the bits
that aren't read-only, and we'd be done.  And there would be less user
confusion.

I can have a go at implementing this if it sounds like a workable idea,
although that part of the code is completely unfamiliar to me...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Inhibiting read-only

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> So if there were a `inhibit-read-only' text property, we could avoid

There is already the read-only property, only it cannot express
negative.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Inhibiting read-only

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@suse.de> writes:

> There is already the read-only property, only it cannot express
> negative.

Yeah.  A value of nil means the same as the absence of the property.

We would make `read-only inhibit' mean "inhibit buffer-wide
read-onlyness", but then that means that if somebody today is using
`read-only inhibit' (for some reason or other) to make text read-only,
then that would break.  I don't think that's very likely, though...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Inhibiting read-only

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 20 Jun 2013 10:44:25 +0200
> Cc: James Cloos <cloos@jhcloos.com>, emacs-devel@gnu.org
> 
> I like `read-only' buffers -- they have an obvious interface.  If the
> user decides to switch read-only off (which I sometimes do in otherwise
> non-editable buffers) to do some weird ad-hoc editing, there's a
> standard, convenient key-stroke for that.
> 
> So if there were a `inhibit-read-only' text property, we could avoid
> doing all these tricks with `before-change-function' and the like -- we
> could just make the buffer read-only, put the text property on the bits
> that aren't read-only, and we'd be done.  And there would be less user
> confusion.
> 
> I can have a go at implementing this if it sounds like a workable idea,
> although that part of the code is completely unfamiliar to me...

Can you explain once more why putting the read-only property on all
the text except those parts you want to be modifiable is not what you
want?

Re: Inhibiting read-only

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you explain once more why putting the read-only property on all
> the text except those parts you want to be modifiable is not what you
> want?

Because `C-x C-q' doesn't work, and because copying/yanking read-only
text is annoying.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Inhibiting read-only

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@IRO.UMontreal.CA,  cloos@jhcloos.com,  emacs-devel@gnu.org
> Date: Thu, 20 Jun 2013 17:59:20 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can you explain once more why putting the read-only property on all
> > the text except those parts you want to be modifiable is not what you
> > want?
> 
> Because `C-x C-q' doesn't work, and because copying/yanking read-only
> text is annoying.

I don't see why the former would be a problem.  If you really want it
to work, you can bind it to a command that removes the read-only
properties.

As for the latter, can you elaborate about the annoyance, since
read-only is in yank-excluded-properties?

Re: Inhibiting read-only

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't see why the former would be a problem.  If you really want it
> to work, you can bind it to a command that removes the read-only
> properties.

Sure.  But why would we?  A read-only buffer is a simple and
understandable interface that gives us this already.

> As for the latter, can you elaborate about the annoyance, since
> read-only is in yank-excluded-properties?

Oh, is that a new thing?  Then that's not an annoyance (any more).

Having to re-apply properties to ensure that we still are read-only
after inserting text (modulo stickiness) is pretty annoying.

Being able to use a read-only buffer, but have some text be modifiable,
seems like a simple, obvious and symmetrical thing to do.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Inhibiting read-only

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@IRO.UMontreal.CA,  cloos@jhcloos.com,  emacs-devel@gnu.org
> Date: Thu, 20 Jun 2013 19:09:39 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't see why the former would be a problem.  If you really want it
> > to work, you can bind it to a command that removes the read-only
> > properties.
> 
> Sure.  But why would we?  A read-only buffer is a simple and
> understandable interface that gives us this already.

But the read-only buffer doesn't fit your bill, it requires that you
develop a non-trivial infrastructure we currently lack.  Isn't it
better to use existing features instead?

> > As for the latter, can you elaborate about the annoyance, since
> > read-only is in yank-excluded-properties?
> 
> Oh, is that a new thing?

AFAIR, it's very old.

> Having to re-apply properties to ensure that we still are read-only
> after inserting text (modulo stickiness) is pretty annoying.

I don't see the annoyance.  Can you elaborate the difficulties you
envision?

> Being able to use a read-only buffer, but have some text be modifiable,
> seems like a simple, obvious and symmetrical thing to do.

But marking the entire buffer read-only and then using text properties
to inhibit that for some portions of the text sounds wrong to me.
Especially when we already have facilities for making only part of the
text read-only.

Re: Inhibiting read-only

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> But the read-only buffer doesn't fit your bill, it requires that you
> develop a non-trivial infrastructure we currently lack.  Isn't it
> better to use existing features instead?

The "existing way" to do this now is to use `before-change-function',
which is what Customize does.  And it sucks.

>> Having to re-apply properties to ensure that we still are read-only
>> after inserting text (modulo stickiness) is pretty annoying.
>
> I don't see the annoyance.  Can you elaborate the difficulties you
> envision?

Re-applying text properties after massaging the buffer (from some
command) is an annoyance.

> But marking the entire buffer read-only and then using text properties
> to inhibit that for some portions of the text sounds wrong to me.
> Especially when we already have facilities for making only part of the
> text read-only.

Well, we could have facilities for the opposite very easily.  The
commands already look up the `read-only' text property, so all we have
to do is add the proper action for a special value, and Bob should be a
quite close relative soon.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Inhibiting read-only

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@IRO.UMontreal.CA,  cloos@jhcloos.com,  emacs-devel@gnu.org
> Date: Thu, 20 Jun 2013 19:58:04 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But the read-only buffer doesn't fit your bill, it requires that you
> > develop a non-trivial infrastructure we currently lack.  Isn't it
> > better to use existing features instead?
> 
> The "existing way" to do this now is to use `before-change-function',
> which is what Customize does.  And it sucks.

That's one way.  The other is using read-only properties.

> >> Having to re-apply properties to ensure that we still are read-only
> >> after inserting text (modulo stickiness) is pretty annoying.
> >
> > I don't see the annoyance.  Can you elaborate the difficulties you
> > envision?
> 
> Re-applying text properties after massaging the buffer (from some
> command) is an annoyance.

I don't see why.

> > But marking the entire buffer read-only and then using text properties
> > to inhibit that for some portions of the text sounds wrong to me.
> > Especially when we already have facilities for making only part of the
> > text read-only.
> 
> Well, we could have facilities for the opposite very easily.  The
> commands already look up the `read-only' text property, so all we have
> to do is add the proper action for a special value, and Bob should be a
> quite close relative soon.

I see you cannot be convinced, so I will shut up.

Re: Inhibiting read-only

[Stephen J. Turnbull]

Lars Magne Ingebrigtsen writes:

 > Oh, is [yank-excluded-properties] a new thing?  Then that's not an
 > annoyance (any more).

Are you sure this wasn't just an annoyance for XEmacs users?  We don't
have yank-excluded-properties yet.[1]  It's up to you whether to care
about XEmacs or not, of course, I'm just providing information.


Footnotes: 
[1]  In theory XEmacs handles this by using non-copyable extents.  In
practice the text-property interface is used a lot so we should add
this feature.  But it won't happen tomorrow.