[kate] [Bug 489600] New: Some .kateconfig settings are applied only after file reload (pressing F5)
https://bugs.kde.org/show_bug.cgi?id=489600 Bug ID: 489600 Summary: Some .kateconfig settings are applied only after file reload (pressing F5) Classification: Applications Product: kate Version: 23.08.5 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: chri...@mailbox.org Target Milestone: --- SUMMARY After having used a .kateconfig file for a long time (mostly for file type-dependent tab-related settings), I wanted to also use it to change the font for some file types. First I was happy to see that there is in fact a documented variable for this but then I was disappointed to see that it had no effect. Only by chance did I notice that after reloading the file (by pressing F5) the setting was actually applied. STEPS TO REPRODUCE 1. If you do not have one already, create a .kateconfig file in your home directory. (Learn about [kateconfig-files](https://kate-editor.org/2006/02/09/kateconfig-files/) if you want to. 2. Add a modeline like the following `kate-wildcard(*.txt): word-wrap-column 20; font-size 18; font Noto Sans;`. The `word-wrap-column 20` is just for testing (this should work), the specific `font` does not matter -- pick any font you have installed (non-mono for more obvious effect). Learn about [kate-modelines](https://kate-editor.org/2006/02/09/kate-modelines/) if you want to. 3. Open a file ending in `.txt`. OBSERVED RESULT You will see your default font (and the marker line after 20 columns). EXPECTED RESULT You will see a large non-mono font. SOFTWARE/OS VERSIONS Linux: openSUSE 15.6 KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 486310] Add Clip or Folder dialog window too small
https://bugs.kde.org/show_bug.cgi?id=486310 Chris K. changed: What|Removed |Added CC||cplove2...@vivaldi.net --- Comment #3 from Chris K. --- Similar problem for circa one week » after Linux Manjaro big-update to Plasma 6. Kdenlive seems to work fine (as far as I can tell), but the saving of FX-stacks opens up a window which now (in Plasma 6) is a) way to small » i have to resize it everytime (for years the size was perfect, I didn't even thing about it) b) the text-focus does not change automatically "into" the then opened "save as new FX-stack" window (I have to click the field where the name of the new fx-stack goes) Thank you, best regards (from Germany) Chris -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 486310] Add Clip or Folder dialog window too small
https://bugs.kde.org/show_bug.cgi?id=486310 --- Comment #4 from Chris K. --- Sorry, I wanted to write "...think about it..." (not "...thing about it..."). Best regards Chris -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 453800] New: Kate's Recent Files List | every entry on list can be opened only once after update to 22.04.0 (restart of Kate necessary)
https://bugs.kde.org/show_bug.cgi?id=453800 Bug ID: 453800 Summary: Kate's Recent Files List | every entry on list can be opened only once after update to 22.04.0 (restart of Kate necessary) Product: kate Version: 22.04.0 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: cplove2...@vivaldi.net Target Milestone: --- SUMMARY All entries in Kate's Recent Files List/Menu can be clicked/opened only once in a current Kate session. If all entries (file links) in the list are clicked/opened the Recent Files List is "grayed out" (set to empty). The "bug" (?) appeared first after the current update of Kate (Manjaro 5.15.38-1) on the 14th of May 2022 STEPS TO REPRODUCE 1. Open/click on Recent Files List (Menu) 2. Open an entry and/or all entries (file links) in the list 3. Every entry (file link) is clickable only once in a current Kate session 4. After all entries in the Recent Files List are clicked/opened in one Kate session, the list is set to "empty" (grayed out) 5. Kate has to be closed/restarted in order to see the Recent Files List. After the restart of Kate the "game starts over again"... SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.15.38-1-MANJARO (64-bit) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 453800] Kate's Recent Files List | every entry on list can be opened only once after update to 22.04.0 (restart of Kate necessary)
https://bugs.kde.org/show_bug.cgi?id=453800 --- Comment #1 from Chris K. --- Additional Comment: Prior to Kate-update 22.04.0 an entry (file link) could be opened/closed any number of times. For me it makes no sense to have a list where an entry (file link) can be opened only once per session (often I open/close a file or files multiple times per Kate session if a new code change is necessary...) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 453800] Kate's Recent Files List | every entry on list can be opened only once after update to 22.04.0 (restart of Kate necessary)
https://bugs.kde.org/show_bug.cgi?id=453800 --- Comment #3 from Chris K. --- Update: Today I removed all settings and personal data from this two local folders /home/*USER*/.config/kate/ /home/*USER*/.local/share/kate/ in order to test if I had some kind of mistake or wrong setting in there (etc.). But no, nothing changed: Kate still allows entries (file links) in the Recent File List to be opened only once and then sets the menu to empty (grays it out). This "bug" (if it is one) is not a major one, but makes my work a little bit tiresome as I have to close/reopen Kate in order to have access to the Recent File List... I'm 100 % sure that this behaviour did't exist prior the the last Kate update (I did it on the 14 May of 2022). At this point I cannot tell if it is a special problem with Kate + Manjaro or a general one with every KDE distro. Thank you, best regards. Chris K. from Germany -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 453800] Kate's Recent Files List | every entry on list can be opened only once after update to 22.04.0 (restart of Kate necessary)
https://bugs.kde.org/show_bug.cgi?id=453800 --- Comment #4 from Chris K. --- Update II: I just tested the function "New Session (Alt+S)" in order to restart Kate automatically without closing it. The result is "funny": All entries/links in my Recent File List which were clicked one time in my last session are left in the Recent File List when I click "New Session (Alt+S)". In detail: If I had two links/entries in my last Recent File List, the next time I start a "New Session" I will have four links: -> two duplicated links at the top which are clickable (only once) -> two dead links at the bottom, which are not openable (dead) If I click at the two entries/links at the top, my Recent File List is set to empty and grayed out (the two old links at the bottom are dead as I mentioned above). If I then click on "New Session (Alt+S), two new links will be added to the Recent File List at the top while now four dead links are still visible. This game can be played into infinity: If I click on the two new entries on the top, the list will be grayed out; a "New Session" will then show six/eight/ten/12/14/...n+2 dead links in the Recent File List an two new clickable links. My current, very simple Recent File List with only two entries looked like this (two css-files from my Vivaldi Browser): cplove.css (clickable) common.css (clickable) cplove.css (dead, from previous session) common.css (dead, from previous session) cplove.css (dead, from previous-previous session) common.css (dead, from previous-previous session) cplove.css (dead, from previous-previous-previous session) common.css (dead, from previous-previous-previous session) cplove.css (dead, from previous-previous-previous-previous session) common.css (dead, from previous-previous-previous-previous session) Thank you, best regards. Chris K. from Germany -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 432283] More generous value range for tab width
https://bugs.kde.org/show_bug.cgi?id=432283 --- Comment #3 from Chris K --- Thank you for the quick action. I agree that 200 is reasonable (there should be some boundary); certainly works for me. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 432283] New: More generous value range for tab width
https://bugs.kde.org/show_bug.cgi?id=432283 Bug ID: 432283 Summary: More generous value range for tab width Product: kate Version: 20.04.2 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: indentation Assignee: kwrite-bugs-n...@kde.org Reporter: christop...@kappe.biz Target Milestone: --- Created attachment 135286 --> https://bugs.kde.org/attachment.cgi?id=135286&action=edit tab-separated CSV file, colums wider than 16 The maximum width I can configure the tabulator character to take is 16. This is probably more than enough for 90% of all cases or more but lately I have to deal with a scenario more often where a larger value would be nice. 16 seems like an arbitrary and unnecessarily low value. I propose to allow e.g. up to 99; this can still be represented by a signed byte (if there is a technical constraint) and presented in a two digits wide integer input (if this plays a role). Concrete case for the feature request: CSV files where the separator is tab, not comma. When such files have few columns but large values, such files can theoretically nicely be viewed and edited in Kate (given a reasanable window size). For values that are wider than 16 characters, however, currently the alignment of the columns is lost. STEPS TO REPRODUCE 1. Open attached example.csv 2. Try to set tab width e.g. to 28 OBSERVED RESULT Even the "miscellaneous" option allows only for max. 16. EXPECTED RESULT Possibility to set at least, say, 50; maybe 99 or even greater. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Leap 15.2 (available in About System) KDE Plasma Version: 5.18.6 KDE Frameworks Version: 5.71.0 Qt Version: 5.12.7 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 491939] New: Shortcut (custom) for recently opened files does not work
https://bugs.kde.org/show_bug.cgi?id=491939 Bug ID: 491939 Summary: Shortcut (custom) for recently opened files does not work Classification: Applications Product: kate Version: 23.08.5 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: chri...@mailbox.org Target Milestone: --- SUMMARY I always have my Kate menu bar hidden because I usually don't need it. Only rarely I want to quickly access the recently opened files. To avoid always having to make the menu bar visible and navigate to this item, I have now set a shortcut for this action. It does show up next to the menu item label but pressing the combination has no effect for me, even if I already have the file menu open, so in no "state" of Kate. This is frustrating. I want to kindly ask to either remove the possibility to set a shortcut for this action if it cannot be implemented easily, or please actually implement it. STEPS TO REPRODUCE 1. Configure a keyboard shortcut for "Open Recent" (e.g. Ctrl+Shift+P). 2. Press the shortcut keys. OBSERVED RESULT Nothing happens. EXPECTED RESULT The list of recently opened files is shown, similar to when navigating to this point in the File menu. SOFTWARE/OS VERSIONS Linux: openSUSE Leap 15.6 KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 489600] Some .kateconfig settings are applied only after file reload (pressing F5)
https://bugs.kde.org/show_bug.cgi?id=489600 --- Comment #2 from Chris K --- (In reply to TraceyC from comment #1) > The bug says some settings are applied after a reload. Can you let me know > one or two settings that are applied without a reload for testing purposes? > I want to confirm if this is behavior by design or inconsistent behavior. > > Note: The current documentation doesn't mention whether it's expected that > the user needs to reload a document to reflect changes in the .kateconfig > file > https://docs.kde.org/stable5/en/kate/katepart/config-variables.html One thing that works directly (after opening a fitting file) is the *word-wrap-column* variable (as given in the original report). Another example is *replace-tabs* (off/on). This is definitely the intention; you cannot expect people to open a file and then immediately manually reload it, just to get the settings applied. The inconsistent behavior is the font family and size, which requires this kind of reload. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 491069] New: Going through tabs with Ctrl+PageUp/Down does not wrap around
https://bugs.kde.org/show_bug.cgi?id=491069 Bug ID: 491069 Summary: Going through tabs with Ctrl+PageUp/Down does not wrap around Classification: Applications Product: kate Version: 23.08.5 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: chri...@mailbox.org Target Milestone: --- SUMMARY I know that the usual way of going through the tabs of the tabbar in Kate with Ctrl+Tab and Ctrl+Shift+Tab is different from most other applications in that it always goes back to the last one used. Personally this has annoyed me oftentimes but recently I found out by chance that you can also go through the tabs with Ctrl+PageUp/Down. This does the expected left/right movement. It also works in all other apps I have tried, e.g., Firefox, Dolphin, Konsole. However, while in all these apps pressing Ctrl+PageDown on the last (rightmost) tab leads the user to the first (leftmost) tab, this does not work in Kate. Which is quite frustrating. STEPS TO REPRODUCE 1. Open two files in Kate. 2. Having focused the second one, press Ctrl+PageDown. OBSERVED RESULT Nothing happens. EXPECTED RESULT The focus goes to the first tab. SOFTWARE/OS VERSIONS Linux: openSUSE 15.6 kernel 6.4.0-150600.23.14-default (64-bit) KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 ADDITIONAL INFORMATION I think this could be fixed very easily if you know where. Like "if i==n: i = 0" -- You are receiving this mail because: You are watching all bug changes.
[Touchpad-KCM] [Bug 342929] inverted scroll direction not handled
https://bugs.kde.org/show_bug.cgi?id=342929 Chris K. changed: What|Removed |Added CC||coldlookinggl...@gmail.com --- Comment #29 from Chris K. --- (In reply to davidebasilio from comment #28) > One last observation: it seems that the setting is not preserved after > resuming from suspension. > > For example, right after resume, kmail has standard scrolling. > If I close and reopen it, it gets back to inverted scrolling. Yes. See https://bugs.kde.org/show_bug.cgi?id=350240 -- You are receiving this mail because: You are watching all bug changes.
[Touchpad-KCM] [Bug 342929] inverted scroll direction not handled
https://bugs.kde.org/show_bug.cgi?id=342929 Chris K. changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #30 from Chris K. --- *** This bug has been confirmed by popular vote. *** -- You are receiving this mail because: You are watching all bug changes.
[Touchpad-KCM] [Bug 342929] inverted scroll direction not handled
https://bugs.kde.org/show_bug.cgi?id=342929 --- Comment #31 from Chris K. --- This makes the new openSUSE (42.2) almost unusable for me; I'm so used to the "inverted" scrolling. I switched to this behavior only a few days after I got myself a smartphone and it was working just fine for all applications under 42.1. Personally, I am surprised how many people still seem to use the mouse wheel the old way but obviously there are two groups of users who prefer one option respectively. So this configuration possibility MUST work. Adding to the existing comments, I, too, notice inconsistent behavior. While `xinput set-button-map "Logitech USB-PS/2 Optical Mouse" 1 2 3 5 4` fixes the problem for me for most applications untill the next reboot or unsuspend, some apps like Kate are not affected. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 489600] Some .kateconfig settings are applied only after file reload (pressing F5)
https://bugs.kde.org/show_bug.cgi?id=489600 --- Comment #5 from Chris K --- Thank you! :-) -- You are receiving this mail because: You are watching all bug changes.
