[session-split] More things to session

[elextr]

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

[kugel-]

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.

[elextr]

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.

[kugel-]

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

[elextr]

This is what is in session.conf, note current_page seems to be in both with -1 in geany.conf and 0 in session.conf?

[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

opened about.c 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.

[elextr]

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.

[xiota]

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...

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.

Another split might be GUI vs non-GUI preferences... But then there would be too many different config files. (Or not. There are already a lot of config files.)

[elextr]

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 😁 In other words thats too individual to be useful.

[xiota]

@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. Even if they don't sync settings across computers, having to reconfigure msgwin/sidebar location whenever a new session is created would be annoying.

With your approach, almost everything is session because everything is eventually tied to GUI. Very few settings affect only 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) because it affects only the appearance of the file.

So a method to find sessionable preferences would be to run diff on sequential copies to see what preferences are frequently changing.

... In other words thats too individual to be useful.

Only if only your configs were used to find sessionable preferences.

[elextr]

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.

[xiota]

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 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.)

sidebar/msgwin visibility is a gray area. There is a setting the user can change explicitly, but Geany saves state by changing the setting directly. Since state saving is automated, I would consider this a session preference. Gray area settings could be removed from preferences, since Geany automatically manages them. The menu to show/hide would remain (an "implicit" setting). Or the meaning of the setting in preferences could be changed (eg, startup default vs restore state), so that Geany saves state by changing a different variable.

---

@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. Settings that change more frequently across a greater number of users are better candidates than settings that do or don't change for only one (or a few).

and it doesn't affect the files being edited

That 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, indent (but only if tabs to spaces is enabled). The vast majority of other settings affect the editing environment (eg, GUI), but not the edited files.

[elextr]

@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.

[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

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?

It seems part of the problem is not so much config/session split, but also shared vs individualized settings... eg, so that a project/config file could be included in a git repository. In this context, it makes sense that you would want GUI settings to be considered "session" (really, individualized). (Some of your comments about project behavior also make sense in a shared settings context.)

[kugel-]

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.

[kugel-]

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"

[elextr]

@kugel- (sorry @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.

[kugel-]

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.

[elextr]

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.

[kugel-]

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.