The session split branch seems to work AFAICT.
But there are lots of settings in `geany.conf` that I believe are session settings, essentially all the GUI ones for example.
Below is the `geany.conf` created by this branch with "yes" or "no" beside the ones I suggest, don't mind if the branch is merged into main and these added after (discussion), @kugel- can choose.
``` [geany] no default_open_path no cmdline_new_files yes notebook_double_click_hides_widgets yes tab_close_switch_to_mru yes tab_pos_sidebar yes sidebar_pos yes symbols_sort_mode yes msgwin_orientation yes highlighting_invert_all no pref_main_search_use_current_word no check_detect_indent no detect_indent_width no use_tab_to_indent no pref_editor_tab_width no indent_mode no indent_type yes virtualspace no autocomplete_doc_words no completion_drops_rest_of_word no autocompletion_max_entries no autocompletion_update_freq yes color_scheme yes scroll_lines_around_cursor no mru_length no disk_check_timeout yes show_editor_scrollbars no brace_match_ltgt no use_gtk_word_boundaries no complete_snippets_whilst_editing no indent_hard_tab_width no editor_ime_interaction no use_atomic_file_saving no gio_unsafe_save_backup no use_gio_unsafe_file_saving no keep_edit_history_on_reload no show_keep_edit_history_on_reload_msg no reload_clean_doc_on_file_change no save_config_on_file_change no extract_filetype_regex no allow_always_save no find_selection_type no replace_and_find_by_default yes show_symbol_list_expanders yes compiler_tab_autoscroll yes statusbar_template yes new_document_after_close yes msgwin_status_visible yes msgwin_compiler_visible yes msgwin_messages_visible yes msgwin_scribble_visible no documents_show_paths yes sidebar_page no pref_main_load_session no pref_main_project_session no pref_main_project_file_in_basedir yes pref_main_save_winpos yes pref_main_save_wingeom no pref_main_confirm_exit yes pref_main_suppress_status_messages yes switch_msgwin_pages no beep_on_errors no auto_focus yes sidebar_symbol_visible yes sidebar_openfiles_visible yes editor_font yes tagbar_font yes msgwin_font yes show_notebook_tabs yes show_tab_cross yes tab_order_ltr yes tab_order_beside yes tab_pos_editor yes tab_pos_msgwin no use_native_windows_dialogs yes show_indent_guide yes show_white_space yes show_line_endings yes show_markers_margin yes show_linenumber_margin yes long_line_enabled yes long_line_type yes long_line_column yes long_line_color no symbolcompletion_max_height no symbolcompletion_min_chars no use_folding no unfold_all_children no use_indicators no line_wrapping no auto_close_xml_tags no complete_snippets no auto_complete_symbols no pref_editor_disable_dnd no pref_editor_smart_home_key no pref_editor_newline_strip no line_break_column no auto_continue_multiline no comment_toggle_mark no scroll_stop_at_last_line no autoclose_chars no pref_editor_default_new_encoding no pref_editor_default_open_encoding no default_eol_character no pref_editor_new_line no pref_editor_ensure_convert_line_endings no pref_editor_replace_tabs no pref_editor_trail_space no pref_toolbar_show no pref_toolbar_append_to_menu no pref_toolbar_use_gtk_default_style no pref_toolbar_use_gtk_default_icon no pref_toolbar_icon_style no pref_toolbar_icon_size no pref_template_developer no pref_template_company no pref_template_mail no pref_template_initial no pref_template_version no pref_template_year no pref_template_date no pref_template_datetime no context_action_cmd yes sidebar_visible yes statusbar_visible yes msgwindow_visible yes fullscreen no color_picker_palette no scribble_text no scribble_pos no custom_date_format
[build-menu] no number_ft_menu_items no number_non_ft_menu_items no number_exec_menu_items
[search] no pref_search_hide_find_dialog no pref_search_always_wrap no pref_search_current_file_dir no find_all_expanded no replace_all_expanded yes position_find_x yes position_find_y yes position_replace_x yes position_replace_y yes position_fif_x yes position_fif_y no fif_regexp no fif_case_sensitive no fif_match_whole_word no fif_invert_results no fif_recursive no fif_extra_options no fif_use_extra_options no fif_files no fif_files_mode no find_regexp no find_regexp_multiline no find_case_sensitive no find_escape_sequences no find_match_whole_word no find_match_word_start no find_close_dialog no replace_regexp no replace_regexp_multiline no replace_case_sensitive no replace_escape_sequences no replace_match_whole_word no replace_match_word_start no replace_search_backwards no replace_close_dialog
[plugins] no load_plugins no custom_plugin_path no active_plugins
[VTE] no send_cmd_prefix no send_selection_unsafe no load_vte no font no scroll_on_key no scroll_on_out no enable_bash_keys no ignore_menu_bar_accel no follow_path no run_in_vte no skip_run_script no cursor_blinks no scrollback_lines no shell no colour_fore no colour_back no last_dir
[tools] no terminal_cmd no browser_cmd no grep_cmd
[printing] no print_cmd no use_gtk_printing no print_line_numbers no print_page_numbers no print_page_header no page_header_basename no page_header_datefmt
[files] yes current_page
```
Thanks for the list! I think I'll do some of these that I'd consider no-brainers but others are more or less debatable. E.g. I clearly disagree on virtualspace but msgwin_orientation is an item where I'm not sure myself.
I do not want to keep the branch creeping until all possible discussions are settled, so thanks for the offer to merge it beforehand.
The list is only a starting point for discussion, definitely not definitive, thats why I think its ok to merge the branch since it can take time to consider settings that are unclear, but in the meantime other PRs changing settings can get built on top instead of session-split getting conflicts.
The list is just suggestions, so I have defaulted to yes if I'm unsure so it can be looked at by others.
The Geany project does not have a clear definition of what constitutes a "session" setting, since until now it didn't matter :-). What I have used as an initial definition is a setting that an individual user is likely to change, possibly often, and it doesn't affect the files being edited, hence for example GUI settings are session, but not indent settings.
I clearly disagree on virtualspace but msgwin_orientation is an item where I'm not sure myself.
Given how many settings there are I didn't look all of them up in the manual/code when making the list, but relied on memory or the setting name (risky).
Having looked at it, I agree `virtualspace` is an editor setting, so not session specific, and I am also unsure about `msgwin_orientation` because it seems unlikely the user will change it very often, but as I said I defaulted to yes.
But for another example `msgwin_visible` is definitely session since its state changes often, sometimes automatically.
The following ones are already in session.conf (position_* with #3003, current_page already now). Did you compile the right branch?
``` yes position_find_x yes position_find_y yes position_replace_x yes position_replace_y yes position_fif_x yes position_fif_y […] [files] yes current_page ```
This is what is in session.conf, note `current_page` seems to be in both?
``` [files] recent_files recent_projects current_page FILE_NAME_0
[project] session_file project_file_path
[geany] treeview_position msgwindow_position geometry
[VTE] last_dir ``` I used a nice fresh clone to build from, scrolling back through terminal history showed I did (in ~) ``` mkdir geany-split cd geany-split git clone https://github.com/geany/geany.git cd geany git checkout session_split ./autogen.sh --prefix=/home/lex/geany-split make -j 4 install cd ../bin ./geany -c ../config ``` change a couple of settings and window size and close geany, read the config and session files.
I havn't yet tried running the branch with an existing config dir, must do that.
I havn't yet tried running the branch with an existing config dir, must do that.
Seems to work, @kugel- I suggest merging the session-split branch ASAP so other settings changes can be built on top.
What I have used as an initial definition is a setting that an individual user is likely to change, possibly often, and it doesn't affect the files being edited...
That's almost just the plain definition of an ordinary preference?
@kugel- mentioned [elsewhere](https://github.com/geany/geany/issues/3015#issuecomment-975987322)...
Store the session part elsewhere... so that the remaining project part is largely static and invariant across systems, so that can be checked in... Likewise, my goal for the session split is to be able to store geany.conf in my personal "dotfiles" repository that I sync between laptop and workstation.
So a method to find sessionable preferences would be to run diff on sequential copies to see what preferences are frequently changing.
hence for example GUI settings are session, but not indent settings.
This probably wouldn't work well for kugel's use case because his goal appears to be to sync a base config across multiple computers. Infrequently changed GUI settings should be synced in that scenario.
Infrequently changed GUI settings should be synced in that scenario.
I said "and it doesn't affect the files being edited, hence for example GUI settings are session".
This would exactly support the @kugel- use-case since its pretty likely his screen sizes are different between laptop and workstation, so GUI things (geometry, location of message window, size of message window etc) are likely to be different. So these would stay with the machine and the appropriate screen(s).
So a method to find sessionable preferences would be to run diff on sequential copies to see what preferences are frequently changing.
Well its an idea, we can use mine, but by my usual usage almost nothing would be session except the files :grin: In other words thats too individual to be useful.
@elextr
This would exactly support the @kugel- use-case since its pretty likely his screen sizes are different between laptop and workstation, so GUI things (geometry, location of message window, size of message window etc) are likely to be different.
So these would stay with the machine and the appropriate screen(s).
Location of message window and sidebar do *not* depend on screen size. But they are settings users would likely want synced across computers, assuming they don't just use the defaults, because it would be an annoyance to have to reconfigure them whenever a new session is created.
With your approach, almost everything is session because everything is eventually tied to GUI. Very few settings affect the edited file. Indentation width does so only because of tabs-to-spaces. For projects, like Geany, where real tabs are used for indentation, it would be a session preference (by your definition).
In other words thats too individual to be useful.
Only if only your configs were used to find sessionable preferences.
Location of message window and sidebar do not depend on screen size.
The preferable position/size depends on window size, and the possible window size depends on screen size, a window wider/higher than the screen is impossible. A wide (relative to height) window supports having the message window at the side and a wider symbols pane, with a less ultra wide window it is preferable to have it on the bottom, and a Raspberry Pi window supports not much of either.
These are most definitely not the settings users want synced between machines unless they are exactly the same screen and the user chose a similar window size. If the two machines are the same the user just syncs both `geany.conf` and `session.conf`.
With your approach, almost everything is session because everything is eventually tied to GUI
Reducio ad absurdum.
reconfigure msgwin/sidebar location whenever a new session is created would be annoying.
Yes, if the capability to create a new session is added to Geany it should copy the current values, its on the same machine as the current session, so it should have the same layout by default. But ATM the only way within Geany to create new session files is to create a whole new config directory with `-c` and that writes default values.
Only if only your configs were used to find sessionable preferences.
Or your configs, or @kugel-s .... everybody has different use-cases. My point was that removing existing use-cases because its not how _you_ or _I_ use Geany is not acceptable.
A better rule of thumb for session variables would be anything the user does not or cannot set explicitly. Or put another way, Geany should avoid resetting/undoing what the user has explicitly set. If there is a setting in the preferences dialog, or elsewhere, it should not be a session config. This has precedence, for instance, with the filetype auto-detection. Geany does *not* redetect filetype on reload because the user *might* have explicitly changed it.
* MRU – session – not explicitly set by the user * Window position and geometry – session – not explicitly set by the user * Sidebar/msgwin location – *not* session – explicitly set by user in preferences. * Sidebar/msgwin position – session – not explicitly set by user. (The user can change it, but this is an *implicit* change. There is no *explicit* setting in preferences or elsewhere.)
-----
@elextr Your definition is overly inclusive. Only a handful of settings don't fit your criteria as session variables. You essentially confirm this when you stated, "I have defaulted to yes if I'm unsure". (You give a different reason for that default, but using an unsuitable definition of "session" would contribute that that problem.)
The core of the definition you suggest is:
a setting that an individual user is likely to change, possibly often...
That would be detected by running diff on sequential config files (as I suggested). Although I did not mention collecting samples from multiple users, I pretty much took it as a given since it is a common, well-known approach to avoid over-specificity. Configs that change more frequently across a greater number of users are better candidates than configs that do or don't change for only one (or a few).
and it doesn't affect the files being edited
That part is arbitrary. You and other devs have described project files as just "named sessions". You state that indent settings are *not* session config, but indent settings are part of project files (indicating that it likely *is* session config).
There are only a handful of settings that affect the edited file. Default encoding, line endings. The vast majority of other settings affect the editing environment (eg, GUI), but not the edited files.
@xiota I would have to say your definition is overly exclusive, it leaves sessions with almost nothing in them, so conf (and project when its split) will still be changing often, and avoiding that is one of the reasons behind the split.
To be clear I don't believe there is a simple absolute rule that can always be applied, we need to use some brainpower, not rules, or statistics, the guidance I expressed is a starting point.
That would be detected by running diff on sequential config files (as I suggested).
To find out _how often_ something is changed this would need to be performed many many times, not gonna happen.
You and other devs have described project files as just "named sessions".
That is a term to indicate that they are very simple, not like VS or Eclipse "Projects". The indent settings and the session files list are in one file now because that is all there is, it does not guide where they should be when the session and project are split.
I would have to say your definition is overly exclusive, it leaves sessions with almost nothing in them, so conf (and project when its split) will still be changing often
If Geany does not change settings that the user explicitly sets, why would the conf file frequently change unless the user is constantly changing settings?
Regarding plugins, I would consider all of them to be session prefs.
`active_plugins` and `custom_plugin_path` contain local paths, thus they are not suitable for sharing between different machines. `load_plugins` is generally questionable. Users that don't want plugin simply don't enable any plugin. So the key is more of a debug option to me.
Anything below tools is system dependent. On my work machine I might be forced to Ubuntu while on my laptop I'm free to use KDE, or I cannot install my favorite grep clone system-wide on my workstation.
Apart from that we have rather sane defaults that work everywhere (except maybe terminal_cmd).
I would make a PR migrating these to session.conf
``` [tools] make_cmd=make browser_cmd= grep_cmd=grep terminal_cmd=gnome-terminal -e "/bin/sh %c"
@kugel agree with the first three, as you say terminal is more debatable, for example you would not want to migrate a `gnome-terminal` command to a KDE system that might not have it installed.
That's the point. On a kde "Konsole" is more appropriate, and thus it's probably that a user uses gnome-terminal on machine A and konsole on machine B.
Ahhh, I misread your "(except maybe terminal_cmd)" as "maybe not move that to session", but on re-reading it I see its referring to the default not being always sane.
So in that case we agree all four should be moved to session.conf.
Right, I was refering to the default. xterm is not a great default.
Unfortunately, there doesn't seem to be a XDG or freedesktop standard for "default terminal application" so I won't touch the default.
github-comments@lists.geany.org