Re: [PATCH] Set the buffer to be modified after recovery
On 16/04/10 22:47, Marvin Renich wrote: * James Vega [100416 11:43]: On Fri, Apr 16, 2010 at 11:28 AM, Marvin Renich wrote: Shouldn't this set curbuf->b_changed based on the "modified" setting from the swap file, so that if you "recover" a file that was not modified, you don't set the modified flag? I'd think that any time you recover from a swap file, the buffer should be considered "modified". The modified flag indicates that the buffer is different than the on-disk file with the same name. Whether or not the buffer was modified at the time that the swap file was last updated has no bearing on whether the content recovered from the swap file matches the current contents of the file that was being edited. That's up to the user to diagnose and decide what steps to take. Maybe I am missing something. If you are recovering from a swap file, doesn't Vim read the current version of the file from disk, then apply the changes that are in the swap file? So, if the swap file has modified=no, the buffer will match the current version of the file on disk. Is there something else going on that I have missed? I haven't tested it, so maybe I misunderstood; but what I understood from reading the posts was that recovery never sets 'modified' regardless of whether the swapfile says that the file was modified. OTOH if you recover the same file twice with the same swapfile, without editing or deleting it between them, the second recovery will "do nothing" even if it has "modified:yes" in the swapfile. I don't think this is a big deal; if you are explicitly recovering, you probably are paying attention to what you are doing, but then again, this patch is because people asked to be notified if they try to quit without saving after recovering. ...Marvin The reason for recovering is that some people "forget" to save their changes even after quite a long editing session... and then if there is a power fail, or an editor crash, it is too late to hit :w . Vim, however, records what it did to the buffer in memory (unless you have set 'noswapfile') so that will probably be left (except possibly the last few seconds) even after a crash or a blackout. The problem happens after restarting Vim, if you recover, hit ZZ (or :xa) to leave Vim, and then (thinking that your recovery is done) delete the swapfile... only to find out the next minute that ZZ sent your whole recovery to never-never land! If the recovery were to set 'modified', then ZZ (in a Vim with only one window open) or :xa would write the changes, but (except with 'autowriteall' on of course) :qa would refuse to close, telling you that you have a modified buffer, and that if you want to forget the changes then you must add an exclamation mark. Best regards, Tony. -- The Heineken Uncertainty Principle: You can never be sure how many beers you had last night. -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: your mail
> Instead of asking Bram to try to go back to the old development model > which failed, you might try getting some interest on the vim-dev list. > Describe what you would like to achieve, what you have done, what you > have problems with. If someone else is interested you might get some > help and maybe at some point get your features implemented. > > -- > Cheers, > Lech > > I would be happy to contribute to vim code. I failed several times due to the complexity of the code. I am sure everybody would profit if the code would be re-factored a bit. This was discussed several time, but unfortunately most of the users/developers see almost zero interest in that. One should just define some interfaces for buffer, window, etc. and then it would be much easier to build on top of that. 99% of the scripts could be reused, lot of them could be improved by writing faster C code. Myself I started to write some models for the buffer. The windowing system should work sthg. like links2 does, where different gui system would implement a driver for windowing etc. Porting would be much easier to new gui systems etc. etc. I am sure I will not hurt anybody, especially Bram, but vi/vim and ideas behind is/are a global inheritance. Question: is anybody interested in that? -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: your mail
On 11-Apr-2010 Marc Weber wrote: > In-reply-to: <201004111433.o3bexv8r012...@masaka.moolenaar.net> > References: <201004111433.o3bexv8r012...@masaka.moolenaar.net> > > > Hi Bram, > > > I will try to include a few patches that have been pending for a while. > > I don't have much time available, thus I will only include things that > > take a few hours of my time. That basically means patches that are > > ready to be included. > > This started bothering me for a long time. I appreciate every minute you > spend on Vim. The last updates adding completion features provide much > value to me. > > If the Vim community started funding you would you consider adding some > more optional features to Vim? Maybe you know the code base best. > > I think there are many Vim users in the world. If many Vim users just > spend some dollars it may be enough to pay some of your time which is > limited. > > This mail is sent to all Vim mailing lists. So I suggest sending replies > to this thread to v...@vim.org only so that no cross posting > takes place. > > Maybe its only my interest that Vim evolves. I don't know. That's why > I'm asking you and the community. I can assure you it's not only your interest that Vim evolves. And I would too be happy to sponsor Vim development. This model, however, has already been tested and it has failed. > I'd like to see some async communication support. I started working on > it. But I don't have time left working on it. But I could spend some > money. This would allow users implement debugger integrations using > scripting languages. > > Who else feels this way? Instead of asking Bram to try to go back to the old development model which failed, you might try getting some interest on the vim-dev list. Describe what you would like to achieve, what you have done, what you have problems with. If someone else is interested you might get some help and maybe at some point get your features implemented. -- Cheers, Lech -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: [PATCH] Set the buffer to be modified after recovery (was: Re: Save recovered file with ZZ?)
On Fri, Apr 16, 2010 at 10:53:34PM +0200, Lech Lorens wrote: > On 16-Apr-2010 Christian Brabandt wrote: > > Hi James! > > > > On Fr, 16 Apr 2010, James Vega wrote: > > > > > On Fri, Apr 16, 2010 at 11:28 AM, Marvin Renich wrote: > > > > * Christian Brabandt [100416 08:35]: > > > >> This has come up on the vim_use mailinglist. The problem seems to be > > > >> that after recovery of a swap buffer, the file should be modified so > > > >> you > > > >> are not loosing your changes after e.g. accidently hitting ZZ > > > >> > > > > Shouldn't this set curbuf->b_changed based on the "modified" setting > > > > from the swap file, so that if you "recover" a file that was not > > > > modified, you don't set the modified flag? > > > > > > I'd think that any time you recover from a swap file, the buffer should > > > be considered "modified". The modified flag indicates that the buffer > > > is different than the on-disk file with the same name. Whether or not > > > the buffer was modified at the time that the swap file was last updated > > > has no bearing on whether the content recovered from the swap file > > > matches the current contents of the file that was being edited. That's > > > up to the user to diagnose and decide what steps to take. > > > > That would be my understanding as well. > > Correct me if I am wrong, but I understand that the current behaviour is > that if you recover a file it does not get the "modified" attribute. As > a result if you press ZZ, you exit Vim without saving the recovered > contents. That's a very good point. Since the swap file isn't automatically deleted after a recovery, you can always re-recover if you ZZ/:x when you intended to :w. Given that perspective, I retract my suggestion that 'modified' is set. > IOW, I personally prefer the current behaviour. Still, I believe that > there might be a somewhat more complicated solution which would satisfy > both needs. IMO, that way would be performing automatic diffing of the recovered buffer with the on-disk file. If anything short of that is done, then the current behavior should be maintained. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: [PATCH] Set the buffer to be modified after recovery (was: Re: Save recovered file with ZZ?)
On 16-Apr-2010 Christian Brabandt wrote: > Hi James! > > On Fr, 16 Apr 2010, James Vega wrote: > > > On Fri, Apr 16, 2010 at 11:28 AM, Marvin Renich wrote: > > > * Christian Brabandt [100416 08:35]: > > >> This has come up on the vim_use mailinglist. The problem seems to be > > >> that after recovery of a swap buffer, the file should be modified so you > > >> are not loosing your changes after e.g. accidently hitting ZZ > > >> > > > Shouldn't this set curbuf->b_changed based on the "modified" setting > > > from the swap file, so that if you "recover" a file that was not > > > modified, you don't set the modified flag? > > > > I'd think that any time you recover from a swap file, the buffer should > > be considered "modified". The modified flag indicates that the buffer > > is different than the on-disk file with the same name. Whether or not > > the buffer was modified at the time that the swap file was last updated > > has no bearing on whether the content recovered from the swap file > > matches the current contents of the file that was being edited. That's > > up to the user to diagnose and decide what steps to take. > > That would be my understanding as well. Correct me if I am wrong, but I understand that the current behaviour is that if you recover a file it does not get the "modified" attribute. As a result if you press ZZ, you exit Vim without saving the recovered contents. While this might seem like a defect, I find it to prevent me from accidentally overwriting the contents of the original file on the disk. And I can always restore the contents that have not been written when I pressed ZZ by invoking Vim once again with "-r swapfile-name" arguments. IOW, I personally prefer the current behaviour. Still, I believe that there might be a somewhat more complicated solution which would satisfy both needs. But then, maybe Bram decides it's a bug in fact? -- Cheers, Lech -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: [PATCH] Set the buffer to be modified after recovery (was: Re: Save recovered file with ZZ?)
* James Vega [100416 11:43]: > On Fri, Apr 16, 2010 at 11:28 AM, Marvin Renich wrote: > > Shouldn't this set curbuf->b_changed based on the "modified" setting > > from the swap file, so that if you "recover" a file that was not > > modified, you don't set the modified flag? > > I'd think that any time you recover from a swap file, the buffer should > be considered "modified". The modified flag indicates that the buffer > is different than the on-disk file with the same name. Whether or not > the buffer was modified at the time that the swap file was last updated > has no bearing on whether the content recovered from the swap file > matches the current contents of the file that was being edited. That's > up to the user to diagnose and decide what steps to take. Maybe I am missing something. If you are recovering from a swap file, doesn't Vim read the current version of the file from disk, then apply the changes that are in the swap file? So, if the swap file has modified=no, the buffer will match the current version of the file on disk. Is there something else going on that I have missed? I don't think this is a big deal; if you are explicitly recovering, you probably are paying attention to what you are doing, but then again, this patch is because people asked to be notified if they try to quit without saving after recovering. ...Marvin -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: [PATCH] Set the buffer to be modified after recovery (was: Re: Save recovered file with ZZ?)
Hi James! On Fr, 16 Apr 2010, James Vega wrote: > On Fri, Apr 16, 2010 at 11:28 AM, Marvin Renich wrote: > > * Christian Brabandt [100416 08:35]: > >> This has come up on the vim_use mailinglist. The problem seems to be > >> that after recovery of a swap buffer, the file should be modified so you > >> are not loosing your changes after e.g. accidently hitting ZZ > >> > > Shouldn't this set curbuf->b_changed based on the "modified" setting > > from the swap file, so that if you "recover" a file that was not > > modified, you don't set the modified flag? > > I'd think that any time you recover from a swap file, the buffer should > be considered "modified". The modified flag indicates that the buffer > is different than the on-disk file with the same name. Whether or not > the buffer was modified at the time that the swap file was last updated > has no bearing on whether the content recovered from the swap file > matches the current contents of the file that was being edited. That's > up to the user to diagnose and decide what steps to take. That would be my understanding as well. regards, Christian -- hundred-and-one symptoms of being an internet addict: 107. When using your phone you forget that you don't have to use your keyboard. -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: [PATCH] Set the buffer to be modified after recovery (was: Re: Save recovered file with ZZ?)
On Fri, Apr 16, 2010 at 11:28 AM, Marvin Renich wrote: > [dropping vim_use] > > * Christian Brabandt [100416 08:35]: >> This has come up on the vim_use mailinglist. The problem seems to be >> that after recovery of a swap buffer, the file should be modified so you >> are not loosing your changes after e.g. accidently hitting ZZ >> >> Signed-off-by: Christian Brabandt >> --- >> src/memline.c | 1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/src/memline.c b/src/memline.c >> index 102b61e..c4a0d87 100644 >> --- a/src/memline.c >> +++ b/src/memline.c >> @@ -1326,6 +1326,7 @@ ml_recover() >> * the buffer. Delete it. >> */ >> ml_delete(curbuf->b_ml.ml_line_count, FALSE); >> + curbuf->b_changed = TRUE; >> curbuf->b_flags |= BF_RECOVERED; >> >> recoverymode = FALSE; >> -- >> 1.6.5.7 >> >> regards, >> Christian > > Shouldn't this set curbuf->b_changed based on the "modified" setting > from the swap file, so that if you "recover" a file that was not > modified, you don't set the modified flag? I'd think that any time you recover from a swap file, the buffer should be considered "modified". The modified flag indicates that the buffer is different than the on-disk file with the same name. Whether or not the buffer was modified at the time that the swap file was last updated has no bearing on whether the content recovered from the swap file matches the current contents of the file that was being edited. That's up to the user to diagnose and decide what steps to take. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: [PATCH] Set the buffer to be modified after recovery (was: Re: Save recovered file with ZZ?)
[dropping vim_use] * Christian Brabandt [100416 08:35]: > This has come up on the vim_use mailinglist. The problem seems to be > that after recovery of a swap buffer, the file should be modified so you > are not loosing your changes after e.g. accidently hitting ZZ > > Signed-off-by: Christian Brabandt > --- > src/memline.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/src/memline.c b/src/memline.c > index 102b61e..c4a0d87 100644 > --- a/src/memline.c > +++ b/src/memline.c > @@ -1326,6 +1326,7 @@ ml_recover() > * the buffer. Delete it. > */ > ml_delete(curbuf->b_ml.ml_line_count, FALSE); > +curbuf->b_changed = TRUE; > curbuf->b_flags |= BF_RECOVERED; > > recoverymode = FALSE; > -- > 1.6.5.7 > > regards, > Christian Shouldn't this set curbuf->b_changed based on the "modified" setting from the swap file, so that if you "recover" a file that was not modified, you don't set the modified flag? ...Marvin -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: syntax highlighting: how to skip ":" with paranthese
On Apr 15, 5:02 am, callpraths wrote:
> Hi,
> I tried searching the forum for a similar thread but to no avail.
> I am writing a syntax highlighting file and want recognise
> const as keyword.
So, you're writing a NEW syntax file, correct?
> The problem is that things like
> const:
> const:a
> should also be recognised, but not aconstb.
Sounds like you should just use a syn match command instead of a syn
keyword command, then you can construct a regex to use.
>
> Now, vim already is clear enough to recognise const( and highlights it. Is
> there a way of add ":" to the list of parentheses so that this goes through?
Huh? How did you get it to recognize "const("? In what way does Vim
"recognize" it? Unless you explicitly add the ( to the highlight rule,
Vim won't automatically highlight it the same as the "const" before
it, but you might be seeing some sort of parenthesis-matching behavior.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: Planning Vim 7.3
On 11-Apr-2010 Bram Moolenaar wrote:
>
> I hope to bring out a first beta version by the end of May. That gives
> everybody time to send me updated and polished patches and runtime
> files. I need to have these halfway May, I also need some time to
> integrate everything.
I attached a patch enabling the quickfix window titles which I sent to
vim-dev about a year ago. This is against Vim 7.2.411.
--
Cheers,
Lech
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
diff --git a/runtime/doc/cmdline.txt b/runtime/doc/cmdline.txt
index c87e61c..15becb7 100644
--- a/runtime/doc/cmdline.txt
+++ b/runtime/doc/cmdline.txt
@@ -505,6 +505,7 @@ followed by another Vim command:
:bufdo
:command
:cscope
+:csettitle
:debug
:folddoopen
:folddoclosed
@@ -513,6 +514,7 @@ followed by another Vim command:
:help
:helpfind
:lcscope
+:lsettitle
:make
:normal
:perl
diff --git a/runtime/doc/index.txt b/runtime/doc/index.txt
index afe1513..6d131ac 100644
--- a/runtime/doc/index.txt
+++ b/runtime/doc/index.txt
@@ -1147,6 +1147,7 @@ The commands are sorted on the non-optional part of their name.
|:cquit| :cq[uit] quit Vim with an error code
|:crewind| :cr[ewind] go to the specified error, default first one
|:cscope| :cs[cope] execute cscope command
+|:csettitle| :cse[ttitle] change the title of the quickfix window
|:cstag| :cst[ag] use cscope to jump to a tag
|:cunmap| :cu[nmap] like ":unmap" but for Command-line mode
|:cunabbrev| :cuna[bbrev] like ":unabbrev" but for Command-line mode
@@ -1296,6 +1297,7 @@ The commands are sorted on the non-optional part of their name.
|:lpfile| :lpf[ile] go to last location in previous file
|:lrewind| :lr[ewind] go to the specified location, default first one
|:ls| :ls list all buffers
+|:lsettitle| :lse[ttitle] like ":csettitle" but use the location list
|:ltag| :lt[ag] jump to tag and add matching tags to the
location list
|:lunmap| :lu[nmap] like ":unmap!" but includes Lang-Arg mode
diff --git a/runtime/doc/quickfix.txt b/runtime/doc/quickfix.txt
index 6734170..15f9296 100644
--- a/runtime/doc/quickfix.txt
+++ b/runtime/doc/quickfix.txt
@@ -310,7 +310,8 @@ use this code: >
'buftype' equal to "quickfix". Don't change this!
If there already is a quickfix window, it will be made
the current window. It is not possible to open a
- second quickfix window.
+ second quickfix window. The window's title will
+ indicate the command used to get the list of errors.
*:lop* *:lopen*
:lop[en] [height] Open a window to show the location list for the
@@ -335,6 +336,22 @@ use this code: >
:lw[indow] [height] Same as ":cwindow", except use the window showing the
location list for the current window.
+ *:cse* *:csettitle*
+:cse[ttitle] [arguments]
+ Change the title of the quickfix window. If no
+ arguments are provided, the title will be cleared.
+:cse[ttitle]!
+ Reset the quickfix window's title to the default
+ value.
+
+ *:lse* *:lsettitle*
+:lse[ttitle] [arguments]
+ Same as ":csettitle" but acts on the location list
+ window.
+:lse[ttitle]!
+ Reset the location window's title to the default
+ value.
+
Normally the quickfix window is at the bottom of the screen. If there are
vertical splits, it's at the bottom of the rightmost column of windows. To
make it always occupy the full width: >
diff --git a/runtime/doc/tags b/runtime/doc/tags
index cf872e7..36d1b82 100644
--- a/runtime/doc/tags
+++ b/runtime/doc/tags
@@ -1991,6 +1991,8 @@ $VIMRUNTIME starting.txt /*$VIMRUNTIME*
:crewind quickfix.txt /*:crewind*
:cs if_cscop.txt /*:cs*
:cscope if_cscop.txt /*:cscope*
+:cse quickfix.txt /*:cse*
+:csettitle quickfix.txt /*:csettitle*
:cstag if_cscop.txt /*:cstag*
:cu map.txt /*:cu*
:cuna map.txt /*:cuna*
@@ -2315,6 +2317,8 @@ $VIMRUNTIME starting.txt /*$VIMRUNTIME*
:lr quickfix.txt /*:lr*
:lrewind quickfix.txt /*:lrewind*
:ls windows.txt /*:ls*
+:lse quickfix.txt /*:lse*
+:lsettitle quickfix.txt /*:lsettitle*
:lt tagsrch.txt /*:lt*
:ltag tagsrch.txt /*:ltag*
:lu map.txt /*:lu*
diff --git a/src/buffer.c b/src/buffer.c
index 0569f16..1f0bb72 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -2548,6 +2548,7 @@ buflist_list(eap)
buf_T *buf;
int len;
int i;
+char_u *bname;
for (buf = firstbuf; buf != NULL && !got_int; buf = buf->b_next)
{
@@ -2555,8 +2556,11 @@ buflist_list(eap)
if (!buf->b_p_bl && !eap->forceit)
continue;
msg_putchar('\n');
- if (buf_spname(buf) != NULL)
- STRCPY(NameBuff, buf_spname(buf));
+ if ((bname = (char_u *)buf_spname(buf)) != NULL)
+ {
+ vim_strncpy(NameBuff, bname, MAXPATHL - 1);
+ vim_free(bname);
+ }
else
home_replace(buf, buf->b_fname, NameBuff,
[PATCH] Set the buffer to be modified after recovery (was: Re: Save recovered file with ZZ?)
Hi Tony! On Do, 15 Apr 2010, Tony Mechelynck wrote: [...] > After recovering, you should check the results, and, if correct, do a > "forced write" with :w or :wq (not ZZ :x :wa or :xa). But IMHO if the > recovery modifies the buffer (i.e. makes it different from the file on > disk), it should also set the local 'modified' option. This has come up on the vim_use mailinglist. The problem seems to be that after recovery of a swap buffer, the file should be modified so you are not loosing your changes after e.g. accidently hitting ZZ Signed-off-by: Christian Brabandt --- src/memline.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/memline.c b/src/memline.c index 102b61e..c4a0d87 100644 --- a/src/memline.c +++ b/src/memline.c @@ -1326,6 +1326,7 @@ ml_recover() * the buffer. Delete it. */ ml_delete(curbuf->b_ml.ml_line_count, FALSE); +curbuf->b_changed = TRUE; curbuf->b_flags |= BF_RECOVERED; recoverymode = FALSE; -- 1.6.5.7 regards, Christian -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: syntax highlighting: how to skip ":" with paranthese
On 15-Apr-2010 callpraths wrote:
>
> Hi,
> I tried searching the forum for a similar thread but to no avail.
> I am writing a syntax highlighting file and want recognise
> const as keyword.
> The problem is that things like
> const:
> const:a
> should also be recognised, but not aconstb.
>
> Now, vim already is clear enough to recognise const( and highlights it. Is
> there a way of add ":" to the list of parentheses so that this goes through?
> Is there an alternative way of achieving what I need.
>
> Thanks in advance for all the help.
I have to admit that I don't understand your problem. Would you describe
it in more details?
How should "const" be highlighted?
How exactly (character-by-character) should "const:a" be highlighted?
Where does Vim recognise "const(" and how does it highlight it?
--
Cheers,
Lech
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
