> I can think of a couple alternatives, but none which require so few changes
> (ex. explicit size variables for each array, sentinel-terminated arrays, etc).
I really think any solution should minimize the risk of likely problems (well,
at least the ones that are likely to happen, e.g.
> @b4n for the places this is used, is there a (compile time testable) value of
> array element you could use as a non-entry so its always arrays and so
> doesn't mix arrays and pointers, then the GCC warning will catch if anyone
> does call it with a pointer?
None that I can think of; the
GCC 8 introduced `-Wsizeof-pointer-div` which is enabled by `-Wall` and
warns for sizeof divisions that look like they would compute the size
of a static array but are called on something on which this doesnt
work (e.g. a pointer as LHS). This is quite reasonable and useful, but
it fails to
@elextr I'm saying the 4th icon from the left (double arrows pointing to a
drive) is a Geany-specific icon,
`$srcdir/icons/tango/scalable/geany-save-all.svg` or one of its rendered PNG
versions. And that icon displays fine AFAICT (good size, not blurry).
--
You are receiving this because you
@elextr Hence me saying *icons/tango/scalable/geany-save-all.svg*, notice the
*tango* in the path ;)
@paulmenzel If there are sizes at which the icon is missing, could you try
adding those sizes and see if it helps?
```bash
# To be run from Geany's source directory.
prefix=/usr/ # where Geany
@elextr yes it does, the 4th one is *geany-save-all*, see
*icons/tango/scalable/geany-save-all.svg*
--
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/2394#issuecomment-553324662
@paulmenzel The GTK version is automatically selected (it'll use the one you
have), but is currently conservative towards GTK2 (if you have both, GTK2 will
be selected).
The help text looks OK to me, and I'm not sure *"default=yes if available and
GTK2 is not available, no otherwise"* would be
I couldn't reproduce this issue, but I don't have actual HiDPI hardware, and
playing with scaling with the GTK debugging tool doesn't expose this behavior.
Useful info I guess:
* This icon is distributed by Geany (*geany-build*)
* The *geany-save-all* icon (4th from the left) we also distribute
Actually apart from saving bandwidth, I'd rather have people go to
https://www.geany.org/download/releases/ and all the extras, like the
opportunity to check check the signatures or whatnot. But well…
--
You are receiving this because you are subscribed to this thread.
Reply to this email
OK I just tested uploading assets to 1.36 release:
https://github.com/geany/geany/releases/tag/1.36.0
As I expected, it didn't remove the "source code" downloads.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@codebrainz I'm afraid that won't remove/replace the auto-generated zip/tar of
the VCS tag; but yes we could upload the items there as well. But as
"incorrect" auto-generated GitHub links are still there, nothing will be
solved. I hope I'm wrong tho.
I blame GitHub here if it's not possible
Why would you need to run autogen (and thus need Autotools) from release
tarballs? They should be including everything you need.
Note that GitHub's "source code" automatic downloads are *not* release
tarballs, release tarballs should be downloaded from
https://www.geany.org/download/releases/
I think it's worth supporting because IMO we should not break on valid input,
but depending on the difficulty it might be worth waiting on us getting the new
uctags C and C++ parser. Yes, I'll try and really get that thing merged "soon".
--
You are receiving this because you are subscribed to
> 2. and if it did, the return_ifs can shortcut return and leave it
> uninitialised.
@elextr got a point, it's actually technically correct to say the value may not
be initialized because of those checks, and it seem impossible for a tool to
infer that those checks will succeed, even if we
Ideally you'd push again to the original `showzoom` branch so that we have the
canonical PR as @codebrainz said, but I'm OK either way so long as we get the
wonderful docs back :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
b4n requested changes on this pull request.
You lost the documentation changes in the rebase.
I rebased myself and it gave me 2f0d6220d36cf2a533b78010bd6071e6bdcf6944 that
you can find on branch https://github.com/b4n/geany/commits/showzoom
--
You are receiving this because you are
b4n approved this pull request.
LGTM, and it works fine.
Only thing is that I'd like to squash the commits I think as part of the second
relevant commit is fixups on the first one, but I can also do that when merging
if you'd like.
--
You are receiving this because you are subscribed to
b4n commented on this pull request.
> @@ -304,6 +305,21 @@ static gchar *create_statusbar_statistics(GeanyDocument
> *doc,
g_string_append_printf(stats_str, "%d",
sci_get_style_at(doc->editor->sci,
pos));
I suggest something like this
```diff
diff --git a/src/sciwrappers.c b/src/sciwrappers.c
index 647c44454..5dc59b93e 100644
--- a/src/sciwrappers.c
+++ b/src/sciwrappers.c
@@ -968,9 +968,9 @@ void sci_set_font(ScintillaObject *sci, gint style, const
gchar *font, gint size
}
-gint
b4n requested changes on this pull request.
Apart from that function name and using fractional sizes, looks pretty good to
me.
> +gint sci_get_fontsize(ScintillaObject *sci, gint style)
+{
+ return (gint) SSM(sci, SCI_STYLEGETSIZE, (uptr_t) style, 0);
+}
I would still like to see the
> @b4n It sounds like you're not really interested in crediting me for fixing
> this - does this mean I won't be added to the list of contributors?
To be blunt, I really don't care who's credited here :) But I'll happily
credit you, my example was not trying to draw it away from you.
--
You
Better. IMO we should just use my version that has all the small things I'd
like to see changed here (comment, location of the change (which is my bad
because of an incorrect comment, sorry), no leftover unrelated whitespace
changes, clearer commit message, no leftover history), but basically
b4n commented on this pull request.
> editor->sci = editor_create_widget(editor);
+ sci_set_multipaste(editor->sci, SC_MULTIPASTE_EACH);
My bad, I meant `create_new_sci()` which is the one having the other similar
defaults
--
You are receiving this because you are subscribed to
*, and the
function shouldn't be exposed in the headers anyway):
```diff
>From 9b503708203a4986736da33d882f695dee6119c0 Mon Sep 17 00:00:00 2001
From: Colomban Wendling
Date: Mon, 30 Sep 2019 20:09:12 +0200
Subject: [PATCH] Enable multi-selection clipboard paste
When pasting a single-line clipboard cont
@codebrainz I don't actually know how well this works, I just stumbled on an
old build directory configured this way and found this failure. Maybe we could
just prevent making a static build, or just ignore it as we don't advertise it;
I juts figured this was a very innocent fix if it can be
You can also close the document by clicking on it with the middle mouse button.
--
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/2330#issuecomment-536499332
Merged #5 into master.
--
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/infrastructure/pull/5#event-2670580593
You can view, comment on, or merge this pull request online at:
https://github.com/geany/infrastructure/pull/5
-- Commit Summary --
* Add scripts used to publish a new release
-- File Changes --
A scripts/md5sums (14)
A scripts/md5sums_plugins (14)
A scripts/publish-release
## General
* Give precedence to user-defined filetype extension mappings over default ones
([PR#2166](https://github.com/geany/geany/pull/2166)).
* Give precedence to the longest matching filetype pattern
([Issue#1499](https://github.com/geany/geany/issues/1499),
Merged #2329 into master.
--
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/2329#event-2670514012
b4n approved this pull request.
LGTM
--
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/2329#pullrequestreview-294634530
> Note that if the clipboard contains a rectangular selection it seems to be
> only pasted once irrespective of this option.
Well to be fair pasting a multi-line selection is the only use case I though of
that would cause issues, so if it still behaves as it does now it's probably
fine. But I
b4n requested changes on this pull request.
This is OK as an example of the behavior you want, but won't be merged like
this.
We don't modify the Scintilla source itself, and Scintilla has all what is
needed to change this from Geany's code. Also, we most probably won't force
this one all
It contains all the useful translations for the *shiftcolumn* plugin, so even
though that's only 3 strings, it seems partly useful (not like if only 3 of all
strings in Geany itself were translated).
Is this file problematic for any reason I'm not aware of? Yes, it'd need some
work from Danish
b4n approved this pull request.
LGTM
--
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/2312#pullrequestreview-291515818
@hongquan to try and be clearer, the fold on line 4 on the right side
corresponds to the one on line *20* on the left.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@hongquan what's wrong with those? AFAICS they fold after the `>` of the
opening tag, so as your opening tags are spanning multiple lines, you don't see
them on the same line as the start of the tag. The first fold is for the
`` (which `>` is indeed on line 18) open tag, and the second for
I can't really believe I could be suggesting something like this, but anyone
tried [meson](https://mesonbuild.com/) or such? I'm not totally opposed
against moving away from Autotools in the unlikely event there's a decent
alternative (e.g. that does everything we need from AT [1], and has
> I don't understand this at all. Prototypes are irrelevant, I don't understand
> what you mean.
It's another kind of forward declarations, and if we start with structs "just
because", where do we stop?
> Please explain what you mean about the struct name changing being bad enough.
> You
@LarsGit223 at least `projfilecmds` is being accessed outside `build.c`, in
`project.c`, so it's not actually completely private to `build.c`. If it was,
build.h should have had the forward declaration, and `build.c` the complete one.
@ntrel `struct _GeanyEntryActionPrivate` and `struct
@lynas685 Geany provides by default 2 separate commands for C++: "Compile" and
"Build". "Compile" will only call the compiler to create an object file (`.o`)
which is not an executable by itself but a compiled version of the file that
can be used later on to create an executable (you can think
b4n requested changes on this pull request.
I have to agree with @kugel- here: if the file uses a symbol defined in a
header, it should include it. Manually introducing forward declarations should
IMO be left to breaking circular dependencies alone.
Also, I don't know how it is on your machine,
…or [json_pp](https://metacpan.org/pod/distribution/JSON-PP/bin/json_pp)
--
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-plugins/issues/891#issuecomment-526828634
The question is not very clear, and the goal far from obvious, but note that in
the symbols tree view there are headers (like *Functions*, *Classes*,
*Structs*, etc.) that don't have tags attached, so it's expected getting the
content of the TAG column for them yields `NULL`.
--
You are
I meant the content of the navbar; I think the transparency adds background
noise that makes it harder to read the foreground text. It possibly could be
improved by blurring what's underneath (not sure it's possible even in 2019s
web browsers?), or by enhancing foreground contrast, or whatnot.
I don't really like the transparency, I think it makes everything a lot less
readable.
For the subtle shadow, yeah it's probably a good idea.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Looks pretty good, and I especially like the additional spacing between the
logo and the name :+1:
--
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/www.geany.org/issues/15#issuecomment-524636858
Is this still relevant? Looking at the conversation in #2261 it's kind of
unclear.
However, this looks good anyhow.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
b4n approved this pull request.
Looks good and safe
--
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/2263#pullrequestreview-279286138
b4n approved this pull request.
OK
--
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/2268#pullrequestreview-279286002
b4n approved this pull request.
LGTM, and I agree with @ntrel's rationale on splitting 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/2272#pullrequestreview-279285583
> Also, GTK+3 broke on-the-fly theme changes, so apps have to be restarted when
> you change the themes
Odd, that should work in GTK3 as well, and does IME (although I did have had to
provide a fix for something related to this a few years back, which might
suggest they don't pay enough
b4n commented on this pull request.
> @@ -817,7 +816,8 @@ static gchar *prepare_run_cmd(GeanyDocument *doc, gchar
> **working_dir, guint cmd
{
if (vc->skip_run_script)
{
- utils_free_pointers(2, cmd_string_utf8,
working_dir_utf8,
b4n commented on this pull request.
> @@ -817,7 +816,8 @@ static gchar *prepare_run_cmd(GeanyDocument *doc, gchar
> **working_dir, guint cmd
{
if (vc->skip_run_script)
{
- utils_free_pointers(2, cmd_string_utf8,
working_dir_utf8,
I still don't have a strong opinion, but as is the file doesn't seem very
useful.
I tend to agree with @codebrainz, mostly because in 2019 it's likely user CSS
will add rules on top of a framework, and if it's not it's likely be to either
highly complex or very simple.
If we suppose very
See #2259
--
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/607#issuecomment-521551760
Merged #2250 into master.
--
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/2250#event-2553693308
Closed #703 via 46d5e7542b8396ed593f2e319f71d153a67684dc.
--
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/703#event-2553693401
> Ctrl+mouse wheel to zoom the current tab only is standard behaviour, try it
> in your browser.
Actually it's shifting: current Firefox is applying zoom to the current
*website* (not even web page), which might be displayed in several tabs, in
which case it applies to several tabs.
And I
See #2250
--
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/407#issuecomment-519828390
Closed #407.
--
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/407#event-2545719059
Creating a new PR as #407 has no more branch attached to it and so can't be
updated.
This needs squashing when review is done.
Basically it's #407 on top of master, plus a few minor changes to please me
:slightly_smiling_face:
You can view, comment on, or merge this pull request online at:
b4n approved this pull request.
LGTM
--
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/#pullrequestreview-268203660
b4n commented on this pull request.
> @@ -439,20 +441,35 @@ static gint socket_fd_open_unix(const gchar *path)
return -1;
}
- /* fix for #1888561:
-* in case the configuration directory is located on a network file
system or any other
-* file
It's likely that the tag types are not compatible with XML. Tag types are
specific to each parser, and might or might not overlap.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
We'll need a whole lot more information to be able to help. First off, we'll
need the platform you're using, and all the Geany version details (Help→Debug
Messages), any any other information that can be useful to pinpoint the issue
further (e.g. input language, whether you're using an input
[on periodic cleanup]
OK fair enough. It'd actually be kind of strange to clean up sockets (but who
knows). Let's just hope it's OK for now then, and not worry about it further.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
b4n approved this pull request.
Apart from the nitpicking below, LGTM
>
if (utils_is_file_writable(real_path) != 0)
{ /* if real_path is not writable for us, fall back to
~/.config/geany/geany_socket_*_* */
/* instead of creating a symlink and print a
Late on my part, but just to support @elextr's point: don't worry about Geany
for extending parsers. We definitely don't want slowing down uctags
development, and as mentioned we already have what's needed to detect what
needs be updated when pulling a new uctags version.
The API tlib should
@LarsGit223 The thing is that *~/.config/gtk-3.0/gtk.css* has the highest
priority possible -- user priority. It's actually pretty much the right thing
to do to let this win.
In our specific case where it's a user setting, it could be arguable that we
should give it user priority, and then it
The first commit can be generally useful if e.g. Python is not generally found
in the PATH, for selecting `python3` by default, or if the environment doesn't
provide a generic `python` link but only versioned ones (like `python2` and
`python3`).
The second one implements the suggestion from
Merged #2218 into master.
--
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/2218#event-2493046093
b4n requested changes on this pull request.
I like the idea, but I'm a little worried about what [the
spec](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables)
says on lifetime of files in that directory:
*Files in this directory MAY be subjected to periodic
b4n requested changes on this pull request.
Looks good apart from the comments below
> @@ -82,6 +82,7 @@ gchar sci_get_char_at
> (ScintillaObject *sci, gint pos);
void sci_scroll_caret
b4n approved this pull request.
Looks good and works with example error messages from NVCC which is the
configured compiler in the build settings.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The idea looks quite neat, but bear in mind that
* translated strings are often fairly different in length than English ones.
If this could be a problem, we'll need different translations for the toolbar,
but bear in mind that it's sometimes very awkward to shorten a translation, so
width of
It's quite odd that computing the caret position and the glyph position don't
agree, but it might indeed be a bug in the fond itself ("monospace" generally
is an alias for the default monospaced font), or how one of the component use
it.
If you'd like and have time for it, it could be nice to
As @elextr said, we don't have any control on what Debian provides, and we
still support GTK2 if selected (but that's a selection only the binary provider
can make). You can still rebuild Geany yourself and make that selection, just
bare in mind that you'll also have to rebuild any plugins you
Closed #2214.
--
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/2214#event-2478447651
Shouldn't we add it to the `filetypes.CUDA.conf` file we provide then?
--
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/2213#issuecomment-510619274
b4n commented on this pull request.
Looks fine
> @@ -383,6 +381,10 @@ GeanyDocument *document_get_current(void)
void document_init_doclist(void)
{
documents_array = g_ptr_array_new();
+#ifdef GEANY_DEBUG
+ // add a dummy invalid document to catch naive iteration
+
b4n approved this pull request.
--
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/2181#pullrequestreview-258562765
/me liketh the box-shadow
--
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/www.geany.org/issues/13#issuecomment-508829521
> I weren't completely sure if this issue has low priority because I don't know
> if there are valid use cases for such filenames or if this problem is a
> symptom of a higher priority problem.
It is a slight problem in that it can be used to inject remote commands from a
filename, but even so
> WFM, provide exactly the steps you use to open it.
You need a running instance of Geany already, for the open to send files
through the socket. Then it fails, as filenames are split by line.
> Is there any legitimate use case of using line breaks in filenames? Even if
> it works, it feels
You need to "unmap" YAML in *filetype_extensions.conf*. What you should do is
in the *user's* `filetype_extensions.conf` add a `YAML=` line that does not
include the extensions you want somewhere else.
The technical reason for this is that the system and user's files are merged,
with the
I don't think NC is needed, as it prevents some fairly useful uses like
publishing in a selling magazine (which could quote the website or such, etc.).
I don't really care which one it is though, and I welcome any counter
arguments, I just mention this because not all "commercial" uses are
b4n approved this pull request.
Nitpicking below, otherwise looks good :+1:
> +set -e
+
+TOKENS_CPP_FILE="/tmp/nsis_tokens.cpp"
+TOKENS_CPP_URL="https://raw.githubusercontent.com/kichik/nsis/master/Source/tokens.cpp;
+BUILD_CPP_FILE="/tmp/nsis_build.cpp"
b4n commented on this pull request.
> +
+# extract variable names (then sort the result, conver to lowercase and
replace new lines by spaces)
+variables=$(\
+sed --silent --regexp-extended\
+--expression 's/^[
]*m_ShellConstants.add\(_T\("(.*)"\),.*,.*\);.*$/\1/p' \
+
b4n approved this pull request.
--
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/2181#pullrequestreview-252519744
b4n commented on this pull request.
> @@ -39,8 +39,7 @@ variables=$(\
variables_extra='{nsisdir} 0 1 2 3 4 5 6 7 8 9 r0 r1 r2 r3 r4 r5 r6 r7 r8 r9
\\n \\r \\t $'
variables="${variables_extra} ${variables}"
# prefix each element with a dollar sign
-declare -a variables_array=(${variables})
b4n requested changes on this pull request.
Apart from the one comment, LGTM
> @@ -39,8 +39,7 @@ variables=$(\
variables_extra='{nsisdir} 0 1 2 3 4 5 6 7 8 9 r0 r1 r2 r3 r4 r5 r6 r7 r8 r9
\\n \\r \\t $'
variables="${variables_extra} ${variables}"
# prefix each element with a dollar sign
That's real odd… and actually by default Ctrl+k only *deletes* one
or more lines, so it's not even related to clipboard. @toxpal could you try
changing the key combination for the action (*Edit → Preferences → Keybindings
→ Editor → Delete current line(s)*) and see if it still happens with the
what happens if you use another clipboard-related command, like
Ctrl+C or Ctrl+X?
--
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/2201#issuecomment-503952652
> I'm pretty sure it was called `string_2` to remain generic enough for this
> type of thing. If not `string_2` then use `string_3` or `string_4` which I
> don't believe are used much.
Hum, so these names are not clear enough and should be better documented;
because my understanding was rather
b4n approved this pull request.
LGTM, but commits should be squashed with a more accurate commit message
fitting the new change
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
b4n approved this pull request.
Apart from the 2 comments that I'm sure are nothing, I have nothing else to
say, as I don't know much of it and trust you on this :)
> +
+# extract variable names (then sort the result, conver to lowercase and
replace new lines by spaces)
+variables=$(\
+sed
> Instead of `string_2` I've made string escapes use `string_1,bold`.
I'm not sure forcing a style attribute is a good idea, as it won't have any
effect if the base style has it already. Also bold specifically apparently
sometimes cause issues with some poor fonts that get emulated boldness
Yes, you can configure that: in
[*filetypes.markdown*](https://www.geany.org/manual/#filetype-definition-files),
add the corresponding [`comment_open` and
`comment_close`](https://www.geany.org/manual/#settings-section) options in the
`settings` section.
E.g.,
Sounds good indeed :)
--
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/www.geany.org/issues/4#issuecomment-500162916
901 - 1000 of 3110 matches
Mail list logo
