bug#72465: [PATCH 1/2] Document how set path to C source code for SUSE based systems

bug#72465: [PATCH 1/2] Document how set path to C source code for SUSE based systems

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

* etc/PROBLEMS(Problems when reading or debugging Emacs C code):
Document how to install Emacs C source and how to set path it for SUSE
based distributions such as openSUSE and SUSE Linux Enterprise.
---
 etc/PROBLEMS | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index c1ad8321fa6..ef205da2c17 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -456,6 +456,25 @@ However, the exact directory name will depend on the system, and you
 will need to both upgrade source and debug info when your system
 upgrades or patches Emacs, and change your startup file accordingly.
 
+** SUSE based distributions (openSUSE, SUSE Linux Enterprise)
+
+On systems with distributions, you can install source and debug info
+via superuser commands like the following:
+
+    # Install Emacs source and debuginfo by using --plus-content
+    zypper --plus-content debug,source install emacs-debuginfo emacs-debugsource
+
+To get describe-function and similar commands to work, you can then
+add something like the following to your startup file:
+
+    (setq find-function-C-source-directory
+          (car (file-expand-wildcards "/usr/src/debug/emacs-*/src")))
+
+The line above should work for all systems using zypper besides SUSE
+based ones, however it could be that you have to adjust the path to
+the sources slightly depending on the version of the distribution you
+have installed.
+
 ** Source and debuginfo for other systems
 
 If your system follows neither the Debian nor the Red Hat patterns,
-- 
2.45.2

bug#72465: [PATCH 1/2] Document how set path to C source code for SUSE based systems

[Eli Zaretskii]

> Date: Sun, 4 Aug 2024 16:09:36 +0300
> From:  Björn Bidar via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> * etc/PROBLEMS(Problems when reading or debugging Emacs C code):
> Document how to install Emacs C source and how to set path it for SUSE
> based distributions such as openSUSE and SUSE Linux Enterprise.
> ---
>  etc/PROBLEMS | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)

Thanks, I installed this on the emacs-30 branch, after some
reformatting and minor editing.

Please in the future try to conform to our conventions regarding
maximum line length in commit log messages, and other minor formatting
nits.

In addition, please don't submit patches of a series as separate
messages with separate and different Subject lines, because then the
bug tracker creates a separate bug report from each message you send.
Instead, attach them all as separate attachments to a single email
message and send it only once.  (And in general, we here prefer that
patches that constitute a single coherent changeset not be broken into
several patches, but instead submitted as a single patch: that makes
the review simpler.)

Thanks.

bug#72465: [PATCH 1/2] Document how set path to C source code for SUSE based systems

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 4 Aug 2024 16:09:36 +0300
>> From:  Björn Bidar via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> * etc/PROBLEMS(Problems when reading or debugging Emacs C code):
>> Document how to install Emacs C source and how to set path it for SUSE
>> based distributions such as openSUSE and SUSE Linux Enterprise.
>> ---
>>  etc/PROBLEMS | 19 +++++++++++++++++++
>>  1 file changed, 19 insertions(+)
>
> Thanks, I installed this on the emacs-30 branch, after some
> reformatting and minor editing.
>
> Please in the future try to conform to our conventions regarding
> maximum line length in commit log messages, and other minor formatting
> nits.

I had trouble keeping the change in line the the summary part of the
message.

Similar for the line length in the file itself. Now reading the file
again it seems obvious I will do better next time.

> In addition, please don't submit patches of a series as separate
> messages with separate and different Subject lines, because then the
> bug tracker creates a separate bug report from each message you send.
> Instead, attach them all as separate attachments to a single email
> message and send it only once.  (And in general, we here prefer that
> patches that constitute a single coherent changeset not be broken into
> several patches, but instead submitted as a single patch: that makes
> the review simpler.)

From my point of view using the patch as the email message directly
allows reviewing it inline much easier than a file where you can't
really do that. Plus reading the manual and etc/CONTRIBUTE was confusing
as they didn't say exactly the same. E.g. the manual didn't say anything
that you prefer git patches as attachment, which is uncommon from other
projects I know so far.

That I send three messages in a row like this was my lack oversight  on how
debbugs works which I should have known already.

As you can see I tried to follow the conventions.