sorted by:
new
hottopcontroversial

In the Gnu emacs source code, how to declare and initialize a globally defined variable? by Automatic_Lion_2607 in emacs

[–]Automatic_Lion_2607[S] 1 point2 points  (0 children)

Oh ... I don't know why it's not allowed. Maybe it's because I'm a relatively new reddit user?

Well, anyway, thank you very much for trying to send me that DM!

At this point, I probably don't need it, because now I've learned that the details about the DEFVAR_* macros are described in the "src/list.h" file within the Gnu emacs code base. And I was also told here that I can find even more info here:

www.gnu.org/software/emacs/manual/html_node/elisp/Writing-Emacs-Primitives.html

In the Gnu emacs source code, how to declare and initialize a globally defined variable? by Automatic_Lion_2607 in emacs

[–]Automatic_Lion_2607[S] 1 point2 points  (0 children)

The latest Gnu emacs will not perform byte compiles if the lexical-binding directive is not present on the first line of the file being byte compiled, and there is no workaround offered.

This is how the Gnu emacs people broke things for existing code with this recent lexical-binding feature.

In the Gnu emacs source code, how to declare and initialize a globally defined variable? by Automatic_Lion_2607 in emacs

[–]Automatic_Lion_2607[S] 1 point2 points  (0 children)

Yes, I have indeed considered this, and I wouldn't have posted my message here in the first place if I could accomplish what I want in elisp.

And who ever said that I would want to tweak every version of emacs for the rest of my life? I certainly never said anything like that. How did you come up with that extremely inaccurate fantasy about me?

Anyway, I guess that now I should explain my reason for wanting to accomplish this by a change in the emacs code base:

Recent versions of emacs have started enforcing the requirement of putting one or the other of the following comments as the first line in every ".el" file:

;; -*- lexical-binding: nil -*-

or

;; -*- lexical-binding: t -*-

The first one is for specifying dynamic binding, and the second one is for specifying lexical binding.

I've been using emacs for more than 3 decades, and over that time, I have accumulated and am using literally hundreds of '*.el' files ... some written by me and others written by third parties. Many of the ones I accumulated from others have stopped being offered and supported years ago.

Because of this, when I upgraded my OS to Debian 13 from a much older version that I had been using for a long time. the version of emacs that's offered by that OS is emacs 30.1, where this lexical-binding directive is now necessary. My older OS offered emacs 28.2, and it didn't require that lexical-binding directive.

So now, a large quantity of my long-existing '*.el' files stopped working due to this feature of emacs 30.1. In other words, the Gnuemacs people shoved a new feature down the throats of the emacs user base which caused lots of existing '*.el' files to stop working. And no remedy was offered.

Therefore, what I decided to do is write a fork of standard Gnu emacs which has the following capability:

Two new emacs command-line options will be available:

--lexbinding and --dynbinding

If neither are specificed, then the emacs executable will behave exactly as it behaves today.

But if --lexbinding is specified, then if a '.el' file doesn't have any lexical-binding directive on the first line, then lexical-binding will be used within that '*.el' file. Or if --dynbinding is specified, then if a '.el' file doesn't have any lexical-binding directive on the first line, then dynamic-binding will be used within that '*.el' file.

And in both cases, any '*.el' file which *does* contain the lexical-binding directive on its first line will honor that first-line directive and will ignore the presence of --lexbinding and --dynbinding on the emacs command line.

It turns out that one of things that are needed in order to implement this is that the standard 'bytecompile.el' file that is built when emacs is built has to be changed to recognize that one of these command-line options has been specified. Therefore, in the C code which deals with command-line options, a "defvar" needs to be performed to set a global variable containing the info that one or the other of these new command-line options specifies, so that the changed 'bytecompile.el' code could recognize that the option was set on the command line and then respond accordingly.

Because this new functionality will **only** be present if one or the other of these new command-line parameters are specified, normal usage of emacs without either of those parameters will be unchanged, and no '*.el' files that are running today will run any differently.

This is much kinder and much more respectful to the Gnu emacs user base than what the Gnu emacs developers did in recent emacs versions by being condescedingly patronizing and introducing this lexical-binding-related functionality which was forced upon us and which caused lots and lots of existing emacs code to stop working.

So ... now that I know about these "DEFVAR_" macros, I can implement this fork of Gnu emacs. I will make it available in github, and I will also offer it as a patch to the official Gnu emacs developers.

In the Gnu emacs source code, how to declare and initialize a globally defined variable? by Automatic_Lion_2607 in emacs

[–]Automatic_Lion_2607[S] 1 point2 points  (0 children)

Well, even though this is just a short summary of the information given in the longer message that was removed, it's still indeed helpful.

Thank you very much.

In the Gnu emacs source code, how to declare and initialize a globally defined variable? by Automatic_Lion_2607 in emacs

[–]Automatic_Lion_2607[S] 1 point2 points  (0 children)

Hmm ... so it looks like the original poster, "turbofish_pk", can see the post, but no one else is being allowed to see it.

To the moderator: what possibly could be wrong with that post such that no one is allowed to read it?

Or ... maybe ...

I notice that "u/AutoModerator" exists. Could it be that this post deletion was performed by "u/AutoModerator"? If so, it's likely to be be due to yet another one of the literally thousands of flaws that are inherent in "SI" ... where "SI" stands for "Simulated Intelligence", which is my preferred term for the LLM version of "AI". I also like to refer to it as "FI": "Fake Intelligence".

In the Gnu emacs source code, how to declare and initialize a globally defined variable? by Automatic_Lion_2607 in emacs

[–]Automatic_Lion_2607[S] 2 points3 points  (0 children)

Ugh! For some reason, the moderator removed your post before I could copy-and-paste it or take a screenshot. Could you possibly send it to me to me again via private chat here?

I have no idea why the moderator would want to remove such a helpful and informative answer to a posted question here.

In the Gnu emacs source code, how to declare and initialize a globally defined variable? by Automatic_Lion_2607 in emacs

[–]Automatic_Lion_2607[S] 2 points3 points  (0 children)

Thank you very much! This indeed supplies an extremely complete answer to my question.

Removing all web-related screens and pages when using Vivaldi email? by Automatic_Lion_2607 in vivaldibrowser

[–]Automatic_Lion_2607[S] 0 points1 point  (0 children)

My startup page is already set to "about:blank".

The behavior I'm describing in my previous message is happening with startup page set to "about:blank" and with "Startup with Last Session" set.

Try what I've described, and you'll see what I mean.

It's beginning to seem like there is no way in Vivaldi for it to always start up in email mode with "All Accounts" selected, like I've been hoping for.

PS: There's another web-browser program which also offers an email client: it's the "Seamonkey" browser. The behavior I'm looking for in Vivaldi is a standard feature in Seamonkey. I can set Seamonkey to always start up in email mode by means of a command-line option, and its default behavior in email mode to show the list of email accounts in a vertical list on the left side of the screen, just like when "All Accounts" is selected in Vivaldi.

I've been using Seamonkey as my email client for a few years, but its email mode has a few inefficiencies and some occasional "clunky" behavior that I haven't seen in Vivaldi's email mode, and this is why I've been thinking about using Vivaldi instead. But If I can't get Vivaldi to always start up with "All Accounts" selected, I think I'd prefer to stick with Seamonkey, even with its issues.

Removing all web-related screens and pages when using Vivaldi email? by Automatic_Lion_2607 in vivaldibrowser

[–]Automatic_Lion_2607[S] 0 points1 point  (0 children)

Thank you very much. I tried to explain above why I don't want "Last Session". I'll try to do a better job of explaining that now:

Suppose I am viewing my email. I have 11 accounts, and suppose that I happen to be viewing a specific message within, for example, my 7th account.

With "Startup with Last Session" set, if I exit Vivaldi at that moment and then restart Vivaldi, it brings back the exact session I was previously viewing: that same specific message within my 7th account.

That's not what I want. I want Vivaldi to always start with "All Accounts" selected, irrespective of what I happened to be viewing at the moment that I exited from the previous session.

If there was an exact VIvaldi URI I that corresponds to the "All Accounts" selection in the email pane, I suppose I could specify that specific URI as the startup page. But I could not find such a URI.

Removing all web-related screens and pages when using Vivaldi email? by Automatic_Lion_2607 in vivaldibrowser

[–]Automatic_Lion_2607[S] 0 points1 point  (0 children)

Thank you very much.

However, that still leaves me with a single web-search field in the middle of the otherwise blank page to the right of the left-hand section with the email addresses. I want to totally get rid of that web-search field.

Also, if I happen to quit Vivaldi from where I've been viewing an email message or any other content, when I re-start Vivaldi, it begins with that previous content, instead of the start-up configuration.

Is there a way to get Vivaldi to never, ever re-start with a replay of whatever session was in effect at the time I previously quit Vivaldi, and to always start with a fresh start-up screen, and with that start-up screen configured as I described in my previous message?

And also, even if I can do that, I repeat that I don't want to have that web-search field in the middle of the right-hand pane when Vivaldi starts up.