Re: [Windows] Remove the default binding between buffer-zoom and Alt+0

[Richard Kimberly Heck]

On 1/15/21 10:59 PM, Joel Kulesza wrote:
> On Fri, Jan 15, 2021 at 7:46 PM Scott Kostyshak  > wrote:
>
> On Fri, Jan 15, 2021 at 08:27:23PM -0500, Richard Kimberly Heck wrote:
> > On 1/15/21 3:57 PM, Yuriy Skalko wrote:
> > >> However, by default, in LyX, this has a very problematic
> side-effect:
> > >> Alt+0
> > >> resets the zoom level to zero. Personally, I know how to
> configure this
> > >> shortcut, but newcomers may be left puzzled (and leave
> completely).
> > >>
> > >> Moreover, it's more common to use Ctrl+0 to reset the zoom
> level, at
> > >> least
> > >> on Windows: most Web browsers do it (at least Firefox,
> Chrome, and
> > >> IE), all
> > >> Microsoft Office programs. It does not work for LibreOffice or
> > >> Notepad++.
> > >>
> > >> I would propose to change the default binding to Ctrl+0, as
> it's more
> > >> common (although not ubiquitous), and this would fix the
> problem of
> > >> changing zoom when you try to insert a character.
> > >>
> > >> What do you think of this?
> > >
> > > There are also zooming shortcuts Alt+"+", Alt+"-". To be
> consistent
> > > these should also use Ctrl. But Ctrl+"-" is already bound to
> > > Hyphenation Point insert. Is it OK to rebind it to Alt+"-"?
> >
> > I'm pretty used to it as it is. I'm not sure we need to worry
> too much
> > about consistency here, though I'll be interested to hear what
> others
> > have to say.
>
> I think I would support changing the bindings to be more
> consistent with other applications. I forget why we have things
> the way they are.
>
>
> Coming from another OS (macOS), I'd expect Ctrl-+ to be zoom in,
> Ctrl-"-" to be zoom out, and Ctrl-0 to be reset zoom (to be the
> corollaries of the idiomatic Cmd-... behavior on macOS).  So, I'd
> support this binding change.

There is the option of having platform-specific bindings.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Windows] Remove the default binding between buffer-zoom and Alt+0

[Richard Kimberly Heck]

On 1/15/21 10:36 PM, Andrew Parsloe wrote:
> On 16/01/2021 3:46 pm, Scott Kostyshak wrote:
>> On Fri, Jan 15, 2021 at 08:27:23PM -0500, Richard Kimberly Heck wrote:
>>> On 1/15/21 3:57 PM, Yuriy Skalko wrote:
> However, by default, in LyX, this has a very problematic side-effect:
> Alt+0
> resets the zoom level to zero. Personally, I know how to configure this
> shortcut, but newcomers may be left puzzled (and leave completely).
>
> Moreover, it's more common to use Ctrl+0 to reset the zoom level, at
> least
> on Windows: most Web browsers do it (at least Firefox, Chrome, and
> IE), all
> Microsoft Office programs. It does not work for LibreOffice or
> Notepad++.
>
> I would propose to change the default binding to Ctrl+0, as it's more
> common (although not ubiquitous), and this would fix the problem of
> changing zoom when you try to insert a character.
>
> What do you think of this?
 There are also zooming shortcuts Alt+"+", Alt+"-". To be consistent
 these should also use Ctrl. But Ctrl+"-" is already bound to
 Hyphenation Point insert. Is it OK to rebind it to Alt+"-"?
>>> I'm pretty used to it as it is. I'm not sure we need to worry too much
>>> about consistency here, though I'll be interested to hear what others
>>> have to say.
>> I think I would support changing the bindings to be more consistent with 
>> other applications. I forget why we have things the way they are.
>>
>> Scott
>
> As a LyX user on windows, I would be reluctant to see Ctrl+-  changed.
> To meit sits comfortably alongside Ctrl+space to give a protected space
>
This is the kind of thing I had in mind. I've been using Ctrl+- for a
protected hyphen since Word Perfect, at least (which is what I used
before switching to Linux in 2002 or so).

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Windows] Remove the default binding between buffer-zoom and Alt+0

[Richard Kimberly Heck]

On 1/15/21 10:36 PM, Andrew Parsloe wrote:
> On 16/01/2021 3:46 pm, Scott Kostyshak wrote:
>> On Fri, Jan 15, 2021 at 08:27:23PM -0500, Richard Kimberly Heck wrote:
>>> On 1/15/21 3:57 PM, Yuriy Skalko wrote:
> However, by default, in LyX, this has a very problematic side-effect:
> Alt+0
> resets the zoom level to zero. Personally, I know how to configure this
> shortcut, but newcomers may be left puzzled (and leave completely).
>
> Moreover, it's more common to use Ctrl+0 to reset the zoom level, at
> least
> on Windows: most Web browsers do it (at least Firefox, Chrome, and
> IE), all
> Microsoft Office programs. It does not work for LibreOffice or
> Notepad++.
>
> I would propose to change the default binding to Ctrl+0, as it's more
> common (although not ubiquitous), and this would fix the problem of
> changing zoom when you try to insert a character.
>
> What do you think of this?
 There are also zooming shortcuts Alt+"+", Alt+"-". To be consistent
 these should also use Ctrl. But Ctrl+"-" is already bound to
 Hyphenation Point insert. Is it OK to rebind it to Alt+"-"?
>>> I'm pretty used to it as it is. I'm not sure we need to worry too much
>>> about consistency here, though I'll be interested to hear what others
>>> have to say.
>> I think I would support changing the bindings to be more consistent with 
>> other applications. I forget why we have things the way they are.
>>
>> Scott
>
> As a LyX user on windows, I would be reluctant to see Ctrl+-  changed.
> To meit sits comfortably alongside Ctrl+space to give a protected
> space. (To my mind, the odd one out is Alt+. to give an ellipsis
> rather than Ctrl+. for this function.  To maintain equilibrium I
> recall JMarc's description from 17 Jul 2018, "remember that LyX is a
> platypus: something so weirdly designed that everybody is surprised
> that it even exists.")
>
Does LyX glow under black light?

https://www.thecut.com/2020/11/scientists-find-platypuses-glow-under-black-light.html

Someone should file an enhancement request

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX features/InsetParams-refactoring] Refactor decodeInsetParam

[Richard Kimberly Heck]

On 1/15/21 2:10 PM, Yuriy Skalko wrote:
> The branch, InsetParams-refactoring, has been updated.
>   discards  f7c88f53c728d138a7a4292cb94c7ea9d8b560d4 (commit)
>   discards  84563911f714f30b8b794bc2fd938f4f73be6f61 (commit)
>   discards  8ea179303d9e1a0dfb40a28b51154c8c2d766a8d (commit)
>   discards  79e037acd39f6ed3835dee151534b73d61da494a (commit)
>   discards  1d96fa7d50c1ce630f0d1136248a28efd588374c (commit)
>   discards  e3d38bebe72dabab3633cddbaa42fcccedf44465 (commit)
>   discards  d93fa78d901da730b72dbbd035b8f82dc4e42b54 (commit)
>   discards  67c87aa6a85c0a9327d1c28a38dd559614d6c5c8 (commit)
>
> This update added new revisions after undoing existing revisions.  That is
> to say, the old revision is not a strict subset of the new revision.  This
> situation occurs when you --force push a change and generate a repository
> containing something like this:
>
>  * -- * -- B -- O -- O -- O (f7c88f53c728d138a7a4292cb94c7ea9d8b560d4)
> \
>  N -- N -- N (c8085f7472a8c41f4b14070dc88a41a3629d9aa7)
>
> When this happens we assume that you've already had alert emails for all
> of the O revisions, and so we here report only the revisions in the N
> branch from the common base, B.
>
> - Log -
>
> commit c8085f7472a8c41f4b14070dc88a41a3629d9aa7
> Author: Yuriy Skalko 
> Date:   Sun Jan 10 11:05:58 2021 +0200
>
> Refactor decodeInsetParam

These have mostly been posted before, yes?

Riki



-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Windows] Remove the default binding between buffer-zoom and Alt+0

[Joel Kulesza]

On Fri, Jan 15, 2021 at 7:46 PM Scott Kostyshak  wrote:

> On Fri, Jan 15, 2021 at 08:27:23PM -0500, Richard Kimberly Heck wrote:
> > On 1/15/21 3:57 PM, Yuriy Skalko wrote:
> > >> However, by default, in LyX, this has a very problematic side-effect:
> > >> Alt+0
> > >> resets the zoom level to zero. Personally, I know how to configure
> this
> > >> shortcut, but newcomers may be left puzzled (and leave completely).
> > >>
> > >> Moreover, it's more common to use Ctrl+0 to reset the zoom level, at
> > >> least
> > >> on Windows: most Web browsers do it (at least Firefox, Chrome, and
> > >> IE), all
> > >> Microsoft Office programs. It does not work for LibreOffice or
> > >> Notepad++.
> > >>
> > >> I would propose to change the default binding to Ctrl+0, as it's more
> > >> common (although not ubiquitous), and this would fix the problem of
> > >> changing zoom when you try to insert a character.
> > >>
> > >> What do you think of this?
> > >
> > > There are also zooming shortcuts Alt+"+", Alt+"-". To be consistent
> > > these should also use Ctrl. But Ctrl+"-" is already bound to
> > > Hyphenation Point insert. Is it OK to rebind it to Alt+"-"?
> >
> > I'm pretty used to it as it is. I'm not sure we need to worry too much
> > about consistency here, though I'll be interested to hear what others
> > have to say.
>
> I think I would support changing the bindings to be more consistent with
> other applications. I forget why we have things the way they are.
>

Coming from another OS (macOS), I'd expect Ctrl-+ to be zoom in, Ctrl-"-"
to be zoom out, and Ctrl-0 to be reset zoom (to be the corollaries of the
idiomatic Cmd-... behavior on macOS).  So, I'd support this binding change.

- Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Windows] Remove the default binding between buffer-zoom and Alt+0

[Andrew Parsloe]

On 16/01/2021 3:46 pm, Scott Kostyshak wrote:

On Fri, Jan 15, 2021 at 08:27:23PM -0500, Richard Kimberly Heck wrote:

On 1/15/21 3:57 PM, Yuriy Skalko wrote:

However, by default, in LyX, this has a very problematic side-effect:
Alt+0
resets the zoom level to zero. Personally, I know how to configure this
shortcut, but newcomers may be left puzzled (and leave completely).

Moreover, it's more common to use Ctrl+0 to reset the zoom level, at
least
on Windows: most Web browsers do it (at least Firefox, Chrome, and
IE), all
Microsoft Office programs. It does not work for LibreOffice or
Notepad++.

I would propose to change the default binding to Ctrl+0, as it's more
common (although not ubiquitous), and this would fix the problem of
changing zoom when you try to insert a character.

What do you think of this?

There are also zooming shortcuts Alt+"+", Alt+"-". To be consistent
these should also use Ctrl. But Ctrl+"-" is already bound to
Hyphenation Point insert. Is it OK to rebind it to Alt+"-"?

I'm pretty used to it as it is. I'm not sure we need to worry too much
about consistency here, though I'll be interested to hear what others
have to say.

I think I would support changing the bindings to be more consistent with other 
applications. I forget why we have things the way they are.

Scott


As a LyX user on windows, I would be reluctant to see Ctrl+-  changed. 
To meit sits comfortably alongside Ctrl+space to give a protected space. 
(To my mind, the odd one out is Alt+. to give an ellipsis rather than 
Ctrl+. for this function.  To maintain equilibrium I recall JMarc's 
description from 17 Jul 2018, "remember that LyX is a platypus: 
something so weirdly designed that everybody is surprised that it even 
exists.")


Andrew

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Windows] Remove the default binding between buffer-zoom and Alt+0

[Scott Kostyshak]

On Fri, Jan 15, 2021 at 08:27:23PM -0500, Richard Kimberly Heck wrote:
> On 1/15/21 3:57 PM, Yuriy Skalko wrote:
> >> However, by default, in LyX, this has a very problematic side-effect:
> >> Alt+0
> >> resets the zoom level to zero. Personally, I know how to configure this
> >> shortcut, but newcomers may be left puzzled (and leave completely).
> >>
> >> Moreover, it's more common to use Ctrl+0 to reset the zoom level, at
> >> least
> >> on Windows: most Web browsers do it (at least Firefox, Chrome, and
> >> IE), all
> >> Microsoft Office programs. It does not work for LibreOffice or
> >> Notepad++.
> >>
> >> I would propose to change the default binding to Ctrl+0, as it's more
> >> common (although not ubiquitous), and this would fix the problem of
> >> changing zoom when you try to insert a character.
> >>
> >> What do you think of this?
> >
> > There are also zooming shortcuts Alt+"+", Alt+"-". To be consistent
> > these should also use Ctrl. But Ctrl+"-" is already bound to
> > Hyphenation Point insert. Is it OK to rebind it to Alt+"-"?
> 
> I'm pretty used to it as it is. I'm not sure we need to worry too much
> about consistency here, though I'll be interested to hear what others
> have to say.

I think I would support changing the bindings to be more consistent with other 
applications. I forget why we have things the way they are.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Windows] Remove the default binding between buffer-zoom and Alt+0

[Richard Kimberly Heck]

On 1/15/21 3:57 PM, Yuriy Skalko wrote:
>> However, by default, in LyX, this has a very problematic side-effect:
>> Alt+0
>> resets the zoom level to zero. Personally, I know how to configure this
>> shortcut, but newcomers may be left puzzled (and leave completely).
>>
>> Moreover, it's more common to use Ctrl+0 to reset the zoom level, at
>> least
>> on Windows: most Web browsers do it (at least Firefox, Chrome, and
>> IE), all
>> Microsoft Office programs. It does not work for LibreOffice or
>> Notepad++.
>>
>> I would propose to change the default binding to Ctrl+0, as it's more
>> common (although not ubiquitous), and this would fix the problem of
>> changing zoom when you try to insert a character.
>>
>> What do you think of this?
>
> There are also zooming shortcuts Alt+"+", Alt+"-". To be consistent
> these should also use Ctrl. But Ctrl+"-" is already bound to
> Hyphenation Point insert. Is it OK to rebind it to Alt+"-"?

I'm pretty used to it as it is. I'm not sure we need to worry too much
about consistency here, though I'll be interested to hear what others
have to say.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Update docs on the wiki

[Richard Kimberly Heck]

On 1/15/21 2:01 PM, Pavel Sanda wrote:
> On Fri, Jan 15, 2021 at 06:34:08PM +0100, Jean-Pierre Chrétien wrote:
>> The files were at ftp.lyx.de, I uploaded my files on the wiki, in directory
>> LyX/Manuals/2.3
> Good, ftp.lyx.de was Uwe's private affair I believe.
>
>> There is nothing about Japanese, and I'm unable to compile the Japanese
>> documentation. Anybody knows why Uwe did not include these manuals?
> Maybe for the same reason - he could not compile it?

Maybe send an email to Koji? yoko...@gmail.com

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[Windows] Remove the default binding between buffer-zoom and Alt+0

[Yuriy Skalko]

However, by default, in LyX, this has a very problematic side-effect: Alt+0
resets the zoom level to zero. Personally, I know how to configure this
shortcut, but newcomers may be left puzzled (and leave completely).

Moreover, it's more common to use Ctrl+0 to reset the zoom level, at least
on Windows: most Web browsers do it (at least Firefox, Chrome, and IE), all
Microsoft Office programs. It does not work for LibreOffice or Notepad++.

I would propose to change the default binding to Ctrl+0, as it's more
common (although not ubiquitous), and this would fix the problem of
changing zoom when you try to insert a character.

What do you think of this?


There are also zooming shortcuts Alt+"+", Alt+"-". To be consistent 
these should also use Ctrl. But Ctrl+"-" is already bound to Hyphenation 
Point insert. Is it OK to rebind it to Alt+"-"?



Yuriy

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Creating a branch in the features repository

[Yuriy Skalko]

But there were some messages about big file. Is it normal?


The email is too big. Probably because you are pushing a billion commits.


Definitely, there were several thousand commits. So that was just email 
for mailing list. Thanks for the explanation.




I think it is worth to sync master branch in features repository (last
updated in 2015) with master in main repository. This will allow not
to push all commits from 2015 to 2021 for every new feature branch.

Is it OK if I'll do this?


Yes, I think that is fine. Probably you get the same error again, but
it's harmless.

Riki


So, I updated the master branch there and Git become more responsive.


Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Update docs on the wiki

[Pavel Sanda]

On Fri, Jan 15, 2021 at 06:34:08PM +0100, Jean-Pierre Chrétien wrote:
> The files were at ftp.lyx.de, I uploaded my files on the wiki, in directory
> LyX/Manuals/2.3

Good, ftp.lyx.de was Uwe's private affair I believe.

> There is nothing about Japanese, and I'm unable to compile the Japanese
> documentation. Anybody knows why Uwe did not include these manuals?

Maybe for the same reason - he could not compile it?

> The section about 'Maintaining' is also out of date, what should be there?

I do not think we have anyone who stood up as the maintainer for now,
so you can basically scrap that section.

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Update docs on the wiki

[Jean-Pierre Chrétien]

Le 14/01/2021 à 14:00, Jean-Pierre Chrétien a écrit :

Hello,

I'm about to update the docs on the wiki. Could someone give me privately the 
identity and password to connect to ftp://wiki.lyx.org ?




The files were at ftp.lyx.de, I uploaded my files on the wiki, in directory 
LyX/Manuals/2.3


The wiki Manuals directory reads like this now:

https://wiki.lyx.org/LyX/Manuals

I'll create a section about Additional manuals later.

There is nothing about Japanese, and I'm unable to compile the Japanese 
documentation. Anybody knows why Uwe did not include these manuals?


The section about 'Maintaining' is also out of date, what should be there?

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Creating a branch in the features repository

[Richard Kimberly Heck]

On 1/15/21 4:56 AM, Yuriy Skalko wrote:
>
> Recently I've created a new branch in the features repository as
> described here:
> https://wiki.lyx.org/Devel/LyXGit#toc3
>
> But there were some messages about big file. Is it normal?
>
> Here is the Git output:
>
> -
> C:\Projects\LyXGit\lyx>git push features
> InsetParams-refactoring:InsetParams-refactoring  Enter
> passphrase for key '/c/Users/Yuriy/.ssh/id_rsa': Enumerating objects:
> 6533, done.
> Counting objects: 100% (6533/6533), done.
> Delta compression using up to 4 threads
> Compressing objects: 100% (2758/2758), done.
> Writing objects: 100% (5304/5304), 8.09 MiB | 2.38 MiB/s, done.
> Total 5304 (delta 4473), reused 3036 (delta 2489), pack-reused 0
> remote: postdrop: warning: uid=1005: File too large
> remote: sendmail: fatal: yuriy.ska...@gmail.com(1005): message file
> too big

The email is too big. Probably because you are pushing a billion commits.


> I think it is worth to sync master branch in features repository (last
> updated in 2015) with master in main repository. This will allow not
> to push all commits from 2015 to 2021 for every new feature branch.
>
> Is it OK if I'll do this?

Yes, I think that is fine. Probably you get the same error again, but
it's harmless.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Pavel Sanda]

On Fri, Jan 15, 2021 at 10:11:03AM +0100, Jean-Marc Lasgouttes wrote:
> I propose something where prime numbers are used for development releases,
> this would be very simple too.

You made my day :)) P
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Windows] Remove the default binding between buffer-zoom and Alt+0

[Pavel Sanda]

On Fri, Jan 15, 2021 at 02:00:10AM +0100, Thibaut Cuvelier wrote:
> I would propose to change the default binding to Ctrl+0, as it's more
> common (although not ubiquitous), and this would fix the problem of
> changing zoom when you try to insert a character.
> 
> What do you think of this?

Looks reasonable. Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Creating a branch in the features repository

[Yuriy Skalko]

Recently I've created a new branch in the features repository as 
described here:

https://wiki.lyx.org/Devel/LyXGit#toc3

But there were some messages about big file. Is it normal?

Here is the Git output:

-
C:\Projects\LyXGit\lyx>git push features 
InsetParams-refactoring:InsetParams-refactoring  Enter 
passphrase for key '/c/Users/Yuriy/.ssh/id_rsa': 
Enumerating objects: 6533, done.

Counting objects: 100% (6533/6533), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2758/2758), done.
Writing objects: 100% (5304/5304), 8.09 MiB | 2.38 MiB/s, done.
Total 5304 (delta 4473), reused 3036 (delta 2489), pack-reused 0
remote: postdrop: warning: uid=1005: File too large
remote: sendmail: fatal: yuriy.ska...@gmail.com(1005): message file too big
To git.lyx.org:features.git
  * [new branch]InsetParams-refactoring -> 
InsetParams-refactoring

-


I think it is worth to sync master branch in features repository (last 
updated in 2015) with master in main repository. This will allow not to 
push all commits from 2015 to 2021 for every new feature branch.


Is it OK if I'll do this?


Yuriy

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Jean-Marc Lasgouttes]

Le 13/01/2021 à 11:22, José Abílio Matos a écrit :

On a more serious note, I do not insist on the particular use of the x.0
convention. I find it elegant and it gives a nice justification, for example,
why gcc stable releases always starts at .1. FWIW gcc started the new
numbering scheme at version 5, and it already the seventh release where this
numbering schme is used.

In Fedora Rawhide (to be Fedora 34) the current version of gcc is 11.0.0. That
immediately shows that this is not the stable version. The first stable
version will be 11.1.


Yes, it is very immediate. All you have to do is to go to the web site 
of each and every package you want to use and check what they mean by 
3.0 ! I propose something where prime numbers are used for development 
releases, this would be very simple too.


At least, when a version is 2.99.4 or 2.4.0alpha1, I know it is not a 
regular release. Beat that with your "we all know what it means" system.


JMarc

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel