| Commit message (Collapse) | Author | Age | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
Describe the newly added "prefer-osc7" option and clarify that procfs is
now also considered.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently weltschmerz prefers working directory information obtained
from OSC 7 to that from procfs. If a user has not configured their shell
to emit OSC 7 escapes, the OSC 7 path may be out of date. Additionally
some users want only their shell to change the terminal's conception of
working directory, which is a behaviour better matched by the procfs
based working directory detection.
This change allows OSC 7 based working directory detection to be turned
off. The default remains to check OSC 7 first and then fall back to
procfs if there is not valid local path set with OSC 7.
The reason for turning OSC 7 off entirely instead of inverting the order
procfs and OSC 7 are checked in is that procfs based detection should
never fail under normal usage on systems that support it.
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently the configuration object is located in the function level
scope of load_config() and deleted once the function exits. Any flags
that control the program behaviour must therefore be copied into
separate variables, which pollutes the the upper level namespace.
This change keeps the configuration object around after load_config()
exits and makes it accessible by other functions from the shared
namespace. An upcoming change needs this access.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Opening a terminal or file manager window requires weltschmerz to know
the current working directory. At the moment weltschmerz relies on the
application being run in the terminal to generate OSC 7 codes that
specify the path. However, OSC 7 is not yet widely supported by default,
and the VTE terminal emulation layer, which manages the OSC 7 path state
for weltschmerz, will overwrite local paths with ones that point to a
remote computer if an OSC 7 enabled application is run under ssh.
This change adds a fallback that uses the symlink to current working
directory located at /proc/<child pid>/cwd. On Linux this method should
always work and was how these features were implemented before adoption
of OSC 7. The procfs method is used as a fallback instead of the primary
method since it can only see the working directory changes of the direct
child process.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to alert the user to any potential errors in the configuration
files, we keep track of configuration entries that we have not accessed
and print them out. These might include misspellings or otherwise
malformed strings.
To collect those unparsed configuration entries, we remove the ones that
have been successfully parsed from our in-memory KeyFile. The remaining
keys are the offending ones. Unfortunately, because KeyFile.remove_key()
removes only one matching key, we might also be left with any duplicates
that would otherwise be valid entries.
So, if the entry misc.font is specified twice, we currently warn about
an "unknown" key, the second misc.font entry. This could potentially be
misleading to the user.
Since it is too expensive to fix this issue in the code, make sure we
warn instead about "unknown or duplicate" keys. This way we say the
correct thing without incurring a big complexity cost.
|
| |
|
|
|
|
|
|
| |
Both xgettext(1) and msgmerge(1) break messages by default. Since we
currently do not have particularly long strings marked for translation,
turn this particular behaviour off by passing --no-wrap. It would
otherwise lead to spurious breaks in the PO and POT files that are not
particularly nice.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We currently consider periods, commas, colons, semicolons, exclamation
points and question marks following a URL as part of it. While ending a
URL with these characters is technically speaking valid, more commonly
they are a result of people ending a clause with a URL. Let's ignore
such characters if they are present at the very end of a URL.
Make sure to still match them, however, if any non-punctuation
characters follow. This way, almost all actual usage of punctuation
within URLs is unaffected.
|
| |
|
|
|
| |
Describe the "Open with…" feature here as well and make sure to update
the sample configuration file with the new section.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This commit adds a new section, open-with, to the configuration file.
The options specified there will be added as "Open with …" menu items in
the URI context menu. This is to make it easier to perform other actions
on the URI than opening it in the system default browser; a user might
for example add another browser, media player, or a script that
preprocesses the URI before opening it.
|
| |
|
|
|
|
|
| |
Currently po/update-pot.sh assumes English strings and translator
comments cannot contain characters outside of ASCII, and throws an error
upon encountering any. Since we are actually using UTF-8 and not ASCII,
tell xgettext so.
|
| |
|
|
|
|
| |
The upcoming "Open with …" feature will need to spawn subprocesses in
very similar way as open_terminal(). Moving process creation to its own
function allows the same logic to be reused.
|
|
|
Currently weltschmerz has separate context menus for the two types of
URIs one can interact with, even though they contain the same option
with only a little different phrasing. This makes both use the same
context menu, and standardizes terminology to "URI".
This unification is in preparation for an upcoming "Open with …" feature
which will programmatically add items to context menu for URIs. Without
this, we would need to duplicate logic for each of the separate menus.
|
