Skip to content

Conversation

Tibowl
Copy link

@Tibowl Tibowl commented May 15, 2015

  • Fixes some conflicts
  • Adds closing parentheses where missing
  • Changes " to ' in comments to fix when trying to do multikey + =~ results in

≅" U245 # APROXIMATELY EQUAL TO (It actualy means "congruent

instead of ≅

Tibo added 3 commits May 15, 2015 14:31
When trying the aproximately equal to; it resulted in:

≅"	U245	# APROXIMATELY EQUAL TO (It actualy means "congruent

This should fix it.

This also closes brackets on the INVERTED INTERROBANG, it bothered me.
Fixes these conflicts:


<Multi_key> <underscore> <asciicircum>  conflicted with <Multi_key> <underscore> <asciicircum> <underscore>
<Multi_key> <plus> <plus>               conflicted with <Multi_key> <plus> <plus> <less>
<Multi_key> <plus> <plus>               conflicted with <Multi_key> <plus> <plus> <greater>
<Multi_key> <parenleft> <minus>         conflicted with <Multi_key> <parenleft> <minus> <parenright>
<Multi_key> <equal> <d>                 conflicted with <Multi_key> <equal> <d> <e> <f>
<Multi_key> <c> <period>                conflicted with <Multi_key> <c> <period> <period>
<Multi_key> <less> <e>                  conflicted with <Multi_key> <less> <e> <h>
<Multi_key> <less> <e>                  conflicted with <Multi_key> <less> <e> <r>
<Multi_key> <o> <minus>                 conflicted with <Multi_key> <o> <minus> <plus>
<Multi_key> <o> <minus>                 conflicted with <Multi_key> <o> <minus> <greater>
<Multi_key> <exclam> <i>                conflicted with <Multi_key> <exclam> <i> <n>
<Multi_key> <less> <minus>              conflicted with <Multi_key> <less> <minus> <greater>
<Multi_key> <less> <minus>              conflicted with <Multi_key> <less> <minus> <equal> <greater>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_a>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_A>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_ie>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_IE>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_i>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_I>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_o>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_O>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_u>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_U>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_er>
<Multi_key> <grave> <grave>             conflicted with <Multi_key> <grave> <grave> <Cyrillic_ER>
<Multi_key> <asterisk> <apostrophe>     conflicted with <Multi_key> <asterisk> <apostrophe> <A>
<Multi_key> <asterisk> <apostrophe>     conflicted with <Multi_key> <asterisk> <apostrophe> <a>
<Multi_key> <backslash> <o>             conflicted with <Multi_key> <backslash> <o> <slash>

Maybe undo/replace something:
<Multi_key> <Up> <Up>                   conflicted with <Multi_key> <Up> <Up> <Down> <Down> <Left> <Right> <Left> <Right> <b> <a>
@samhocevar
Copy link
Owner

Thanks for the patches. As of now, I do not wish to modify Xorg.txt or Xcompose.txt because they come from external projects, namely Xorg and .XCompose. I very much would like that incompatibilities be fixed by these projects instead. I will leave this pull request open for reference, but I’m afraid I do not wish to fix these issues in that way.

Alternatively I would like a mechanism that lets users solve incompatibilities or set priorities using the GUI, but I haven’t started any work on this yet.

In 910d681 I fixed the parsing bug that you discovered, though; thanks a lot for spotting this! The fix will be in the next release.

@zommuter
Copy link

zommuter commented Apr 5, 2016

Since one can additionally use a .XCompose{,.txt} file, does anything defined in there have overriding priority?

@joaopizani
Copy link

Hi, I have my own XCompose file defined during years of development. And now I have placed it in %USERPROFILE%, but now WinCompose uses BOTH the internal mapping plus the extra ones in my own XCompose file. Is there any way to make my own mappings the ONLY ONES in the system, i.e, delete all mappings that come with WinCompose by default? Would 💗 that.

@samhocevar
Copy link
Owner

You can manually remove the files in c:\Program Files\WinCompose\res\ until #24 is fixed. I’m afraid you’ll have to do it after each upgrade.

@joaopizani
Copy link

One way which I think wouldn't be so complex to implement would be if the loading of the "standard" mappings was made optional. It would be enabled by default, but with an "advance" panel in the options screen the user could choose whether or not to load them.

@joaopizani
Copy link

I already renamed the files in %APPDIR%/res BTW, I read the code and found out where it was loaded, but thx for the tip anyways :)

@rillig
Copy link
Contributor

rillig commented Jun 12, 2016

Another way to prevent the default sequences would be to have a special command Dont_use_standard_sequences. The following code could be added at the beginning of Settings.LoadSequenceString:

if (line.Equals("Dont_use_standard_sequences"))
{
    m_sequences = new SequenceTree();
    m_sequence_count = 0;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants