unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Gregory Heytings <ghe@sdf.org>
To: help-gnu-emacs@gnu.org
Subject: Re: Opening multiple files in a single buffer?
Date: Sat, 13 Jun 2020 16:53:48 +0000	[thread overview]
Message-ID: <alpine.NEB.2.22.394.2006131844570.13873@sdf.lonestar.org> (raw)
In-Reply-To: <680ce1a6-6a1d-9212-9e4a-08cd443e9ef5@gmail.com>


Douglas Lewan:
>
>> I've now been using Emacs for many, many years, and there is perhaps a 
>> single feature I'm really missing, namely opening more than one file in 
>> a single buffer, with the contents of the files appearing one after the 
>> other in the same buffer, with some kind of visual separator between 
>> them. I don't know if that feature exists in other text editors.
>> 
>> For example, suppose you write a book, which has fifteen chapters in 
>> files chap1.tex, ..., chap15.tex.  Opening these files in a single 
>> buffer means that you could use isearch-{forward,backward} in the whole 
>> book.  (I know that multi-isearch-buffers could be used in this 
>> particular case, but it is not as convenient to use.)  You could also 
>> use query-replace on the whole book, or reindent all files, or execute 
>> shell-command on all files at once, and so forth.  (Again I know that 
>> all this can be done with already existing features, e.g. through 
>> dired, but again I find them not as convenient as what I have in mind.)
>> 
>> Each file would have its own major and minor modes, and the mode-line 
>> would adapt depending on the file corresponding to the buffer portion 
>> in which the point is currently located.
>> 
>> My question is: Is this feasible, or is the one-to-one correspondence 
>> between buffers and files too deeply rooted in Emacs' codebase that it 
>> is not feasible?  If it is feasible, could this feature be considered 
>> for implementation in a future Emacs version?
>
> I would say it's feasible, but probably awkward as stated. An 
> application that implements something similar via a sequence of buffers 
> with a way of navigating next and previous and providing appropriate 
> commands via a (map) function would probably be simpler to build and 
> manage. It would also be much more natural.
>

In fact, what I have in mind is not an additional application, but a core 
feature, that would be transparent (or almost transparent) to everything 
else.  It would not require a rewrite of any command.  For example it 
would also be possible to narrow the (multi-file) buffer to the last X 
lines of a file and the first Y lines of the next file in the buffer.

Gregory


  reply	other threads:[~2020-06-13 16:53 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-13 14:31 Opening multiple files in a single buffer? Gregory Heytings
2020-06-13 15:20 ` Douglas Lewan
2020-06-13 16:53   ` Gregory Heytings [this message]
2020-06-13 15:21 ` tomas
2020-06-13 15:36   ` Douglas Lewan
2020-06-13 15:53     ` tomas
2020-06-13 15:49 ` Jakub Jankiewicz
2020-06-13 16:43 ` Stefan Monnier
2020-06-14 11:11   ` Michael Albinus
2020-06-15  8:26   ` Gregory Heytings
2020-06-15  9:33     ` tomas
2020-06-15  9:52       ` Gregory Heytings
2020-06-15 10:58         ` tomas
2020-06-15 12:48     ` Joost Kremers
2020-06-15 14:24       ` Gregory Heytings
2020-06-15 14:41     ` Stefan Monnier
2020-06-15 12:21   ` Sergey Organov
2020-06-15 15:26   ` Gregory Heytings
2020-06-15 15:31     ` Perry Smith
2020-06-13 18:10 ` Dan Hitt
2020-06-13 18:41   ` Jakub Jankiewicz
2020-06-13 18:41   ` Eli Zaretskii
2020-06-13 19:22     ` Gregory Heytings
2020-06-13 19:45       ` Perry Smith
2020-06-13 20:42         ` Gregory Heytings
2020-06-14  5:29           ` Arthur Miller
2020-06-14  7:12             ` Gregory Heytings
2020-06-14  7:45               ` Arthur Miller
2020-06-14 20:14                 ` Gregory Heytings
2020-06-15  6:58                   ` Sv: " arthur miller
2020-06-13 19:31   ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.NEB.2.22.394.2006131844570.13873@sdf.lonestar.org \
    --to=ghe@sdf.org \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).