[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [vile] empty unmodified buffers

From: Rick Sladkey
Subject: RE: [vile] empty unmodified buffers
Date: Wed, 17 Nov 2010 23:11:51 -0500

The old behavior used to annoy me because while I never seem to have
misnamed empty buffers, I always seem to have to go back to what
I was looking at before I enter the first text of a new file.  And
to have the buffer disappear in that situation is very surprising.

After a while, I learned to type "o<ESC>" before using "__" and
that, once a habit, solved the problem.  You sort of "commit" to
the new buffer.  In fact, I didn't notice that it got "fixed" to
how I like.

Better than either extreme, I'd prefer to be prompted with "File
does not exist: do you want to create a new buffer? (y/n):"  which
addresses the problem at its source.  I guess if it were a mode
then always, never, and prompt could be the values.  But no
change is fine too...

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Paul Fox
Sent: Wednesday, November 17, 2010 8:18 PM
To: address@hidden
Subject: [vile] empty unmodified buffers

so, this clearly isn't a very important bug, since it's been with us
since at least 9.4, which is the earliest tree i have readily at hand. 
but recently i've found it annoying.  i'm not completely wedded to it,
though (clearly, if i've only noticed it recently), so if other people
think the status quo is good, that's fine.

it used to be that if you edited a file, and mis-typed the name, then
when you edited the correct file, the mis-named buffer would be reused.
this happened because of this snippet from getfile2bp():
            if (!b_is_argument(bp) &&
                !b_is_changed(bp) &&
                is_empty_buf(bp) &&
                !ffexists(bp->b_fname)) {
                /* empty, unmodified, and non-existent --
                   then it's okay to re-use this buffer */
                bp->b_active = FALSE;
                ch_fname(bp, nfname);
                return bp;

the first condition of the 'if' says that buffers that were named
on the commandline shouldn't be destroyed.

somewhere along the line, filefind() (which implements ":e") started
using the same core logic as the code for ":args", and as a result,
the BFARGS flag is now set for all edited files.  this essentially
makes all files look like command-line arguments, and so the buffer
reuse above never happens.

i must be fumble-fingering a lot these days, because i seem to be
accumulating unwanted buffers that i didn't use to notice.  the
downside, of course, are the false positives:  you do ":e newfile",
and realize you need to look at something (":e something"), and
when you go to switch back ("__" or ":e#") you find you have to
retype the ":e newfile" because it's gone.  this is why i'd understand
if the feature's unwanted.

anyway...  here's a patch that puts it back the way it used to be.


--- proto.h.orig        2010-11-17 19:59:08.000000000 -0500
+++ proto.h     2010-11-17 19:59:18.000000000 -0500
@@ -598,6 +598,7 @@
 extern int readin (char *fname, int lockfl, BUFFER *bp, int mflg);
 extern int same_fname (const char *fname, BUFFER *bp, int lengthen);
 extern int set_files_to_edit(const char *prompt, int appflag);
+extern int set_args_to_edit(const char *prompt, int appflag);
 extern int slowreadf (BUFFER *bp, int *nlinep);
 extern int write_enc_region (void);
 extern int writeout (const char *fn, BUFFER *bp, int forced, int msgf);
--- file.c.orig 2010-11-17 19:57:16.000000000 -0500
+++ file.c      2010-11-17 20:00:18.000000000 -0500
@@ -695,8 +695,8 @@
     return s;
-set_files_to_edit(const char *prompt, int appflag)
+static int
+set_files_to_edit_worker(const char *prompt, int appflag, int is_arg)
     int status;
     BUFFER *bp, *bp_next;
@@ -705,7 +705,7 @@
     char *actual;
     BUFFER *firstbp = 0;
-    TRACE((T_CALLED "set_files_to_edit(%s, %d)\n", NONNULL(prompt), appflag));
+    TRACE((T_CALLED "set_files_to_edit_worker(%s, %d, %d)\n", NONNULL(prompt), 
appflag, is_arg));
     if ((status = mlreply_file(prompt, &lastfileedited,
                               FILEC_READ | FILEC_EXPAND,
@@ -715,7 +715,8 @@
                status = FALSE;
-           bp->b_flag |= BFARGS;       /* treat this as an argument */
+           if (is_arg)
+               bp->b_flag |= BFARGS;   /* treat this as an argument */
            if (firstbp == 0) {
                firstbp = bp;
                if (!appflag) {
@@ -737,6 +738,18 @@
+set_files_to_edit(const char *prompt, int appflag)
+    return set_files_to_edit_worker(prompt, appflag, FALSE);
+set_args_to_edit(const char *prompt, int appflag)
+    return set_files_to_edit_worker(prompt, appflag, TRUE);
 filefind(int f GCC_UNUSED, int n GCC_UNUSED)
--- buffer.c.orig       2010-11-17 19:59:29.000000000 -0500
+++ buffer.c    2010-11-17 19:59:39.000000000 -0500
@@ -2345,7 +2345,7 @@
        return FALSE;
-    return set_files_to_edit("Set arguments: ", FALSE);
+    return set_args_to_edit("Set arguments: ", FALSE);
@@ -2357,7 +2357,7 @@
     if (end_named_cmd()) {
        return listbuffers(f, n);
-    return set_files_to_edit("Set arguments: ", FALSE);
+    return set_args_to_edit("Set arguments: ", FALSE);

 paul fox, address@hidden (arlington, ma, where it's 46.8 degrees)

vile mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]