Ticket #4177 (closed enhancement: wontfix)

Opened 18 months ago

Last modified 18 months ago

My wishlist for MCEdit

Reported by: psprint Owned by:
Priority: major Milestone:
Component: mcedit Version: master
Keywords: wishlist, mcedit Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:


I'm having many ideas for MCEdit improvements, I'm saving them to a file. Here is its most recent version. Does it qualify maybe for a document MCEditWishList on the Wiki?

  1. Searching of the current word under the cursor.
    • it rather requires to come up with a configurable way of configuring the word boundaries,
    • something like the wholechars command from syntax files.
  2. MarkLineUp and MarkLineDown – working like MarkUp/Down, however selecting whole lines, not just from/to the current horizontal cursor position.
  3. SearchBackwardContinue / SearchOppositeContinue actions (like in mcview).
  4. Increment/subtract from the nearest number on right, like the Ctrl-a/Ctrl-x keys in vim (should be done in a plugin, I have one already in my unofficial S-Lang scripting support).
  5. A file browser widget for Edit… and SaveFile.
  6. Centering of view (#4175) and of cursor (separate functionality).
  7. Scrolling without moving the cursor, so that only the view moves up or down, not like it's now, where the cursor is also moved up or down.
  8. «Recent files» sub-menu in the File menu.
  9. Display of all tag symbols for the current file and jump to selected ones (#4169 does this and more).
  10. Make the bracket matching search for the first matching paren with a non-zero radius, e.g.: 1 or 2 chars left/right).
  11. CK_WindowCascade and CK_WindowTile automatic arranging of windows/files in a cascade or tiled arrangement.
  12. MultiSearch grepping of any listbox by an AND-chained list of keywords of the entered (in an automatically added input to the dialog) query (#4165 implements this).
  13. A command to complete the word/path under the cursor from the disk, current PWD (like Ctrl-x f in vim).
  14. A handy tray of a few Unicode symbols.
  15. Support for the "other file" concept – ability to jump between the header and implementation, i.e.: between .h and .c/.cpp files.
  16. Support for git.
    • show current branch on the window top bar,
    • the query should be done async (could utilize the current background task support?),
    • support for running a commit, pull, push, rebase commands,
    • further support could involve a diff view with staging of selected hunks and lines.
  17. Support for preview of ExternalCommand action – a text field under the entered command that is automatically (or after a request/Preview button press) filled with its results, allowing to preview the result before pasting it into the buffer.
  18. The bookmarks in a list in a window – presented for selection (instead of jumping to them via BookmarkNext/Prev actions).
  19. Showing of the margin only when it's exceeded or approached.
  20. Fixing of the menu hotkeys conflicts, they are there, especially in other locale than en_US.
  21. Window with a terminal for building and other tasks. It doesn't have to be a full terminal emulation at the beginning, a simple popen() will suffice for a start.
  22. Matching of not only parens, but also other blocks, like if/fi, case/esac in shell scripts.
    • it would require a way of configuring the block boundaries, which would yield a general mechanism.
  23. Fix for the paragraph formatting command (it often produces results with an extra spaces added).
  24. Advanced sort – on column A but with a key from column B, etc.
  25. MarkInParens / MarkInParensWide – a selection of currently active pair of parens – with them (*Wide) and without them.
  26. Moving of the selected block line up and down.
  27. An overall light scripting engine based on S-Lang interpreter already present in the linked libslang.so (a very compact and clean C-like scripting language, used before in the JED editor and slrn news reader), with an explicit light syntax to add S-Lang hooks to the actions (hook would be a script function to invoke before the action, if it returns 0 then the action isn't run, only the S-Lang function) directly inside the mc.keymap file ↔ without an actual S-Lang script file (i.e.: it would be only needed for a more sophisticated tasks and for defining the functions).
    • the engine should use the automatic function/symbol exporting to S-Lang interpreter tool called Slirp, a very useful utility.
  28. A few text alteration actions like CapitaliseWord, LowercaseWord, UpcaseWord, etc.
  29. Actions for scrolling left and right.
  30. Alternate WindowList command, that would, besides listing the windows, also:
    • keep the order of the files unchanged,
    • provide (either after a button/key press, or by default with some separation e.g.: by colors) a few of entries from the editor history, joined to the list of currently open files, with a distinct color or other separation,
    • the intention is to create an unified "document fetch source" for any file – a place where one wanting to just switch to a file can go and get the file into the foremost editor,
    • by a smooth integration of the file history and the current open files list it should be possible to make a file switching and opening indistinguishable operation.
  31. MarkInverse – an inversion of current selection.
  32. A listbox dialog with all search result matches, after selection a jump to it should be done. The list could consist of the line texts of the matched lines.
  33. Fixing of the typewriter auto wrapping, so that it doesn't left any space at the end of the broken line.
  34. ReloadFile action – abandoning any changes re-read of the file from the disk.
  35. Implementation of a change of the mcedit process PWD (current working directory) – to be able to easily read and write to files in that location.
  36. Simple operations on the files in the browse dialog from 5. – rm, mkdir, etc.
  37. Line joining (like J normal command in vim).
  38. Character swapping command (like Ctrl-t in readline/Bash).
  39. Opening of the file whose path is under the cursor.
  40. Repeating of all entered commands and characters from the last file save (somewhat like the dot . normal command in vim).
  41. Repeating the completion command should select the next result in the initial completion list (doable via binding configuration after the blocking bugs will be resolved).
  42. The Find definition command should not replace the file and forget the undo history if the file is the same.
  43. Fixing of the terminal disruption when an external command is run (#4171).
  44. History of clipboard (a ring of mcclip files working in a circular buffer configuration?).
  45. Autosuggestions when entering into an input, from the input history, with a different, faint color (like Fish or Zsh's autosuggestions).
  46. Ability to open a file without adding it to the editor history.
  47. Removal of trailing whitespace → moving them to the next line after pressing enter.
  48. Make ctrl-v (pasting) to clear the faded content of the input (it currently doesn't work this way).
  49. In word completion – so that completing e.g.: editcmd_dia|.c would result in editcmd_dialogs.c, not in editcmd_dialogs.c.c like it is now.
  50. Automatic indentation to the level of previous open parenthesis, not to the previous indentation, if there is such paren.
  51. I've forgot what the following meant: g_return_if_fail (error == NULL || *error == NULL);.
  52. Smart jumping to the word boundaries: right jumps to the end of the word on the right, left to the beginning of the word on the left (currently right jumps to the beginning of the next word on the right, which is little confusing IMO; compare e.g.: firefox Ctrl-Right behavior).
  53. Jumps to the previous locations without use of the undo mechanism (like Ctrl-o in vim).
  54. A query that the current file is already open and an ability to jump into it without reopening again.
  55. A support for globbing in the EditFile dialog.
  56. Saving of the undo history somewhere in a side backup when moving to a definition, so that it can be restored when moving back/next with FindPrev, FindNext actions.
  57. An action to look at the definition of the function under the cursor (in a popup window).
  58. Extension of the alternate WindowList command from 30. so that it would make the MultiSearch to look in the TAGS file symbols of the files – and promoting the ones that contain the most matched symbol to up of the list, automatically selecting the first one for approval with Enter.
    • also an extension to show current git status, with e.g.: the number of insertions and deletions in the listed files,
    • support for "other file" in the list – automatic "clustering" of c sources and h header files into a joined pair of entries displayed and sorted together (first h, then c),
    • coloring of the entries according to their type.
  59. Typewriter word wrap ignores auto indentation, it shouldn't be.
  60. Folding support ({{{ / }}} delimited, user blocks, with configurable delimiters).
  61. Showing of the current function in the top bar (fully doable via TAGS file – just detect the last symbol whose definition starts at current line or earlier; already done in #4169 to select the current symbol in the popup listbox).

Change History

comment:1 Changed 18 months ago by andrew_b

  • Status changed from new to closed
  • Resolution set to wontfix
  • Milestone Future Releases deleted

No comments about wishes above.

Some comments about mc development process.

One ticket -- one bug/enhancement/task.

No huge cumulative changes. One commit/patch -- one small (as possible), well-understandable, well-reviewable independent change.

This is not a blog. Not mine, not yours, not anybody's else. Please keep your wishlist in another place, private or public.

I strongly dislike an idea to filling mceditor with many microfeatures that few people will be in demand and about which few people will know at all.

Don't transform a simple editor to some monster with tonnes of dead code.

Just close.

comment:2 Changed 18 months ago by psprint

I think that such sharing can still have sense… Ticket system is not a blog, however someone might get interested with a wish from the list to the level of implementing it.

Anyway, thanks for your opinions and suggestions, I really appreciate it. I also dislike the idea of adding many microfeatures, however just noting that with a proper discoverability probably almost all of the above could be fine to add to mcedit. I sure don't want a monster mcedit, but a richer mcedit with the existing features taken to their fullest state – yes. Like the completion, which works great but is currently pushed down by completing only from current buffer and by the default mapping Alt-Tab obviously colliding with all Xorg window managers. Or like the Find declaration command which also works great however it is pushed down by only a fixed, rigid use case (thus, a micro-feature in question?) – to search (and not e.g.: list) in all files and to jump by an undo-forgetting file replace (even if it's to the same file)… It is a very interesting way of doing tags, and honestly it does work well, however, it is a very narrow-vision of it, exactly like the micro-features in question. I also honestly doubt about the discoverability of it, I've found it because I've got fascinated by the various micros implemented in mcedit, however a regular user probably won't bother (I plan to sent a patch with a warning dialog about missing TAGS file which would include the ctags command example to increase the discoverability, would it have a chance of merging?).

Also, vim and emacs do the micro-feature way much more intensively, although (also) via scriptable plugins (which then try to find their way up to a mainstream popularity, bringing their micro- to the world, which is rather a bad effect, especially in vim, where there is no repository of programming libraries, only end-user plugins), and they're fine.

I'll try to conform to the one-patch ↔ one-small change as much as possible in all my next patches. The previous patches also don't go far away from this principle, except that they sometimes implement big features. I'll try to limit such effect, if only possible.

Note: See TracTickets for help on using tickets.