7 ms·

There is a strange editing mode that I stumbled on by myself, which I can do in Emacs. Suppose I am editing a huge file, and need to make change in some other

by sn41 8y ago

There is a strange editing mode that I stumbled on by myself, which I can do in Emacs. Suppose I am editing a huge file, and need to make change in some other part without necessarily forgetting where I am. I just open a new buffer for the same file, edit the desired area, and close the new buffer. I have the old position restored automatically in the old buffer. Of course, this can be done to arbitrary number of levels. This is because Emacs separates the concept of buffer and the file it visits. This is a basic concept, but its use in the above manner is not something I have explicitly seen mentioned. Do other editors (vi, eclipse, sublime) have similar features?

SPBS 8y ago
:tabedit % will do that in vim. :tabclose to close the tab when you're done.
- nostoc 8y ago
  :split is another way to do it.
  - libjohn 8y ago
    I think buffers/splits are considered a better option than tabs for this use case? I believe tabs are more for layouts of open buffers in splits rather than like browser tabs.
dhimes 8y ago
In vim, I use vsplit to open the same file, make my edit, and close it. tbh, it's faster to mark my spot with m[az], make my edit, and return to my spot `[az] ([az] means any lower case letter).
dedosk 8y ago
MSVC IDE has menu Window -> New Window to mimic this iirc.
- ludwigvan 8y ago
  Little known tip: Word and Excel (and probably other Office apps) have the same. You can edit one part of the document while viewing another part.
mjhoy 8y ago
What you describe can also be done with one buffer and multiple windows that show the same buffer, and I do this all the time. The position of the cursor is associated with a window when multiple windows present the same buffer.
SCdF 8y ago
Sublime definitely does, you can open a new "view" into the same file. I imagine the vi solution (if it doesn't support that) would be marks.
nicolashahn 8y ago
Exact same thing works in vi/vim. I often use ctrl-o to do the same thing (jump back to previous cursor position).
- deleted 8y ago
  [deleted]
- typon 8y ago
  The fact that Ctrl-O and Ctrl-I exist is just a tiny example of why the modern editors just can't compete with vim and the plethora tiny productivity features it has.
  - nicolashahn 8y ago
    Hardcore vimmer here, but I don't think you're right. I know at least VSCode has this functionality and probably other editors as well. I don't use vim because of it's features but more because modal editing and the keybindings are cemented into my muscle memory. There's also the extremely lightweight nature that let's me have several projects open in vim at once with little resource impact. Were I to start over today, I might pick VSCode and be just as happy.
    - typon 8y ago
      I respectfully disagree. I think VSCode's ergonomics pale in comparison to Vim. I just mentioned Ctrl-O, but there's a hundred little other features that I use constantly that VSCode doesn't have, and even if it does, it executes them much slower than Vim does. If Vim's plugin system was improved, it would blow VSCode out of the water.
libjohn 8y ago
You can do the same thing in vim by opening the same buffer in another split. Very useful for editing in multiple places without having to keep jumping around.
barrkel 8y ago
Every programmer's editor and IDE I've used in the past 22 years has had this feature, all the way back to Delphi in 1996. I don't think Turbo Pascal's text UI had the feature but wouldn't be surprised if it did. Support varies in whether e.g. lines introduced above the view cause scrolling, or if the views are sticky to relative position, but the basics of multiple editing cursors in multiple views for a single buffer have been pretty pervasive.
- AsyncAwait 8y ago
  > Every programmer's editor and IDE I've used in the past 22 years has had this feature, all the way back to Delphi in 1996. Well, Emacs is older than all of them.
xte 8y ago
Emacs can do far more nice things, for instance meaningful text navigation so you can move not only between lines and columns but also between functions/method/class definitions, scope/context/namespaces, paragraphs, ... You can edit multiple files at once (for instance if you change a string, like a variable name, in multiple files), you can edit with multiple cursors, record&execute text macro on the fly and with a prefix to transform code/data in a snap... You can edit file/dirs like text in dired, receive a patch via mail and have it highlighted, applied and committed in a snap... List is long to a point that anything you think if useful probably already exists in Emacs, otherwise you can create it in very few lines of elisp at runtime.
- dmitriid 8y ago
  How much time do you need to spend setting up all those possibilities? And figuring out all the little incompatibilities be tween all the plugins and modes, and lisp extensions? Most of what you mentioned already exists in most IDEs.
  - wry_discontent 8y ago
    That's the trouble. It's more flexible than most ides, but you have to configure it, which isn't easy if you lack the imagination or the technical know-how (elisp).
    - dmitriid 8y ago
      > isn't easy if you lack the imagination wat? > or the technical know-how (elisp) It's not just the technical know-how of knowing elisp. It's also the often arcane ways of configuring emacs and the arcane and often undocumented ways of configuring the packages and plugins and modes that you bring into the system. The amount of hacks one needs to maintain a reasonably working emacs is mind-boggling, and has nothing to do with imagination. I know, I used to maintain one: https://gist.github.com/dmitriid/4078311 https://gist.github.com/dmitriid/4078311
      - 8y ago
arambhashura 8y ago
Then you may find the "narrow-to-region" command useful too. It allows you to select a region of text, and make everything else in the buffer invisible and unmodifiable. I find it useful when trying to grok a specific function without getting distracted, or more usefully, doing a search-and-replace without fear of doing a replace in an unintended part of the buffer.

by sn41 8y ago

SPBS 8y ago

:tabedit % will do that in vim. :tabclose to close the tab when you're done.

nostoc 8y ago
:split is another way to do it.
- libjohn 8y ago
  I think buffers/splits are considered a better option than tabs for this use case? I believe tabs are more for layouts of open buffers in splits rather than like browser tabs.

dhimes 8y ago

In vim, I use vsplit to open the same file, make my edit, and close it. tbh, it's faster to mark my spot with m[az], make my edit, and return to my spot `[az] ([az] means any lower case letter).

dedosk 8y ago

MSVC IDE has menu Window -> New Window to mimic this iirc.

ludwigvan 8y ago
Little known tip: Word and Excel (and probably other Office apps) have the same. You can edit one part of the document while viewing another part.

mjhoy 8y ago

What you describe can also be done with one buffer and multiple windows that show the same buffer, and I do this all the time. The position of the cursor is associated with a window when multiple windows present the same buffer.

SCdF 8y ago

Sublime definitely does, you can open a new "view" into the same file. I imagine the vi solution (if it doesn't support that) would be marks.

nicolashahn 8y ago

Exact same thing works in vi/vim. I often use ctrl-o to do the same thing (jump back to previous cursor position).

deleted 8y ago
[deleted]
typon 8y ago
The fact that Ctrl-O and Ctrl-I exist is just a tiny example of why the modern editors just can't compete with vim and the plethora tiny productivity features it has.
- nicolashahn 8y ago
  Hardcore vimmer here, but I don't think you're right. I know at least VSCode has this functionality and probably other editors as well. I don't use vim because of it's features but more because modal editing and the keybindings are cemented into my muscle memory. There's also the extremely lightweight nature that let's me have several projects open in vim at once with little resource impact. Were I to start over today, I might pick VSCode and be just as happy.
  - typon 8y ago
    I respectfully disagree. I think VSCode's ergonomics pale in comparison to Vim. I just mentioned Ctrl-O, but there's a hundred little other features that I use constantly that VSCode doesn't have, and even if it does, it executes them much slower than Vim does. If Vim's plugin system was improved, it would blow VSCode out of the water.

libjohn 8y ago

You can do the same thing in vim by opening the same buffer in another split. Very useful for editing in multiple places without having to keep jumping around.

barrkel 8y ago

Every programmer's editor and IDE I've used in the past 22 years has had this feature, all the way back to Delphi in 1996. I don't think Turbo Pascal's text UI had the feature but wouldn't be surprised if it did. Support varies in whether e.g. lines introduced above the view cause scrolling, or if the views are sticky to relative position, but the basics of multiple editing cursors in multiple views for a single buffer have been pretty pervasive.

AsyncAwait 8y ago
> Every programmer's editor and IDE I've used in the past 22 years has had this feature, all the way back to Delphi in 1996. Well, Emacs is older than all of them.

xte 8y ago

Emacs can do far more nice things, for instance meaningful text navigation so you can move not only between lines and columns but also between functions/method/class definitions, scope/context/namespaces, paragraphs, ... You can edit multiple files at once (for instance if you change a string, like a variable name, in multiple files), you can edit with multiple cursors, record&execute text macro on the fly and with a prefix to transform code/data in a snap... You can edit file/dirs like text in dired, receive a patch via mail and have it highlighted, applied and committed in a snap... List is long to a point that anything you think if useful probably already exists in Emacs, otherwise you can create it in very few lines of elisp at runtime.

dmitriid 8y ago
How much time do you need to spend setting up all those possibilities? And figuring out all the little incompatibilities be tween all the plugins and modes, and lisp extensions? Most of what you mentioned already exists in most IDEs.
- wry_discontent 8y ago
  That's the trouble. It's more flexible than most ides, but you have to configure it, which isn't easy if you lack the imagination or the technical know-how (elisp).
  - dmitriid 8y ago
    > isn't easy if you lack the imagination wat? > or the technical know-how (elisp) It's not just the technical know-how of knowing elisp. It's also the often arcane ways of configuring emacs and the arcane and often undocumented ways of configuring the packages and plugins and modes that you bring into the system. The amount of hacks one needs to maintain a reasonably working emacs is mind-boggling, and has nothing to do with imagination. I know, I used to maintain one: https://gist.github.com/dmitriid/4078311 https://gist.github.com/dmitriid/4078311
    - 8y ago

arambhashura 8y ago

Then you may find the "narrow-to-region" command useful too. It allows you to select a region of text, and make everything else in the buffer invisible and unmodifiable. I find it useful when trying to grok a specific function without getting distracted, or more usefully, doing a search-and-replace without fear of doing a replace in an unintended part of the buffer.