Claudio Bley 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).