Re: FW: use of vim signs

148 views
Skip to first unread message

Christian Brabandt

unread,
May 30, 2013, 3:07:46 AM5/30/13
to vim...@vim.org
Forwarding to vim-dev

On Mi, 29 Mai 2013, Ben Fritz wrote:

> I like the proposal by "glts" myself:
>
> > - ":set nonu nornu" means: I don't want any line numbers;
> > - ":set nu nornu" means: I want to see only absolute numbers;
> > - ":set nonu rnu" means: I want to see only relative numbers;
> > - ":set nu rnu" means: I want to have the best of both worlds.
>
> Christian, what is the problem you have with this approach?

I think, this is confusing. But as I said, I don't have a strong opinion
on that, so here is a patch to try out:

regards,
Christian
--
Die Natur bek�mmert sich nicht um irgendeinen Irrtum; sie selbst
kann nicht anders, als ewig recht handeln, unbek�mmert, was daraus
erfolgen m�ge.
-- Goethe, Maximen und Reflektionen, Nr. 958
number_relativenumber.diff

Nazri Ramliy

unread,
May 30, 2013, 5:13:05 AM5/30/13
to vim_dev, Vimdev
On Thu, May 30, 2013 at 3:07 PM, Christian Brabandt <cbl...@256bit.org> wrote:
> Forwarding to vim-dev
>
> On Mi, 29 Mai 2013, Ben Fritz wrote:
>
>> I like the proposal by "glts" myself:
>>
>> > - ":set nonu nornu" means: I don't want any line numbers;
>> > - ":set nu nornu" means: I want to see only absolute numbers;
>> > - ":set nonu rnu" means: I want to see only relative numbers;
>> > - ":set nu rnu" means: I want to have the best of both worlds.

I like this option-interrelationship. The code simpler too. The only missing
'feature' is the alignment of the current number (patch posted at [1]), compare
(editing misc1.c):

--8<--
1 {
97 char_u *p;
1 char_u *newline;
2 char_u *oldline;
-->8--

vs:

--8<--
1 {
97 char_u *p;
1 char_u *newline;
2 char_u *oldline;
-->8--

The former differentiates the current line number from the relatives ones by
aligning it to the left. This leaves a quite visible gap in the number column
- some people would find this aesthetically displeasing. I find that my brain
spends like a few milliseconds :) saying "oh this blank here is not really part
of the file content, it's the left over space for the current line number" - it
can be distracting at times. Ironically the intention of showing the current
line number there is to avoid the distraction of having to move your eyes down
to the statusline just to find out the current line number.

The latter keeps the current line number aligned with the relative ones.
There's no more gap - no more distraction when eyeballing the lines.
Some would argue that now it's a bit hard to differentiate between current line
number and the relative ones but that can be solved via syntax highlighting but
then there's also people who do not prefer colors in their editor.

Choices... choices...

:/

nazri

[1] https://groups.google.com/forum/#!msg/vim_dev/tOmXNHXsAKE/EiozNh9nUDgJ

Christian Brabandt

unread,
Jun 2, 2013, 7:52:42 AM6/2/13
to vim...@vim.org, Bram Moolenaar
Bram,

On Do, 30 Mai 2013, Christian Brabandt wrote:

> Forwarding to vim-dev
>
> On Mi, 29 Mai 2013, Ben Fritz wrote:
>
> > I like the proposal by "glts" myself:
> >
> > > - ":set nonu nornu" means: I don't want any line numbers;
> > > - ":set nu nornu" means: I want to see only absolute numbers;
> > > - ":set nonu rnu" means: I want to see only relative numbers;
> > > - ":set nu rnu" means: I want to have the best of both worlds.
> >
> > Christian, what is the problem you have with this approach?
>
> I think, this is confusing. But as I said, I don't have a strong opinion
> on that, so here is a patch to try out:

displaying the absolute line number instead of the zero for relative
line numbering seems to have caused many controversial opinions here and
at vim-use (but I have not seen it in the latest todo.txt file).

Would you consider any of the patches that make this behaviour
customizable for the vim 7.4 release?

regards,
Christian
--
Willst du den Wert des Geldes kennenlernen, geh und versuche dir
welches zu borgen.
-- Benjamin Franklin

Bram Moolenaar

unread,
Jun 2, 2013, 10:57:33 AM6/2/13
to Christian Brabandt, vim...@vim.org

Christian Brabandt wrote:

> On Do, 30 Mai 2013, Christian Brabandt wrote:
>
> > Forwarding to vim-dev
> >
> > On Mi, 29 Mai 2013, Ben Fritz wrote:
> >
> > > I like the proposal by "glts" myself:
> > >
> > > > - ":set nonu nornu" means: I don't want any line numbers;
> > > > - ":set nu nornu" means: I want to see only absolute numbers;
> > > > - ":set nonu rnu" means: I want to see only relative numbers;
> > > > - ":set nu rnu" means: I want to have the best of both worlds.
> > >
> > > Christian, what is the problem you have with this approach?
> >
> > I think, this is confusing. But as I said, I don't have a strong opinion
> > on that, so here is a patch to try out:
>
> displaying the absolute line number instead of the zero for relative
> line numbering seems to have caused many controversial opinions here and
> at vim-use (but I have not seen it in the latest todo.txt file).
>
> Would you consider any of the patches that make this behaviour
> customizable for the vim 7.4 release?

There is too much discussion about this. I think the current behavior
is OK and does not have enough disadvantage to justify adding yet
another option.

--
hundred-and-one symptoms of being an internet addict:
42. Your virtual girlfriend finds a new net sweetheart with a larger bandwidth.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Christian Brabandt

unread,
Jun 2, 2013, 2:23:57 PM6/2/13
to vim...@vim.org
Hi Bram!

On So, 02 Jun 2013, Bram Moolenaar wrote:

> There is too much discussion about this. I think the current behavior
> is OK and does not have enough disadvantage to justify adding yet
> another option.

Note, that latest patch I sent, does not require an extra option, is
rather small, makes the code much more readable (imho) and we can even
get rid of test89.

regards,
Christian
--
Ich leider nicht, meine Freunde; aber ich f�hle eine gewisse
Schwierigkeit zu existieren.
-- Bernard Le Bovier de Fontenelle

Bram Moolenaar

unread,
Jun 2, 2013, 3:30:20 PM6/2/13
to Christian Brabandt, vim...@vim.org

Christian Brabandt wrote:

> On So, 02 Jun 2013, Bram Moolenaar wrote:
>
> > There is too much discussion about this. I think the current behavior
> > is OK and does not have enough disadvantage to justify adding yet
> > another option.
>
> Note, that latest patch I sent, does not require an extra option, is
> rather small, makes the code much more readable (imho) and we can even
> get rid of test89.

You mean the patch you sent on May 30?
I don't see anybody responding that they like that solution.

--
hundred-and-one symptoms of being an internet addict:
52. You ask a plumber how much it would cost to replace the chair in front of
your computer with a toilet.

glts

unread,
Jun 2, 2013, 4:07:24 PM6/2/13
to vim...@googlegroups.com, vim...@vim.org
On Sunday, June 2, 2013 9:30:20 PM UTC+2, Bram Moolenaar wrote:

> Christian Brabandt wrote:
>
> > Note, that latest patch I sent, does not require an extra option, is
> > rather small, makes the code much more readable (imho) and we can even
> > get rid of test89.
>
> You mean the patch you sent on May 30?
> I don't see anybody responding that they like that solution.

This is exactly one of the reasons people are calling for a proper issue
tracker on BitBucket or similar. I remember reading one dismissive and
three favourable reactions to this idea either on vim_dev or on vim_use.
On an issue tracker these would have been impossible to overlook.

I proposed this originally but I'm still undecided. I think it would be
good to hear a few more voices.

Grant Farnsworth

unread,
Jun 2, 2013, 4:36:54 PM6/2/13
to vim...@googlegroups.com, Christian Brabandt, vim...@vim.org
> - ":set nonu nornu" means: I don't want any line numbers;
> - ":set nu nornu" means: I want to see only absolute numbers;
> - ":set nonu rnu" means: I want to see only relative numbers;
> - ":set nu rnu" means: I want to have the best of both worlds.

In my opinion this is the best solution I have heard. It preserves the functionality of what people on both sides of the issue want without adding additional options.

I think it actually makes the numbering options in question a little *more* intuitive: I recall that I was confused when I started using vim because I was not expecting setting nu to also unset rnu and vice versa. I guess I was expecting to see both relative numbers and absolute numbers if both were set to true, even though it is unlikely I would ever want it that way. So to me having both options set to true result in a hybrid numbering scheme that includes the current absolute number and the other numbers as relative makes sense.

I believe this is what Christian's patch does, so count me as a fan. Sorry I didn't speak up in support earlier.

Bram Moolenaar

unread,
Jun 2, 2013, 5:09:07 PM6/2/13
to glts, vim...@vim.org
There already is an issue tracker.

--
hundred-and-one symptoms of being an internet addict:
54. You start tilting your head sideways to smile. :-)

ZyX ZyX

unread,
Jun 2, 2013, 6:02:00 PM6/2/13
to vim...@googlegroups.com


On Jun 3, 2013 1:09 AM, "Bram Moolenaar" <Br...@moolenaar.net> wrote:
>
>
> Glts wrote:
>
> > On Sunday, June 2, 2013 9:30:20 PM UTC+2, Bram Moolenaar wrote:
> > > Christian Brabandt wrote:
> > >
> > > > Note, that latest patch I sent, does not require an extra option, is
> > > > rather small, makes the code much more readable (imho) and we can even
> > > > get rid of test89.
> > >
> > > You mean the patch you sent on May 30?
> > > I don't see anybody responding that they like that solution.
> >
> > This is exactly one of the reasons people are calling for a proper issue
> > tracker on BitBucket or similar. I remember reading one dismissive and
> > three favourable reactions to this idea either on vim_dev or on vim_use.
> > On an issue tracker these would have been impossible to overlook.
> >
> > I proposed this originally but I'm still undecided. I think it would be
> > good to hear a few more voices.
>
> There already is an issue tracker.

I can hardly call what Google code has an issue tracker. It lacks basic functionality. It does not even support formatting and attachments, not to mention more advanced things like components. Or such a thing like finely looking UI. It is not surprising most people do not want to use it.

And there are no PR's here. Other issue tracker problems are tolerable,  absence of PR's and attachments makes it impossible to hold patches there making it useless when it comes to resolving the mentioned problem.

> --
> hundred-and-one symptoms of being an internet addict:
> 54. You start tilting your head sideways to smile. :-)
>
>  /// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net   \\\
> ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\  an exciting new programming language -- http://www.Zimbu.org        ///
>  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///
>

> --
> --
> 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
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Bram Moolenaar

unread,
Jun 3, 2013, 5:16:12 AM6/3/13
to ZyX ZyX, vim...@googlegroups.com

ZyX wrote:

> On Jun 3, 2013 1:09 AM, "Bram Moolenaar" <Br...@moolenaar.net> wrote:
> >
> >
> > Glts wrote:
> >
> > > On Sunday, June 2, 2013 9:30:20 PM UTC+2, Bram Moolenaar wrote:
> > > > Christian Brabandt wrote:
> > > >
> > > > > Note, that latest patch I sent, does not require an extra option, is
> > > > > rather small, makes the code much more readable (imho) and we
> > > > > can even get rid of test89.
> > > >
> > > > You mean the patch you sent on May 30?
> > > > I don't see anybody responding that they like that solution.
> > >
> > > This is exactly one of the reasons people are calling for a proper issue
> > > tracker on BitBucket or similar. I remember reading one dismissive and
> > > three favourable reactions to this idea either on vim_dev or on vim_use.
> > > On an issue tracker these would have been impossible to overlook.
> > >
> > > I proposed this originally but I'm still undecided. I think it would be
> > > good to hear a few more voices.
> >
> > There already is an issue tracker.
>
> I can hardly call what Google code has an issue tracker. It lacks basic
> functionality. It does not even support formatting and attachments, not to
> mention more advanced things like components. Or such a thing like finely
> looking UI. It is not surprising most people do not want to use it.

It does support attachments.

> And there are no PR's here. Other issue tracker problems are tolerable,
> absence of PR's and attachments makes it impossible to hold patches there
> making it useless when it comes to resolving the mentioned problem.

What's a PR? Problem Report?

I don't think that the functionality of the Issue Tracker is relevant.
What matters is that the discussions happen on the vim-dev maillist,
that's where the developers are. I don't see that changing no matter
how beautiful or functional any issue tracker would be.

For me, the main issue with Issue trackers is that I can't edit them
with Vim. Switching to a browser and having to click around slows down
my work. That's why I use the todo list.

--
hundred-and-one symptoms of being an internet addict:
58. You turn on your computer and turn off your wife.

Ben Fritz

unread,
Jun 3, 2013, 10:24:08 AM6/3/13
to vim...@googlegroups.com, ZyX ZyX

I think he is referring to a "pull request", so that somebody can fix an issue in a clone of the repository, and request that you pull in and merge the changes.

I didn't get the impression that was something you'd want to do anyway.

But maybe you'd start accepting Hg "bundle"s? Then there would be no doubt where the changes were based on and less bitrot compared to a patch (though a merge or rebase will be needed).

>
> I don't think that the functionality of the Issue Tracker is relevant.
>
> What matters is that the discussions happen on the vim-dev maillist,
>
> that's where the developers are. I don't see that changing no matter
>
> how beautiful or functional any issue tracker would be.
>
>

GitHub's issue tracker is very pretty and has a lot of features. I haven't used BitBucket, I imagine it is similar. Google Code is not as nice, but it's certainly not the worst I've seen. And if you don't plan to use a feature, I don't think it's relevant whether it's there or not.

>
> For me, the main issue with Issue trackers is that I can't edit them
>
> with Vim. Switching to a browser and having to click around slows down
>
> my work. That's why I use the todo list.
>

One problem with the todo list, is that it is not up-to-date until you publish runtime files periodically. So sometimes it is hard to tell whether you noticed a patch or fixed a bug in a later version. And, once a bug goes away from the TODO list, nobody can find it later to see that it was an issue but has been fixed (and when).

Bram Moolenaar

unread,
Jun 3, 2013, 11:42:03 AM6/3/13
to Ben Fritz, vim...@googlegroups.com, ZyX ZyX

Ben Fritz wrote:

> On Monday, June 3, 2013 4:16:12 AM UTC-5, Bram Moolenaar wrote:
> > ZyX wrote:
> >
> > > On Jun 3, 2013 1:09 AM, "Bram Moolenaar" <Br...@moolenaar.net> wrote:
> >
> > > > Glts wrote:
> >
> > > > > On Sunday, June 2, 2013 9:30:20 PM UTC+2, Bram Moolenaar wrote:
> >
> > > > > > Christian Brabandt wrote:
>
> [...]
> > > And there are no PR's here. Other issue tracker problems are tolerable,
> > > absence of PR's and attachments makes it impossible to hold patches there
> > > making it useless when it comes to resolving the mentioned problem.
> >
> > What's a PR? Problem Report?
>
> I think he is referring to a "pull request", so that somebody can fix
> an issue in a clone of the repository, and request that you pull in
> and merge the changes.
>
> I didn't get the impression that was something you'd want to do anyway.
>
> But maybe you'd start accepting Hg "bundle"s? Then there would be no
> doubt where the changes were based on and less bitrot compared to a
> patch (though a merge or rebase will be needed).

Context diffs work just fine. Anybody with basic Linux tools can use
them, no need to figure out hg or git commands and setting up an
environment where they work. I hardly ever had a problem with "bitrot",
except for refactorings where nothing would help.

[...]

> One problem with the todo list, is that it is not up-to-date until you
> publish runtime files periodically. So sometimes it is hard to tell
> whether you noticed a patch or fixed a bug in a later version. And,
> once a bug goes away from the TODO list, nobody can find it later to
> see that it was an issue but has been fixed (and when).

Keeping the TODO list up-to-date is less work than updating stuff on
some website. Whatever issue tracker there is, it's not going to make
MY work more efficient. And since I'm the bottleneck that's what
matters.

There was a promise from someone to keep the Issue Tracker up to date,
close fixed issues and so on, but that doesn't really appear to happen.
I don't really have time to do that on top of everything else.

In an ideal world everything happens wonderfully, we'll have to live
with the real world.

--
hundred-and-one symptoms of being an internet addict:
68. Your cat always puts viruses on your dogs homepage

Ben Fritz

unread,
Jun 3, 2013, 1:30:43 PM6/3/13
to vim...@googlegroups.com, Ben Fritz, ZyX ZyX
Sorry for the duplicate, Bram. I meant to include the list and forgot to "reply all".

On Mon, Jun 3, 2013 at 10:42 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:


>
> Ben Fritz wrote:
>
>> One problem with the todo list, is that it is not up-to-date until you
>> publish runtime files periodically. So sometimes it is hard to tell
>> whether you noticed a patch or fixed a bug in a later version. And,
>> once a bug goes away from the TODO list, nobody can find it later to
>> see that it was an issue but has been fixed (and when).
>
> Keeping the TODO list up-to-date is less work than updating stuff on
> some website. Whatever issue tracker there is, it's not going to make
> MY work more efficient. And since I'm the bottleneck that's what
> matters.
>

I assume you keep the todo list up-to-date as you work, but you just
don't commit/push it until you have other runtime file updates to
push. Do you think you could commit/push the TODO list alongside the
patch (or patch series) when you apply it? That might help to some
extent. Looking at the patches README can help figure out when/if
something got fixed. But it is still sometimes hard to figure out from
the short patch description, what the specific issue is. An issue
tracker ID is helpful there, but a vim_dev discussion link might do as
well. Or at least a date to go with the name of the person
reporting/fixing it.

List admins (or any other responders on the list) can help with having
too many different discussions on the same issue, by referring any
duplicate discussions back to the first discussion and continuing
there only. There is a "close topic" action admins can apply to any
thread, I assume this will prevent new posts to a topic if it has been
referred to a different thread.

ZyX ZyX

unread,
Jun 3, 2013, 4:45:45 PM6/3/13
to Bram Moolenaar, vim...@googlegroups.com, Ben Fritz

The basic idea of having an issue tracker is that *all* bugs, feature requests and pull requests (PR's) go there. Thus you don't need to sync anything since there is nothing to sync with. I.e. switching to issue tracker means shutting down vim-dev mailing list. Otherwise it is not that useful and it either needs to be kept in sync or will contain only partial information.

Note that even Google code bug tracker allows using regular emails to respond to the issue.

Benjamin Fritz

unread,
Jun 3, 2013, 5:36:05 PM6/3/13
to ZyX ZyX, Bram Moolenaar, vim_dev
On Mon, Jun 3, 2013 at 3:45 PM, ZyX ZyX <zyx...@gmail.com> wrote:
>
>
> The basic idea of having an issue tracker is that *all* bugs, feature
> requests and pull requests (PR's) go there.

Yes, if the developers decide they're worth doing anyway. It would
replace the TODO list.

> Thus you don't need to sync
> anything since there is nothing to sync with. I.e. switching to issue
> tracker means shutting down vim-dev mailing list.

No. Some projects (TortoiseSVN for example) require that all issues be
vetted on a mailing list before they go in the bug tracker. Entering a
bug in the tracker without agreement on the mailing list means the bug
gets rejected without inspection. Then only relevant information to
resolving or reproducing the bug goes in the issue tracker. Discussion
about how to fix the bug (or whether to fix it) can go on in the
mailing list. Many projects have a mailing list as first contact, and
then the response is not "I'll add it to the TODO list", it is "filed
as bug ID 123456".

Ben Fritz

unread,
Jun 3, 2013, 5:39:21 PM6/3/13
to vim...@googlegroups.com, Christian Brabandt, vim...@vim.org

Back on topic: Bram, this method seems to have a good deal of support, and does not introduce any new options. What do you think?

Bram Moolenaar

unread,
Jun 4, 2013, 5:18:49 AM6/4/13
to Ben Fritz, vim...@googlegroups.com, Christian Brabandt, vim...@vim.org
Yeah, it appears this time there is nobody against this solution.

--
hundred-and-one symptoms of being an internet addict:
78. You find yourself dialing IP numbers on the phone.

tooth pik

unread,
Jun 4, 2013, 6:13:53 AM6/4/13
to vim...@googlegroups.com
On Tue, Jun 04, 2013 at 11:18:49AM +0200, Bram Moolenaar wrote:

> Ben Fritz wrote:

> > On Sunday, June 2, 2013 3:36:54 PM UTC-5, Grant Farnsworth wrote:
> > > > - ":set nonu nornu" means: I don't want any line numbers;
> > > > - ":set nu nornu" means: I want to see only absolute numbers;
> > > > - ":set nonu rnu" means: I want to see only relative numbers;
> > > > - ":set nu rnu" means: I want to have the best of both worlds.
> > >
> > > In my opinion this is the best solution I have heard. It preserves
> > > the functionality of what people on both sides of the issue want
> > > without adding additional options.
> > >
> > > I think it actually makes the numbering options in question a little
> > > *more* intuitive: I recall that I was confused when I started using
> > > vim because I was not expecting setting nu to also unset rnu and
> > > vice versa. I guess I was expecting to see both relative numbers
> > > and absolute numbers if both were set to true, even though it is
> > > unlikely I would ever want it that way. So to me having both options
> > > set to true result in a hybrid numbering scheme that includes the
> > > current absolute number and the other numbers as relative makes
> > > sense.
> > >
> > > I believe this is what Christian's patch does, so count me as a fan.
> > > Sorry I didn't speak up in support earlier.
> >
> > Back on topic: Bram, this method seems to have a good deal of support,
> > and does not introduce any new options. What do you think?

> Yeah, it appears this time there is nobody against this solution.

it is indeed an intuitive and option minimizing approach, and our BDFL
isn't against it -- that matters

oh mama -- if I were a practiced patch cooker-upper I'd be on this --
I know exactly what we need here -- it's all in the thread -- the two
gotchas are (1) I am NOT a practiced patch cooker-upper, and (2) Bram
only accepts patches from ppl who post their real name right here in
front of god and everybody -- eesh -- that is so not me -- Grant? --
Christian?...

we are soo close...

--
_|_ _ __|_|_ ._ o|
|_(_)(_)|_| ||_)||<
|

Charles Campbell

unread,
Jun 5, 2013, 11:38:20 AM6/5/13
to vim...@googlegroups.com
Bram Moolenaar wrote:
> [snip] (discussion about relative numbers)
> There is too much discussion about this. I think the current behavior
> is OK and does not have enough disadvantage to justify adding yet
> another option.
I won't be using the relative numbers option in its current state.

Regards,
C Campbell

Charles Campbell

unread,
Jun 5, 2013, 11:43:23 AM6/5/13
to vim...@googlegroups.com
Christian Brabandt wrote:
> Forwarding to vim-dev
>
> On Mi, 29 Mai 2013, Ben Fritz wrote:
>
>> I like the proposal by "glts" myself:
>>
>>> - ":set nonu nornu" means: I don't want any line numbers;
>>> - ":set nu nornu" means: I want to see only absolute numbers;
>>> - ":set nonu rnu" means: I want to see only relative numbers;
>>> - ":set nu rnu" means: I want to have the best of both worlds.
>> Christian, what is the problem you have with this approach?
> I think, this is confusing. But as I said, I don't have a strong opinion
> on that, so here is a patch to try out:
>
I plan on trying your patch out soon, probably tonight (can't build vim
on my SL6.3 at work properly, although I can build it on a SL6.3 system
at home). Sounds like a good solution to me.

Regards,
C Campbell

Ben Fritz

unread,
Jun 5, 2013, 11:54:31 AM6/5/13
to vim...@googlegroups.com, charles.e...@nasa.gov
On Wednesday, June 5, 2013 10:43:23 AM UTC-5, Charles Campbell wrote:
>
> I plan on trying your patch out soon, probably tonight (can't build vim
>
> on my SL6.3 at work properly, although I can build it on a SL6.3 system
>
> at home). Sounds like a good solution to me.
>

It looks like it became patch 7.3.1115.

Reply all
Reply to author
Forward
0 new messages