Variable number of newlines before responses #599
Conversation
Can you give me an example? |
|
My headings have line-spacing and line-height already, so empty lines are extraneous. I realize terminal users will prefer newlines all the time and prioritize plain-text readability, but it's Emacs and we make different choices. |
|
Values of 0, 1 and 2 newlines make sense here. Maybe this can be specified more generally as a string? Like
FWIW, I don't think it's a good idea to make user prompts headings, at least in Org mode. You end up bundling unrelated semantic aspects of the document, and features like context restriction to headings and The default prompt prefix remains a heading for historical reasons. Aside: Adjusting the spacing is also something you can easily do in (defun gptel-adjust-spacing (beg _end)
(save-excursion
(goto-char beg)
(when (looking-back "\n\n" (- (point) 2))
(delete-char -1))))
(add-hook 'gptel-post-response-functions #'gptel-adjust-spacing) |
To the extent that it's true, it's another example of displaying a view fighting against the view being literal context. It's a good example case for needing a 'gptel-ignore text property. If my request and response headings are ignored, it doesn't matter. But I do also see the case for the branching context. For now I'm using 2nd and 3rd level headings for my context. Because the model is mimicking the input, it occasionally throws out a first level heading, which would break the tree. I have suppressed this in the system prompt, but 4o-mini just loves to ape whatever is in context.
I agree. I'll re-work it as such. |
Yes, this is why branching context is disabled by default -- if you turn it on, you know what you're doing. |
|
|
This pulls out the double-newlines that separate request from response and allow customization. With fancy graphical headings, empty lines are unneeded and actually quite bad.
|
Thanks for the PR! |
This pulls out the double-newlines that separate request from response and allow customization. With fancy graphical headings, empty lines are unneeded and actually quite bad.
With fancy graphical headings, empty lines are unneeded and actually quite bad.
I can't imagine anyone wants values other than 1 or 2. Maybe this should be...
`gptel-response-blank-line'?
I can rework it. Probably the right way to decide is "what will users recognize on first glance?"