Controling modifications and cuting invisible ?

Controling modifications and cuting invisible ?

[François Fleuret]

Hi people,

My mode to control mpg321 is definitely usable now (I just posted it
in gnu.emacs.sources), but several problems remain.

The first one is: how to control precisely how the buffer can be
modified ? So far, the only way I found was to clear the keymap with
make-sparse-keymap, and redefine any single key remaining that can
change something (i.e. ^j ^d etc.). This seems pretty dumb to me. What
would be the "stylish" way ?

Also, I use the invisible attribute to hide data field in each line
(basically the filename associated to a mp3), so that I can use those
field when I invoke mpg321, while keeping a neat display for the
user. This works pretty well, but for a reason I do not understand,
cut/paste operation do not preserve this attribute ... Any clue ?

And the last one: I use an overlay to highlight the current mp3. This
is neat, but I was not able to find how to make the overlay to cover
the complete line (i.e. all the width, even if the line stops before),
without creating weird effect when the user modifies the
buffer. Basically, to make the overlay as large as the window, I used
something like:

(move-overlay mp3play-current-overlay (point-at-bol) (1+ (point-at-eol)))

the 1+ puting the \n in the overlay. This works as long as I do not
move a line accross the overlay with the following code:

(transpose-regions (line-beginning-position) (1+ (line-end-position))
                   (line-beginning-position 2) (1+ (line-end-position 2)))

Doing that make the overlay include the line I am moving ...

Any piece of answer for any of those question will be welcome :)

Regards,

--
François Fleuret

Re: Controling modifications and cuting invisible ?

[Stefan Monnier]

> The first one is: how to control precisely how the buffer can be
> modified ? So far, the only way I found was to clear the keymap with
> make-sparse-keymap, and redefine any single key remaining that can
> change something (i.e. ^j ^d etc.). This seems pretty dumb to me. What
> would be the "stylish" way ?

How about (setq buffer-read-only t) ?
You can also unbind C-x C-q so that people can't easily change the
read-only status.  If you want to be nastier, you can also use
the `read-only' text-property.  And if you really want to get nasty, you
can add to that the keymap trick you're already using plus
`modification-hooks', `insert-in-front-hooks' and `insert-behind-hooks'
text-properties plus an overlay with the same properties.  Oh and you can
also add some `keymap' and `local-map' properties with the keymap
you've devised.  That should keep the nasty guys out ;-)

> Also, I use the invisible attribute to hide data field in each line
> (basically the filename associated to a mp3), so that I can use those
> field when I invoke mpg321, while keeping a neat display for the
> user. This works pretty well, but for a reason I do not understand,
> cut/paste operation do not preserve this attribute ... Any clue ?

How do you add the attribute ?  I'd guess you're using overlays (which are
not really associated with the text but only with the locations).
If you use text-properties and it doesn't work, then you'll need to
give us more info so we can figure out what's wrong.

> And the last one: I use an overlay to highlight the current mp3. This
> is neat, but I was not able to find how to make the overlay to cover
> the complete line (i.e. all the width, even if the line stops before),
> without creating weird effect when the user modifies the
> buffer. Basically, to make the overlay as large as the window, I used
> something like:
> 
> (move-overlay mp3play-current-overlay (point-at-bol) (1+ (point-at-eol)))

BTW (1+ (point-at-eol)) is the same as (point-at-bol 2), except when
(point-at-eol) == (point-max).

> the 1+ puting the \n in the overlay. This works as long as I do not
> move a line accross the overlay with the following code:
> 
> (transpose-regions (line-beginning-position) (1+ (line-end-position))
>                    (line-beginning-position 2) (1+ (line-end-position 2)))
> 
> Doing that make the overlay include the line I am moving ...

As mentioned, overlays are not associated with the text but only with
locations.  `transpose-regions' will remove some text from one place and
insert it at some other place, but Emacs has no idea that it's the same text
and that the overlay should be moved with it.  If you use text-properties,
it should work better (but it has other problems for this kind of use).

I suggest that you simply reset the overlay after each command.
Or better yet, just use hl-line-mode (or some other such mode, there are
plenty) which do nothing else than "mark the current line with an overlay".

> Any piece of answer for any of those question will be welcome :)

Tout le plaisir était pour moi,


        Stefan

Re: Controling modifications and cuting invisible ?

[Lute Kamstra]

François Fleuret <francois.fleuret@noos.fr> writes:

[...]

> The first one is: how to control precisely how the buffer can be
> modified ? So far, the only way I found was to clear the keymap with
> make-sparse-keymap, and redefine any single key remaining that can
> change something (i.e. ^j ^d etc.). This seems pretty dumb to me. What
> would be the "stylish" way ?

Make the buffer read only?  

  (setq buffer-read-only t)

Lute.

-- 
(spook) => "smuggle anarchy NATO"
(insert-file-contents "~/.signature") => (error "`~/.signature' too rude")

Re: Controling modifications and cuting invisible ?

[Kai Großjohann]

François Fleuret <francois.fleuret@noos.fr> writes:

> The first one is: how to control precisely how the buffer can be
> modified ? So far, the only way I found was to clear the keymap with
> make-sparse-keymap, and redefine any single key remaining that can
> change something (i.e. ^j ^d etc.). This seems pretty dumb to me. What
> would be the "stylish" way ?

suppress-keymap

-- 
This line is not blank.

Re: Controling modifications and cuting invisible ?

[François Fleuret]

Hi,

Kai Großjohann wrote on 22 May 2003 17:33:48 MET:

> suppress-keymap

>From what I observe, even after a suppress-keymap, many keys can still
modify the buffer (like ^j, ^d, TAB, etc.) From the documentation,
suppress-keymap removes all self-inserting keys. My problem is that I
want to remove *all* keys which can alter the buffer, while keeping
usual keys (of course) to switch buffer, move windows, etc.

It seems that what people usually do to control how the buffer cna be
altered (after a quick look at gnus, vm, rmail etc.) consists in
remaping all key one by one ...

Regards,

-- 
François Fleuret

Re: Controling modifications and cuting invisible ?

[Oliver Scholz]

François Fleuret <francois.fleuret@noos.fr> writes:
[...]
> My problem is that I want to remove *all* keys which can alter the
> buffer, while keeping usual keys (of course) to switch buffer, move
> windows, etc.

I'd say the usual way to do this is to make the buffer read-only:

(setq buffer-read-only t)

Then commands or functions that are supposed to modify the content of
the buffer can do this by binding `inhibit-read-only' temporarily to
t:

(let ((inhibit-read-only t))
  ...
  (modify-the-buffer-contents)
  ...
  )


    Oliver
-- 
4 Prairial an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: Controling modifications and cuting invisible ?

[Oliver Scholz]

François Fleuret <francois.fleuret@noos.fr> writes:
[...]
> Also, I use the invisible attribute to hide data field in each line
> (basically the filename associated to a mp3), so that I can use those
> field when I invoke mpg321, while keeping a neat display for the
> user. This works pretty well, but for a reason I do not understand,
> cut/paste operation do not preserve this attribute ... Any clue ?

I'd rather consider this as a feature. When I copy&paste ... erm ...
kill-ring-save&yank something from a buffer, I don't want to be
surprised by invisible text.

> And the last one: I use an overlay to highlight the current mp3. This
> is neat, but I was not able to find how to make the overlay to cover
> the complete line (i.e. all the width, even if the line stops before),
> without creating weird effect when the user modifies the
> buffer. Basically, to make the overlay as large as the window, I used
> something like:
>
> (move-overlay mp3play-current-overlay (point-at-bol) (1+ (point-at-eol)))
>
> the 1+ puting the \n in the overlay. This works as long as I do not
> move a line accross the overlay with the following code:
>
> (transpose-regions (line-beginning-position) (1+ (line-end-position))
>                    (line-beginning-position 2) (1+ (line-end-position 2)))
>
> Doing that make the overlay include the line I am moving ...

IIRC a overlay is implemented with markers or something similar. (But
I have not read the code, so I may be wrong.) So there is no way but
to update your overlay after `transpose-region', for example with
`move-overlay'.

    Oliver
-- 
4 Prairial an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: Controling modifications and cuting invisible ?

[Stefan Monnier]

>>>>> "FF" == François Fleuret <francois.fleuret@noos.fr> writes:
> It seems that what people usually do to control how the buffer cna be
> altered (after a quick look at gnus, vm, rmail etc.) consists in
> remaping all key one by one ...

You got the relation going in the wrong way: they do the rebinding because
the default ones don't work anyway (because they made the buffer
read-only), so they replace them with something more useful.


        Stefan