Claudio Bley <
claudio.bley@googlemail.com> writes:
> At Tue, 19 Nov 2013 03:24:02 -0500,
> Glenn Morris wrote:
>>
>> Claudio Bley wrote:
>>
>> > I think the regexp should be changed to "\\`\(.\|\n\)\\'" to allow a
>> > single newline also.
>>
>> We already tried that once; it caused more problems than it solved:
>>
http://debbugs.gnu.org/2689>
> I see. So lets get this solved.
>
> At first, changing the regexp is just the right thing to do and
> in itself, IMO, does not break anything.
Indeed.
> Alas, it does not solve the problem at hand because
> `widget-specify-field' behaves /badly/ when the field ends with a
> newline.
>
> So, actually, this hunk of your patch trying to work around
> this behaviour broke other things.
[...]
> How about using a special :value-create function for character fields?
I don't think that's needed.
> Furthermore, the presentation of the character values is bad,
> usability-wise, because for nonprintable chars you cannot see what
> value the field actually has.
>
> How about displaying those chars in the buffer in another format?
> E.g. use escape sequences like \n \r et cetera?
Or we could do what Isearch does, and display TAB as ^I, and so on.
> I (rather hackish) way to fix this would be to always insert a ?\n
> as part of the value of a character field:
>
> (defun widget-field-char-create (widget)
> "Create an editable character field."
> (let ((value (widget-get widget :value))
> (from (point))
> ;; This is changed to a real overlay in `widget-setup'. We
> ;; need the end points to behave differently until
> ;; `widget-setup' is called.
> (overlay (cons (make-marker) (make-marker))))
> (widget-put widget :field-overlay overlay)
> (insert value)
> (insert ?\n) ;; EEEK
> (unless (memq widget widget-field-list)
> (setq widget-field-new (cons widget widget-field-new)))
> (move-marker (cdr overlay) (point))
> (set-marker-insertion-type (cdr overlay) nil)
> (insert ?\n)
> (move-marker (car overlay) from)
> (set-marker-insertion-type (car overlay) t)))
>
> What do you think?
I don't think this is needed.
I attach a patch that should fix this (but that does not change the
way the characters are displayed) and that doesn't introduce the
breakage of Bug#3136 (for which I added a test).
0001-Allow-the-newline-character-in-the-character-widget-.patch