New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Advertise Kakoune #249

Closed
mawww opened this Issue Feb 10, 2015 · 24 comments

Comments

Projects
None yet
@mawww
Owner

mawww commented Feb 10, 2015

Hello Kakoune users,

I feel Kakoune is now quite mature, with no major feature missing. It seems the interaction interface is good enough for most of the use cases I thrown at it, with a good example being clang.kak providing code completion and syntastic like diagnostics in ~120 lines.

We have basic syntax highlighting for most common programming language (perl being the main lacking one), reasonable make and grep interaction, even a proof of concept YouCompleteMe support script (https://github.com/mawww/kak-ycmd) .

All that to say, I think it is now time to try to get more users, and hence more use cases.

This issue is there to list the different things that would help Kakoune get noticed, and hopefully attract users.

Off the top of my head:

  • A website
  • An Icon/Logo
  • A new demonstration video/gif demonstrating the most impressive features
  • An equivalent to vimtutor to help newcomers understand how Kakoune works
  • Posting about Kakoune on different news site
  • getting Kakoune reviewed by a Vim news site, http://usevim.com talked about Kakoune a while ago, but nothing in depth (@alexyoung Hello !)
  • neovim/neovim#211 it seems there is some demand for a multiselection supporting vim-like. Maybe advertise Kakoune to the people asking for multiple carrets there (@Ivanca, @FelikZ greetings !)
  • Get some feedback on what Kakoune is missing, what are the pain points.

Any additional idea/comments ?

Cheers,

Maxime.

@dumblob

This comment has been minimized.

Show comment
Hide comment
@dumblob

dumblob Feb 11, 2015

Just for reference, I made this info public in (sorry, it's not in English - let the Google translate be your companion 😃):
http://www.root.cz/zpravicky/kakoune-novy-textovy-editor-inspirovany-vimem/
http://www.abclinuxu.cz/zpravicky/kakoune-novy-textovy-editor-inspirovany-vimem

Regarding additional ideas - I have actually a feature-request list already cca half a year old as I was afraid to propose it too early. Here you are:

  1. show detected file type
  2. set paste (using \ before entering insert mode will disable hooks during the whole insert session?)
  3. set wrap
  4. vsplit (without tmux?) + easy copying, switching etc. between the windows
  5. jump to function decl
  6. jump to matching parenthesis/brace/bracket/...
  7. auto-enclosure of parenthesis/braces/brackets/...
  8. highlight matching parenthesis/brace/bracket/...
  9. loop over last 3 significant cursor positions (in Vim it's double-apostrophe '' which loops over only 2 such positions)
  10. (auto)folding + expansion for markup languages (Markdown, Asciidoc, ...)
  11. highlight non-ASCII characters by default and add some prefix character like ^
  12. clipboard (copy_to yanked text and paste_from - see neovim/neovim#1822)

Already reported/planned somewhere:

I. restore session after opening (cursor position, search history, command history)
II. kakdiff - really important feature deserving priority raising :)

dumblob commented Feb 11, 2015

Just for reference, I made this info public in (sorry, it's not in English - let the Google translate be your companion 😃):
http://www.root.cz/zpravicky/kakoune-novy-textovy-editor-inspirovany-vimem/
http://www.abclinuxu.cz/zpravicky/kakoune-novy-textovy-editor-inspirovany-vimem

Regarding additional ideas - I have actually a feature-request list already cca half a year old as I was afraid to propose it too early. Here you are:

  1. show detected file type
  2. set paste (using \ before entering insert mode will disable hooks during the whole insert session?)
  3. set wrap
  4. vsplit (without tmux?) + easy copying, switching etc. between the windows
  5. jump to function decl
  6. jump to matching parenthesis/brace/bracket/...
  7. auto-enclosure of parenthesis/braces/brackets/...
  8. highlight matching parenthesis/brace/bracket/...
  9. loop over last 3 significant cursor positions (in Vim it's double-apostrophe '' which loops over only 2 such positions)
  10. (auto)folding + expansion for markup languages (Markdown, Asciidoc, ...)
  11. highlight non-ASCII characters by default and add some prefix character like ^
  12. clipboard (copy_to yanked text and paste_from - see neovim/neovim#1822)

Already reported/planned somewhere:

I. restore session after opening (cursor position, search history, command history)
II. kakdiff - really important feature deserving priority raising :)

@mawww

This comment has been minimized.

Show comment
Hide comment
@mawww

mawww Feb 11, 2015

Owner
  1. show detected file type: well you can using :echo %opt{filetype} but I guess you mean in the status line, in which case that might require a more general status line customization system.
  2. yep \ before entering insert mode will disable hooks for this insert session (\ before any command disable hooks for the command) so that replace vim's :set paste
  3. line wrapping highlighter is still missing
  4. vsplit, use tmux or your x11 window manager for that. :new will create a window, using a vsplit by default in tmux, or just a new terminal under x11. Integrated window management is a non goal, however with tmux (and x11 if you have xdotool installed), Kakoune is already able to switch focus to a given client (see make.kak or grep.kak for example)
  5. ctags.kak provides jump to function decl for most languages, it requires the readtags command (available in exuberant ctags source, but not installed by default). the https://github.com/fishman/ctags version already install it by default and will probably become the official exuberant ctags soon.
  6. m does jump to matching char.
  7. You mean auto insertion of the closing paren when you insert the opening one ? very easy to do with a hook :hook buffer InsertChar \( 'exec )<left>'
  8. the show_matching highlighter does that, enable it for all windows with hook global WinCreate .* %{ addhl show_matching } in you kakrc
  9. not sure what you mean, <c-s> saves push the current selection on the jump list, <c-i> goes forward in it, <c-o> backward.
  10. folding is still missing
  11. invalid utf8 already gets highlighted
  12. clipboard communication with the OS should be quite easy with a few hooks. I actually use these mapping on my work (cygwin based) machine:
map global user y '<a-|>putclip<ret>:echo -color Information "yanked to win32 clipboard"<ret>'
map global user p '<a-!>getclip<ret>:echo -color Information "pasted from win32 clipboard"<ret>'
map global user P '!getclip<ret>:echo -color Information "pasted from win32 clipboard"<ret>'
map global user R ':reg w "%sh{getclip}"<ret>"wR:echo -color Information "replaced from win32 clipboard"<ret>'

I. restore session is not supported, however on crash, kakoune will try to save all modified buffers to .${buf_name}.kak.XXXXXX
II. yep, kakdiff is totally missing as it depends on something similar to folding.

So to recap, what is really missing here is:

  • line wrapping highlighter
  • folding
  • diffing interface
  • status line customization

Thanks a lot for your feedback !

Owner

mawww commented Feb 11, 2015

  1. show detected file type: well you can using :echo %opt{filetype} but I guess you mean in the status line, in which case that might require a more general status line customization system.
  2. yep \ before entering insert mode will disable hooks for this insert session (\ before any command disable hooks for the command) so that replace vim's :set paste
  3. line wrapping highlighter is still missing
  4. vsplit, use tmux or your x11 window manager for that. :new will create a window, using a vsplit by default in tmux, or just a new terminal under x11. Integrated window management is a non goal, however with tmux (and x11 if you have xdotool installed), Kakoune is already able to switch focus to a given client (see make.kak or grep.kak for example)
  5. ctags.kak provides jump to function decl for most languages, it requires the readtags command (available in exuberant ctags source, but not installed by default). the https://github.com/fishman/ctags version already install it by default and will probably become the official exuberant ctags soon.
  6. m does jump to matching char.
  7. You mean auto insertion of the closing paren when you insert the opening one ? very easy to do with a hook :hook buffer InsertChar \( 'exec )<left>'
  8. the show_matching highlighter does that, enable it for all windows with hook global WinCreate .* %{ addhl show_matching } in you kakrc
  9. not sure what you mean, <c-s> saves push the current selection on the jump list, <c-i> goes forward in it, <c-o> backward.
  10. folding is still missing
  11. invalid utf8 already gets highlighted
  12. clipboard communication with the OS should be quite easy with a few hooks. I actually use these mapping on my work (cygwin based) machine:
map global user y '<a-|>putclip<ret>:echo -color Information "yanked to win32 clipboard"<ret>'
map global user p '<a-!>getclip<ret>:echo -color Information "pasted from win32 clipboard"<ret>'
map global user P '!getclip<ret>:echo -color Information "pasted from win32 clipboard"<ret>'
map global user R ':reg w "%sh{getclip}"<ret>"wR:echo -color Information "replaced from win32 clipboard"<ret>'

I. restore session is not supported, however on crash, kakoune will try to save all modified buffers to .${buf_name}.kak.XXXXXX
II. yep, kakdiff is totally missing as it depends on something similar to folding.

So to recap, what is really missing here is:

  • line wrapping highlighter
  • folding
  • diffing interface
  • status line customization

Thanks a lot for your feedback !

@dumblob

This comment has been minimized.

Show comment
Hide comment
@dumblob

dumblob Feb 13, 2015

3 . line wrapping highlighter should also support a customization of the indentation width (by default the same as indentwidth?)
6. right, I missed it in the source code (it's missing in the README file)
7. yes, I meant auto-insertion and auto-deletion (only in case, the two characters are immediately next to each other) - e.g. probably something like :hook buffer InsertChar <backspace> 'exec ???only_if_it_was_opening_brace_and_the_character_on_the_right_side_is_a_closing_brace???<right><backspace>' (hope that it's not recursive)
8. don't know why, but show_matching doesn't highlight anything for me after putting the hook to my kakrc
9. yes, that's what I meant, but cyclic <c-i> <c-o> and limited to only a small number of items (user-configurable)
11. actually, I meant highlighting all ASCII characters, which don't have a clearly visible glyph representation (i.e. all non-printable characters except for a) HT and b) depending on the file type either LF or CRLF) using caret notation and/or color highlighting.
I. restore session is discussed in #74; but the unsaved file content recovery is an absolute must - it happens surprisingly often to close accidentaly window or experience failed wake-up from hibernation etc.

Thanks for your patience!

dumblob commented Feb 13, 2015

3 . line wrapping highlighter should also support a customization of the indentation width (by default the same as indentwidth?)
6. right, I missed it in the source code (it's missing in the README file)
7. yes, I meant auto-insertion and auto-deletion (only in case, the two characters are immediately next to each other) - e.g. probably something like :hook buffer InsertChar <backspace> 'exec ???only_if_it_was_opening_brace_and_the_character_on_the_right_side_is_a_closing_brace???<right><backspace>' (hope that it's not recursive)
8. don't know why, but show_matching doesn't highlight anything for me after putting the hook to my kakrc
9. yes, that's what I meant, but cyclic <c-i> <c-o> and limited to only a small number of items (user-configurable)
11. actually, I meant highlighting all ASCII characters, which don't have a clearly visible glyph representation (i.e. all non-printable characters except for a) HT and b) depending on the file type either LF or CRLF) using caret notation and/or color highlighting.
I. restore session is discussed in #74; but the unsaved file content recovery is an absolute must - it happens surprisingly often to close accidentaly window or experience failed wake-up from hibernation etc.

Thanks for your patience!

@p0nce p0nce referenced this issue Mar 7, 2015

Merged

Logo proposal. #253

@xificurC

This comment has been minimized.

Show comment
Hide comment
@xificurC

xificurC Jun 7, 2015

Contributor

Hi there, first let me say I'm enjoying using kakoune a lot and wish it good luck conquering the world! :)
I'd have a few questions/suggestions:

  1. New title. I think experiment should be dropped and a short and interesting title picked. Example ideas:
    There's a new vi in town
    Vi in less keystrokes
    Text editor for the 21st century
    The simple, fast and efficient text editor
  2. Paging. <c-f> and <c-b> work but are not documented in the readme. Maybe <c-d> and <c-u> could be implemented as well?
  3. Edit directory. I'd expect to find myself in the current buffer's directory upon pressing :e.
    E.g. if I start kakoune in ~ and :e code/cpp/kakoune/rc/c-family.kak upon next :e I'd expect to be in code/cpp/kakoune/rc but I find myself in ~.
  4. Go to line begin/end. Since e.g. both <a-l> and gl select to line end couldn't one of them go there without selecting?
    This would reduce key strokes in some cases (e.g. <a-l>li or <a-l>;i would become <a-l>i.
    For me it makes sense to have both instead of having 2 mappings for one.
  5. Highlighter show_matching doesn't seem to be working.
  6. Map only for keys. Would/is it possible to map commands to keys?
  7. Search selection with * could show as information what is the search pattern that is being saved.
  8. Some commands (e.g. onkey) use registers to store information. Is there or could there be a hidden register for such commands?
    What register should I use to store something? If it is publicly available my code could mess up someone's register if one happens to use the same the command did.
    This is unhygienic.
  9. Prioritize folding and diffing. These are commonly used in other editors and new users will be looking and asking for them.
  10. Plugins. New users will be looking for a surround, paredit, powerline, snipmate/yasnippet, fugitive/magit clone
    (although I'd expect users to start working on this).

That's all from the past 2 days, I'm sure more will come as I start using the editor more.
Best of luck and thanks for this great project!

Contributor

xificurC commented Jun 7, 2015

Hi there, first let me say I'm enjoying using kakoune a lot and wish it good luck conquering the world! :)
I'd have a few questions/suggestions:

  1. New title. I think experiment should be dropped and a short and interesting title picked. Example ideas:
    There's a new vi in town
    Vi in less keystrokes
    Text editor for the 21st century
    The simple, fast and efficient text editor
  2. Paging. <c-f> and <c-b> work but are not documented in the readme. Maybe <c-d> and <c-u> could be implemented as well?
  3. Edit directory. I'd expect to find myself in the current buffer's directory upon pressing :e.
    E.g. if I start kakoune in ~ and :e code/cpp/kakoune/rc/c-family.kak upon next :e I'd expect to be in code/cpp/kakoune/rc but I find myself in ~.
  4. Go to line begin/end. Since e.g. both <a-l> and gl select to line end couldn't one of them go there without selecting?
    This would reduce key strokes in some cases (e.g. <a-l>li or <a-l>;i would become <a-l>i.
    For me it makes sense to have both instead of having 2 mappings for one.
  5. Highlighter show_matching doesn't seem to be working.
  6. Map only for keys. Would/is it possible to map commands to keys?
  7. Search selection with * could show as information what is the search pattern that is being saved.
  8. Some commands (e.g. onkey) use registers to store information. Is there or could there be a hidden register for such commands?
    What register should I use to store something? If it is publicly available my code could mess up someone's register if one happens to use the same the command did.
    This is unhygienic.
  9. Prioritize folding and diffing. These are commonly used in other editors and new users will be looking and asking for them.
  10. Plugins. New users will be looking for a surround, paredit, powerline, snipmate/yasnippet, fugitive/magit clone
    (although I'd expect users to start working on this).

That's all from the past 2 days, I'm sure more will come as I start using the editor more.
Best of luck and thanks for this great project!

@jkonecny12

This comment has been minimized.

Show comment
Hide comment
@jkonecny12

jkonecny12 Jun 8, 2015

Contributor
  1. Edit directory. I'd expect to find myself in the current buffer's directory upon pressing :e.
    E.g. if I start kakoune in ~ and :e code/cpp/kakoune/rc/c-family.kak upon next :e I'd expect to be in code/cpp/kakoune/rc but I find myself in ~.

IMHO I think this is good behavior I think it's more meaningful to open kakoune in one place and open files from this one place instead of moving it between places. I'm seeing this as good behavior mostly for programming where you open root folder src and opening files from there instead of thinking where I must go from this position...

  1. Go to line begin/end. Since e.g. both and gl select to line end couldn't one of them go there without selecting?

I have the same opinion but I thought that I missed some keys.

  1. Map only for keys. Would/is it possible to map commands to keys?

I'm using this in my kakrc and it's working like a charm.
map global user n ':eval %{nextbuffer}<ret>'
in other words, you have eval mechanism for this.


I would like to add one question. I was trying to create my highlighter (I will add it to repository when it's done) but I find out that almost every highlighter using instead of color names some inner variables like meta ,value... but I didn't find that in documentation and they are not highlighted as colors.
Are these variables for common use and if they are please add them to documentation.

Thank you @mawww it's really super editor ;).

Contributor

jkonecny12 commented Jun 8, 2015

  1. Edit directory. I'd expect to find myself in the current buffer's directory upon pressing :e.
    E.g. if I start kakoune in ~ and :e code/cpp/kakoune/rc/c-family.kak upon next :e I'd expect to be in code/cpp/kakoune/rc but I find myself in ~.

IMHO I think this is good behavior I think it's more meaningful to open kakoune in one place and open files from this one place instead of moving it between places. I'm seeing this as good behavior mostly for programming where you open root folder src and opening files from there instead of thinking where I must go from this position...

  1. Go to line begin/end. Since e.g. both and gl select to line end couldn't one of them go there without selecting?

I have the same opinion but I thought that I missed some keys.

  1. Map only for keys. Would/is it possible to map commands to keys?

I'm using this in my kakrc and it's working like a charm.
map global user n ':eval %{nextbuffer}<ret>'
in other words, you have eval mechanism for this.


I would like to add one question. I was trying to create my highlighter (I will add it to repository when it's done) but I find out that almost every highlighter using instead of color names some inner variables like meta ,value... but I didn't find that in documentation and they are not highlighted as colors.
Are these variables for common use and if they are please add them to documentation.

Thank you @mawww it's really super editor ;).

@xificurC

This comment has been minimized.

Show comment
Hide comment
@xificurC

xificurC Jun 8, 2015

Contributor

I'm seeing this as good behavior mostly for programming where you open root folder src and opening files from there instead of thinking where I must go from this position...

I guess everyone has a different approach :) I often launch kak from home and open files from within it instead of cding to the right place first. That leaves me retyping the path/to/src everytime. Also this doesn't scale well if you want to open 2-3 projects from different places, then you'll be really lost. I just realized that this could be implemented through hooks on WinCreate/WinDisplay with cd, so I'll play around with that. I still think this would be a more reasonable default, but that's just my opinion.

I'm using this in my kakrc and it's working like a charm.
map global user n ':eval %{nextbuffer}<ret>'
in other words, you have eval mechanism for this.

I see, thanks for that!

I find out that almost every highlighter using instead of color names some inner variables like meta ,value ...

I might be wrong ( @mawww correct me if I am ) but if you look at share/kakrc you'll see some default faces being defined, like value, comment etc. These faces are used in rc/your-language.kak to define highlighting. With this setup you can change the color scheme easily since all language highlighters are using the same faces. In short you should be using these faces for highlighting your language instead of baking in some colors.

Contributor

xificurC commented Jun 8, 2015

I'm seeing this as good behavior mostly for programming where you open root folder src and opening files from there instead of thinking where I must go from this position...

I guess everyone has a different approach :) I often launch kak from home and open files from within it instead of cding to the right place first. That leaves me retyping the path/to/src everytime. Also this doesn't scale well if you want to open 2-3 projects from different places, then you'll be really lost. I just realized that this could be implemented through hooks on WinCreate/WinDisplay with cd, so I'll play around with that. I still think this would be a more reasonable default, but that's just my opinion.

I'm using this in my kakrc and it's working like a charm.
map global user n ':eval %{nextbuffer}<ret>'
in other words, you have eval mechanism for this.

I see, thanks for that!

I find out that almost every highlighter using instead of color names some inner variables like meta ,value ...

I might be wrong ( @mawww correct me if I am ) but if you look at share/kakrc you'll see some default faces being defined, like value, comment etc. These faces are used in rc/your-language.kak to define highlighting. With this setup you can change the color scheme easily since all language highlighters are using the same faces. In short you should be using these faces for highlighting your language instead of baking in some colors.

@mawww

This comment has been minimized.

Show comment
Hide comment
@mawww

mawww Jun 8, 2015

Owner
  1. New title. I think experiment should be dropped and a short and interesting title picked. Example ideas:

We could eventually change that at some point yeah, not a very big priority though.

  1. Paging. and work but are not documented in the readme. Maybe and could be implemented as well?

Yep, documentation fixes are welcome ;), not sure what and would do, do you mean as in emacs to move cursor down/up ?

  1. Edit directory. I'd expect to find myself in the current buffer's directory upon pressing :e.
    E.g. if I start kakoune in ~ and :e code/cpp/kakoune/rc/c-family.kak upon next :e I'd expect to be in code/cpp/kakoune/rc but I find myself in ~.

I'd rather have that implemented as hooks than in core

  1. Go to line begin/end. Since e.g. both and gl select to line end couldn't one of them go there without selecting?

done as of 66866aa

  1. Highlighter show_matching doesn't seem to be working.

It only highlights when the cursor is on the character, and use bold by default, which might not work with your terminal.

  1. Map only for keys. Would/is it possible to map commands to keys?

@jkonecny12 answered that

  1. Search selection with * could show as information what is the search pattern that is being saved.

Good idea, could you open an issue for that (so that I do not forget)

  1. Some commands (e.g. onkey) use registers to store information. Is there or could there be a hidden register for such commands?

Good point, could you open an issue about that

  1. Prioritize folding and diffing. These are commonly used in other editors and new users will be looking and asking for them.

Agreed

  1. Plugins. New users will be looking for a surround, paredit, powerline, snipmate/yasnippet, fugitive/magit clone

Let the users do the work !

More seriously, I prefer to work on support scripts for the features I actually use, but I will happily lend a hand if someone wants to write/improve a plugin for his use case.

I might be wrong ( @mawww correct me if I am ) but if you look at share/kakrc you'll see some default faces being defined...

Yep thats the case, these default faces should be documented properly though.

Owner

mawww commented Jun 8, 2015

  1. New title. I think experiment should be dropped and a short and interesting title picked. Example ideas:

We could eventually change that at some point yeah, not a very big priority though.

  1. Paging. and work but are not documented in the readme. Maybe and could be implemented as well?

Yep, documentation fixes are welcome ;), not sure what and would do, do you mean as in emacs to move cursor down/up ?

  1. Edit directory. I'd expect to find myself in the current buffer's directory upon pressing :e.
    E.g. if I start kakoune in ~ and :e code/cpp/kakoune/rc/c-family.kak upon next :e I'd expect to be in code/cpp/kakoune/rc but I find myself in ~.

I'd rather have that implemented as hooks than in core

  1. Go to line begin/end. Since e.g. both and gl select to line end couldn't one of them go there without selecting?

done as of 66866aa

  1. Highlighter show_matching doesn't seem to be working.

It only highlights when the cursor is on the character, and use bold by default, which might not work with your terminal.

  1. Map only for keys. Would/is it possible to map commands to keys?

@jkonecny12 answered that

  1. Search selection with * could show as information what is the search pattern that is being saved.

Good idea, could you open an issue for that (so that I do not forget)

  1. Some commands (e.g. onkey) use registers to store information. Is there or could there be a hidden register for such commands?

Good point, could you open an issue about that

  1. Prioritize folding and diffing. These are commonly used in other editors and new users will be looking and asking for them.

Agreed

  1. Plugins. New users will be looking for a surround, paredit, powerline, snipmate/yasnippet, fugitive/magit clone

Let the users do the work !

More seriously, I prefer to work on support scripts for the features I actually use, but I will happily lend a hand if someone wants to write/improve a plugin for his use case.

I might be wrong ( @mawww correct me if I am ) but if you look at share/kakrc you'll see some default faces being defined...

Yep thats the case, these default faces should be documented properly though.

@xificurC

This comment has been minimized.

Show comment
Hide comment
@xificurC

xificurC Jun 9, 2015

Contributor

Yep, documentation fixes are welcome ;), not sure what and would do, do you mean as in emacs to move cursor down/up ?

If I remember correctly [f]orward/[b]ackward (i.e. <c-f> and <c-b>) move a whole page and [d]own/[u]p (i.e. <c-d> and <c-u>) move half a page in vim. Sometimes it's easier to follow the code if you move by half pages only. Not a big priority but shouldn't be hard to implement.

It only highlights when the cursor is on the character, and use bold by default, which might not work with your terminal.

Could it be configurable? Or at least have a background color, bold is hard to notice.

I opened the issues you asked me to. I'd be happy to contribute more once I have a bit more time.

Contributor

xificurC commented Jun 9, 2015

Yep, documentation fixes are welcome ;), not sure what and would do, do you mean as in emacs to move cursor down/up ?

If I remember correctly [f]orward/[b]ackward (i.e. <c-f> and <c-b>) move a whole page and [d]own/[u]p (i.e. <c-d> and <c-u>) move half a page in vim. Sometimes it's easier to follow the code if you move by half pages only. Not a big priority but shouldn't be hard to implement.

It only highlights when the cursor is on the character, and use bold by default, which might not work with your terminal.

Could it be configurable? Or at least have a background color, bold is hard to notice.

I opened the issues you asked me to. I'd be happy to contribute more once I have a bit more time.

@mawww

This comment has been minimized.

Show comment
Hide comment
@mawww

mawww Jun 10, 2015

Owner

Could it be configurable? Or at least have a background color, bold is hard to notice.

It is the MatchingChar builtin face, so you can set it to whatever you fancy.

Owner

mawww commented Jun 10, 2015

Could it be configurable? Or at least have a background color, bold is hard to notice.

It is the MatchingChar builtin face, so you can set it to whatever you fancy.

@cshimmin

This comment has been minimized.

Show comment
Hide comment
@cshimmin

cshimmin Jun 23, 2015

Hi,
I just learned about this project, since it just hit the front page of hackernews. Perhaps this is the wrong place for the discussion, but if the following is true:

Kakoune is now quite mature, with no major feature missing

why not consider having a proper release version? It's not exactly "advertising" per se, in the sense of other things listed here. But having a normal release cycle allows you to drop the headline Kakoune <minor version bump> released! on hackernews/reddit/etc every once in a while. And some people will only want to download and run a stable version, rather than run from the bleeding edge.

cshimmin commented Jun 23, 2015

Hi,
I just learned about this project, since it just hit the front page of hackernews. Perhaps this is the wrong place for the discussion, but if the following is true:

Kakoune is now quite mature, with no major feature missing

why not consider having a proper release version? It's not exactly "advertising" per se, in the sense of other things listed here. But having a normal release cycle allows you to drop the headline Kakoune <minor version bump> released! on hackernews/reddit/etc every once in a while. And some people will only want to download and run a stable version, rather than run from the bleeding edge.

@lenormf

This comment has been minimized.

Show comment
Hide comment
@lenormf

lenormf Oct 9, 2015

Contributor

@mawww

  • A new demonstration video/gif demonstrating the most impressive features
Contributor

lenormf commented Oct 9, 2015

@mawww

  • A new demonstration video/gif demonstrating the most impressive features
@FranzSkuffka

This comment has been minimized.

Show comment
Hide comment
@FranzSkuffka

FranzSkuffka Oct 29, 2015

How about a twitter account?

FranzSkuffka commented Oct 29, 2015

How about a twitter account?

@benoit-intrw

This comment has been minimized.

Show comment
Hide comment
@benoit-intrw

benoit-intrw Nov 7, 2015

Contributor

Hello,

I've started a collaborative news about Kakoune on the french community site LinuxFr:

https://linuxfr.org/redaction/news/kakoune-un-editeur-de-caractere

Feel free to join me to improve and enrich information given in this article.

Contributor

benoit-intrw commented Nov 7, 2015

Hello,

I've started a collaborative news about Kakoune on the french community site LinuxFr:

https://linuxfr.org/redaction/news/kakoune-un-editeur-de-caractere

Feel free to join me to improve and enrich information given in this article.

@benoit-intrw

This comment has been minimized.

Show comment
Hide comment
@benoit-intrw
Contributor

benoit-intrw commented Nov 12, 2015

@jubalh

This comment has been minimized.

Show comment
Hide comment
@jubalh

jubalh Nov 12, 2015

Contributor

I also think that a version #315 would help a lot in getting adopted by distros and thus promoting to the spread of kakoune.

Contributor

jubalh commented Nov 12, 2015

I also think that a version #315 would help a lot in getting adopted by distros and thus promoting to the spread of kakoune.

@FranzSkuffka

This comment has been minimized.

Show comment
Hide comment
@FranzSkuffka

FranzSkuffka Nov 13, 2015

I think it's perfectly usable at this point and totally deserves a release.

FranzSkuffka commented Nov 13, 2015

I think it's perfectly usable at this point and totally deserves a release.

@rennis250

This comment has been minimized.

Show comment
Hide comment
@rennis250

rennis250 Feb 21, 2016

Contributor

Since I am just learning the editor now, I would be happy to build a small "tutor" as I figure things out.

Contributor

rennis250 commented Feb 21, 2016

Since I am just learning the editor now, I would be happy to build a small "tutor" as I figure things out.

@jkonecny12

This comment has been minimized.

Show comment
Hide comment
@jkonecny12

jkonecny12 Feb 22, 2016

Contributor

That would be super nice @rennis250 . Thank you

Contributor

jkonecny12 commented Feb 22, 2016

That would be super nice @rennis250 . Thank you

@cGuille

This comment has been minimized.

Show comment
Hide comment
@cGuille

cGuille Dec 5, 2016

Hello,

Any news about a "kaktutor"?
Did you get the chance to start something @rennis250?

I am currently discovering kakoune and I thought it would really help.

cGuille commented Dec 5, 2016

Hello,

Any news about a "kaktutor"?
Did you get the chance to start something @rennis250?

I am currently discovering kakoune and I thought it would really help.

@alexanderjeurissen

This comment has been minimized.

Show comment
Hide comment
@alexanderjeurissen

alexanderjeurissen Dec 17, 2016

This issue thread is becoming quite long, and turning in a general feature request / discussion thread. As far as I understand there are five remaining issues described in this thread:

  • getting Kakoune reviewed by a Vim news site
  • An equivalent to vimtutor to help newcomers understand how Kakoune works (@rennis250 mentioned he might start implementation of this)
  • line wrapping highlighter
  • folding
  • diffing interface (e.g. kakdiff)

I'd like to propose that we create separate issues for these items and continue in depth discussion there. Whats your thought on this @mawww

alexanderjeurissen commented Dec 17, 2016

This issue thread is becoming quite long, and turning in a general feature request / discussion thread. As far as I understand there are five remaining issues described in this thread:

  • getting Kakoune reviewed by a Vim news site
  • An equivalent to vimtutor to help newcomers understand how Kakoune works (@rennis250 mentioned he might start implementation of this)
  • line wrapping highlighter
  • folding
  • diffing interface (e.g. kakdiff)

I'd like to propose that we create separate issues for these items and continue in depth discussion there. Whats your thought on this @mawww

@mawww

This comment has been minimized.

Show comment
Hide comment
@mawww

mawww Dec 17, 2016

Owner
Owner

mawww commented Dec 17, 2016

@alexanderjeurissen

This comment has been minimized.

Show comment
Hide comment
@alexanderjeurissen

alexanderjeurissen Dec 17, 2016

@mawww Thanks for your quick response, Because a lot of the issues described here have already been tackled or filed in separate issues, how do you feel about closing this issue and creating a separate issue about the kakoune tutor. The reason I'm asking is because for new contributors this issue isn't really clear and actionable.

alexanderjeurissen commented Dec 17, 2016

@mawww Thanks for your quick response, Because a lot of the issues described here have already been tackled or filed in separate issues, how do you feel about closing this issue and creating a separate issue about the kakoune tutor. The reason I'm asking is because for new contributors this issue isn't really clear and actionable.

@mawww

This comment has been minimized.

Show comment
Hide comment
@mawww

mawww Dec 17, 2016

Owner
Owner

mawww commented Dec 17, 2016

@Delapouite

This comment has been minimized.

Show comment
Hide comment
@Delapouite

Delapouite Jan 20, 2017

Contributor
I think we already have issues regarding wrapping, folding, and the diff support.

Cross refs:

Contributor

Delapouite commented Jan 20, 2017

I think we already have issues regarding wrapping, folding, and the diff support.

Cross refs:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment