Feature suggestion: Alternative setting to use a separator string to visually indicate the separation of headers and body

[ikenichiro]

Description

This is an feature suggestion of using a identical separator text which looks like a horizontal line instead of a blank line to separate the header and body.

This improves the simplicity to visually understand the separator, preventing accidental operation in deleting the separator (which leads to loosing all the editing data upon closing the editor). I understand blank lines are comfortable too, so instead of replacing the current idea using a blank line, maybe introducing an checkbox option to use a separator would be nice.

For example, previous external-editor had a line something like -=-=-=-=-=-=-=-=-=#DontRemoveThisLine#=-=-=-=-=-=-=-=-=- Having something like this which could be identified as a horizontal line, gives clear visual information of where the header and body separates which for me is very helpful when composing an e-mail.

Although the previous external-editor used the word DontRemoveThisLine, I think it could be something else like BodyStartsAfterThisLine, but I won't argue with word choices, furthermore, it looked like the text was probably translated based on locale setting, but I don't think that would be necessary since having a visual information of something indicating a separator is enough instead of the need of reading it as a sentence. However some kind of unique text should be used within the separator since a lot of people use all kinds of fancy separator between their e-mail body and signature, which may match this extensions separator by coincidence, which would leading to a potential bug/issue.

---

Information about Environment, Configuration, Logs, Screenshots are omitted because this is a feature suggestion instead of a bug

[Frederick888]

Thanks for the suggestion. But I don't think we should do this.

EER can do a lot of things. However not everything is EER's responsibility. This particular issue is about presentation, and therefore should be taken care of by the presentation layer, i.e. the editors.

For example, here's a Neovim script I've been using:

local M              = {}
local api            = vim.api

local MAX_SCAN_LINES = 50
local NAMESPACE      = 'eml-separator'

function M.first_empty_line(bufnr)
  local lines = api.nvim_buf_get_lines(bufnr, 0, MAX_SCAN_LINES, false)
  for i, l in ipairs(lines) do
    if l:len() == 0 then
      return i - 1
    end
  end
  return nil
end

local namespace_id = nil
local function get_namespace()
  if namespace_id ~= nil then
    return namespace_id
  end
  namespace_id = api.nvim_create_namespace(NAMESPACE)
  return namespace_id
end

local extmark_id = nil
---@diagnostic disable-next-line: unused-local
function M.draw_eml_separator(ev, winid, bufnr)
  local ns_id = get_namespace()
  local empty_line = M.first_empty_line(bufnr)
  if empty_line == nil then
    if extmark_id ~= nil then
      api.nvim_buf_del_extmark(bufnr, ns_id, extmark_id)
      extmark_id = nil
    end
    return
  end
  local highlight = api.nvim_get_hl_id_by_name('Identifier')
  local extmark_opts = {
    virt_text = { { ('~'):rep(17) .. ' Header-Body Separator, Do NOT Delete ' .. ('~'):rep(17), highlight } },
    hl_mode = 'blend',
    virt_text_pos = 'overlay',
    ephemeral = true,
  }
  if extmark_id ~= nil and extmark_id > 0 then
    extmark_opts['id'] = extmark_id
  end
  extmark_id = api.nvim_buf_set_extmark(bufnr, ns_id, empty_line, 0, extmark_opts)
end

function M.setup()
  api.nvim_create_autocmd({ "FileType" }, {
    pattern = { "mail" },
    callback = function()
      local ns_id = get_namespace()
      api.nvim_set_decoration_provider(ns_id, { on_win = M.draw_eml_separator, })
    end
  })
end

return M

https://github.com/Frederick888/external-editor-revived/assets/4507647/d23daed9-cb9d-4b5c-a2d9-3dd61994559c

I used Neovim's 'extended mark' feature and as you can see, it works much better than an actual separator line. It moves itself automatically to the first blank line, and we don't need to worry about it messing with Neovim's EML highlighting. So really I don't think it's EER's job and it cannot do a decent job about this anyway.