Two new idea to improve efficiency

[Kingxukai]

During use, I found two areas that could be improved:

1. When browsing and wanting to edit a document, I find that when switching to the editor (vim), it doesn’t go to the corresponding section, but instead starts from the beginning.
2. There are no direct shortcuts to jump to the top or bottom, like the g or G commands in less.

Do you think these are worth to implement? Thanks for your contribute^_^

[davep]

1. Anyone could use any possible editor that exists; it's kind of hard to know how that information would be provided.
2. Home and End are direct shortcuts for that; but I'm happy to add other shortcuts while in the markdown document itself as long as they don't clash with anything else. Added Add vim/less-friendly bindings for going home/end #80 (and in turn Add vim/less-friendly home/end bindings to EnhancedVerticalScroll textual-enhanced#39 as that's where the change will need to be made).

[Kingxukai]

https://github.com/search?q=repo%3Acharmbracelet%2Fglow%20EDITOR&type=code
Maybe can refer what glow do

[davep]

I'm afraid I don't understand what that's supposed to be showing me; I don't see anything relevant there.

The point is though: there are more editor choices that I can possibly know; each with their own command lines and communication protocols, etc. I've taken the standard Unix route of using $VISUAL if it is defined, if not then using $EDITOR -- this is a very common approach.

Now, I could add an option that sits between $VISUAL/$EDITOR and the built-in editor and have something that is format-expanded, providing values such as the top line visible, that sort of thing; but there's a problem there too: there is very little relationship between the rendered version of a Markdown document and its source. Someone could write a Markdown document that is rendered as 1,000 lines, but it's all on a single line in the source.

[Kingxukai]

I see, perhaps create a branch to retrieve the line info only when using popular editors like Vim or Emacs; otherwise, skip it. Does it possible?
And about the issue of many characters being displayed on a single line,
I think the slider solution can be continued used;
Alternatively, Hike could adopt a method of displaying the number of line jumps without actually increasing the line count (though I’m not sure if this approach is feasible).
Additionally, could an option to display line numbers be added?

[davep]

I see, perhaps create a branch to retrieve the line info only when using popular editors like Vim or Emacs; otherwise, skip it.

I'm not quite sure what you mean by "create a branch" here. Honestly, I don't really like the idea of making special-cases for particular editors when there's the long-standing standard of using VISUAL and EDITOR.

I think the slider solution can be continued used;

I don't think I know what "the slider solution" means here.

Additionally, could an option to display line numbers be added?

Probably not without dumping the use of Textual's Markdown widget and building my own from scratch. Again, it's worth keeping in mind that there is no relationship between the number of lines that are rendered on the screen vs the number of the line that a particular item of text comes from in the source document. For example, consider these 3 different views of the exact same document:

Exact same Markdown document, very different line counts, etc.

I'll keep it in mind but I don't see this as been something I'd look to tackle any time soon as it doesn't really seem to have that much utility and is, to some degree, antithetical to the idea of a markdown viewer (which is all about rendering the result, not bothering about the source).

[davep]

There's now a new release that adds some extra keys for home/end movement within the markdown document (amongst other things).

[Kingxukai]

Get it! Well done.