> I guess that still has the problem that we have no idea what GTK+ theme the
> user will choose, so it's not really possible to pick properly contrasting
> colours.
Its true, but we can pick bright colours instead of the dark ones currently
implemented. Its very likely that it will give a
> My solution would be to add comments to the CSS file so that the users of
> dark themes only have to uncomment to have a functional contrast.
I guess that still has the problem that we have no idea what GTK+ theme the
user will choose, so it's not really possible to pick properly contrasting
Sounds related to #1095.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2652#issuecomment-724370158
@b4n now 1.37 is out, whats your thoughts on this?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/2600#issuecomment-724332427
Maybe, and actually it looks like there are other problems, eg IIUC `->` is a
token so why only the `>` is highlighted I'm not sure. Definitely should be
checked with latest Scintilla and fixes posted there.
--
You are receiving this because you are subscribed to this thread.
Reply to this
while @elextr is right, it looks like Scintilla should juts be considering `:`
as a separator :) Are there cases where it shouldn't? If so, then it becomes
semantic and tricky.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Highlighting is purely syntactic, anything to be highlighted must be able to be
determined purely from syntax, no semantics allowed.
Whilst I don't know Erlang, from your descriptions the examples look like they
would require semantic knowledge, eg what a "list" is vs purely a '[' and ']',
I thought of something. I guess people in this community are really geek and
like to tweak a CSS file. But I believe most users of dark themes don't really
want to think of colours to customize _geany.css_ so the contrast between the
letters and background is reasonable. My solution would be to
This also happens with 1.36. The reason seems that modules are not shown in
the symbols tree, and then the hierarchy is displayed directly in the tag name.
Could you try the patch below and see if it's better for you?
```diff
diff --git a/src/symbols.c b/src/symbols.c
index a54b6ef4c..a6192f04b
1) Create a path with unicode characters (cyrillic, for example) under Windows,
and a some file (with a some content! For example, "ABCDE"):
C:\dev\слово\src\file.py
2) Open console and go to the C:\dev\слово\src\ folder.
3) Launch Geany from command line with the file name as the parameter:
Image attached with badly highlighted 'TRY' expressions
![Screenshot_2020-11-09_10-19-31](https://user-images.githubusercontent.com/8375315/98545997-109a5580-2275-11eb-88a1-f5e34030498b.png)
Another case
This happens with erlang files, just erlang files
Im on 1.37. If im not wrong, this didnt happened on 1.36...
It looks (erlang file):
![Screenshot_2020-11-09_09-55-08](https://user-images.githubusercontent.com/8375315/98543800-c2378780-2271-11eb-9407-01aa93edb541.png)
It should look (python
Maybe one reproducing the issue could bisect if it happened since 1.36? Not
sure how easy bisecting is on Windows/Macos (probably depends on how easy it is
to build), but that could possibly be a cheap-ish way of figuring this out.
I'm exclusively on Linux, and my startup times always have
I think `message-dialog-restore-traditional-look-on-unity.patch` creates a
problem, because only this patch contains the words `GtkMessageDialog`,
`GtkWidget`, `icon` and `image`. (By the way this bug exists in
`geany.input()`'s window too.)
@b4n, will you add your patch to upstream?
--
You
14 matches
Mail list logo