[Bug 2065612] [NEW] Primary monitor showing as UNKNOWN and refresh rate is off

Public bug reported: Hi, I'm also facing the same issue in version 24.04 that wasn't present in version 22.04. Since upgrading, my monitor is identified as 'unknown,' and I'm unable to adjust the refresh rate from 60Hz to either 120Hz or 240Hz, even though my monitor fully supports this Hz level.

[Desktop-packages] [Bug 1978401] [NEW] display turns suddenly off and then on again

Public bug reported: Hi, Randomly the display turns off and then on again. Happens sometimes many times and others times not at all, randomly. Related to https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics- drivers-495/+bug/1956252 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package:

[Touch-packages] [Bug 1978401] [NEW] display turns suddenly off and then on again

Public bug reported: Hi, Randomly the display turns off and then on again. Happens sometimes many times and others times not at all, randomly. Related to https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics- drivers-495/+bug/1956252 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package:

[Ubuntu-x-swat] [Bug 1978401] [NEW] display turns suddenly off and then on again

Public bug reported: Hi, Randomly the display turns off and then on again. Happens sometimes many times and others times not at all, randomly. Related to https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics- drivers-495/+bug/1956252 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package:

[Kernel-packages] [Bug 1956252] Re: display turns suddenly off, i need to re-plug the cable

I also tried different versions of the graphic driver. ** Description changed: Hi, Randomly the display turns off and then I need to re-plug the monitor - afterward it works again. Happens sometimes many times and others not at - all, randomly. - + afterwards it works again. Happens

[Kernel-packages] [Bug 1956252] [NEW] display turns suddenly off, i need to re-plug the cable

Public bug reported: Hi, Randomly the display turns off and then I need to re-plug the monitor afterwards it works again. Happens sometimes many times and others times not at all, randomly. Description:Ubuntu Jammy Jellyfish (development branch) Release:22.04

[Bug 1956252] Re: display turns suddenly off, i need to re-plug the cable

I also tried different versions of the graphic driver. ** Description changed: Hi, Randomly the display turns off and then I need to re-plug the monitor - afterward it works again. Happens sometimes many times and others not at - all, randomly. - + afterwards it works again. Happens

[Kernel-packages] [Bug 1956252] Re: display turns suddenly off, i need to re-plug the cable

Happens on 20.04, 20.10, 21.04, 21.10, and 22.10 but less often on 22.10 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-495 in Ubuntu. https://bugs.launchpad.net/bugs/1956252 Title: display turns suddenly off,

[Bug 1956252] Re: display turns suddenly off, i need to re-plug the cable

Happens on 20.04, 20.10, 21.04, 21.10, and 22.10 but less often on 22.10 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956252 Title: display turns suddenly off, i need to re-plug the cable To

[Bug 1956252] [NEW] display turns suddenly off, i need to re-plug the cable

Public bug reported: Hi, Randomly the display turns off and then I need to re-plug the monitor afterwards it works again. Happens sometimes many times and others times not at all, randomly. Description:Ubuntu Jammy Jellyfish (development branch) Release:22.04

Re: ENB: Dubious idea: multi-dimentional outlines

Am Dienstag, 21. April 2020 15:56:26 UTC+2 schrieb Edward K. Ream: One thought was to put one or more unit tests for node p in p.u, p's user > data. Clearly that's possible. Moreover, a script could discover and run > such unit tests. > > That's not really multidimensionl, just nested, as

Re: Reproducible computational science

Am Dienstag, 7. April 2020 21:57:27 UTC+2 schrieb Brad: > > > I wonder if Leo could be a compelling platform for this use case. > > Why do you think that? What is leo offering that other solutions miss? The idea would be to have a sharable Leo file of a given format that would > include

Re: A better way to send code to language processors

Am Dienstag, 24. März 2020 01:32:29 UTC+1 schrieb Thomas Passin: I often use mixtures of code and non-code blocks. If there are different > kinds of code blocks, though, there can be problems if you want to execute > them. If you execute each code block with a different language processor,

Re: A better way to send code to language processors

Am Montag, 23. März 2020 16:49:08 UTC+1 schrieb Edward K. Ream: This post > > shows a button that sends code to rust. Thomas adapted it for Graal/JS > here

Re: Zettelkasten - Notes Jim but not as we know them.

Am Freitag, 28. Februar 2020 15:19:38 UTC+1 schrieb Thomas Passin: It's not about storage, it's about reducing visual clutter in the text. > Understandable. I have that problem too. Im thinking about moving my metadata to p.v.u and adding a metadata-widget on the editor-side to not forget

Re: Zettelkasten - Notes Jim but not as we know them.

Am Freitag, 28. Februar 2020 04:51:42 UTC+1 schrieb andyjim: Another ugly and inconvenient question: Are you contemplating a command to > automate starting a new zettel (is it ok to use that term for the time > being? I gather you plan to find a new term.)? Sorry to bring it up again, > but

Re: Zettelkasten - Notes Jim but not as we know them.

Am Freitag, 28. Februar 2020 02:11:20 UTC+1 schrieb Thomas Passin: I think the capabilities of the Nav tab will go a long way. > True, there is also that. I always forget it, because it's so bad UX. BTW Using "created" instead of "timestamp" would be more self-documentating. >> > > That's up

Re: Zettelkasten - Notes Jim but not as we know them.

Am Donnerstag, 27. Februar 2020 15:46:04 UTC+1 schrieb Thomas Passin: But in general you are not wrong here. Leo Editor can be used that way, >> even though it's not be the best for this. But it's not the worst either. >> It depends on how you polish it and yourself. Using Leo in a way to copy

Re: Zettelkasten - Notes Jim but not as we know them.

Am Mittwoch, 26. Februar 2020 23:50:11 UTC+1 schrieb andyjim: I must frankly admit that the only reason I am barking up the zettelkasten > tree is that I have failed to run across a better system > You never played with Wikis? Or generally Hypertext? though of course not a replica of

Re: Zettelkasten - Notes Jim but not as we know them.

Am Dienstag, 25. Februar 2020 17:33:10 UTC+1 schrieb Thomas Passin: All right; I've not seen the term "zettelkasten" applied to systems before > Luhmann's got publicised. > Well, I can't speak for the etymology of the word. It's even in germany not the most popular usage for this word

Re: Zettelkasten - Notes Jim but not as we know them.

Am Dienstag, 25. Februar 2020 02:37:13 UTC+1 schrieb Thomas Passin: Note: Luhmann was the inventer of the zettelkasten. > Ok, just for clarification: No he was not. Zettelkasten is a german word for a box (=kasten) of paperslips (=zettel). It's pretty common tool. People before Luhmann used

Re: Zettelkasten - Notes Jim but not as we know them.

Am Montag, 24. Februar 2020 20:28:05 UTC+1 schrieb andyjim: > I'm still wondering exactly how Luhmann's indexing played out. > He used manual maintained index-cards of keywords. Just big lists of keywords with reference-numbers which he used a startingpoint to dig into a topic. You can

Re: Inspired by Vitalije's prototype

Am Dienstag, 12. Juni 2018 12:43:11 UTC+2 schrieb Edward K. Ream: Terry, Vitalije, Ville Vainio, Bernhard Mulder, Kent Tenney, Marc-Antoine > Parent, Paul Paterson and others have all made significant contributions to > Leo. By any reasonable measure, Leo is open software. > It's not whether

Re: Inspired by Vitalije's prototype

Am Dienstag, 12. Juni 2018 12:50:00 UTC+2 schrieb vitalije: > But just FYI here is the explanation from github how they count contributions. Ok, I see where you are coming from. Did you confirm that commits to develop are not appearing in your contribution-list after devel was merged to

Re: Inspired by Vitalije's prototype

Am Montag, 11. Juni 2018 15:48:00 UTC+2 schrieb vitalije: Since March 2018, when it was declared that only Edward should commit to > the master brunch, no contribution is counted for any other developer in > leo-editor team. > This is not true. The individual commits of every developer are

Re: Any plausible use for uA's that can't be serialized to json?

Am Dienstag, 1. Mai 2018 23:07:36 UTC+2 schrieb Edward K. Ream: Several Leo devs have suggested using json rather than pickle to represent > Leo's uA's. > > Does anyone presently use any uA that can't be serialized into json? > > Not sure whether you are aware about it, but pythons json-module

Re: Basic Layout of the Leo GUI

Am Mittwoch, 18. April 2018 22:32:37 UTC+2 schrieb john lunzer: That said, your argument appears to be based on something, the "conventions > and standards" of IDE GUIs, that if it exists at all is a rapidly changing > amorphous blob at best. > Not true. There is strong core of established

Re: Merging 5.8-dev into master is next

Am Mittwoch, 28. Februar 2018 11:01:04 UTC+1 schrieb Edward K. Ream: > > On Wed, Feb 28, 2018 at 3:39 AM, 'Marcel Franke' via leo-editor < > leo-e...@googlegroups.com > wrote: > >> >> The usual way to do this today: >> >> master as stable. >>

Re: Merging 5.8-dev into master is next

Am Dienstag, 27. Februar 2018 21:36:11 UTC+1 schrieb Edward K. Ream: > > On Tue, Feb 27, 2018 at 2:19 PM, Matt Wilkie > wrote: > > Would it be easier to invert the process, and have dedicated releases >> branches and then master never needs to be frozen? >> > > ​Anything is

Re: What I've just learned from Vitalije

Am Donnerstag, 14. Dezember 2017 11:05:46 UTC+1 schrieb Edward K. Ream: ​In our code, bool(node) is always True, so this comment is a bit off the > mark. > Well that's a chance to fix this. You are also free to enhance the check.Checking expliciet for None is popular with other DOM-libs.

Re: What I've just learned from Vitalije

Am Mittwoch, 13. Dezember 2017 22:28:50 UTC+1 schrieb Edward K. Ream: def a_generator(): > if 0: > yield 'abc' # Makes the function a generator > return None > This only works with Python 3. Python 2 does not support mixing return and yield. It's also overcomplicated.

Re: My last lecture. Part 1: Why Leo is noteworthy

Offray Vladimir Luna Cárdenas wrote: This idea of an always present outline has been key to me for organizing > writings. Some coworkers have found in the past that this helps them when > we're correcting their text. On a sightly off-topic, most of them are > school teachers making their

Re: My last lecture. Part 1: Why Leo is noteworthy

Edward K. Ream wrote: ​Unconvincing.​ > > >> > What surprise... ​The naming principle I use is this: the more important the name, the > shorter it should be. > That is obvious, and it is still wrong. If you want your comments to be taken seriously, you should refrain from > nit

Re: My last lecture. Part 1: Why Leo is noteworthy

Edward K. Ream wrote: Leo's API consists primarily of *generators*, such as c.all_positions(), >>> p.self_and_subtree(), etc. and *properties*, such as p.b, p.h, p.gnx >>> and p.v.u. >>> >> >> One thing I always wondered about...is there a reason why Leos API is so >> unpythonic? >> > >

Re: My last lecture. Part 1: Why Leo is noteworthy

Edward K. Ream wrote: Leo's API consists primarily of *generators*, such as c.all_positions(), > p.self_and_subtree(), etc. and *properties*, such as p.b, p.h, p.gnx and > p.v.u. > One thing I always wondered about...is there a reason why Leos API is so unpythonic? > AFAIK, these

Re: Making Leo easier to install

Edward K. Ream wrote: > > > What speaks against a traditional executable package? py2exe >> ​[snip] >> > > ​The py2exe is windows only, and afaik does not support including > (downloading, unpacking) the appropriate Qt ​code. Neither does NSIS, > again afaik. > No, it's possible to package

Re: Making Leo easier to install

Kent Tenney wrote: Given Leo's programmability and vast number of plugins, it is really > a platform for building things, and a learning curve is involved. > Getting it installed correctly and painlessly is required but doesn't > help in understanding what power is available. > > See, VM and

Re: Making Leo easier to install

Edward K. Ream wrote: In essence, this file would be a VM (Virtual Machine) containing: > VMs are heavy on the performance, need additional software and integrate bad into the system. Also, VMs need an underlying OS, which would mean some Linux-Distribution which run parallel to the existing

Re: Monthly updates as advertising

Edward K. Ream wrote: > The easiest advertising, and perhaps the most effective, are release > announcements. > The most efficient is people talking about something. Release announcements only fetch attention, but they don't discussions. Also, where would you put those announcements to?

Re: Monthly updates as advertising

Edward K. Ream wrote: > If I released a new version of Leo every month that would substantially >>> increase Leo's online presence. >>> >> >> Has Leo even enough manpower to deliver something worth in a month? >> Because nobody will be impressed >> from a list of 3 bugfixes and a new

Re: Making Leo easier to install

Kent Tenney wrote: Yeah, I've been very impressed with the ease of installing > and upgrading Calibre. > > Do you have insight into how they prepare their installer? > You can find the code under https://github.com/kovidgoyal/calibre/tree/master/setup Seems they have their own toolchain,

Re: A note to new users

john lunzer wrote: > Splitting nodes on a def tag would be custom behavior. Though I may > eventually add this functionality into my refactoring plugin because it > sounds quite useful. Along with a split-on-tag function a merge-on-tag > function would be super useful as well. > A

Re: A note to new users

john lunzer wrote: Unless i've overseen something, it only outlines structure, meaning >> functions/methods and classes, and only at import-time. >> Not loops, conditionals, comments and it does not update them after a >> change in the body, only when it reimports from the file. > > > I think

Re: A note to new users

Terry Brown wrote: > For me, one example, editing XML, a simple DB definition. Editing the > XML using Leo's XML editing "leo2xml", not editing XML directly, which > is not something you should be doing regularly. So I want the field > I'm editing and all following fields in the table

Re: A note to new users

Edward K. Ream wrote: > > > Still there would be a *long* way to go to make either vim or emacs a > Leonine environment. > Depends on how good the core is separated from the UI. A headless leo which acts as a database-system, delivers data and recives commands for working on the data could

Re: A note to new users

john lunzer wrote: > > From my short time testing out sr-speedbar (which keeps the speedbar in > the original window) speedbar works opposite of Leo. It builds up an > outline from parsing directory tree and source code of each file. This is > immensely useful for navigation but it lacks the

Re: A note to new users

Am Dienstag, 22. September 2015 12:54:49 UTC+2 schrieb john lunzer: > > Leo's stability in code manipulation is not prone to failure, it is very > deterministic. > You mean node-manipulation? Because actual code-manipulation does not seem to be a feature from Leo. Leo just copies

Re: A note to new users

At 22. September 2015 15:49:04 UTC+2 john lunzer wrote: Given that Leo is written in Python I think that it is natural for Leo to > be aimed at being a premier IDE for Python language programming. > So, does it compete with more with IDLE or more with Eclipse or even PyCharm? And for whom?

Re: A note to new users

john lunzer wrote: The lack of outlining feels like a handicap at best and trying to program > nearly blind at worst. > Did you try the code-outline-plugins of vim or emacs? For vim it's "tagbar", for emacs i think it was "speedbar". Folding is another useful way for (inline-)outlining of